Два своих офиса соединены двумя каналами.
Задача:
1. Трафик, маркированный tos=1 отправлять в канал 1.
2. Остальной трафик отправлять в канал 2.
3. Когда какой-то канал падает, трафик уходит в другой канал.Видится вариант (и он описан в примерах): использовать route-map и IP SLA.
Но так как офис свой, то доступны и другие механизмы, в частности доступны протоколы маршрутизации.Поэтому есть еще варианты, кроме SLA?
Чем надежнее и проще, тем лучше.
> Но так как офис свой, то доступны и другие механизмы, в частности
> доступны протоколы маршрутизации.Какие железки???
На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, в роутинге для этих сетей сделал офсссеты.
Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но там какое-то взрослое железо было.
>> Но так как офис свой, то доступны и другие механизмы, в частности
>> доступны протоколы маршрутизации.
> Какие железки???
> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
> в роутинге для этих сетей сделал офсссеты.
> Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но
> там какое-то взрослое железо было.3945 в центре, в офисах 3925 и 2921.
>> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
>> в роутинге для этих сетей сделал офсссеты.А, если возможно, можно чуть подробнее про этот механизм?
>>> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
>>> в роутинге для этих сетей сделал офсссеты.
> А, если возможно, можно чуть подробнее про этот механизм?Мы используем в КВС EIGRP.
Есть допустим два канала параллельно между двумя роутерами.
Tun1 для реалтайма и Tun2 для всего остального.
interface Tun1
bandwidth 2000
delay 350
!
interface Tun2
bandwidth 2000
delay 300В такой ситуации весь траффик бы шел через Tun2, т.к. у него delay меньше, но:
router eigrp 1
offset-list REALTIME out 100000 Tun2
!
ip access-list standard REALTIME
permit 10.10.10.0
permit 10.10.20.0
permit 10.20.30.0 0.0.0.255К сетям, попадающим в акес-лист, при экспорте маршрутов через Tun2 метрика увеличивается на 100000. Таким образом удаленный роутер считает что этот маршрут менее приоритетный для этих сетей. И в эти сети устанавливает маршрут через Tun1. Когда что-то падает, то других вариантов кроме единственного интерфейса у роутера нет.
Цифа оффсета подбирается такой, чтобы вычисленная разница метрик обоих интерфейсов была меньше. Короче опытным путем можно найти. Эти цифры взяты с рабочего конфига.
С обратной стороны есесно похожий конфиг.
> 3945 в центре, в офисах 3925 и 2921.У нас почти такое-же.
>> Но так как офис свой, то доступны и другие механизмы, в частности
>> доступны протоколы маршрутизации.
> Какие железки???
> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
> в роутинге для этих сетей сделал офсссеты.
> Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но
> там какое-то взрослое железо было.Подумалось, а будет работать такой механизм?
Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF.
"Привязываем" каждый экземпляр OSPF к разным каналам.
Так что пока есть канал путь прописан через него. С помощью приоритетов интерфейсов?
Падает канал, только тогда ospf прокладывает маршрут через другой канал.
Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
В один экземпляр ospf, тот route-map, где tos=1
В другой экземпляр ospf, тот route-map, где tos=0Будет работать?
>[оверквотинг удален]
> Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF.
> "Привязываем" каждый экземпляр OSPF к разным каналам.
> Так что пока есть канал путь прописан через него. С помощью приоритетов
> интерфейсов?
> Падает канал, только тогда ospf прокладывает маршрут через другой канал.
> Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
> В один экземпляр ospf, тот route-map, где tos=1
> В другой экземпляр ospf, тот route-map, где tos=0
> Будет работать?Как ты интересно будешь делать редистрибьюцию по TOS ?
>[оверквотинг удален]
>> "Привязываем" каждый экземпляр OSPF к разным каналам.
>> Так что пока есть канал путь прописан через него. С помощью приоритетов
>> интерфейсов?
>> Падает канал, только тогда ospf прокладывает маршрут через другой канал.
>> Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
>> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
>> В один экземпляр ospf, тот route-map, где tos=1
>> В другой экземпляр ospf, тот route-map, где tos=0
>> Будет работать?
> Как ты интересно будешь делать редистрибьюцию по TOS ?А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
Не все route-map-ы съест?
Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?
> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
> Не все route-map-ы съест?
> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?3 версия не об этом.
> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?Где ты это вообще увидел?
В сиське роут-мапы только так называются, на деле могут использоваться для совершенно разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS просто проигнорируют или вообще не заматчат.> Не все route-map-ы съест?
> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?OSPFv3 это IPv6 расширение предыдущего варианта.
>> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
> Где ты это вообще увидел?
> В сиське роут-мапы только так называются, на деле могут использоваться для совершенно
> разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS
> просто проигнорируют или вообще не заматчат.
>> Не все route-map-ы съест?
>> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?Да, видимо такая конструкция не заработает в принципе.
Чтобы попасть в route-map пакет должен пройти, и записаться маршрут в ospf. Но пакет идет из центра на узел. А передается маршрут на узел.Может быть как вариант передавать из route-map не сам маршрут, а метрику?
В разные ospf-ы с разными метриками?Впрочем, времени, к сожалению, мало. Буду пробовать через SLA.
Спасибо большое за идеи и обсуждение!
>[оверквотинг удален]
>> "Привязываем" каждый экземпляр OSPF к разным каналам.
>> Так что пока есть канал путь прописан через него. С помощью приоритетов
>> интерфейсов?
>> Падает канал, только тогда ospf прокладывает маршрут через другой канал.
>> Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
>> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
>> В один экземпляр ospf, тот route-map, где tos=1
>> В другой экземпляр ospf, тот route-map, где tos=0
>> Будет работать?
> Как ты интересно будешь делать редистрибьюцию по TOS ?Не по TOS. А в зависимости от TOS обычный маршрут передавать в тот или другой процесс ospf.
Маршрут будет или в одном или в другом процессе ospf.
А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное для себя прохождение тарфка по каналам.
> Не по TOS. А в зависимости от TOS обычный маршрут передавать в
> тот или другой процесс ospf.
> Маршрут будет или в одном или в другом процессе ospf.
> А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное
> для себя прохождение тарфка по каналам.Ты похоже вообще не понимешь о чем говоришь.
Протоколы маршрутизации манипулируют таблицей маршрутизации _роутера_, которая у него _в дефолтном варианте_ ОДНА. Роутеру абсолютно фиолетово, каким протоколом маршрутизации добавлен тот или иной маршрут в его таблицу, для роутера есть лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние каналов.
Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы.
Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном VRF приземлить на роутере и там иметь другие метрики.
>[оверквотинг удален]
> добавлен тот или иной маршрут в его таблицу, для роутера есть
> лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать
> только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу
> маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние
> каналов.
> Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в
> зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь
> несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы.
> Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном
> VRF приземлить на роутере и там иметь другие метрики.Знаний и опыта мало, не спорю.
Таблица маршрутизации одна, но один и тот же маршрут можно прописать много раз с разными метриками. Источник может быть различным, например прописать статику с метрикой 254.
Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут, то автоматически в таблице маршрутизации появится статический маршрут.
>>[оверквотинг удален]
> Знаний и опыта мало, не спорю.
> Таблица маршрутизации одна, но один и тот же маршрут можно прописать много
> раз с разными метриками. Источник может быть различным, например прописать статику
> с метрикой 254.
> Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут,
> то автоматически в таблице маршрутизации появится статический маршрут.Точно. Только TOS тут в выборе никак не участвует.
>>>[оверквотинг удален]
>> Знаний и опыта мало, не спорю.
>> Таблица маршрутизации одна, но один и тот же маршрут можно прописать много
>> раз с разными метриками. Источник может быть различным, например прописать статику
>> с метрикой 254.
>> Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут,
>> то автоматически в таблице маршрутизации появится статический маршрут.
> Точно. Только TOS тут в выборе никак не участвует.Одну схему сообразил:
в каждом узле ставится два маршрутизатора (у нас так и задумано, для резервирования).
условно назовем: "основной" (1) маршрутизатор и "резервный" (2) маршрутизатор.
к каждому маршрутизатору цепляется один канал: к основному маршрутизатору основной канал, в резервному маршрутизатору - резервный.
Между маршрутизаторами отдельный линк. Т.е. у каждого маршрутизатора три линка: внутрь, откуда приходит трафик, наружный (на канал) и между собой.На каждом маршрутизаторе поднимается eigrp c привязкой к каналу. Т.е. всего два узла в каждом eigrp задейтствовано. Если падает канал, то маршруты eigrp пропадают (проверено на практике на другой схеме). Прописывается статический маршрут на соседний маршрутизатор с большей метрикой, чем маршрут eigrp, например 254.
На каждый машрутизатор вешается политика, что если пакет приходит из межлинкового интерфейса, то он просто кидается в канал.И перед этими маршрутизаторами ставится еще один маршрутизатор "распределения"? Может можно его избежать?
И так, как идет трафик:
пакет попадает в маршрутизатор распределения. На нем route-map c tosами на разные каналы.
C конструкцией next-hop на основной или резервный маршрутизатор.
Попадая в маршрутизатор трафик уходит по eigrp по нужному каналу. Если падает канал, то исчезает маршрут в eigrp и трафик уходит в соседний маршрутизатор по межлинковому соединению. Там еще один route-map, привязанный к межлинковому интерфейсу, к котором next-hop просто свой канал.
Т.е. маршрутизатор "понимает", что если трафик пришел от соседа, то там канала нет, значит просто пуляй в свой канал, ничего не остается.
Проблемы две:
1. Можно ли избежать маршрутизатора "распределения".
И вторая проблема, в наших условиях более важная:
у нас один канал не точка-точка, а составной, причем в промежутке стоит оборудование (Alcatel) не поддерживаеющее eigrp, а поддерживает is-is и ospf.
Соответсвенно если падает канал, маршрут в резервном маршрутизаторе не исчезнет, останется на этот Алкатель.Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое решение в условиях когда все каналы и оборудование свое).
Или как?
Может можно как-то настроить ospf, что если два соседа теряют связь, то ospf "разваливается" (удаляет свои маршруты) во всех узлах?
> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое
> решение в условиях когда все каналы и оборудование свое).У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения межсайтовые. никаких особых проблем нет.
>> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое
>> решение в условиях когда все каналы и оборудование свое).
> У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения
> межсайтовые. никаких особых проблем нет.Я понимаю, что решение с туннелями есть.
с MTU несколько выше накладные расходы. Я понимаю, что скорости сейчас большие.
с MTU возможны проблемы у приложений из-за невозможности согласования. Я понимаю, что если правильно mtu настроить на интерфейсах, то проблем быть не должно.
Но хочется красивого, элегантного решения, оборудование-то своё.Возвращаясь к схеме с протоколом маршрутизации.
Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ маршрутизации.
Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать, у меня все-равно тупик.
А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него хорошо бы избавиться или зарезервировать в горячем режиме.
> Возвращаясь к схеме с протоколом маршрутизации.
> Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае
> когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ
> маршрутизации.
> Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через
> канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать,
> у меня все-равно тупик.
> А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.
> Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него
> хорошо бы избавиться или зарезервировать в горячем режиме.От маршрутизатора "распределения" красиво избавиться можно так:
1. По протоколу hsrp весь трафик поступает на одну из Цисок, пусть "основную".
2. Весь трафик у нас распределен всего по двум каналам (больше каналов нет), поэтому трафик по tos-aм резервного канала направляем через конструкцию "route-map, set next-hop" на резервный маршрутизатор (через внутренний интерфейс!). Все остальные tos-ы никуда не отправляем! Они остаются на "основном" маршрутизаторе, они для него и предназначены, т.е. просто пропускаем через маршрутизатор дальше.
Возможно придется отключить icmp redirect.
3. А дальше выстраиваем ospf-ы как описано ранее. Цепочкой. Полагая, что если канал упадет, то маршрутизатор по ospf-у передаст это низлежащему маршрутизатору и тот уберет ospf-ный маршрут из своей таблицы маршрутизации.Остается проверить этот механизм на стенде.
И возможно решить такую проблему как резервирование: отказ любого провода/порта/платы/устройства не должен приводить к потере трафика.
>> Возвращаясь к схеме с протоколом маршрутизации.
>> Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае
>> когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ
>> маршрутизации.
>> Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через
>> канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать,
>> у меня все-равно тупик.
>> А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.
>> Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него
>> хорошо бы избавиться или зарезервировать в горячем режиме.Работает конструкция на стенде!
Маршрут в низлежащем маршрутизаторе пропадает.Более того, пока не проверял, но может быть возможно отказаться от политики на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в основном и резервном маршрутизаторе разные).
А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip redirect).
Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не умрет по TTL(?)?
Поди ничего страшного, что думаете?
> Поди ничего страшного, что думаете?честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это все добро - рехнешься.
самое простое и правильное - выделить воип в отдельные сегменты. правда слабо применительно если софтфоны в большом ходу.
>> Поди ничего страшного, что думаете?
> честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это
> все добро - рехнешься.
> самое простое и правильное - выделить воип в отдельные сегменты. правда слабо
> применительно если софтфоны в большом ходу.ospf в каждом маршрутизаторе и несколько строчек (число удаленных сетей) статики с метрикой 254, один route-map с tos-ами или сетями (на любой вкус). Вроде всё.
Если дело выгорит, конфигурацию опубликую, люди сами оценят что сложнее.
> Более того, пока не проверял, но может быть возможно отказаться от политики
> на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в
> основном и резервном маршрутизаторе разные).
> А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным
> и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip
> redirect).
> Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не
> умрет по TTL(?)?
> Поди ничего страшного, что думаете?Похоже линк между маршрутизаторами нужен.
На внутреннем висит route-map с tos-ами, на линке между маршрутизаторами нет никакого.
http://trace.twnic.net.tw/rtraining/routings.pdf
Читай
> http://trace.twnic.net.tw/rtraining/routings.pdf
> Читайhttp://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configu...
Короче, ключевое слово Cisco MTR.
Правда поддерживается это все добро на операторском классе железа.
>> http://trace.twnic.net.tw/rtraining/routings.pdf
>> Читай
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configu...
> Короче, ключевое слово Cisco MTR.
> Правда поддерживается это все добро на операторском классе железа.Интересно. Не встречал этот MTR.
>>> http://trace.twnic.net.tw/rtraining/routings.pdf
>>> Читай
>> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configu...
>> Короче, ключевое слово Cisco MTR.
>> Правда поддерживается это все добро на операторском классе железа.
> Интересно. Не встречал этот MTR.Ну вот на ASR 1000 серии, команды такие поддерживаются, правда дальше не конфигурил.