Virtual-link?
Рассмотрим следующую топологию:
Общее предназначение виртуал-линков думаю всем известно. Обычно ими соединяют разделенную нулевую область или присоединяют "оторванную" область к нулевой через транзитную. Но это только одно из предназначений, про другое обычно забывают.
Рассмотрим следующую топологию:
Когда мы видим несколько областей стоит понимать, что внутренний маршрут предпочтительней маршрута из соседней области который в свою очередь лучше чем внешний. Если мы из второй области хотим обратиться к первой, то трафик будет отправлен через нулевую. В нашем случае трафик от R4 к R2 (к лупбэку в нулевой области) всегда будет проходить по медленным линкам между ними, т.к. он в бэкбон области. Маршрут будет следующий: R4 > R5 > R3 > R2. Что видится несколько неразумным при наличии пути R4 > R1 > R2.
Для борьбы с подобными не оптимальными маршрутами можно применить виртуал-линки. Нам потребуется соединить им роутеры R3-R1 в area 1. Что изменится? Как ни удивительно, но мы сможем обойти классическое правило: "в multi-area весь трафик идет через нулевую область". Всё дело в свойстве transit capability, благодаря которому при поднятом виртуал-линке, роутеры могут выбирать кратчайший маршрут через транзитную не бэкбон область. Это возможно только при условии, что префиксы полученные через виртуал-линк совпадают с полученными от других областей. Если оно выполнено, то роутер может выбрать маршрут с лучшей метрикой заместо маршрута через виртуал-линк.
Свойство transit-capability появилось в OSPFv2, в первой версии протокола наличие виртуальных линков не позволяло выбирать маршрут в соседнюю область напрямую. Теперь, когда ABR поднимает virtual-link через область, то он начинает рассылать в неё LSA 1 с выставленным битом V. Таким образом роутеры узнают, что они участники транзитной области.
В нашем случае, настроенный виртуал-линк изменит пути трафика на оптимальные. Теперь R4 сможет достигать интересующую его подсеть по кратчайшему пути: R4 > R1 > R2.
Дополнение.
Иногда встречается задача по изменению traffic path в OSPF, по условиям которой нельзя добавлять/изменять интерфейсы, нельзя менять метрики на линках. Для её решения как раз очень удобно отключать transit capability и трафик начнет идти строго по пути виртуал линка. Обычно этого достаточно. Transit capability следует отключать на всех маршрутизатора области.
Свойство transit-capability появилось в OSPFv2, в первой версии протокола наличие виртуальных линков не позволяло выбирать маршрут в соседнюю область напрямую. Теперь, когда ABR поднимает virtual-link через область, то он начинает рассылать в неё LSA 1 с выставленным битом V. Таким образом роутеры узнают, что они участники транзитной области.
В нашем случае, настроенный виртуал-линк изменит пути трафика на оптимальные. Теперь R4 сможет достигать интересующую его подсеть по кратчайшему пути: R4 > R1 > R2.
Дополнение.
Иногда встречается задача по изменению traffic path в OSPF, по условиям которой нельзя добавлять/изменять интерфейсы, нельзя менять метрики на линках. Для её решения как раз очень удобно отключать transit capability и трафик начнет идти строго по пути виртуал линка. Обычно этого достаточно. Transit capability следует отключать на всех маршрутизатора области.
Комментариев нет:
Отправить комментарий