7) Basic Routing Concepts
В этой главе будут рассмотрены базовые концепты маршрутизации. Что-то было рассмотрено в предыдущих главах, что-то будет рассмотрено на более конкретных примерах далее. В целом, на уровне JNCIS-SP нужно понимать какие-то базовые концепты и смысл нижеописанных технологий. Особенно если речь идёт о Routing-Instances и RIB-Groups. В этой главе будет по большей части теория. На практике всё будет применено в последующих главах.
1. Load Balancing
Сама по себе балансировка трафика происходит на базе Per-Flow, хотя и конфигурируется как Per-Packet (для совместимости со старыми версиями JunOS). По факту, балансировка по потоку происходит так: трафик прогоняют через хеш на основе L3 Dst IP/Src IP + L4 Dst Port/Src Port и весь такой поток идёт через один и тот же next-hop. Ещё одна отличительная особенность Load-Balancing в JunOS состоит в том, что для некоторых протоколов она включается отдельно, в дополнение к экспорту политики балансировки в Forwarding Table. Например, статичексом маршруте указывается два Nex-Hop'а, в BGP для группы указывается Multipath.
Настройка маршрутизаторов:
Как видно, без включения балансировки на уровне PFE трафик ходит по одному маршруту всегда:
Это видно и по таблице маршрутизации (достаточно посмотреть на значение Next-Hop в фигурных скобках):
Включим балансировку на MX1, после чего посмотрим таблицу маршрутизации и значение Nex-Hop в фигурных скобках (Тут не указываем происхождение маршрутов и трафика, т.е. не указываем поле From. Значит под эту Policy-Statement будет подходить любой трафик):
Проверка результата:
2. Настройка статических маршрутов с резервом
Пусть у нас останется такая же схема, балнсировку трафика уберём.
Теперь статический маршрут выглядит так:
Проверка:
3. Martian Routes
Это те префиксы, которые никода и ни при каких условиях не попадут в таблицу маршрутизации. Например:
Можно самостоятельно разрешать некоторые префиксы:
4. Aggregate Routes
Название говорит само за себя - нужны для суммаризации маршрутов. Например, для сокращения БД OSPF или для того чтобы собрать мелкие маршруты в один большой и анонсировать этот префикс по BGP. Этот тип маршрута имеет Preference = 130 и активен только тогда, когда у него есть Contribute Routes (More Specific Routes) в таблице маршрутизации. При этом Nex-Hop по умолчанию у него установлен как Reject. В этом случае, если пакет отправляется к Dst IP, который не подкодит ни под один из More Specific Routes на этом маршрутизаторе, то пакет отбрасывается и на Src IP пакета отсылается ICMP ответ, что хост не доступен. Можно указать Next-Hop Discard. Тогда пакет будет просто отброшен.
Для примера можно взять практически ту же схему, немного её изменив:
Настроим OSPF в 0 Area для всех интерфейсов:
Вот какие маршруты будут видны на MX1:
Предположим, что у нас вся серая подсеть 10.0.0.0/8 будет по плану подключена к MX2, тогда нет смысла раздувать базу данных OSPF и проще просто все маршруты собрать в одну большую сеть и экспортировать в OSPF:
Теперь посмотрим как выглядят маршруты:
На MX1 появилась одна сеть, вместо двух. Что мы видим на MX2:
Теперь временно отключим интерфейсы в сторону Linux1 и Linux2 и посмотрим таблицы маршрутизаций повторно:
Т.е. как только все Contibute routes исчезли, маршрут перешёл в Hidden. MX1 теперь тоже ничего не знает о сети 10.0.0.0/8:
5. 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.
Более подробно применение маршрута описано в главе BGP, в разделе BGP Routing Policies.
6. Routing Instances
Тут всё довольно просто. Нужны для отдельного процесса маршрутизации и/или коммутации. Например, нам нужно отдельно маршрутизировать серые сети клиента. И он и мы можем использовать сеть 10.0.0.0/8. Чтобы не было проблем при реализации L3 VPN, нам необходимо производить маршрутизацию серых сетей для клиента отдельно от маршрутизации наших подсетей.
Обычно Routing-Instance состоит из:
Отдельная таблица маршрутизации
Интерфейсы, которые принадлежат этой таблицы (не всегда, зависит от типа Routing-Instance)
Прочие настройки (Отдельные протоколы и прочее)
Всего есть 12 типов Routing-Instance'ов:
Ethernet VPN (EVPN) (MX Series routers only) - для подключения P2MP VPN при помощи EVPN с использованием технологии VXLAN
Forwarding - используется для FBF (Filter Based Forwarding), аналог PBR в Cisco. Это пример Routing-Instance, в которой не указываются интерфейсы
Internet Multicast over MPLS - Служит для переправки мультикаста через MPLS, используя MP-BGP или MVPN
Layer 2 Backhaul VPN (MX Series routers only) - Для пересылки L2VPN-трафика, без соответствующих логических интерфейсов
Layer2-control (MX Series routers only) - Для пересылки клиентского трафика управления (STP, например) по транспортной сети провайдера
Layer 2 VPN - Для построения L2VPN
MPLS forwarding - Необходима для поддержки защиты от MPLS Label Spoofing
Nonforwarding - Используется, когда нужно иметь несколько разных RIB, которые будут формировать одну и ту же FIB.
Virtual router - Используется для разделения таблиц маршрутизации на одном роутере. Можно сделать простой L3VPN, если клиент подключен с одного и того же маршрутизатора. Не требует настройки VRF import, VRF export, VRF target, или Route Distinguisher'а
Virtual switch (MX Series routers only) - Необходим для изоляции LAN-сегмента, например для настройки отдельного процесса STP
VPLS - для развёртывания P2MP VPN
VRF - Для развёртывания классического L3 VPN при помощи MPLS
7. Route Leaking
Допустим, мы создали отдельную Routing-Instance, включили туда интерфейсы, но тут нам понадобилось добавить в эту таблицу маршрутную информацию из другой RIB, от определённого протокола. Тут нам поможет Route Leaking. Для этого служат RIB-Groups. Идея состоит в том, что мы группируем различные RIB, а потом указываем какие маршруты какого протокола мы хотим перенести в другую RIB.
Last updated
Was this helpful?