Не очень понятно, зачем - симметричная маршрутизация нужна только в случае кривых МСЭ или жестких uPRF. Но в принципе можно балансировать метрикой используемого там протокола динамической маршрутизации. Сеть 10.16.128.0 каким-то образом анонсируется ведь в сторону S50-4.
Нет задачи делать балансировку - надо обеспечить резервирование сети. Фактически вся сеть - как на картинке, только свитчей типа S50-1 - несколько десятков. И нужно резервировать линки от свитчей до маршрутизатора и сами маршрутизаторы в ядре. Проблема может быть в том, что линки от свитчей к маршрутизаторам могут идти через активное оборудование, так что физический обрыв линка не может быть использован как сигнал для пересчета маршрутизации в ядре - исходящие из ядра пакеты будут какое-то время продолжать идти в никуда.
Оборудование по краям сети - совсем тупое, можно сконфигурить только один default gateway.
Где-то проблема в дизайне. Резервировать линки можно только в контролируемой среде. В противном случае ни один супер-пупер протокол не поможет - если железка видит порт в апе и не знает, что через него трафик не пойдет - она будет в него посылать фреймы. Использовать протоколы динамической маршрутизации, использовать ip sla, чтобы класть физику с маршрутизаторов, строить резервные линки с MST между коммутаторами.
Ок, не будем рассматривать случай когда физика падает, пусть будет в точности как на картинке. Есть теоретическая возможность свести TX и RX потоки в ядре на один линк при каждой смене VRRP/HSRP мастера?
Чтобы трафик проходил обязательно через один маршрутизатор от клиента дальше в обе стороны) нужен любой IGP (OSPF например) с соответствующими метриками между S50-2,3,5 + track vrrp для интерфейса на S50-4 (в некоторых маршрутизаторах можно трекать маршрут в таблице а не интерфейс, тоже может быть удобно, если много сетей) Отвечая коментаторам выше - зачем - затем, что если вы этого не сделаете, то в такой схеме у вас будет блэкхол при обрыве линка на s50-4 c активным VVRP Если в схему добавить L3 линк между S50-2 и S50-3 с тем же OSPF, эта проблема уходит, и тогда действительно возможно будет излишне заморачиваться с VRRP треком
Смотреть надо шире - при чём тут вообще VRRP? Для S50-4 вообще не важно, объединены ли S50-2 и S50-3 в массив VRRP (ну или там HSRP), или это просто альтернативные маршруты для резервирования. Соответственно, и решать эту задачу надо стандартными средствами. Например, использовать протоколы маршрутизации, или настраивать IP SLA на S50-4.
только привязать трекинг к vrrp группе, аннонсировать сеть с активного роутера с большей метрикой, чем с резервного. vrrp же имеет виртуальный mac - трафик пойдет в направлении к девайсу по большей метрике, от девайса - к активному спикеру.
согласен, что это попытка собрать koenigsegg из деталей для запорожца, но в принципе возможно.
насколько тупые девайсы? можно сделать две разные подсетки, а на девайсах secondary. тогда они всегда доступны по разным адресам (с разных адресов, написанных статиками на девайсе, ну, если конечно, статики и secondary поддерживаются)
Dell - это только для иллюстрации, из интернета. Свитчи - Westermo Lynx L210, которые, как выяснилось, умеют трекинг делать только следя за состоянием собственного протокола внутри своего кольца. В самом ядре - Cisco IE3010, софт которой поддерживает очень избирательно функционал свитчей и маршрутизаторов. Железки по краям - всякие промышленные контроллеры.
Пока всё более-менее работает по STP, где обрыв линка оказывает малое влияние на трафик, а вот восстановление топологии - существенно больше. Похоже придётся страдать с таймерами.
не припоминаю по своему опыту никаких проблем с таймерами stp, а с interoperability в сети на разновендорнорном оборудовании на много граблей наступал.
Comments 31
Но в принципе можно балансировать метрикой используемого там протокола динамической маршрутизации. Сеть 10.16.128.0 каким-то образом анонсируется ведь в сторону S50-4.
Reply
Оборудование по краям сети - совсем тупое, можно сконфигурить только один default gateway.
Reply
Резервировать линки можно только в контролируемой среде. В противном случае ни один супер-пупер протокол не поможет - если железка видит порт в апе и не знает, что через него трафик не пойдет - она будет в него посылать фреймы.
Использовать протоколы динамической маршрутизации, использовать ip sla, чтобы класть физику с маршрутизаторов, строить резервные линки с MST между коммутаторами.
Reply
Есть теоретическая возможность свести TX и RX потоки в ядре на один линк при каждой смене VRRP/HSRP мастера?
Reply
Reply
Если нет связи с S50-1, но интерфейс активен - как ядро определит, что туда не надо слать пакеты?
Reply
Reply
нужен любой IGP (OSPF например) с соответствующими метриками между S50-2,3,5 + track vrrp для интерфейса на S50-4 (в некоторых маршрутизаторах можно трекать маршрут в таблице а не интерфейс, тоже может быть удобно, если много сетей)
Отвечая коментаторам выше - зачем - затем, что если вы этого не сделаете, то в такой схеме у вас будет блэкхол при обрыве линка на s50-4 c активным VVRP
Если в схему добавить L3 линк между S50-2 и S50-3 с тем же OSPF, эта проблема уходит, и тогда действительно возможно будет излишне заморачиваться с VRRP треком
Reply
Reply
Reply
Reply
согласен, что это попытка собрать koenigsegg из деталей для запорожца, но в принципе возможно.
насколько тупые девайсы? можно сделать две разные подсетки, а на девайсах secondary. тогда они всегда доступны по разным адресам (с разных адресов, написанных статиками на девайсе, ну, если конечно, статики и secondary поддерживаются)
Reply
Свитчи - Westermo Lynx L210, которые, как выяснилось, умеют трекинг делать только следя за состоянием собственного протокола внутри своего кольца.
В самом ядре - Cisco IE3010, софт которой поддерживает очень избирательно функционал свитчей и маршрутизаторов.
Железки по краям - всякие промышленные контроллеры.
Пока всё более-менее работает по STP, где обрыв линка оказывает малое влияние на трафик, а вот восстановление топологии - существенно больше. Похоже придётся страдать с таймерами.
Reply
Reply
Leave a comment