Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Правильно ли я понял, в итоге получается обычный ECMP.
Первый же сайт, типо одноклассников, который учитывает в сессии ip адрес, и тут же вы получите факап. в виде разъяренных пользователей, которые должны будут каждые N минут вводить логин и пароль.
B* 0.0.0.0/0 [20/0] via 60.0.0.2 (ISPB), 00:00:20
[20/0] via 50.0.0.2 (ISPA), 00:00:20
Первый же сайт, типо одноклассников, который учитывает в сессии ip адрес, и тут же вы получите факап. в виде разъяренных пользователей, которые должны будут каждые N минут вводить логин и пароль.
Скорее работает как обычный PAT, только в пуле неупорядоченные адреса из некоторого диапазона.
Часто разъяренные пользователи приходят ругаться на обычный PAT?
Часто разъяренные пользователи приходят ругаться на обычный PAT?
на PAT, конечно же нет, но я говорю о другом нюансе.
мой хост 192.168.0.100/24 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100->60.0.0.1))->Хост назначения(8.8.8.8)
хост 8.8.8.8 с учётом моего IP адреса создал cookie.
вопрос в следующем, если я через некоторое время (но меньшее жизни куки), обращусь к хосту 8.8.8.8, каков шанс, что мой трафик уйдёт с адрес 60.0.0.1, а не 50.0.0.1??
мой хост 192.168.0.100/24 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100->60.0.0.1))->Хост назначения(8.8.8.8)
хост 8.8.8.8 с учётом моего IP адреса создал cookie.
вопрос в следующем, если я через некоторое время (но меньшее жизни куки), обращусь к хосту 8.8.8.8, каков шанс, что мой трафик уйдёт с адрес 60.0.0.1, а не 50.0.0.1??
ну, официальный гайд говорит следующее о TCP сессиях:
Но давайте предположим что провайдер выдал сетку вам 50.0.0.0/29,
и вы настроили PAT на все доступные вам адреса 50.0.0.2 — 50.0.0.6,
тот же эффект что и при дуал нате.
When port translation is configured .. .. TCP translations time out after 24 hours, unless a RST or FIN is seen on the stream, in which case it times out in 1 minute.
Но давайте предположим что провайдер выдал сетку вам 50.0.0.0/29,
и вы настроили PAT на все доступные вам адреса 50.0.0.2 — 50.0.0.6,
тот же эффект что и при дуал нате.
=))) вы же понимаете, к чему я виду =)
давайте по другому
1) запрос
мой хост 192.168.0.100:45555 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:45555->60.0.0.1:45555))->Хост назначения(8.8.8.8:80)
2) запрос ajax или полученеи картинок и т.п.д
мой хост 192.168.0.100:41111 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:41111->???.???.???.???:41111))->Хост назначения(8.8.8.8:80)
в итоге получим два соединения, и не факт что, второе выйдет с адреса 60.0.0.1
давайте по другому
1) запрос
мой хост 192.168.0.100:45555 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:45555->60.0.0.1:45555))->Хост назначения(8.8.8.8:80)
2) запрос ajax или полученеи картинок и т.п.д
мой хост 192.168.0.100:41111 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:41111->???.???.???.???:41111))->Хост назначения(8.8.8.8:80)
в итоге получим два соединения, и не факт что, второе выйдет с адреса 60.0.0.1
я не уверен как работает в таких случаях дуал НАТ, но уверен так же как и классика
а тут нат не при делах будет, вначале отработает маршрутизация и выберется один из исходящих интерфесов, а потом уже применется соответствующий нат. В отличии от случая с сеткой /29 на одном интерфейсе, тут да, будут помниться нат трансляции и всё будет ок
Сделал тесты, я не знаю почему но он всегда выпускает клиента с тем же IP адресом для определенного source, если пакет приходит снаружи клиентского интерфейса. С самого роутера идет шафл.
Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
Тестировалось на следующем софте:
7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
Тестировалось на следующем софте:
7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
сделаю тесты напишу вам здесь
ну даже если в этом месте может возникнуть проблема, мы можем всегда включить тюнинг ecmp на cisco
через per-destination а не per-packet
через per-destination а не per-packet
Сделал тесты, я не знаю почему но он всегда выпускает клиента с тем же IP адресом для определенного source, если пакет приходит снаружи клиентского интерфейса. С самого роутера идет шафл.
Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
Тестировалось на следующем софте:
7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
Не могу объяснить почему. По логике ECMP действительно должен был произойти шафл, но он происходит только с разными source IP. Может быть по дефолту на тестовой системе стоит ecmp per destination. Это единственное объяснение которое у меня пока есть. Так что все ок.
Тестировалось на следующем софте:
7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2)
нашел объяснение в ecmp хеше, дописал объяснение в конец статьи, спасибо вам за замечание
я бы всё таки добавил, что необходимо включить cef.
так как в RFC по ecmp явным образом не сказано учитывается ли порты src и dst при расчёте хеша
ip cef distributed
так как в RFC по ecmp явным образом не сказано учитывается ли порты src и dst при расчёте хеша
Вы одно слово в заголовке забыли написать — название вендора. «Балансировка траффика между двумя NAT на разных провайдерах на одном физическом роутере _Cisco_». Потому что название в том виде, как есть, выглядит обещанием статьи с теорией балансировки, а на практике начинается с места в карьер прямо с варианта с vrf. Так что как быстрый howto — неплохо (хотя впервые в публичном howto вижу балансировку с, ни много ни мало, BGP внутри роутера для балансировки!), но это все равно очень cisco-only.
А что с определением живости интернета через конкретных аплинков? У вас прописана логика загрузки обоих каналов, но что делать, если один из них упадет?
P.S. Кстати, навскидку не скажу, но, если аплинки не в виде интерфейсов со статическими IP, а в виде, скажем, pppoe- или l2tp-соединений (а сегодня все больше провайдеров стараются сделать именно так, ибо для них так удобнее; шлюзы по умолчанию в этом случае могут, скажем, меняться от «дозвона» к дозвону), там, вроде бы, могут быть «моменты» в настройке.
А что с определением живости интернета через конкретных аплинков? У вас прописана логика загрузки обоих каналов, но что делать, если один из них упадет?
P.S. Кстати, навскидку не скажу, но, если аплинки не в виде интерфейсов со статическими IP, а в виде, скажем, pppoe- или l2tp-соединений (а сегодня все больше провайдеров стараются сделать именно так, ибо для них так удобнее; шлюзы по умолчанию в этом случае могут, скажем, меняться от «дозвона» к дозвону), там, вроде бы, могут быть «моменты» в настройке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Балансировка траффика между двумя NAT на разных провайдерах на одном физическом роутере cisco