Why Summarization Is Not Recommended On Loopbacks In Case Of MPLS Environment

Introduction
This document shows the impact of summary on loopback addresses in MPLS environment.


Requirements
Prior reading to this document you should be familiar with mpls vpn environment. The most important is to know about PHP & Double PHP


Understand the current topology


As shown in the figure 1 service provider is having tier three architecture

a)Tier one consists of core which will be participating only in area 0
b)Tier two are directly connected with area 0 and local area
c)Tier three is those which are connected to tier two not directly with tier 1. Tier three is only participating in local area.

The same model is using for all the locations. Every tier 2 has allocated a pool of /16 subnet. Why /16 so that summary can be performed for area 1 to area 0. By doing summary only single route will come in area 0 and no more flaps will participate in spf calculations. In the figure 1 PUNE is a tier two pop and aggregation of all the links which are coming from tier 3 or from local PUNE. A schematic ip pool of 10.1.0.0/16 is allocated to PUNE Provisioning team and further this pool is divided into 255 multiple networks of /24 like given below

10.1.1.0/24
10.1.2.0/24
10.1.3.0/24

Every /24 is allocated to each pop. 10.1.255.0/24 is reserved for loopback addresses & 10.1.253.0/24,10.1.252.0/24 & 10.1.252.0/24 is reserved for wan addresses.

Requirement of POP

a)OSPF as IGP
b)MP-BGP
c)Loopback address
d)Wan Addresses
e)Lan Addresses

With every /24 pool which is being given to every pop & a /32 ip address is given from 10.1.255.0/24 pool. When the routes are advertised to MP-BGP loopbacks of pop routers are used for next-hop. It means ldp is performing on loopback addresses.

Note:- That's why labels are always advertised for loopback addresses not for all the routes.


Performing Summary

Now the time has come to do the summary on PUNE routers so that the number of routes must decrease from the core. Prior to this everything is working fine. But as soon as the summary performs the whole PUNE vpn customers went into the dark. They are not able to access their VPN'S across country. What's the reason for this? Routes are learning properly, IGPs are reachable but what happen to vpn customers?


The reason for black hole

In my PHP post I cleared mentioned that the Penultimate Hop Popping will occur only for directly connected & summary routes. It means every router is giving implicit null to the adjacent router for its loopback address. In figure 1 T-PE2 is giving implicit null to T-PE1 for its loopback 10.1.255.2. It means when the packet destined to 10.1.255.2 will come to T-PE1 it will simply remove the upper label which is IGP label and forward the packet with vpn label. On reaching T-PE2 it will the vpn label which is getting from one of its interfaces and forwards the packets towards it.


Now what happened in case of summarization at ABR. On ABR summary is performed for 10.1.0.0/16 pool which also includes your loopback addresses. As soon as the summary announced on ABR, a implicit null was announced to the directly connected peers in area 0. When any of the packet has to reach to pune region from any of the other locations they know they are getting /16 pool from the PUNE ABR and packet is forwarded towards the destination. When the packet reaches to TIER 1 routers they know they are getting implicit null form PUNE router; It means they need to do the PHP. So they removed the IGP label and forward the packet with VPN label. When the packet reached to PUNE ABR and check the label which is actually a VPN label but that VPN is not attached to PUNE router consensus packet started drops.


Workaround

Either perform the summary for which excludes your loopback addresses. Second method is used all together different pool for ip addresses which will never participate in summarization.


regards
shivlu jain

People who read this post also read :