Interarea LDP
Что-то давненько я не блогал длинной и скучной нудятины про сети. Видимо, работа удовлетворяет потребности в писательстве ;)
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.
О чем речь?
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался 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:
ABR2:
Можно видеть, что маршруты к лупбекам хорошо агрегированы, а маршруты к линкам не покидают пределов своей области:
Для тестирования на PE1 и PE2 заведем VRF test и засунем в него по одному маршрутику:
PE1:
PE2:
Для того, чтобы PE1 и PE2 сообщали друг другу VPNv4 маршруты, сделаем между ними BGP-сессию, по которой будет ходить только VPNv4. Ничто не мешает использовать route reflector, можно offline RR, но в нашем случае с двумя PE обойдемся без:
PE1:
PE2:
Пока в нашем VPN коннективити нету, что не удивительно, ибо LSP у нас разорваны в точках суммаризации:
Для того, чтобы обеспечить раздачу /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):
У нас нет рабочих LSP PE1->ABR2 и PE2->ABR1. Поэтому переписывания next-hop в сторону ядра нам недостаточно. Надо переписывать next-hop в сторону периферийных областей.
Поскольку у нас все находится в одной автономной системе, то для организации "опорных точек" ABR должны быть route reflector'ами. Да, можно было бы сделать BGP confederation, но я поленился рисовать еще один пример, поэтому конфигурация с конфедерацией остается в качестве упражнения для читателя :)
Конфигурация вполне прямолинейна:
ABR1:
ABR2:
Вуаля, все волшебным образом пингается:
Итак, чем хороша такая конструкция, а чем плоха?
Хороша она тем, что мы достигли нашей основной цели: разгрузили 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) Стек меток стал глубже. Вместо привычного двухметочного стека можно наблюдать трехметочный на некоторых участках трассы:
Это объясняется просто. Верхняя метка - транспортная LDP-метка, вторая - транспортная BGP-метка, ради которой все и затевалось, и последняя, естественно, - VPN-метка.
Это во-первых означает некоторый дополнительный оверхед и, во-вторых, возможно, удастся напороться на некоторые платформенные ограничения, особенно, если сочетать нашу конструкцию TE в area 0, с LDP, вложенным в TE-туннель, и с каким-нибудь FRR вдобавок. Если постараться, меток пять можно набрать, что может привести к интересным эффектам.
Такова плата за экономию forwarding state на чистых P-роутерах. Но плата, прямо скажем, небольшая.
3) Сходимость. Как авторы драфта правильно указывают, сходимость этой конструкции BGP-шная. Можно выкручиваниемрук таймеров добиться относительно пристойного времени, но все равно это вне конкуренции с IGP.
4) Сложность и управляемость. Хмм. Я бы сказал так: сконфигурять это можно без особых проблем, но траблшутить надо привыкнуть. Это серьезный недостаток. Как сказал David Meyer из Sprint'а:
Эта конструкция не то чтобы уж совсем совсем замороченная, но она явно пытается отклониться от этих замечательных принципов.
В догонку. Интересно, что обсуждаемый драфт вызвал довольно жаркую дискуссию в 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 в ближайшем будущем
This entry was originally posted in my livejournal
Чего хотят авторы драфта? Позволить суммаризацию, но сохранить возможность построения 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 прямо сейчас, не дожидаясь милостей от
Уважаемые читатели могут сказать, что описанная конструкция разгружает 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-шная. Можно выкручиванием
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 в ближайшем будущем
This entry was originally posted in my livejournal
0 TrackBacks
Listed below are links to blogs that reference this entry: Interarea LDP.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/69
Вышла 02.txt версия драфта. Затрудняюсь ответить, что именно поменяли. Но вообще, мне драфт не нравится. Не могу сказать что именно, но что-то уебищное в нем чую нутром, чую что хуйня получится в продакшене от таких затей, особенно в плане стабильности сети.
Про описаный выебон с БГП... По-моему весьма очевидно, что такой выебон ну его нахуй. В самом драфте в кратце сказано, да добавить особо нечего. По сути это тоже самое, что и CsC. Но внутри одной АС поднимать CsC, P-роутеры (а внутри АС они ж реально P) грузить BGP'ёй не очень-то кашерно. Кто траблшутил CsC когда-нить да поймет меня.
Вообще, с нынешними ценами на пямять и процессоры я как-то трудно себе представляю огромное(!) количество проблем от роутликенга PE-шных лупбаков в кору. Складывается ощущение, что народу реально нехуй делать, а моск требует активности. :-)
Этот драфт не только во второй версии. В mpls@ietf уже Last Call на него объявили. Т.е. все движется к победному концу - к публикации в RFC и реализации вендорами.
Сама по себе стабильность от реализации этого драфта не пострадает. Нет там никаких дестабилизирующих факторов. Другое дело, что этот драфт не достигает цели в плане уменьшения количества сигнальной информации LDP - IGP меньше, а LDP в себе несет столько же. Тоже хлеб, но все равно не слишком здорово. Я об этом и о том, какие есть подходы к решению, писал: http://net-geek.org/dbg/2007/11/mpls-2007.html.
> По-моему весьма очевидно, что такой выебон ну его нахуй.
Ну, я собственно и не скрываю, что это выебон. :)
И что траблшутить это не слишком приятно, тоже написал.
Хотя если приперло, то и такое можно сделать.
Что касается гружения P-роутеров BGP, то я считаю, что это наименьшая проблема. Во-первых этот BGP требуется только на ABR, во-вторых несет в себе совсем не много маршрутов - только лупбеки, и в-третьих относительно стабилен - такого route churn, как в FV там и близко не будет. Собственно, про это написано прямо в этом посте: абзац с циферкой 1 в обсуждении недостатков этой конструкции.
> По сути это тоже самое, что и CsC
На самом деле, это скорее Inter-AS option C внутри одной AS, чем CsC, ибо в этой конструкции лупбеки идут не как vpnv4 маршруты, а как labeled ipv4. Впрочем, суть ты уловил верно, CsC и option C - родственники, если на них поглядеть повнимательней.
> я как-то трудно себе представляю огромное(!) количество проблем
Дело вот в чем. Area без суммаризации - деньги на ветер. Смысл теряется почти полностью. Если ты ликаешь лупбеки в кору и из коры, то самый практически все бенефиты от разделения на area ты потерял. Соответственно, хочется и на елку влезть, и пузо не ободрать.
> Складывается ощущение, что народу реально нехуй делать, а моск требует активности. :-)
Ну и это тоже :)