# 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. ![Схема сети](/files/-MXvsixMTXG-r9z3_vwp) Настройка маршрутизаторов: ``` root@MX1# show routing-options static { route 10.0.0.0/24 next-hop [ 192.168.0.1 192.168.1.1 ]; } root@MX1# show interfaces lo0 unit 0 { family inet { address 8.8.8.8/32; } } root@MX2# show routing-options static { route 8.8.8.8/32 next-hop [ 192.168.0.0 192.168.1.0 ]; } ``` Как видно, без включения балансировки на уровне PFE трафик ходит по одному маршруту всегда: ``` root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.061 ms 0.778 ms 0.740 ms 2 10.0.0.10 (10.0.0.10) 0.830 ms 1.466 ms 0.843 ms [edit] root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.098 ms 0.862 ms 0.609 ms 2 10.0.0.10 (10.0.0.10) 0.500 ms 0.667 ms 0.468 ms [edit] root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.095 ms 0.827 ms 0.578 ms 2 10.0.0.10 (10.0.0.10) 0.620 ms 0.567 ms * [edit] root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.016 ms 0.846 ms 0.762 ms 2 10.0.0.10 (10.0.0.10) 0.911 ms 1.266 ms 0.821 ms ``` Это видно и по таблице маршрутизации (достаточно посмотреть на значение Next-Hop в фигурных скобках): ``` root@MX1# run show route 10.0.0.0 extensive inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 10.0.0.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 10.0.0.0/24 -> {192.168.0.1} *Static Preference: 5 Next hop type: Router, Next hop index: 1048574 Address: 0x961407c Next-hop reference count: 1 Next hop: 192.168.0.1 via ge-0/0/0.0, selected Session Id: 0x140 Next hop: 192.168.1.1 via ge-0/0/1.0 Session Id: 0x141 State: Age: 20:02 Validation State: unverified Task: RT Announcement bits (1): 0-KRT AS path: I ``` Включим балансировку на MX1, после чего посмотрим таблицу маршрутизации и значение Nex-Hop в фигурных скобках (Тут не указываем происхождение маршрутов и трафика, т.е. не указываем поле From. Значит под эту Policy-Statement будет подходить любой трафик): ``` root@MX1# show | compare [edit routing-options] + forwarding-table { + export Load_Balancing; + } [edit] + policy-options { + policy-statement Load_Balancing { + then { + load-balance per-packet; + } + } + } root@MX1# run show route 10.0.0.0 extensive inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 10.0.0.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 10.0.0.0/24 -> {192.168.0.1, 192.168.1.1} *Static Preference: 5 Next hop type: Router, Next hop index: 1048574 Address: 0x961407c Next-hop reference count: 2 Next hop: 192.168.0.1 via ge-0/0/0.0, selected Session Id: 0x140 Next hop: 192.168.1.1 via ge-0/0/1.0 Session Id: 0x141 State: Age: 19:20 Validation State: unverified Task: RT Announcement bits (1): 0-KRT AS path: I ``` Проверка результата: ``` root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 1.080 ms 0.880 ms 192.168.0.1 (192.168.0.1) 0.623 ms 2 10.0.0.10 (10.0.0.10) 1.002 ms 0.891 ms 0.641 ms [edit] root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.165 ms 192.168.1.1 (192.168.1.1) 0.925 ms 1.462 ms 2 10.0.0.10 (10.0.0.10) 1.074 ms 0.924 ms 0.927 ms ``` ## 2. Настройка статических маршрутов с резервом ![](/files/-MXvx_k70EzgICTJ1-FL) Пусть у нас останется такая же схема, балнсировку трафика уберём. Теперь статический маршрут выглядит так: ``` root@MX1# show | compare [edit routing-options static route 10.0.0.0/24] + next-hop 192.168.1.1; + qualified-next-hop 192.168.0.1 { + preference 10; + } root@MX1# run show route 10.0.0.0 inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[Static/5] 00:18:23 > to 192.168.1.1 via ge-0/0/1.0 [Static/10] 00:00:12 > to 192.168.0.1 via ge-0/0/0.0 ``` Проверка: ``` root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 1.299 ms 0.858 ms 0.854 ms 2 10.0.0.10 (10.0.0.10) 0.920 ms 0.882 ms 0.859 ms root@MX1# deactivate interfaces ge-0/0/1 root@MX1# commit commit complete root@MX1# run traceroute 10.0.0.10 source 8.8.8.8 traceroute to 10.0.0.10 (10.0.0.10) from 8.8.8.8, 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 1.121 ms 0.716 ms 0.744 ms 2 10.0.0.10 (10.0.0.10) 1.029 ms 0.844 ms 0.714 ms ``` ## 3. Martian Routes Это те префиксы, которые никода и ни при каких условиях не попадут в таблицу маршрутизации. Например: ``` root@MX1# run show route martians inet.0: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed 224.0.0.0/4 exact -- disallowed 224.0.0.0/24 exact -- disallowed inet.1: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed inet.2: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed 224.0.0.0/4 exact -- disallowed 224.0.0.0/24 exact -- disallowed inet.3: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed 224.0.0.0/4 exact -- disallowed 224.0.0.0/24 exact -- disallowed inet.5: 0.0.0.0/0 exact -- allowed 0.0.0.0/8 orlonger -- disallowed 127.0.0.0/8 orlonger -- disallowed 192.0.0.0/24 orlonger -- disallowed 240.0.0.0/4 orlonger -- disallowed 224.0.0.0/4 exact -- disallowed 224.0.0.0/24 exact -- disallowed ...... inet6.0: ::1/128 exact -- disallowed ff00::/8 exact -- disallowed ff02::/16 exact -- disallowed inet6.1: ::1/128 exact -- disallowed inet6.2: ::1/128 exact -- disallowed ff00::/8 exact -- disallowed ff02::/16 exact -- disallowed inet6.3: ::1/128 exact -- disallowed ff00::/8 exact -- disallowed ff02::/16 exact -- disallowed root@MX1# show routing-options static route 10.0.0.0/24 { next-hop 192.168.1.1; qualified-next-hop 192.168.0.1 { preference 10; } } route 192.0.0.0/24 next-hop 192.168.0.1; root@MX1# run show route 192.0.0.0/24 hidden extensive inet.0: 5 destinations, 5 routes (4 active, 0 holddown, 1 hidden) 192.0.0.0/24 (1 entry, 0 announced) Static Preference: 5 Next hop type: Router, Next hop index: 556 Address: 0x9690270 Next-hop reference count: 4 Next hop: 192.168.0.1 via ge-0/0/0.0, selected Session Id: 0x140 State: Age: 47 Validation State: unverified Task: RT AS path: I ``` Можно самостоятельно разрешать некоторые префиксы: ``` root@MX1# show | compare [edit routing-options] + martians { + 192.0.0.0/24 orlonger allow; + } root@MX1# run show route 192.0.0.0/24 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.0.0.0/24 *[Static/5] 00:01:44 > to 192.168.0.1 via ge-0/0/0.0 ``` ## 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. Тогда пакет будет просто отброшен. Для примера можно взять практически ту же схему, немного её изменив: ![](/files/-MXw9aHeDNaqeiENqV3-) Настроим OSPF в 0 Area для всех интерфейсов: {% tabs %} {% tab title="MX1" %} ``` ospf { area 0.0.0.0 { interface ge-0/0/0.0 { interface-type p2p; } } } ``` {% endtab %} {% tab title="MX2" %} ``` ospf { area 0.0.0.0 { interface ge-0/0/0.0 { interface-type p2p; } interface ge-0/0/2.0 { passive; } interface ge-0/0/3.0 { passive; } } } ``` {% endtab %} {% endtabs %} Вот какие маршруты будут видны на MX1: ``` root@MX1# run show route inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[OSPF/10] 00:00:42, metric 2 > to 192.168.0.1 via ge-0/0/0.0 10.0.1.0/24 *[OSPF/10] 00:00:42, metric 2 > to 192.168.0.1 via ge-0/0/0.0 192.168.0.0/31 *[Direct/0] 01:18:08 > via ge-0/0/0.0 192.168.0.0/32 *[Local/0] 01:18:08 Local via ge-0/0/0.0 224.0.0.5/32 *[OSPF/10] 00:01:53, metric 1 MultiRecv ``` Предположим, что у нас вся серая подсеть 10.0.0.0/8 будет по плану подключена к MX2, тогда нет смысла раздувать базу данных OSPF и проще просто все маршруты собрать в одну большую сеть и экспортировать в OSPF: ``` root@MX2# show | compare [edit] + routing-options { + aggregate { + route 10.0.0.0/8 discard; + } + } [edit protocols ospf] + export Aggregate-Export; [edit protocols ospf area 0.0.0.0] - interface ge-0/0/2.0 { - passive; - } - interface ge-0/0/3.0 { - passive; - } [edit] + policy-options { + policy-statement Aggregate-Export { + term 1 { + from protocol aggregate; + then accept; + } + } + } ``` Теперь посмотрим как выглядят маршруты: ``` root@MX1# run show route inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8 *[OSPF/150] 00:00:06, metric 0, tag 0 > to 192.168.0.1 via ge-0/0/0.0 192.168.0.0/31 *[Direct/0] 01:28:43 > via ge-0/0/0.0 192.168.0.0/32 *[Local/0] 01:28:43 Local via ge-0/0/0.0 224.0.0.5/32 *[OSPF/10] 00:12:28, metric 1 MultiRecv ``` На MX1 появилась одна сеть, вместо двух. Что мы видим на MX2: ``` root@MX2# run show route 10.0.0.0/8 inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8 *[Aggregate/130] 00:01:40 Discard 10.0.0.0/24 *[Direct/0] 00:19:38 > via ge-0/0/2.0 10.0.0.1/32 *[Local/0] 00:19:38 Local via ge-0/0/2.0 10.0.1.0/24 *[Direct/0] 00:15:57 > via ge-0/0/3.0 10.0.1.1/32 *[Local/0] 00:15:57 Local via ge-0/0/3.0 root@MX2# run show route 10.0.0.0/8 extensive inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 10.0.0.0/8 (1 entry, 1 announced) TSI: KRT in-kernel 10.0.0.0/8 -> {} OSPF area : 0.0.0.0, LSA ID : 10.0.0.0, LSA type : Extern *Aggregate Preference: 130 Next hop type: Discard Address: 0x92c4a24 Next-hop reference count: 2 State: Age: 1:47 Validation State: unverified Task: Aggregate Announcement bits (2): 0-KRT 1-OSPF AS path: I (LocalAgg) Flags: Discard Depth: 0 Active AS path list: AS path: I Refcount: 2 Contributing Routes (2): 10.0.0.0/24 proto Direct 10.0.1.0/24 proto Direct ``` Теперь временно отключим интерфейсы в сторону Linux1 и Linux2 и посмотрим таблицы маршрутизаций повторно: ``` root@MX2# show | compare [edit interfaces] ! inactive: ge-0/0/2 { ... } ! inactive: ge-0/0/3 { ... } root@MX2# run show route hidden extensive inet.0: 4 destinations, 4 routes (3 active, 0 holddown, 1 hidden) 10.0.0.0/8 (1 entry, 0 announced) Aggregate Next hop type: Discard Address: 0x92c4a24 Next-hop reference count: 1 State: Age: 5:33 Validation State: unverified Task: Aggregate AS path: I Flags: ASPathChanged Discard Depth: 0 Inactive ``` Т.е. как только все Contibute routes исчезли, маршрут перешёл в Hidden. MX1 теперь тоже ничего не знает о сети 10.0.0.0/8: ``` root@MX1# run show route inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/31 *[Direct/0] 01:35:45 > via ge-0/0/0.0 192.168.0.0/32 *[Local/0] 01:35:45 Local via ge-0/0/0.0 224.0.0.5/32 *[OSPF/10] 00:19:30, metric 1 MultiRecv ``` ## 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 состоит из: 1. Отдельная таблица маршрутизации 2. Интерфейсы, которые принадлежат этой таблицы (не всегда, зависит от типа Routing-Instance) 3. Прочие настройки (Отдельные протоколы и прочее) Всего есть 12 типов Routing-Instance'ов: 1. Ethernet VPN (EVPN) (MX Series routers only) - для подключения P2MP VPN при помощи EVPN с использованием технологии VXLAN 2. Forwarding - используется для FBF (Filter Based Forwarding), аналог PBR в Cisco. Это пример Routing-Instance, в которой не указываются интерфейсы 3. Internet Multicast over MPLS - Служит для переправки мультикаста через MPLS, используя MP-BGP или MVPN 4. Layer 2 Backhaul VPN (MX Series routers only) - Для пересылки L2VPN-трафика, без соответствующих логических интерфейсов 5. Layer2-control (MX Series routers only) - Для пересылки клиентского трафика управления (STP, например) по транспортной сети провайдера 6. Layer 2 VPN - Для построения L2VPN 7. MPLS forwarding - Необходима для поддержки защиты от MPLS Label Spoofing 8. Nonforwarding - Используется, когда нужно иметь несколько разных RIB, которые будут формировать одну и ту же FIB. 9. Virtual router - Используется для разделения таблиц маршрутизации на одном роутере. Можно сделать простой L3VPN, если клиент подключен с одного и того же маршрутизатора. Не требует настройки VRF import, VRF export, VRF target, или Route Distinguisher'а 10. Virtual switch (MX Series routers only) - Необходим для изоляции LAN-сегмента, например для настройки отдельного процесса STP 11. VPLS - для развёртывания P2MP VPN 12. VRF - Для развёртывания классического L3 VPN при помощи MPLS ## 7. Route Leaking Допустим, мы создали отдельную Routing-Instance, включили туда интерфейсы, но тут нам понадобилось добавить в эту таблицу маршрутную информацию из другой RIB, от определённого протокола. Тут нам поможет Route Leaking. Для этого служат RIB-Groups. Идея состоит в том, что мы группируем различные RIB, а потом указываем какие маршруты какого протокола мы хотим перенести в другую RIB. {% hint style="info" %} Настройка Routing-Instances и Route Leaking (RIB-Groups) рассмотрена в главе по BGP, в разделе BGP Routing Policies, подглаве Filter Based Forwarding. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://netlabs.gitbook.io/juniper/7-basic-routing-concepts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.