Балансировка между несколькими NAT

[crank]

Есть два каталиста 3750, которые терминируют абонентов (IP Unnumebred). В ядре сети стоит циска 7604. Поставлена задача разбалансировать трафик между двумя серверами, выполняющими функции НАТа и шейпера.

 

Топология сети

 

На форуме нашел (тык), что красиво решить данную задачу можно с помощью SLB. Раньше с этим не сталкивался. Подскажите как всё это правильно приготовить.

Edited January 12, 2016 by crank

[crank]

Как я понял мне нужно настроить firewallfarms. Делаем

 

ip slb probe NAT1 ping
address 172.16.0.1
!
ip slb firewallfarm NAT_FARM
inservice
!
real 172.16.0.1
 probe NAT1
 inservice
!

 

На циске 7604 проверить в данный момент нет возможности. В эмуляторе GNS3 на c7200 пинги пошли, сервер определился как доступный, но вот клиентский трафик на него не отправляется, а маршрутизируется как обычно. По документации с сайта cisco весь трафик после такой настройки должен уходить на активные сервера не смотря на таблицу маршрутизации. Баг это, фича или может я что-то не так понял? Подскажите куда копать дальше.

[NiTr0]

как вариант - синхронизация таблиц коннтрака + ecmp.

[crank]

ecmp в данной случае, я так понимаю, раскидает по round-robin?

 

Еще думал над другими вариантами балансировки трафика

Раскидать абонентов по разным VRF. В одном VRF сделать наиболее приоритетным дефолт в сторону NAT1, в другом в сторону NAT2 соответственно.

Использовать PBR+SLA и вручную раскидать абонентов пополам.

С бордера на один каталист проанонсировать одну половину префиксов X.X.X.X/8, на другой каталист вторую половину соответственно.

 

Кто какие решение использует/посоветует?

Edited January 14, 2016 by crank

[ShyLion]

Доверить CEFу не вариант? Т.е. два дефолта с одинаковой метрикой. При большом количестве пар DST-SRC должно статистически 50/50 разложиться.

[tehmeh]

Там в теме по ссылке один благородный дон рассказывает о пертурбациях CEF-кэша при любом multipath'е, что приводит к перемещению потока на линк, на котором сервер ничего об этом потоке не знает.

То есть вариант годен только в случае с синхронизацией трансляций по всей ферме.

[ShyLion]

Там в теме по ссылке один благородный дон рассказывает о пертурбациях CEF-кэша при любом multipath'е, что приводит к перемещению потока на линк, на котором сервер ничего об этом потоке не знает.

То есть вариант годен только в случае с синхронизацией трансляций по всей ферме.

 

Дык CEF до NAT. После NAT соурсы у разных потоков будут разные и обратка прилетит в тот сервер, который и натил. Нечего там синхронизировать.

 

Или там прям на ходу CEF переобувается?

[nuclearcat]

Синхронизация трансляций убьет весь смыл балансировки. Во многих решениях с ростом количества трансляций - падает производительность.

Я просто разбиваю сети клиентов пополам или более и раскидываю по серверам. Иногда можно вычислить тяжелые ресурсы и выдать им отдельный нат, но тогда нужно как-то мониторить распределение нагрузки, будет semi-automatic, если есть нужные скрипты

[tehmeh]

Там в теме по ссылке один благородный дон рассказывает о пертурбациях CEF-кэша при любом multipath'е, что приводит к перемещению потока на линк, на котором сервер ничего об этом потоке не знает.

То есть вариант годен только в случае с синхронизацией трансляций по всей ферме.

 

Дык CEF до NAT. После NAT соурсы у разных потоков будут разные и обратка прилетит в тот сервер, который и натил. Нечего там синхронизировать.

 

Или там прям на ходу CEF переобувается?

Прям на ходу, именно поэтому серверы-соседи должны знать всё.

 

будет semi-automatic, если есть нужные скрипты

Дык вариантов вагон. Тема-то вообще про SLB.

[ShyLion]

Прям на ходу, именно поэтому серверы-соседи должны знать всё.

 

А как часто? Если там раз в день, то и хер бы с ним.

[tehmeh]

Прям на ходу, именно поэтому серверы-соседи должны знать всё.

 

А как часто? Если там раз в день, то и хер бы с ним.

Я сослался на пост, поэтому вряд ли поделюсь ценной информацией.

Но в рамках легитимного офтопа хотелось бы и самому уточнить - воды с тех пор не мало утекло, возможно есть и success story. Скоро и сами планируем с ASR на тазы выносить NAT.

[iValera]

Скоро и сами планируем с ASR на тазы выносить NAT.

Почему если не секрет, выросли объемы, а доходы не на столько сильно?)

[rdc]

проще всего это сделать с помощью LAG.

 

например, на длинке это настраивается так:

config link_aggregation algorithm ip_source_dest

исходящий трафик от хомячков аккуратно разольётся в разные наты, причём трафик на один и тот же хост всегда будет идти через один и тот же нат.

как на циске - не знаю, но по тому же принципу заработает так же.

[iValera]

проще всего это сделать с помощью LAG.

 

например, на длинке это настраивается так:

config link_aggregation algorithm ip_source_dest

исходящий трафик от хомячков аккуратно разольётся в разные наты, причём трафик на один и тот же хост всегда будет идти через один и тот же нат.

как на циске - не знаю, но по тому же принципу заработает так же.

А если NAT сервера разнесены по сегментам сети и не подключаются в 1 коммутатор?

[foxroot]

В качестве NAT используются сервера на базе Linux? если да то возможно на них просто поставить quagga и поднять OSPF между серверами и роутером. Через ospf проанонсить default gateway с одинаковой метрикой. в итоге на роутрер будет два маршрута 0.0.0.0/0. на интерфейс vlan (на которых строиться ospf) включите команды ip load-sharing per-packet. в итоге роутре будет балансировать пакеты между двумя гетвеями. если роутер juniper а не cisco то примените следующие

 

show routing-options

graceful-restart;

forwarding-table {

export per-flow-load-balancing;

}

show policy-options policy-statement per-flow-load-balancing

term balance {

then {

load-balance per-packet;

}

}

[iValera]

В качестве NAT используются сервера на базе Linux? если да то возможно на них просто поставить quagga и поднять OSPF между серверами и роутером. Через ospf проанонсить default gateway с одинаковой метрикой. в итоге на роутрер будет два маршрута 0.0.0.0/0. на интерфейс vlan (на которых строиться ospf) включите команды ip load-sharing per-packet. в итоге роутре будет балансировать пакеты между двумя гетвеями. если роутер juniper а не cisco то примените следующие

 

show routing-options

graceful-restart;

forwarding-table {

export per-flow-load-balancing;

}

show policy-options policy-statement per-flow-load-balancing

term balance {

then {

load-balance per-packet;

}

}

Обратите внимание на сообщение выше http://forum.nag.ru/forum/index.php?showtopic=112109&view=findpost&p=1227865