Как VRRP увязать с протоколами маршрутизации?

Jun 05, 2014 11:36

Пытаюсь понять, как выходит трафик из ядра в направлении HSRP/VRRP группы.
Вот простейшая схема (найденная на просторах сети):

Read more... )

Leave a comment

Comments 31

vpluto June 5 2014, 09:41:37 UTC
Не очень понятно, зачем - симметричная маршрутизация нужна только в случае кривых МСЭ или жестких uPRF.
Но в принципе можно балансировать метрикой используемого там протокола динамической маршрутизации. Сеть 10.16.128.0 каким-то образом анонсируется ведь в сторону S50-4.

Reply

hazan June 5 2014, 09:52:04 UTC
Нет задачи делать балансировку - надо обеспечить резервирование сети. Фактически вся сеть - как на картинке, только свитчей типа S50-1 - несколько десятков. И нужно резервировать линки от свитчей до маршрутизатора и сами маршрутизаторы в ядре. Проблема может быть в том, что линки от свитчей к маршрутизаторам могут идти через активное оборудование, так что физический обрыв линка не может быть использован как сигнал для пересчета маршрутизации в ядре - исходящие из ядра пакеты будут какое-то время продолжать идти в никуда.

Оборудование по краям сети - совсем тупое, можно сконфигурить только один default gateway.

Reply

vpluto June 5 2014, 09:54:48 UTC
Где-то проблема в дизайне.
Резервировать линки можно только в контролируемой среде. В противном случае ни один супер-пупер протокол не поможет - если железка видит порт в апе и не знает, что через него трафик не пойдет - она будет в него посылать фреймы.
Использовать протоколы динамической маршрутизации, использовать ip sla, чтобы класть физику с маршрутизаторов, строить резервные линки с MST между коммутаторами.

Reply

hazan June 5 2014, 10:12:10 UTC
Ок, не будем рассматривать случай когда физика падает, пусть будет в точности как на картинке.
Есть теоретическая возможность свести TX и RX потоки в ядре на один линк при каждой смене VRRP/HSRP мастера?

Reply


jrmm June 5 2014, 09:44:25 UTC
зачем тем же путём? балансировки же не будет

Reply

hazan June 5 2014, 09:53:13 UTC
Нужно обеспечить резервирование, а не балансировку.
Если нет связи с S50-1, но интерфейс активен - как ядро определит, что туда не надо слать пакеты?

Reply

jrmm June 5 2014, 10:41:12 UTC
а что именно "нет связи"? например, будет ли отрабатывать ARP на этом участке?

Reply


oldboyscout June 5 2014, 09:57:59 UTC
Чтобы трафик проходил обязательно через один маршрутизатор от клиента дальше в обе стороны)
нужен любой IGP (OSPF например) с соответствующими метриками между S50-2,3,5 + track vrrp для интерфейса на S50-4 (в некоторых маршрутизаторах можно трекать маршрут в таблице а не интерфейс, тоже может быть удобно, если много сетей)
Отвечая коментаторам выше - зачем - затем, что если вы этого не сделаете, то в такой схеме у вас будет блэкхол при обрыве линка на s50-4 c активным VVRP
Если в схему добавить L3 линк между S50-2 и S50-3 с тем же OSPF, эта проблема уходит, и тогда действительно возможно будет излишне заморачиваться с VRRP треком

Reply

hazan June 5 2014, 10:24:00 UTC
Совсем забыл про трек в VRRP группах - спасибо, напомнили комментом выше.

Reply


yva June 5 2014, 11:29:42 UTC
Смотреть надо шире - при чём тут вообще VRRP? Для S50-4 вообще не важно, объединены ли S50-2 и S50-3 в массив VRRP (ну или там HSRP), или это просто альтернативные маршруты для резервирования. Соответственно, и решать эту задачу надо стандартными средствами. Например, использовать протоколы маршрутизации, или настраивать IP SLA на S50-4.

Reply

hazan June 5 2014, 13:37:53 UTC
Задача - TX и RX потоки из ядра сети должны идти через один маршрутизатор на границе.

Reply


lastsky June 5 2014, 20:24:09 UTC
только привязать трекинг к vrrp группе, аннонсировать сеть с активного роутера с большей метрикой, чем с резервного. vrrp же имеет виртуальный mac - трафик пойдет в направлении к девайсу по большей метрике, от девайса - к активному спикеру.

согласен, что это попытка собрать koenigsegg из деталей для запорожца, но в принципе возможно.

насколько тупые девайсы? можно сделать две разные подсетки, а на девайсах secondary. тогда они всегда доступны по разным адресам (с разных адресов, написанных статиками на девайсе, ну, если конечно, статики и secondary поддерживаются)

Reply

hazan June 6 2014, 07:13:49 UTC
Dell - это только для иллюстрации, из интернета.
Свитчи - Westermo Lynx L210, которые, как выяснилось, умеют трекинг делать только следя за состоянием собственного протокола внутри своего кольца.
В самом ядре - Cisco IE3010, софт которой поддерживает очень избирательно функционал свитчей и маршрутизаторов.
Железки по краям - всякие промышленные контроллеры.

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

Reply

lastsky June 6 2014, 10:45:26 UTC
не припоминаю по своему опыту никаких проблем с таймерами stp, а с interoperability в сети на разновендорнорном оборудовании на много граблей наступал.

Reply


Leave a comment

Up