路由匯總對MPLS的影響
我們來詳細的解讀一下，其實很好理解，這個和LDP的標簽捆綁有着密不可分的原因，
因為LDP協議會為本地所產生的路由條止捆綁標簽，然后，匯總條目同樣是本地產生的，
那么它在往外發的時候，要么是implicit-null 要么是explicit-null，反正就是空。
解：
如上圖所示:
控制層面
1 RE有一條更新，發送給RD，而此時標簽為POP,彈出，這個沒有問題
2 RD收到以后，再傳給RC時，會為此條路由捆綁上一條本地的標簽，55
3 RC收到以后，再傳給RB，同樣會捆綁上一條本地標簽44
4 RB收到以后，同樣會傳給RA。
這是一個標簽的MPLS的控制層面過程，
但是現在問題來了，
現在在RC上對這個條目進行匯總，看看會發生什么？
1 RC會發送自己的匯總條目，並且壓上標簽為POP，發送給RB，
2 RB發送這個匯總條目給RA， 壓入標簽23
數據層面
看看數據是怎么走的吧
RA訪問10.1.1.0/24這個目標是這樣的，
1 RA查自己的FIB表，一看，需要impose 標簽值為23，好，走你
2 RB收到以后，一看是個標簽包，那么查自己的LFIB表，23 對應的OUTgoing 動作是POP，
那就直接彈出，變成了IP包，直接發給RC，
3 RC收到這個IP包以后，查看自己的FIB表，一看是去往RE的，但是需要impose 標簽，值 為44，,又查看了一下LFIB表，好走你44--55 走你
4 RD查LFIB表，55---POP，好，轉出去
5 RE，最終才到達了目標主機RE的相連網段。
由此可以看出一個問題
在整個MPLS域中，數據走的並不是很順暢， 由於做了路由匯總，導致RC再次進行標簽捆綁分發，
所以說，在MPLS的網絡環境中，除了在邊界設備上做匯總，中間的設備上最好不要做匯總。因為會造成一些意想不到的后果。
我們用一個實例來看一下
全網運行EIGRP，以及MPLS，
在R5上宣告一條路由，10.1.1.0/24
然后在R3上的F0/0接口方向進行路由匯總，
我們來查看一下R3的mpls ldp bindings
可以看到，10.1.1.0/24的條目本地捆綁標簽為304，來自於鄰居4.4.4.4通行的標簽為405
當有數據經過R3時，會查詢FLIB表，入站為304，出站為405，直接進行標簽轉發
機智的你是否發現了一個小細節，
在R3上還有一個路由前綴
10.1.0.0/16，本地捆綁的標簽類型為隱含空，什么意思？
這是一條本地所產生的路由，肯定要被這樣標記的，無可厚非。
那么既然R3這樣標記了，在R2上會是什么樣呢？
還可以看到原來的10.1.1.0/24嗎？
我猜應該是看不到的，為什么？
這取決於IGP協議進行了匯總，所以你根本就看不到/24的,只能看到/16的
本地207，outgoing 動作為Pop,彈出，有點兒意思，
執行了PHP次末跳彈出，
到底是怎么回事兒呢？
咱們tracert 一下看看，數據包倒底是怎么走的吧
看到在經過R3時，進行了一次拆標簽，IP包轉發
如果我們把匯總關掉呢？
來看一下
當我把R3上的路由匯總手動關閉后，就出現了這樣的現象，直接走的都是MPLS標簽交換。
所以說，在MPLS的環境中，在一些中間設備上最好不要進行路由匯總！！！！
如果是這種單純的環境中沒有任何的影響，可以通信，但如果是MPLS VPN 的情況，將會是致命的，因為沒有標簽將無法在vpnv4的通道中被傳輸
--------------------------------
CCIE成長之路 --- 梅利