Два офиса соединяются через филиал, который должен нести собственный трафик и очень мало другого. Филиалу нужны маршруты к обоим сайтам, и ни один из сайтов не должен предпочитать его как путь между ними. Удаление филиала из топологии решило бы проблему транзита и нарушило бы требование, потому что филиал по-прежнему должен достигать обоих сайтов, а оба сайта по-прежнему должны достигать филиала.

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

Начните с пути, которого хотите избежать

Нарисуйте топологию так, как её видит протокол, а не так, как её видит схема. Какие интерфейсы образуют смежности, какие находятся в одной области и какие из этих смежностей несли бы трафик между двумя офисами, если бы филиал был предпочтительнее? Это три отдельных вопроса, и схема ни на один из них не отвечает надёжно.

Затем найдите альтернативный путь. Если единственный маршрут между офисами идёт через филиал, никакая метрика не сможет увести трафик с него, потому что трафику некуда идти. Резервирование — не деталь этого проекта, а его предпосылка. Второй путь, существующий только на бумаге, не считается.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Эти три вида отвечают на разные вопросы: кто является соседом, какие интерфейсы участвуют и с какой стоимостью, и какой путь устройство выбирает сейчас. Развёртывание туннеля добавляет четвёртый: линия на схеме не доказывает, что смежность образовалась через неё, а образованная смежность не доказывает, что пересылка идёт тем же путём. Именно в туннельных проектах этот разрыв проявляется чаще всего.

Что объявляет максимальная метрика

RFC 6987 описывает маршрутизатор, объявляющий свои не-stub связи с максимальной метрикой связи, определённой как 0xffff. Маршрутизатор по-прежнему описывает себя и свои связи; он просто оценивает их по верхней границе диапазона, так что каждый другой маршрутизатор считает путь через него дорогим.

Это изменение router-LSA, а не удаление топологии. Различие важно: очистка router-LSA отзывает саму информацию о топологии, что может отозвать и отношения, необходимые для достижения маршрутизатора и префиксов за ним. Сохранение объявления и повышение его цены сохраняет эти отношения. В этом вся разница между этим приёмом и удалением.

Механизм RFC 6987 также не имеет ничего общего с типами областей или с выборами назначенного маршрутизатора. Stub-область блокирует категорию объявлений состояния связи на границе области, а stub-маршрутизатор оценивает собственные связи. Похожие слова, несвязанная механика.

Почему достижимость сохраняется, а транзит нет

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

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

Это то поведение, которое нужно проверить, а не предполагать. Посмотрите на router-LSA, который создаёт филиал, затем на путь, который выбирает другой маршрутизатор для назначения за филиалом и для назначения в другом офисе. Два ответа должны различаться, и если они не различаются, изменение метрики не доходит до того решения, о котором вы думаете.

Проблема последнего пути

Тот же RFC прямо указывает, что приём не запрещает использование. Когда альтернативный путь отказывает, маршрутизаторы возвращаются на дорогой путь через филиал, потому что он по-прежнему является допустимым путём, а протокол предпочитает дорогой маршрут отсутствию маршрута.

Приемлем ли такой откат — вопрос политики, на который нужно ответить до развёртывания. Филиал на небольшом восходящем канале, внезапно несущий межофисный трафик, может быть хуже аварии и может быть именно тем, что вам нужно во время окна обслуживания. Оба ответа законны; молчание — нет.

Если требование — строгий запрет, а не предпочтение, один только проект метрики его не даст. Нужно принудительное применение пересылки, соответствующее замыслу, плюс определённое поведение для случая, когда трафик всё же приходит. Объявление пути как пригодного и последующий сброс трафика создают чёрную дыру, которую диагностировать сложнее, чем петлю маршрутизации.

Для OSPFv3 RFC обсуждает бит R как другой способ исключить участие в транзите. Не предполагайте, что он наследует то же поведение последнего пути, что и приём максимальной метрики, и не копируйте настройки между двумя семействами адресов так, будто это одна и та же функция.

Докажите это в нормальных и отказных условиях

Проверьте дважды: один раз при доступных обоих путях и один раз при удалённом предпочтительном пути. Первый тест показывает, что предпочтение работает, а второй показывает, что сеть делает, когда предпочтение соблюсти нельзя. Пропуск второго теста оставляет важную половину неисследованной.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Вид базы данных показывает объявленную метрику, поиск маршрута показывает выбранный следующий переход, а трассировка показывает, куда на самом деле ушли пакеты. Когда эти три совпадают, у вас проверенный проект, а не конфигурация, которая выглядит правильной.

Затем восстановите предпочтительный путь и подтвердите, что филиал возвращается к переносу только собственного трафика. Шаг восстановления относится к тесту, а не к уборке, потому что проект, работающий только до следующего изменения, — не проект. Запишите оба результата, включая откат, потому что второй — это ответ, который кому-то понадобится в три часа ночи.

Похожие статьи