В этой главе будут рассмотрены базовые концепты маршрутизации. Что-то было рассмотрено в предыдущих главах, что-то будет рассмотрено на более конкретных примерах далее. В целом, на уровне 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.
Настройка маршрутизаторов:
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: <Active Int Ext>
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: <Active Int Ext>
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. Настройка статических маршрутов с резервом
Пусть у нас останется такая же схема, балнсировку трафика уберём.
Теперь статический маршрут выглядит так:
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# 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. Тогда пакет будет просто отброшен.
Для примера можно взять практически ту же схему, немного её изменив:
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@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: <Active Int Ext>
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: <Hidden Int Ext>
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 состоит из:
Отдельная таблица маршрутизации
Интерфейсы, которые принадлежат этой таблицы (не всегда, зависит от типа 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.
Настройка Routing-Instances и Route Leaking (RIB-Groups) рассмотрена в главе по BGP, в разделе BGP Routing Policies, подглаве Filter Based Forwarding.
