MPLS LSPs & Summarization
Не так давно ув. dbg сообщал о способах введения суммаризации в MPLS ядрах. Вот где-то в этих окрестностях:
http://dbg.livejournal.com/70327.html
Так вот что подумалось:
Еще тогда меня зацепила мысль: "можно использовать Inter-Area MPLS TE, но масштабируемость этой схемы оставляет желать лучшего". Почему - вроде очевидно: InterArea TE туннели прошивают все роутеры ядра и число FW state растет безобразно быстро (есть и еще минусы, об них позже). От всего этого можно было бы тут и забить на идейку, но! Вспоминается такой хороший документ как RFC 4206:
"Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"
Оццы не подкачали, короче говоря. Идея, как обычно, проста и очевидна ;). Вместо того, чтобы тянуть все PE-PE MPLS TE туннели вчистую через ядро, мы укладываем их внутрь уже готовой сетки туннелей в ядре. Ну например (см. картинку у dbg) в Area 0 строим full-mesh из TE туннелей между ABR, а между Area 1 и Area 2 PEs тянем туннели так чтобы они легли внутри сетки, покрывающей Area 0.
Таким образом, ядро знает лишь о своей full-mesh топологии туннелей, а все что ходит внутри этой паутины ему по барабану.
Остались две беды. Во-первых, как я понял для себя, RFC 4206 и недецкий GMPLS у циски наблюдается только в IOS XR. Так что пощупать его морду в лабораторных условиях у меня не выходит :) Да, в IOS есть просто MPLS TE FA, но уложить в него LSP увы не выходит :) Впрочем на эту беду есть workaround, который я сегодня и прогнал на 7200. Об workaround чуть ниже :)
Вторая беда. Хоть мы и решили проблему с ростом FW state, остаются еще мелочи: сигнальный оверхед на поддержание всех MPLS TE туннелей (вложенных) плюс еще небольшая головная боль в виде лишних меток из-за вложенности LSP.
А теперь workaround. Очень тупой, скажем прямо. Вместо MPLS TE туннелей в "ядре" прокидываем GRE туннели между ABR и уже в них закладываем MPLS TE. Традиционно, роль транспортной метки ядра играет GRE header, ну и дальше все очевидно.
Хотел еще что-то написать, но уже лень :)
http://dbg.livejournal.com/70327.html
Так вот что подумалось:
Еще тогда меня зацепила мысль: "можно использовать Inter-Area MPLS TE, но масштабируемость этой схемы оставляет желать лучшего". Почему - вроде очевидно: InterArea TE туннели прошивают все роутеры ядра и число FW state растет безобразно быстро (есть и еще минусы, об них позже). От всего этого можно было бы тут и забить на идейку, но! Вспоминается такой хороший документ как RFC 4206:
"Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"
Оццы не подкачали, короче говоря. Идея, как обычно, проста и очевидна ;). Вместо того, чтобы тянуть все PE-PE MPLS TE туннели вчистую через ядро, мы укладываем их внутрь уже готовой сетки туннелей в ядре. Ну например (см. картинку у dbg) в Area 0 строим full-mesh из TE туннелей между ABR, а между Area 1 и Area 2 PEs тянем туннели так чтобы они легли внутри сетки, покрывающей Area 0.
Таким образом, ядро знает лишь о своей full-mesh топологии туннелей, а все что ходит внутри этой паутины ему по барабану.
Остались две беды. Во-первых, как я понял для себя, RFC 4206 и недецкий GMPLS у циски наблюдается только в IOS XR. Так что пощупать его морду в лабораторных условиях у меня не выходит :) Да, в IOS есть просто MPLS TE FA, но уложить в него LSP увы не выходит :) Впрочем на эту беду есть workaround, который я сегодня и прогнал на 7200. Об workaround чуть ниже :)
Вторая беда. Хоть мы и решили проблему с ростом FW state, остаются еще мелочи: сигнальный оверхед на поддержание всех MPLS TE туннелей (вложенных) плюс еще небольшая головная боль в виде лишних меток из-за вложенности LSP.
А теперь workaround. Очень тупой, скажем прямо. Вместо MPLS TE туннелей в "ядре" прокидываем GRE туннели между ABR и уже в них закладываем MPLS TE. Традиционно, роль транспортной метки ядра играет GRE header, ну и дальше все очевидно.
Хотел еще что-то написать, но уже лень :)