4.1) Смена типов областей и Load Balancing

Схема сети

Для примера работы областей настроим распространение Direct-маршрута в Area 2 и распространим эту сеть по OSPF (Воображаемая сеть с протоколом RIP):

RT.VVK.NOV#

set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24
set policy-options policy-statement RIP_ORIGINATE from protocol direct
set policy-options policy-statement RIP_ORIGINATE then accept
set protocols ospf export RIP_ORIGINATE

Stub Area и Totally-Stub Area

Так как Area1 является полностью тупиковой (в ней нет маршрутизаторов, которые распространяют маршруты, полученные от других протоколов, по OSPF), то можно настроить её как Stub Area, а, затем, и как Totally-Stub Area.

Для этого на каждом маршрутизаторе (ABR в том числе), который принадлежит Area1 нужно указать, атрибут stub:

RT.MSK.M8#

set protocols ospf area 1 stub

Однако, после коммита, исчезнут все External-маршруты, а дефолтный к ABR так и не появится. Для этого на ABR (RT.MSK.M9) надо явно объявить анонсирование Default-маршрута в эту Area и выбрать для него метрику:

RT.MSK.M9#

set protocols ospf area 1 stub default-metric 5

Теперь же вместо External-маршрутов появился маршрут по умолчанию через ABR:

Можно ещё больше сократить таблицу маршрутизации, убрав Inter маршруты и перестав анонсировть LSA3 в область, для этого на ABR для этой области нужно указать атрибут no-summaries:

RT.MSK.M9#

set protocols ospf area 1 stub no-summaries

Теперь таблица маршрутизации выглядит так:

Not-So-Stubby Area (NSSA)

Если мы хотим распространять маршруты, полученные от других протоколов маршрутизации в этой области, но при этом нам не нужно хранить маршруты от других областей, то можно настроить NSSA (аналогично на всех роутерах в этой Area):

set protocols ospf area 2 nssa

Далее необходимо настроить ABR для работы с LSA7 и отменить передачу LSA3 в область, если нужно:

RT.SPB.LNX#

set protocols ospf area 2 nssa no-summaries
set protocols ospf area 2 nssa default-lsa default-metric 5
set protocols ospf area 2 nssa default-lsa metric-type 1

В данном примере показано, что мы запретили распространение LSA3 в этой области (1 строка), добавили распространение маршрута по умолчанию через ABR (2 строка) и выбрали первый тип метрики (строка 3). Эта метрика складывает стоимость внешнего маршрута со стоимостью пути до ASBR, в то время как вторая (стандартная) учитывает только стоимость внешнего маршрута.

По итогу таблица маршрутизации на RT.EKB.LEN выглядит так:

Видно, что по LSA7 мы получаем маршруты от ASBR внутри области и, при этом имеем один маршрут Inter из области через RT.SPB.LNX, так как у него default-metric=5, а у RT.SPB.MIR default-metric=15.

Вот что будет, если сменить у RT.SPB.LNX default-metric на 30 (трафик пойдёт через RT.SPB.MIR):

При этом линк в сторону RIP пингуется:

Load Balancing

Балансировка трафика. Тут всё просто. Балансировка будет только если до Destination IP есть несколько путей с одинаковой метрикой. Настроим балансировку:

policy-options {
    policy-statement LoadBalancing {
        from protocol ospf;
        then {
            load-balance per-packet;
        }
    }
}
routing-options {
    forwarding-table {
        export LoadBalancing;
    }
}

После этого проверим сколько записей у нас сохранилось для маршрута с RT.SPB.LNX до LoopBack-адреса RT.SPB.STL и произведём трассировку:

[e-mail]# run show route 10.0.0.200    

inet.0: 49 destinations, 57 routes (49 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.200/32      *[OSPF/10] 09:29:46, metric 2
                    > to 10.0.0.14 via ae0.0
                      to 10.0.0.6 via ae3.0

[edit]
[e-mail]# run traceroute 10.0.0.200 
traceroute to 10.0.0.200 (10.0.0.200), 30 hops max, 40 byte packets
 1  10.0.0.6 (10.0.0.6)  1.405 ms  0.830 ms 10.0.0.14 (10.0.0.14)  1.320 ms
 2  10.0.0.200 (10.0.0.200)  4.198 ms  1.556 ms  1.397 ms

[edit]
[e-mail]# run traceroute 10.0.0.200    
traceroute to 10.0.0.200 (10.0.0.200), 30 hops max, 40 byte packets
 1  10.0.0.14 (10.0.0.14)  1.383 ms  1.473 ms 10.0.0.6 (10.0.0.6)  1.528 ms
 2  10.0.0.200 (10.0.0.200)  1.550 ms  1.406 ms  1.454 ms

Собственно тут всё видно. Для одного маршрута появилось два Next-Hop'а, через которые мы периодически и ходим.

Это было настроено в главе про BGP, поэтому Load Balancing не включен в конфигурации устройств. Также можно не конфигурировать в policy-statement LoadBalancing поле from, тогда балансировка будет работать для всех протоколов, вообще.