forum.opennet.ru - "два одновременно работающих (по tos) канала между офисами" (27)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"два одновременно работающих (по tos) канала между офисами"

Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"два одновременно работающих (по tos) канала между офисами"	+/–
Сообщение от tvy (ok) on 23-Ноя-14, 16:15
Два своих офиса соединены двумя каналами. Задача: 1. Трафик, маркированный tos=1 отправлять в канал 1. 2. Остальной трафик отправлять в канал 2. 3. Когда какой-то канал падает, трафик уходит в другой канал. Видится вариант (и он описан в примерах): использовать route-map и IP SLA. Но так как офис свой, то доступны и другие механизмы, в частности доступны протоколы маршрутизации. Поэтому есть еще варианты, кроме SLA? Чем надежнее и проще, тем лучше.
Ответить \| Правка \| Cообщить модератору

Оглавление

два одновременно работающих (по tos) канала между офисами, ShyLion, 16:26 , 23-Ноя-14, (1)

два одновременно работающих (по tos) канала между офисами, tvy, 16:33 , 23-Ноя-14, (2)

два одновременно работающих (по tos) канала между офисами, tvy, 16:47 , 23-Ноя-14, (3)

два одновременно работающих (по tos) канала между офисами, ShyLion, 06:19 , 24-Ноя-14, (7)

два одновременно работающих (по tos) канала между офисами, ShyLion, 06:06 , 24-Ноя-14, (6)

два одновременно работающих (по tos) канала между офисами, tvy, 18:57 , 23-Ноя-14, (4)

два одновременно работающих (по tos) канала между офисами, ShyLion, 06:06 , 24-Ноя-14, (5)

два одновременно работающих (по tos) канала между офисами, tvy, 11:14 , 24-Ноя-14, (8)

два одновременно работающих (по tos) канала между офисами, tvy, 11:19 , 24-Ноя-14, (9)
два одновременно работающих (по tos) канала между офисами, ShyLion, 11:19 , 24-Ноя-14, (10)

два одновременно работающих (по tos) канала между офисами, tvy, 13:51 , 24-Ноя-14, (12)

два одновременно работающих (по tos) канала между офисами, tvy, 12:12 , 24-Ноя-14, (11)

два одновременно работающих (по tos) канала между офисами, ShyLion, 15:05 , 24-Ноя-14, (13)

два одновременно работающих (по tos) канала между офисами, tvy, 19:10 , 24-Ноя-14, (14)

два одновременно работающих (по tos) канала между офисами, ShyLion, 07:01 , 25-Ноя-14, (15)

два одновременно работающих (по tos) канала между офисами, tvy, 15:14 , 25-Ноя-14, (18)

два одновременно работающих (по tos) канала между офисами, ShyLion, 15:49 , 25-Ноя-14, (19)

два одновременно работающих (по tos) канала между офисами, tvy, 16:40 , 25-Ноя-14, (20)

два одновременно работающих (по tos) канала между офисами, tvy, 18:14 , 25-Ноя-14, (22)

два одновременно работающих (по tos) канала между офисами, tvy, 11:27 , 26-Ноя-14, (23)
два одновременно работающих (по tos) канала между офисами, ShyLion, 13:00 , 26-Ноя-14, (25)
два одновременно работающих (по tos) канала между офисами, tvy, 13:49 , 26-Ноя-14, (27)
два одновременно работающих (по tos) канала между офисами, tvy, 13:44 , 26-Ноя-14, (26)

два одновременно работающих (по tos) канала между офисами, ShyLion, 07:06 , 25-Ноя-14, (16)

два одновременно работающих (по tos) канала между офисами, ShyLion, 07:14 , 25-Ноя-14, (17)

два одновременно работающих (по tos) канала между офисами, Merridius, 17:55 , 25-Ноя-14, (21)

два одновременно работающих (по tos) канала между офисами, ShyLion, 12:56 , 26-Ноя-14, (24)

Сообщения по теме [Сортировка по времени | RSS]

1. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 23-Ноя-14, 16:26

> Но так как офис свой, то доступны и другие механизмы, в частности
> доступны протоколы маршрутизации.
Какие железки???
На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, в роутинге для этих сетей сделал офсссеты.
Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но там какое-то взрослое железо было.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 23-Ноя-14, 16:33

>> Но так как офис свой, то доступны и другие механизмы, в частности
>> доступны протоколы маршрутизации.
> Какие железки???
> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
> в роутинге для этих сетей сделал офсссеты.
> Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но
> там какое-то взрослое железо было.
3945 в центре, в офисах 3925 и 2921.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 23-Ноя-14, 16:47

>> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
>> в роутинге для этих сетей сделал офсссеты.
А, если возможно, можно чуть подробнее про этот механизм?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 24-Ноя-14, 06:19

>>> На 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. Когда что-то падает, то других вариантов кроме единственного интерфейса у роутера нет.
Цифа оффсета подбирается такой, чтобы вычисленная разница метрик обоих интерфейсов была меньше. Короче опытным путем можно найти. Эти цифры взяты с рабочего конфига.
С обратной стороны есесно похожий конфиг.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 24-Ноя-14, 06:06

> 3945 в центре, в офисах 3925 и 2921.
У нас почти такое-же.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 23-Ноя-14, 18:57

>> Но так как офис свой, то доступны и другие механизмы, в частности
>> доступны протоколы маршрутизации.
> Какие железки???
> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно,
> в роутинге для этих сетей сделал офсссеты.
> Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но
> там какое-то взрослое железо было.
Подумалось, а будет работать такой механизм?
Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF.
"Привязываем" каждый экземпляр OSPF к разным каналам.
Так что пока есть канал путь прописан через него. С помощью приоритетов интерфейсов?
Падает канал, только тогда ospf прокладывает маршрут через другой канал.
Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
В один экземпляр ospf, тот route-map, где tos=1
В другой экземпляр ospf, тот route-map, где tos=0
Будет работать?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 24-Ноя-14, 06:06

>[оверквотинг удален]
> Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF.
> "Привязываем" каждый экземпляр OSPF к разным каналам.
> Так что пока есть канал путь прописан через него. С помощью приоритетов
> интерфейсов?
> Падает канал, только тогда ospf прокладывает маршрут через другой канал.
> Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
> В один экземпляр ospf, тот route-map, где tos=1
> В другой экземпляр ospf, тот route-map, где tos=0
> Будет работать?
Как ты интересно будешь делать редистрибьюцию по TOS ?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 24-Ноя-14, 11:14

>[оверквотинг удален]
>> "Привязываем" каждый экземпляр 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?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 24-Ноя-14, 11:19

> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
> Не все route-map-ы съест?
> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?
3 версия не об этом.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 24-Ноя-14, 11:19

> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
Где ты это вообще увидел?
В сиське роут-мапы только так называются, на деле могут использоваться для совершенно разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS просто проигнорируют или вообще не заматчат.
> Не все route-map-ы съест?
> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?
OSPFv3 это IPv6 расширение предыдущего варианта.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 24-Ноя-14, 13:51

>> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map?
> Где ты это вообще увидел?
> В сиське роут-мапы только так называются, на деле могут использоваться для совершенно
> разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS
> просто проигнорируют или вообще не заматчат.
>> Не все route-map-ы съест?
>> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos?
Да, видимо такая конструкция не заработает в принципе.
Чтобы попасть в route-map пакет должен пройти, и записаться маршрут в ospf. Но пакет идет из центра на узел. А передается маршрут на узел.
Может быть как вариант передавать из route-map не сам маршрут, а метрику?
В разные ospf-ы с разными метриками?
Впрочем, времени, к сожалению, мало. Буду пробовать через SLA.
Спасибо большое за идеи и обсуждение!

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 24-Ноя-14, 12:12

>[оверквотинг удален]
>> "Привязываем" каждый экземпляр OSPF к разным каналам.
>> Так что пока есть канал путь прописан через него. С помощью приоритетов
>> интерфейсов?
>> Падает канал, только тогда ospf прокладывает маршрут через другой канал.
>> Прописываем как обычно route-map-ы, где указываем нужные tos-ы.
>> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов.
>> В один экземпляр ospf, тот route-map, где tos=1
>> В другой экземпляр ospf, тот route-map, где tos=0
>> Будет работать?
> Как ты интересно будешь делать редистрибьюцию по TOS ?
Не по TOS. А в зависимости от TOS обычный маршрут передавать в тот или другой процесс ospf.
Маршрут будет или в одном или в другом процессе ospf.
А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное для себя прохождение тарфка по каналам.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

13. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 24-Ноя-14, 15:05

> Не по TOS. А в зависимости от TOS обычный маршрут передавать в
> тот или другой процесс ospf.
> Маршрут будет или в одном или в другом процессе ospf.
> А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное
> для себя прохождение тарфка по каналам.
Ты похоже вообще не понимешь о чем говоришь.
Протоколы маршрутизации манипулируют таблицей маршрутизации _роутера_, которая у него _в дефолтном варианте_ ОДНА. Роутеру абсолютно фиолетово, каким протоколом маршрутизации добавлен тот или иной маршрут в его таблицу, для роутера есть лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние каналов.
Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы.
Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном VRF приземлить на роутере и там иметь другие метрики.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 24-Ноя-14, 19:10

>[оверквотинг удален]
> добавлен тот или иной маршрут в его таблицу, для роутера есть
> лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать
> только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу
> маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние
> каналов.
> Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в
> зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь
> несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы.
> Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном
> VRF приземлить на роутере и там иметь другие метрики.
Знаний и опыта мало, не спорю.
Таблица маршрутизации одна, но один и тот же маршрут можно прописать много раз с разными метриками. Источник может быть различным, например прописать статику с метрикой 254.
Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут, то автоматически в таблице маршрутизации появится статический маршрут.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 25-Ноя-14, 07:01

>>[оверквотинг удален]
> Знаний и опыта мало, не спорю.
> Таблица маршрутизации одна, но один и тот же маршрут можно прописать много
> раз с разными метриками. Источник может быть различным, например прописать статику
> с метрикой 254.
> Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут,
> то автоматически в таблице маршрутизации появится статический маршрут.
Точно. Только TOS тут в выборе никак не участвует.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 25-Ноя-14, 15:14

>>>[оверквотинг удален]
>> Знаний и опыта мало, не спорю.
>> Таблица маршрутизации одна, но один и тот же маршрут можно прописать много
>> раз с разными метриками. Источник может быть различным, например прописать статику
>> с метрикой 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 "разваливается" (удаляет свои маршруты) во всех узлах?

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 25-Ноя-14, 15:49

> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое
> решение в условиях когда все каналы и оборудование свое).
У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения межсайтовые. никаких особых проблем нет.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 25-Ноя-14, 16:40

>> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое
>> решение в условиях когда все каналы и оборудование свое).
> У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения
> межсайтовые. никаких особых проблем нет.
Я понимаю, что решение с туннелями есть.
с MTU несколько выше накладные расходы. Я понимаю, что скорости сейчас большие.
с MTU возможны проблемы у приложений из-за невозможности согласования. Я понимаю, что если правильно mtu настроить на интерфейсах, то проблем быть не должно.
Но хочется красивого, элегантного решения, оборудование-то своё.
Возвращаясь к схеме с протоколом маршрутизации.
Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ маршрутизации.
Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать, у меня все-равно тупик.
А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.
Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него хорошо бы избавиться или зарезервировать в горячем режиме.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (ok) on 25-Ноя-14, 18:14

> Возвращаясь к схеме с протоколом маршрутизации.
> Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае
> когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ
> маршрутизации.
> Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через
> канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать,
> у меня все-равно тупик.
> А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.
> Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него
> хорошо бы избавиться или зарезервировать в горячем режиме.
От маршрутизатора "распределения" красиво избавиться можно так:
1. По протоколу hsrp весь трафик поступает на одну из Цисок, пусть "основную".
2. Весь трафик у нас распределен всего по двум каналам (больше каналов нет), поэтому трафик по tos-aм резервного канала направляем через конструкцию "route-map, set next-hop" на резервный маршрутизатор (через внутренний интерфейс!). Все остальные tos-ы никуда не отправляем! Они остаются на "основном" маршрутизаторе, они для него и предназначены, т.е. просто пропускаем через маршрутизатор дальше.
Возможно придется отключить icmp redirect.
3. А дальше выстраиваем ospf-ы как описано ранее. Цепочкой. Полагая, что если канал упадет, то маршрутизатор по ospf-у передаст это низлежащему маршрутизатору и тот уберет ospf-ный маршрут из своей таблицы маршрутизации.
Остается проверить этот механизм на стенде.
И возможно решить такую проблему как резервирование: отказ любого провода/порта/платы/устройства не должен приводить к потере трафика.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 26-Ноя-14, 11:27

>> Возвращаясь к схеме с протоколом маршрутизации.
>> Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае
>> когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ
>> маршрутизации.
>> Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через
>> канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать,
>> у меня все-равно тупик.
>> А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf.
>> Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него
>> хорошо бы избавиться или зарезервировать в горячем режиме.
Работает конструкция на стенде!
Маршрут в низлежащем маршрутизаторе пропадает.
Более того, пока не проверял, но может быть возможно отказаться от политики на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в основном и резервном маршрутизаторе разные).
А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip redirect).
Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не умрет по TTL(?)?
Поди ничего страшного, что думаете?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 26-Ноя-14, 13:00

> Поди ничего страшного, что думаете?
честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это все добро - рехнешься.
самое простое и правильное - выделить воип в отдельные сегменты. правда слабо применительно если софтфоны в большом ходу.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 26-Ноя-14, 13:49

>> Поди ничего страшного, что думаете?
> честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это
> все добро - рехнешься.
> самое простое и правильное - выделить воип в отдельные сегменты. правда слабо
> применительно если софтфоны в большом ходу.
ospf в каждом маршрутизаторе и несколько строчек (число удаленных сетей) статики с метрикой 254, один route-map с tos-ами или сетями (на любой вкус). Вроде всё.
Если дело выгорит, конфигурацию опубликую, люди сами оценят что сложнее.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

26. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от tvy (??) on 26-Ноя-14, 13:44

> Более того, пока не проверял, но может быть возможно отказаться от политики
> на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в
> основном и резервном маршрутизаторе разные).
> А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным
> и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip
> redirect).
> Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не
> умрет по TTL(?)?
> Поди ничего страшного, что думаете?
Похоже линк между маршрутизаторами нужен.
На внутреннем висит route-map с tos-ами, на линке между маршрутизаторами нет никакого.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

16. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 25-Ноя-14, 07:06

http://trace.twnic.net.tw/rtraining/routings.pdf
Читай

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 25-Ноя-14, 07:14

> http://trace.twnic.net.tw/rtraining/routings.pdf
> Читай
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configu...
Короче, ключевое слово Cisco MTR.
Правда поддерживается это все добро на операторском классе железа.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от Merridius (ok) on 25-Ноя-14, 17:55

>> 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.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

24. "два одновременно работающих (по tos) канала между офисами" +/–

Сообщение от ShyLion (ok) on 26-Ноя-14, 12:56

>>> 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 серии, команды такие поддерживаются, правда дальше не конфигурил.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "два одновременно работающих (по tos) канала между офисами"	+/–
Сообщение от ShyLion (ok) on 23-Ноя-14, 16:26
> Но так как офис свой, то доступны и другие механизмы, в частности > доступны протоколы маршрутизации. Какие железки??? На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, в роутинге для этих сетей сделал офсссеты. Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но там какое-то взрослое железо было.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 23-Ноя-14, 16:33
	>> Но так как офис свой, то доступны и другие механизмы, в частности >> доступны протоколы маршрутизации. > Какие железки??? > На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, > в роутинге для этих сетей сделал офсссеты. > Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но > там какое-то взрослое железо было. 3945 в центре, в офисах 3925 и 2921.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 23-Ноя-14, 16:47
	>> На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, >> в роутинге для этих сетей сделал офсссеты. А, если возможно, можно чуть подробнее про этот механизм?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	7. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 24-Ноя-14, 06:19
	>>> На 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. Когда что-то падает, то других вариантов кроме единственного интерфейса у роутера нет. Цифа оффсета подбирается такой, чтобы вычисленная разница метрик обоих интерфейсов была меньше. Короче опытным путем можно найти. Эти цифры взяты с рабочего конфига. С обратной стороны есесно похожий конфиг.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 24-Ноя-14, 06:06
	> 3945 в центре, в офисах 3925 и 2921. У нас почти такое-же.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 23-Ноя-14, 18:57
	>> Но так как офис свой, то доступны и другие механизмы, в частности >> доступны протоколы маршрутизации. > Какие железки??? > На Cisco ISR серий сегменты с IP телефонией и ВКС выделили отдельно, > в роутинге для этих сетей сделал офсссеты. > Где-то мельком видел, что есть фича альтернативного роутинга по классам траффика, но > там какое-то взрослое железо было. Подумалось, а будет работать такой механизм? Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF. "Привязываем" каждый экземпляр OSPF к разным каналам. Так что пока есть канал путь прописан через него. С помощью приоритетов интерфейсов? Падает канал, только тогда ospf прокладывает маршрут через другой канал. Прописываем как обычно route-map-ы, где указываем нужные tos-ы. А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов. В один экземпляр ospf, тот route-map, где tos=1 В другой экземпляр ospf, тот route-map, где tos=0 Будет работать?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	5. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 24-Ноя-14, 06:06
	>[оверквотинг удален] > Поднимаем на каждом маршрутизаторе два экземпляра (процесса) OSPF. > "Привязываем" каждый экземпляр OSPF к разным каналам. > Так что пока есть канал путь прописан через него. С помощью приоритетов > интерфейсов? > Падает канал, только тогда ospf прокладывает маршрут через другой канал. > Прописываем как обычно route-map-ы, где указываем нужные tos-ы. > А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов. > В один экземпляр ospf, тот route-map, где tos=1 > В другой экземпляр ospf, тот route-map, где tos=0 > Будет работать? Как ты интересно будешь делать редистрибьюцию по TOS ?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	8. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 24-Ноя-14, 11:14
	>[оверквотинг удален] >> "Привязываем" каждый экземпляр 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?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	9. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 24-Ноя-14, 11:19
	> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map? > Не все route-map-ы съест? > Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos? 3 версия не об этом.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 24-Ноя-14, 11:19
	> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map? Где ты это вообще увидел? В сиське роут-мапы только так называются, на деле могут использоваться для совершенно разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS просто проигнорируют или вообще не заматчат. > Не все route-map-ы съест? > Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos? OSPFv3 это IPv6 расширение предыдущего варианта.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	12. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 24-Ноя-14, 13:51
	>> А зачем тогда вообще нужна редистрибьюция в ospf c помощью route-map? > Где ты это вообще увидел? > В сиське роут-мапы только так называются, на деле могут использоваться для совершенно > разных вещей, например для полиси-роутинга. Протоколы маршрутизации match секции с TOS > просто проигнорируют или вообще не заматчат. >> Не все route-map-ы съест? >> Может ospf (какая-нибудь последняя версия, 3?) поддерживает маршрутизацию по tos? Да, видимо такая конструкция не заработает в принципе. Чтобы попасть в route-map пакет должен пройти, и записаться маршрут в ospf. Но пакет идет из центра на узел. А передается маршрут на узел. Может быть как вариант передавать из route-map не сам маршрут, а метрику? В разные ospf-ы с разными метриками? Впрочем, времени, к сожалению, мало. Буду пробовать через SLA. Спасибо большое за идеи и обсуждение!
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	11. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 24-Ноя-14, 12:12
	>[оверквотинг удален] >> "Привязываем" каждый экземпляр OSPF к разным каналам. >> Так что пока есть канал путь прописан через него. С помощью приоритетов >> интерфейсов? >> Падает канал, только тогда ospf прокладывает маршрут через другой канал. >> Прописываем как обычно route-map-ы, где указываем нужные tos-ы. >> А дальше делаем редистрибьюцию маршрутов в OSPF с помощью route-map-ов. >> В один экземпляр ospf, тот route-map, где tos=1 >> В другой экземпляр ospf, тот route-map, где tos=0 >> Будет работать? > Как ты интересно будешь делать редистрибьюцию по TOS ? Не по TOS. А в зависимости от TOS обычный маршрут передавать в тот или другой процесс ospf. Маршрут будет или в одном или в другом процессе ospf. А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное для себя прохождение тарфка по каналам.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	13. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 24-Ноя-14, 15:05
	> Не по TOS. А в зависимости от TOS обычный маршрут передавать в > тот или другой процесс ospf. > Маршрут будет или в одном или в другом процессе ospf. > А разные процессы ospf "привязываются" к разным интерфейсам, что бы обеспечить приоритетное > для себя прохождение тарфка по каналам. Ты похоже вообще не понимешь о чем говоришь. Протоколы маршрутизации манипулируют таблицей маршрутизации _роутера_, которая у него _в дефолтном варианте_ ОДНА. Роутеру абсолютно фиолетово, каким протоколом маршрутизации добавлен тот или иной маршрут в его таблицу, для роутера есть лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние каналов. Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы. Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном VRF приземлить на роутере и там иметь другие метрики.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	14. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 24-Ноя-14, 19:10
	>[оверквотинг удален] > добавлен тот или иной маршрут в его таблицу, для роутера есть > лишь набор префиксов и их приоритет (AD). Поэтому ты можешь манипулировать > только сетями, и ничем другим. Кроме того, маршрутизатор может ИГНОРИРОВАТЬ таблицу > маршрутизации и применять policy-routing, тогда тебе нужно вручную контролировать состояние > каналов. > Еще вариант, если твое коммутационное оборудование может тегировать пакеты по виланам в > зависимости от Cos значения, то можно разрулить VRF-ами, тогда можно иметь > несколько таблиц маршрутизации, но конфиг у тебя увеличится в разы. > Или, опять-же если голосовое все в отдельном вилане, то можно в отдельном > VRF приземлить на роутере и там иметь другие метрики. Знаний и опыта мало, не спорю. Таблица маршрутизации одна, но один и тот же маршрут можно прописать много раз с разными метриками. Источник может быть различным, например прописать статику с метрикой 254. Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут, то автоматически в таблице маршрутизации появится статический маршрут.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	15. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 25-Ноя-14, 07:01
	>>[оверквотинг удален] > Знаний и опыта мало, не спорю. > Таблица маршрутизации одна, но один и тот же маршрут можно прописать много > раз с разными метриками. Источник может быть различным, например прописать статику > с метрикой 254. > Этого маршрута в таблице маршрутизации не будет, но если "упадет" динамический маршрут, > то автоматически в таблице маршрутизации появится статический маршрут. Точно. Только TOS тут в выборе никак не участвует.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	18. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 25-Ноя-14, 15:14
	>>>[оверквотинг удален] >> Знаний и опыта мало, не спорю. >> Таблица маршрутизации одна, но один и тот же маршрут можно прописать много >> раз с разными метриками. Источник может быть различным, например прописать статику >> с метрикой 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 "разваливается" (удаляет свои маршруты) во всех узлах?
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	19. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 25-Ноя-14, 15:49
	> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое > решение в условиях когда все каналы и оборудование свое). У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения межсайтовые. никаких особых проблем нет.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	20. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 25-Ноя-14, 16:40
	>> Вариант: делать туннель (не хочется, так как занижается MTU, не совсем красивое >> решение в условиях когда все каналы и оборудование свое). > У нас большая компания (авиакомпания, в тройке лидеров), тунелями сделаны все соединения > межсайтовые. никаких особых проблем нет. Я понимаю, что решение с туннелями есть. с MTU несколько выше накладные расходы. Я понимаю, что скорости сейчас большие. с MTU возможны проблемы у приложений из-за невозможности согласования. Я понимаю, что если правильно mtu настроить на интерфейсах, то проблем быть не должно. Но хочется красивого, элегантного решения, оборудование-то своё. Возвращаясь к схеме с протоколом маршрутизации. Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ маршрутизации. Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать, у меня все-равно тупик. А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf. Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него хорошо бы избавиться или зарезервировать в горячем режиме.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	22. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (ok) on 25-Ноя-14, 18:14
	> Возвращаясь к схеме с протоколом маршрутизации. > Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае > когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ > маршрутизации. > Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через > канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать, > у меня все-равно тупик. > А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf. > Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него > хорошо бы избавиться или зарезервировать в горячем режиме. От маршрутизатора "распределения" красиво избавиться можно так: 1. По протоколу hsrp весь трафик поступает на одну из Цисок, пусть "основную". 2. Весь трафик у нас распределен всего по двум каналам (больше каналов нет), поэтому трафик по tos-aм резервного канала направляем через конструкцию "route-map, set next-hop" на резервный маршрутизатор (через внутренний интерфейс!). Все остальные tos-ы никуда не отправляем! Они остаются на "основном" маршрутизаторе, они для него и предназначены, т.е. просто пропускаем через маршрутизатор дальше. Возможно придется отключить icmp redirect. 3. А дальше выстраиваем ospf-ы как описано ранее. Цепочкой. Полагая, что если канал упадет, то маршрутизатор по ospf-у передаст это низлежащему маршрутизатору и тот уберет ospf-ный маршрут из своей таблицы маршрутизации. Остается проверить этот механизм на стенде. И возможно решить такую проблему как резервирование: отказ любого провода/порта/платы/устройства не должен приводить к потере трафика.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	23. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 26-Ноя-14, 11:27
	>> Возвращаясь к схеме с протоколом маршрутизации. >> Подумалось: а случайно протокол марщрутизации не удалит свой маршрут автоматически в случае >> когда дальше цепочка разорвалась? Ведь на то он и протокол ДИНАМИЧЕСКОЙ >> маршрутизации. >> Если маршрутизатор (Алкатель) знает, что канала нет (он не видит соседа через >> канал), он может сказать "резервному" маршрутизатору: не надо в меня пихать, >> у меня все-равно тупик. >> А значит "резервный" маршрутизатор тоже удалит у себя маршрут из ospf. >> Если это так, то остается решить проблему маршрутизатора "распределения", т.е. от него >> хорошо бы избавиться или зарезервировать в горячем режиме. Работает конструкция на стенде! Маршрут в низлежащем маршрутизаторе пропадает. Более того, пока не проверял, но может быть возможно отказаться от политики на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в основном и резервном маршрутизаторе разные). А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip redirect). Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не умрет по TTL(?)? Поди ничего страшного, что думаете?
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	25. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 26-Ноя-14, 13:00
	> Поди ничего страшного, что думаете? честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это все добро - рехнешься. самое простое и правильное - выделить воип в отдельные сегменты. правда слабо применительно если софтфоны в большом ходу.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору


	27. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 26-Ноя-14, 13:49
	>> Поди ничего страшного, что думаете? > честно читать эти бредни не хочется. костыль на костыле. сопровождать потом это > все добро - рехнешься. > самое простое и правильное - выделить воип в отдельные сегменты. правда слабо > применительно если софтфоны в большом ходу. ospf в каждом маршрутизаторе и несколько строчек (число удаленных сетей) статики с метрикой 254, один route-map с tos-ами или сетями (на любой вкус). Вроде всё. Если дело выгорит, конфигурацию опубликую, люди сами оценят что сложнее.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	26. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от tvy (??) on 26-Ноя-14, 13:44
	> Более того, пока не проверял, но может быть возможно отказаться от политики > на межлинковом интерфейсе, ведь маршрут уже есть по ospf-у (ospf-ы в > основном и резервном маршрутизаторе разные). > А может можно вообще отказаться от межлинкового соединения между маршрутизаторами (основным > и резервным), а пересылать через внутренний интерфейс (лучше видимо отключить ip > redirect). > Пропадут оба канала, ну покидают маршрутизаторы друг другу пакет, пока он не > умрет по TTL(?)? > Поди ничего страшного, что думаете? Похоже линк между маршрутизаторами нужен. На внутреннем висит route-map с tos-ами, на линке между маршрутизаторами нет никакого.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору

16. "два одновременно работающих (по tos) канала между офисами"	+/–
Сообщение от ShyLion (ok) on 25-Ноя-14, 07:06
http://trace.twnic.net.tw/rtraining/routings.pdf Читай
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	17. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 25-Ноя-14, 07:14
	> http://trace.twnic.net.tw/rtraining/routings.pdf > Читай http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configu... Короче, ключевое слово Cisco MTR. Правда поддерживается это все добро на операторском классе железа.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	21. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от Merridius (ok) on 25-Ноя-14, 17:55
	>> 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.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	24. "два одновременно работающих (по tos) канала между офисами"	+/–
	Сообщение от ShyLion (ok) on 26-Ноя-14, 12:56
	>>> 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 серии, команды такие поддерживаются, правда дальше не конфигурил.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору