BGP Routing Policies
Injecting OSPF Routes into the BGP Routing Table
Допустим у нас появилось 2 клиента, которым нужен большой пул адресов. Пусть мы выделим им подсети 200.0.0.0/25 и 200.0.0.128/25. Для этого можно просто навесить эти адреса на любой интерфейс на любые юниты и включить их в OSPF как passive. Сделаем это на RT.SPB.MIR:
Далее создаём политику по редистрибуции этих маршрутов в BGP:
Маршруты с указанных областей будут попадать в BGP-таблицу, но отправятся они только будут только соседям. Т.е. BGP-маршрут отправится только трём соседям, указанным в конфигурации RT.SPB.MIR. Внутри Sub-AS 65003 маршрут будет распространяться нормально, но вот Route Reflector´ы маршрут, полученный по BGP распространять далее не будут, так как у них есть More Specific Route полученный по OSPF. Что с этим можно сделать? Можно указать на всех роутерах атрибут, который позволит распространять даже неактивные маршруты:
Вот какие префиксы мы анонсируем K12:
Вводим соответствующую команду и получаем результат:
Маршрут попадёт в Hidden из-за нашей политики, которая не позволяет принимать префиксы длиннее 24:
Что можно сделать? Можно либо поменять политики, либо прописать статический маршрут, либо сагрегировать маршруты, что мы и сделаем.
Aggregate Routes
Агрегированные маршруты позволяют без лишних опций сконфигрурировать Less Specific Route для нескольких маршрутов, чтобы передать его по BGP. Агрегированный маршрут будет активен (и как следствие передаваться по BGP) только если у него будут Contribute (More Specific) Routes. Предыдущий конфиг редистрибуции маршрутов можно удалить c RT.SPB.MIR. Добавим агрегированный маршрут, экспортируем его в таблицу BGP атрибут advertise-inactive не потребуется ни на одном из роутеров, так как маршрут будет активным:
Также можно сагрегировать маршруты так, чтобы мы анонсировали contribute routes (More Specific) для Aggregate маршрута, а не сам Aggregate Route, при помощи команды:
Как видно, всё в порядке:
Generate Route
Данный маршрут ничем не отличсается от Aggregate, кроме того, что Next-Hop у него не равен Reject или Discard, а равен он Next-Hop'у одного из Contribute Routes. Используется провайдерами, в основном для установки маршурта 0.0.0.0/0 и передачи его каким-нибудь клиентам.
Допустим, нам необходимо сгенерировать маршрут 0.0.0.0/0 для клиентов, которые берут у нас IP-транзит и не хотят получать Full-View или хотят получать Full-View + Defaul Route. Можно прописать статический маршрут с кучей next-hop адресов, а можно просто прописать Generate Route, указав, что в него мы включим только Contribute Routes от наших аплинков. Т.е. через Policy-Option мы просто запретим попадание наших подсетей, как Contribute Routes для маршрута 0.0.0.0/0.
Прежде всего перенастроим OSPF: удалим все Area и включим все наши линки в Area 0, чтобы не было никаких проблем с маршрутом 0.0.0.0/0, который экспортируется в OSPF на RT.SPB.MIR и который передаётся ABR в stub-areas.
Далее добавим на каждый роутер, у которого есть eBGP-пир, Generate Route 0.0.0.0/0, оставив в Contribute Routes только сети аплинков. Запретим, например, попадание сети 40.0.0.0/8 (предположим, что это наш пул) в которую входит клиентская сеть 40.0.0.0/24. Почему добавляем на каждый роутер с eBGP-пирами? Если Generate Route будет настроен только на одном роутере, и он упадёт, то маршрут просто исчезнет.
Пример настройки на RT.MSK.M34:
Что же мы видим теперь на маршрутизаторах:
Т.е. у нас имеется маршурт по умолчанию, next-hop, которого автоматически подстраивается под текущую ситуацию на сети. И чем больше у нас аплинков, тем больше у нас Nex-Hop адресов, на которые мы сможем отправить трафик. При этом с нашей стороны для этого не потребуется ничего делать. Всё будет происходить согласно Policy-Option.
А теперь предположим, что мы хотим послать запрос на неизвестный нам IP от клиента. Предварительно отключим интерфейсы на RT.VVK.NOV в сторону аплинков. Вот что мы увидим:
10.0.0.14 - это интерфейс на RT.SPB.K12. Трафик ходит так, как нам нужно.
Default Route Adverisment with Policy Option Conditions
Policy Option Conditions позволяет анонсировать маршрут по умолчанию клиентам через различных аплинков в зависимости от того доступны ли они от них определённые префиксы.
Предположим, что у нас на RT.VVK.NOV появился клиент, которому нужно анонсировать маршрут по-умолчанию:
Настром между роутерами BGP-Сессию:
Пусть клиент анонсирует нам префикс 40.0.0.0/24:
Также добавим какой-нибудь адрес на lo0 интерфейс:
Как видно, клиент сейчас принимает Full-View:
Можно анонсировать клиенту маршрут по-умолчанию при условии, что от нас доступен нужный клиенту префикс (101.0.0.0.24):
Заранее выключим AS8001, который анонсирует префикс. Посмотрим что мы будем видеть на клиентском роутере:
Мы не принимаем по BGP ни одного префикса. Попробуем включить AS8001 и снова посмотреть на вывод команд:
Такая конфигурация полезна, когда у клиента есть резерв, но он принимает только default-route. Если этот префикс не доступен, то мы перестаём анонсировать клиенту маршрут по умолчанию и он уходит на резерв.
Filter Based Forwarding (PBR for Cisco)
Предположим, что клиент, которого мы подключили ранее, испытывает трудности с доступом к нужной ему подсети с адресом 101.0.0.0/24 через прямой линк с AS9001. Трассировка выглядит сейчас так:
По AS-PATH маршрута видно, что путь пакетов пролегает через RT.VVK.NOV->AS9001->AS8001. Соответственно нам нужно выбрать такой маршрут, чтобы он проходил через AS9000->AS9002->AS9001->AS80001.
Что тут было сделано описано в комментариях к конфигу. Теперь трассировка выглядит так:
При этом остальные маршруты задеты не будут
Last updated
Was this helpful?