(no subject)
Что-то давненько я не блогал длинной и скучной нудятины про сети. Видимо, работа удовлетворяет потребности в писательстве ;)
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.
О чем речь?
Пусть есть сеть с MPLS'м. В ней есть какой-нибудь IGP: OSPF или IS-IS, не важно. Чтобы MPLS нормально работал в этой сети, /32 адреса лупбеков всех PE-роутеров должны ходить по всей сети россыпью. Это означает, что суммаризовать сети лупбеков на границе областей нельзя. А невозможность суммаризации, по большому счету, убивает саму идею разбиения сети на области - смысл пропадает. Обидно. Понятно, что по нынешним временам в одну область можно запихать много, очень много роутеров, но все-таки не бесконечно много. И однажды сеть перерастет одную область и тогда ой.
Чего хотят авторы драфта? Позволить суммаризацию, но сохранить возможность построения LDP LSP от PE в одной области до PE в другой. Каким образом? Они предлагают изменить процедуру назначения метки для FEC: вместо требуемого по RFC 3036 exact match, они разрешают longest match, и получается, что LDP может построить непрерывный LSP даже в присутствии суммаризации. Круто? Круто.
А можно ли сделать что-то прямо сегодня для того, чтобы разрешить суммаризацию на границах областей, но не поломать end-to-end LSP? Можно. Сами авторы драфта называют два способа: inter-area TE и BGP, как протокол распространения меток. Они называют еще и третий: route leaking - т.е. операцию обратную суммаризации, что как я уже упоминал, сводит затею с разбиением сети на области на нет.
С inter-area TE все понятно: настраивается все как обычно, но сеть начинает упираться уже не в масшатируемость IGP, а в количество TE тоннелей, проходящих через ядро. Причем она упрется в этот предел гораздо раньше, чем в масштабируемость одной области OSPF'а или IS-IS'а.
А с BGP-based решением мы сейчас разберемся.
Идея проста: LDP и RSVP - не единственные протоколы распростанения транспортных меток. Транспортную метку вполне может раздать и по BGP c помощью ipv4+label address family. При этом можно сделать и области, и суммаризацию на их границах, а межобластное распространение /32 и меток для них вынести в BGP. Этим мы разгрузим наш IGP. У такой схемы есть определенные недостатки, но до них мы доберемся ниже, когда будем анализировать масштабируемость, сходимость и управляемость.
Для бесчеловечного эксперимента сделаем небольшой стенд:
IGP-маршрутизация в нем настроена вот так (показаны только конфиги ABR1 и ABR2, на остальных все тривиально):
ABR1:
router ospf 1
log-adjacency-changes
area 0 range 10.0.0.0 255.255.255.0
area 0 range 192.168.0.0 255.255.255.0 not-advertise
area 1 range 10.0.1.0 255.255.255.0
area 1 range 192.168.1.0 255.255.255.0 not-advertise
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 1
ABR2:
router ospf 1
log-adjacency-changes
area 0 range 10.0.0.0 255.255.255.0
area 0 range 192.168.0.0 255.255.255.0 not-advertise
area 2 range 10.0.2.0 255.255.255.0
area 2 range 192.168.2.0 255.255.255.0 not-advertise
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 2
Можно видеть, что маршруты к лупбекам хорошо агрегированы, а маршруты к линкам не покидают пределов своей области:
PE1#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.2.0/24 [110/257] via 192.168.1.1, 12:15:52, Serial0/0.102
O IA 10.0.0.0/24 [110/65] via 192.168.1.1, 12:15:52, Serial0/0.102
PE2#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.0.0/24 [110/65] via 192.168.2.0, 12:16:21, Serial0/0.504
O IA 10.0.1.0/24 [110/257] via 192.168.2.0, 12:16:20, Serial0/0.504
P#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O IA 10.0.2.0/24 [110/129] via 192.168.0.3, 12:16:36, Serial0/0.304
O 10.0.0.2/32 [110/65] via 192.168.0.3, 12:16:36, Serial0/0.304
O IA 10.0.1.0/24 [110/129] via 192.168.0.0, 12:16:31, Serial0/0.302
O 10.0.0.1/32 [110/65] via 192.168.0.0, 12:16:36, Serial0/0.302
Для тестирования на PE1 и PE2 заведем VRF test и засунем в него по одному маршрутику:
PE1:
ip vrf test
rd 100:1
route-target export 100:1
route-target import 100:1
!
interface Loopback666
ip vrf forwarding test
ip address 1.1.1.1 255.255.255.255
PE2:
ip vrf test
rd 100:1
route-target export 100:1
route-target import 100:1
!
interface Loopback666
ip vrf forwarding test
ip address 2.2.2.2 255.255.255.255
Для того, чтобы PE1 и PE2 сообщали друг другу VPNv4 маршруты, сделаем между ними BGP-сессию, по которой будет ходить только VPNv4. Ничто не мешает использовать route reflector, можно offline RR, но в нашем случае с двумя PE обойдемся без:
PE1:
router bgp 100
neighbor 10.0.2.1 remote-as 100
neighbor 10.0.2.1 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.2.1 activate
neighbor 10.0.2.1 send-community extended
exit-address-family
!
address-family ipv4 vrf test
redistribute connected
no auto-summary
no synchronization
exit-address-family
PE2:
router bgp 100
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.1.1 activate
neighbor 10.0.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf test
redistribute connected
no auto-summary
no synchronization
exit-address-family
Пока в нашем VPN коннективити нету, что не удивительно, ибо LSP у нас разорваны в точках суммаризации:
PE1#ping vrf test 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Для того, чтобы обеспечить раздачу /32 и меток, сделаем структуру BGP сессий специально для этой цели. Эта структура не несет VPNv4 маршуртов, она даже не обязана нести IPv4 маршруты обычного интернета - для этого можно сделать отдельную структуру сессий со своими отдельными RR и т.п. Единственная задача этой структуры сессий - распространение транспортных меток посредством BGP. Ну и запихаем в нее маршруты к нашим /32.
Почему схема такая? Все дело в том, что нам нужны, так сказать, "опорные точки", в которых мы будем переписывать next-hop наших labeled IPv4 маршрутов. На это есть две причины:
1) Первая - сугубо техническая: при редистрибуции /32 из OSPF в BGP next-hop будет тем же, что у OSPF-маршрута, т.е. из сети 192.168.1.0/31 или 192.168.2.0/31. Эти сети не покидают пределы своей области, как было показано выше, следовательно такой next-hop неприемлем. Поэтому на роутерах ABR1 и ABR2 мы переписываем next-hop в сторону ядра.
2) Вторая причина важнее.
Процитирую RFC 3107 (Carrying Label Information in BGP-4):
Consider the following LSR topology: A--B--C--D. Suppose that D distributes a label L to A. In this topology, A cannot simply push L onto a packet's label stack, and then send the resulting packet to B. D must be the only LSR that sees L at the top of the stack. Before A sends the packet to B, it must push on another label, which was distributed by B. B must replace this label with yet another label, which was distributed by C. In other words, there must be an LSP between A and D. If there is no such LSP, A cannot make use of label L.
У нас нет рабочих LSP PE1->ABR2 и PE2->ABR1. Поэтому переписывания next-hop в сторону ядра нам недостаточно. Надо переписывать next-hop в сторону периферийных областей.
Поскольку у нас все находится в одной автономной системе, то для организации "опорных точек" ABR должны быть route reflector'ами. Да, можно было бы сделать BGP confederation, но я поленился рисовать еще один пример, поэтому конфигурация с конфедерацией остается в качестве упражнения для читателя :)
Конфигурация вполне прямолинейна:
ABR1:
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal route-map lo2bgp
neighbor 10.0.0.2 remote-as 100
neighbor 10.0.0.2 update-source Loopback0
neighbor 10.0.0.2 route-map to-core out
neighbor 10.0.0.2 send-label
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source Loopback0
neighbor 10.0.1.1 route-reflector-client
neighbor 10.0.1.1 route-map to-area-1 out
neighbor 10.0.1.1 send-label
no auto-summary
!
ip prefix-list area-1-loopbacks seq 5 permit 10.0.1.0/24 ge 32
!
route-map to-core permit 10
match ip address prefix-list area-1-loopbacks
set ip next-hop peer-address
set mpls-label
!
route-map to-area-1 deny 10
match ip address prefix-list area-1-loopbacks
!
route-map to-area-1 permit 20
set ip next-hop peer-address
set mpls-label
!
route-map lo2bgp permit 10
match ip address prefix-list area-1-loopbacks
ABR2:
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal route-map lo2bgp
neighbor 10.0.0.1 remote-as 100
neighbor 10.0.0.1 update-source Loopback0
neighbor 10.0.0.1 route-map to-core out
neighbor 10.0.0.1 send-label
neighbor 10.0.2.1 remote-as 100
neighbor 10.0.2.1 update-source Loopback0
neighbor 10.0.2.1 route-reflector-client
neighbor 10.0.2.1 route-map to-area-2 out
neighbor 10.0.2.1 send-label
no auto-summary
!
ip prefix-list area-2-loopbacks seq 5 permit 10.0.2.0/24 ge 32
!
route-map to-core permit 10
match ip address prefix-list area-2-loopbacks
set ip next-hop peer-address
set mpls-label
!
route-map to-area-2 deny 10
match ip address prefix-list area-2-loopbacks
!
route-map to-area-2 permit 20
set ip next-hop peer-address
set mpls-label
!
route-map lo2bgp permit 10
match ip address prefix-list area-2-loopbacks
Вуаля, все волшебным образом пингается:
PE1#ping vrf test 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/63/108 ms
Итак, чем хороша такая конструкция, а чем плоха?
Хороша она тем, что мы достигли нашей основной цели: разгрузили IGP. В IGP у нас теперь все хорошо агрегировано, маршрутиков мало, ничего лишнего. И, главное, мы можем, если припрет, решить проблему масштабируемости IGP прямо сейчас, не дожидаясь милостей от природы IETF и вендоров.
Уважаемые читатели могут сказать, что описанная конструкция разгружает IGP, но все равно создает forwarding state на роутерах сети, соответвествующий количеству /32. Это так. Но и обсуждаемый драфт делает то же самое. Несмотря на то, что /32 не попадают в IP FIB, соотвествующие им метки все равно живут в LFIB. При этом draft-ietf-mpls-ldp-interarea создает forwarding state на всех роутерах, включая чистые P-роутеры внутри области (в нашем стенде роутер P, который прямо посередине картинки). В нашей конструкции такого не происходит. Роутер P у нас вообще не участвует ни в каком BGP и весь его forwaring state состоит из intra-area маршрутов, агрегированных inter-area и соответствующих им LDP-меток.
То же самое касается объема сигнализации, в которой прнимает участие чистый P-роутер внутри области. В конструкции draft-ietf-mpls-ldp-interarea роутер P будет участвовать в довольно объемной LDP сигнализации, а в нашей конструкции объем сигнализации этого роутера ограничен.
Но бесплатных пирожных не бывает, есть кое-какие недостатки по сравнению с draft-ietf-mpls-ldp-interarea:
1) У нас возник BGP на ABR. Если это чистый P-роутер, то BGP там не нужен. Стоит ли этого бояться? Речь идет о единицах тысяч /32 маршрутов, максимум о малых десяках тысяч. Это серьезная проблема для IGP, но плевое дело для BGP. Как я уже упоминал, ABR, выступающие в роли route reflector'ов, обязаны нести только labeled /32, а не VPNv4 или интернетную таблицу. Поэтому ничего страшного здесь нет.
Как я уже упоминал, на маршрутизаторе P, который чистый core router в area 0, нет вообще никакого BGP. Если б нашем стенде были чистые P-роутеры в периферийных областях, то то же самое касалось бы их.
2) Стек меток стал глубже. Вместо привычного двухметочного стека можно наблюдать трехметочный на некоторых участках трассы:
PE1#trace vrf test 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 192.168.1.1 [MPLS: Labels 21/18 Exp 0] 128 msec 172 msec 100 msec
2 192.168.0.1 [MPLS: Labels 17/16/18 Exp 0] 100 msec 100 msec 108 msec
3 192.168.0.3 [MPLS: Labels 16/18 Exp 0] 112 msec 148 msec 124 msec
4 2.2.2.2 68 msec * 60 msec
Это объясняется просто. Верхняя метка - транспортная LDP-метка, вторая - транспортная BGP-метка, ради которой все и затевалось, и последняя, естественно, - VPN-метка.
Это во-первых означает некоторый дополнительный оверхед и, во-вторых, возможно, удастся напороться на некоторые платформенные ограничения, особенно, если сочетать нашу конструкцию TE в area 0, с LDP, вложенным в TE-туннель, и с каким-нибудь FRR вдобавок. Если постараться, меток пять можно набрать, что может привести к интересным эффектам.
Такова плата за экономию forwarding state на чистых P-роутерах. Но плата, прямо скажем, небольшая.
3) Сходимость. Как авторы драфта правильно указывают, сходимость этой конструкции BGP-шная. Можно выкручиванием рук таймеров добиться относительно пристойного времени, но все равно это вне конкуренции с IGP.
4) Сложность и управляемость. Хмм. Я бы сказал так: сконфигурять это можно без особых проблем, но траблшутить надо привыкнуть. Это серьезный недостаток. Как сказал David Meyer из Sprint'а:
Three S’s
* Simple
NOC Staff can operate it
* Sane
Don’t have to be a PhD to understand and troubleshoot the routing
* Supportable
If it takes twelve hours to figure out what’s wrong, something isn't right...
Эта конструкция не то чтобы уж совсем совсем замороченная, но она явно пытается отклониться от этих замечательных принципов.
В догонку. Интересно, что обсуждаемый драфт вызвал довольно жаркую дискуссию в mpls@ietf.org. В том числе по поводу принятия его в качестве WG-документа. Из вендоров в поддержку выступили люди из Juniper (что неудивительно, поскольку Ina Minei (одна из авторов) работает в Juniper'е), Huawei, ECI, Alcatel и еще кто-то. А вот из Cisco многие (не все) высказались против.
Кажется, я догадываюсь, в чем проблема. Дело в том, что цискина реализация LDP поддерживает только independent control mode, а этот драфт требует на некоторых участах LSP ordered control. А именно: после суммаризации, следующий роутер не знает ничего о существовании деагрегированного FEC, он может узнать о нем только по приходу соотвествующего LDP binding, что по сути дела исключает independent control. Учитывая этот факт и существование альтернативного решения, похоже, не стоит ждать реализации от Cisco в ближайшем будущем.
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.
О чем речь?
Пусть есть сеть с MPLS'м. В ней есть какой-нибудь IGP: OSPF или IS-IS, не важно. Чтобы MPLS нормально работал в этой сети, /32 адреса лупбеков всех PE-роутеров должны ходить по всей сети россыпью. Это означает, что суммаризовать сети лупбеков на границе областей нельзя. А невозможность суммаризации, по большому счету, убивает саму идею разбиения сети на области - смысл пропадает. Обидно. Понятно, что по нынешним временам в одну область можно запихать много, очень много роутеров, но все-таки не бесконечно много. И однажды сеть перерастет одную область и тогда ой.
Чего хотят авторы драфта? Позволить суммаризацию, но сохранить возможность построения LDP LSP от PE в одной области до PE в другой. Каким образом? Они предлагают изменить процедуру назначения метки для FEC: вместо требуемого по RFC 3036 exact match, они разрешают longest match, и получается, что LDP может построить непрерывный LSP даже в присутствии суммаризации. Круто? Круто.
А можно ли сделать что-то прямо сегодня для того, чтобы разрешить суммаризацию на границах областей, но не поломать end-to-end LSP? Можно. Сами авторы драфта называют два способа: inter-area TE и BGP, как протокол распространения меток. Они называют еще и третий: route leaking - т.е. операцию обратную суммаризации, что как я уже упоминал, сводит затею с разбиением сети на области на нет.
С inter-area TE все понятно: настраивается все как обычно, но сеть начинает упираться уже не в масшатируемость IGP, а в количество TE тоннелей, проходящих через ядро. Причем она упрется в этот предел гораздо раньше, чем в масштабируемость одной области OSPF'а или IS-IS'а.
А с BGP-based решением мы сейчас разберемся.
Идея проста: LDP и RSVP - не единственные протоколы распростанения транспортных меток. Транспортную метку вполне может раздать и по BGP c помощью ipv4+label address family. При этом можно сделать и области, и суммаризацию на их границах, а межобластное распространение /32 и меток для них вынести в BGP. Этим мы разгрузим наш IGP. У такой схемы есть определенные недостатки, но до них мы доберемся ниже, когда будем анализировать масштабируемость, сходимость и управляемость.
Для бесчеловечного эксперимента сделаем небольшой стенд:
IGP-маршрутизация в нем настроена вот так (показаны только конфиги ABR1 и ABR2, на остальных все тривиально):
ABR1:
router ospf 1
log-adjacency-changes
area 0 range 10.0.0.0 255.255.255.0
area 0 range 192.168.0.0 255.255.255.0 not-advertise
area 1 range 10.0.1.0 255.255.255.0
area 1 range 192.168.1.0 255.255.255.0 not-advertise
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 1
ABR2:
router ospf 1
log-adjacency-changes
area 0 range 10.0.0.0 255.255.255.0
area 0 range 192.168.0.0 255.255.255.0 not-advertise
area 2 range 10.0.2.0 255.255.255.0
area 2 range 192.168.2.0 255.255.255.0 not-advertise
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 2
Можно видеть, что маршруты к лупбекам хорошо агрегированы, а маршруты к линкам не покидают пределов своей области:
PE1#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.2.0/24 [110/257] via 192.168.1.1, 12:15:52, Serial0/0.102
O IA 10.0.0.0/24 [110/65] via 192.168.1.1, 12:15:52, Serial0/0.102
PE2#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.0.0/24 [110/65] via 192.168.2.0, 12:16:21, Serial0/0.504
O IA 10.0.1.0/24 [110/257] via 192.168.2.0, 12:16:20, Serial0/0.504
P#sh ip ro ospf
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O IA 10.0.2.0/24 [110/129] via 192.168.0.3, 12:16:36, Serial0/0.304
O 10.0.0.2/32 [110/65] via 192.168.0.3, 12:16:36, Serial0/0.304
O IA 10.0.1.0/24 [110/129] via 192.168.0.0, 12:16:31, Serial0/0.302
O 10.0.0.1/32 [110/65] via 192.168.0.0, 12:16:36, Serial0/0.302
Для тестирования на PE1 и PE2 заведем VRF test и засунем в него по одному маршрутику:
PE1:
ip vrf test
rd 100:1
route-target export 100:1
route-target import 100:1
!
interface Loopback666
ip vrf forwarding test
ip address 1.1.1.1 255.255.255.255
PE2:
ip vrf test
rd 100:1
route-target export 100:1
route-target import 100:1
!
interface Loopback666
ip vrf forwarding test
ip address 2.2.2.2 255.255.255.255
Для того, чтобы PE1 и PE2 сообщали друг другу VPNv4 маршруты, сделаем между ними BGP-сессию, по которой будет ходить только VPNv4. Ничто не мешает использовать route reflector, можно offline RR, но в нашем случае с двумя PE обойдемся без:
PE1:
router bgp 100
neighbor 10.0.2.1 remote-as 100
neighbor 10.0.2.1 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.2.1 activate
neighbor 10.0.2.1 send-community extended
exit-address-family
!
address-family ipv4 vrf test
redistribute connected
no auto-summary
no synchronization
exit-address-family
PE2:
router bgp 100
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.1.1 activate
neighbor 10.0.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf test
redistribute connected
no auto-summary
no synchronization
exit-address-family
Пока в нашем VPN коннективити нету, что не удивительно, ибо LSP у нас разорваны в точках суммаризации:
PE1#ping vrf test 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Для того, чтобы обеспечить раздачу /32 и меток, сделаем структуру BGP сессий специально для этой цели. Эта структура не несет VPNv4 маршуртов, она даже не обязана нести IPv4 маршруты обычного интернета - для этого можно сделать отдельную структуру сессий со своими отдельными RR и т.п. Единственная задача этой структуры сессий - распространение транспортных меток посредством BGP. Ну и запихаем в нее маршруты к нашим /32.
Почему схема такая? Все дело в том, что нам нужны, так сказать, "опорные точки", в которых мы будем переписывать next-hop наших labeled IPv4 маршрутов. На это есть две причины:
1) Первая - сугубо техническая: при редистрибуции /32 из OSPF в BGP next-hop будет тем же, что у OSPF-маршрута, т.е. из сети 192.168.1.0/31 или 192.168.2.0/31. Эти сети не покидают пределы своей области, как было показано выше, следовательно такой next-hop неприемлем. Поэтому на роутерах ABR1 и ABR2 мы переписываем next-hop в сторону ядра.
2) Вторая причина важнее.
Процитирую RFC 3107 (Carrying Label Information in BGP-4):
Consider the following LSR topology: A--B--C--D. Suppose that D distributes a label L to A. In this topology, A cannot simply push L onto a packet's label stack, and then send the resulting packet to B. D must be the only LSR that sees L at the top of the stack. Before A sends the packet to B, it must push on another label, which was distributed by B. B must replace this label with yet another label, which was distributed by C. In other words, there must be an LSP between A and D. If there is no such LSP, A cannot make use of label L.
У нас нет рабочих LSP PE1->ABR2 и PE2->ABR1. Поэтому переписывания next-hop в сторону ядра нам недостаточно. Надо переписывать next-hop в сторону периферийных областей.
Поскольку у нас все находится в одной автономной системе, то для организации "опорных точек" ABR должны быть route reflector'ами. Да, можно было бы сделать BGP confederation, но я поленился рисовать еще один пример, поэтому конфигурация с конфедерацией остается в качестве упражнения для читателя :)
Конфигурация вполне прямолинейна:
ABR1:
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal route-map lo2bgp
neighbor 10.0.0.2 remote-as 100
neighbor 10.0.0.2 update-source Loopback0
neighbor 10.0.0.2 route-map to-core out
neighbor 10.0.0.2 send-label
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source Loopback0
neighbor 10.0.1.1 route-reflector-client
neighbor 10.0.1.1 route-map to-area-1 out
neighbor 10.0.1.1 send-label
no auto-summary
!
ip prefix-list area-1-loopbacks seq 5 permit 10.0.1.0/24 ge 32
!
route-map to-core permit 10
match ip address prefix-list area-1-loopbacks
set ip next-hop peer-address
set mpls-label
!
route-map to-area-1 deny 10
match ip address prefix-list area-1-loopbacks
!
route-map to-area-1 permit 20
set ip next-hop peer-address
set mpls-label
!
route-map lo2bgp permit 10
match ip address prefix-list area-1-loopbacks
ABR2:
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal route-map lo2bgp
neighbor 10.0.0.1 remote-as 100
neighbor 10.0.0.1 update-source Loopback0
neighbor 10.0.0.1 route-map to-core out
neighbor 10.0.0.1 send-label
neighbor 10.0.2.1 remote-as 100
neighbor 10.0.2.1 update-source Loopback0
neighbor 10.0.2.1 route-reflector-client
neighbor 10.0.2.1 route-map to-area-2 out
neighbor 10.0.2.1 send-label
no auto-summary
!
ip prefix-list area-2-loopbacks seq 5 permit 10.0.2.0/24 ge 32
!
route-map to-core permit 10
match ip address prefix-list area-2-loopbacks
set ip next-hop peer-address
set mpls-label
!
route-map to-area-2 deny 10
match ip address prefix-list area-2-loopbacks
!
route-map to-area-2 permit 20
set ip next-hop peer-address
set mpls-label
!
route-map lo2bgp permit 10
match ip address prefix-list area-2-loopbacks
Вуаля, все волшебным образом пингается:
PE1#ping vrf test 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/63/108 ms
Итак, чем хороша такая конструкция, а чем плоха?
Хороша она тем, что мы достигли нашей основной цели: разгрузили IGP. В IGP у нас теперь все хорошо агрегировано, маршрутиков мало, ничего лишнего. И, главное, мы можем, если припрет, решить проблему масштабируемости IGP прямо сейчас, не дожидаясь милостей от природы IETF и вендоров.
Уважаемые читатели могут сказать, что описанная конструкция разгружает IGP, но все равно создает forwarding state на роутерах сети, соответвествующий количеству /32. Это так. Но и обсуждаемый драфт делает то же самое. Несмотря на то, что /32 не попадают в IP FIB, соотвествующие им метки все равно живут в LFIB. При этом draft-ietf-mpls-ldp-interarea создает forwarding state на всех роутерах, включая чистые P-роутеры внутри области (в нашем стенде роутер P, который прямо посередине картинки). В нашей конструкции такого не происходит. Роутер P у нас вообще не участвует ни в каком BGP и весь его forwaring state состоит из intra-area маршрутов, агрегированных inter-area и соответствующих им LDP-меток.
То же самое касается объема сигнализации, в которой прнимает участие чистый P-роутер внутри области. В конструкции draft-ietf-mpls-ldp-interarea роутер P будет участвовать в довольно объемной LDP сигнализации, а в нашей конструкции объем сигнализации этого роутера ограничен.
Но бесплатных пирожных не бывает, есть кое-какие недостатки по сравнению с draft-ietf-mpls-ldp-interarea:
1) У нас возник BGP на ABR. Если это чистый P-роутер, то BGP там не нужен. Стоит ли этого бояться? Речь идет о единицах тысяч /32 маршрутов, максимум о малых десяках тысяч. Это серьезная проблема для IGP, но плевое дело для BGP. Как я уже упоминал, ABR, выступающие в роли route reflector'ов, обязаны нести только labeled /32, а не VPNv4 или интернетную таблицу. Поэтому ничего страшного здесь нет.
Как я уже упоминал, на маршрутизаторе P, который чистый core router в area 0, нет вообще никакого BGP. Если б нашем стенде были чистые P-роутеры в периферийных областях, то то же самое касалось бы их.
2) Стек меток стал глубже. Вместо привычного двухметочного стека можно наблюдать трехметочный на некоторых участках трассы:
PE1#trace vrf test 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 192.168.1.1 [MPLS: Labels 21/18 Exp 0] 128 msec 172 msec 100 msec
2 192.168.0.1 [MPLS: Labels 17/16/18 Exp 0] 100 msec 100 msec 108 msec
3 192.168.0.3 [MPLS: Labels 16/18 Exp 0] 112 msec 148 msec 124 msec
4 2.2.2.2 68 msec * 60 msec
Это объясняется просто. Верхняя метка - транспортная LDP-метка, вторая - транспортная BGP-метка, ради которой все и затевалось, и последняя, естественно, - VPN-метка.
Это во-первых означает некоторый дополнительный оверхед и, во-вторых, возможно, удастся напороться на некоторые платформенные ограничения, особенно, если сочетать нашу конструкцию TE в area 0, с LDP, вложенным в TE-туннель, и с каким-нибудь FRR вдобавок. Если постараться, меток пять можно набрать, что может привести к интересным эффектам.
Такова плата за экономию forwarding state на чистых P-роутерах. Но плата, прямо скажем, небольшая.
3) Сходимость. Как авторы драфта правильно указывают, сходимость этой конструкции BGP-шная. Можно выкручиванием рук таймеров добиться относительно пристойного времени, но все равно это вне конкуренции с IGP.
4) Сложность и управляемость. Хмм. Я бы сказал так: сконфигурять это можно без особых проблем, но траблшутить надо привыкнуть. Это серьезный недостаток. Как сказал David Meyer из Sprint'а:
Three S’s
* Simple
NOC Staff can operate it
* Sane
Don’t have to be a PhD to understand and troubleshoot the routing
* Supportable
If it takes twelve hours to figure out what’s wrong, something isn't right...
Эта конструкция не то чтобы уж совсем совсем замороченная, но она явно пытается отклониться от этих замечательных принципов.
В догонку. Интересно, что обсуждаемый драфт вызвал довольно жаркую дискуссию в mpls@ietf.org. В том числе по поводу принятия его в качестве WG-документа. Из вендоров в поддержку выступили люди из Juniper (что неудивительно, поскольку Ina Minei (одна из авторов) работает в Juniper'е), Huawei, ECI, Alcatel и еще кто-то. А вот из Cisco многие (не все) высказались против.
Кажется, я догадываюсь, в чем проблема. Дело в том, что цискина реализация LDP поддерживает только independent control mode, а этот драфт требует на некоторых участах LSP ordered control. А именно: после суммаризации, следующий роутер не знает ничего о существовании деагрегированного FEC, он может узнать о нем только по приходу соотвествующего LDP binding, что по сути дела исключает independent control. Учитывая этот факт и существование альтернативного решения, похоже, не стоит ждать реализации от Cisco в ближайшем будущем.