While studying for my CCIE in the section of MPLS L3 VPN I was reading all the time that we should configure the MP-BGP on the /32 loopback interfaces, But it wasn’t so clear WHY?. So I decided to practice it in a lab and know what will happen if we configured the MP-BGP to be on the connected interfaces.
Once I did that – look at the topology figure – I faced a reachability problem when I tried to reach CE2 from CE1 or in the opposite direction.
Before continuing with the problem we should know about PHP operation that most of us ignore or think it’s trivial in the MPLS…
PHP is penultimate hop popping which means remove the label one hop before its destination. The Edge LSR sends label #3 “implicit-null” to his neighbors for all the directly connected interfaces and summary addresses, so that when the neighbor receive a packet with this destination the PHP will be done.
Lets go back to our main problem, I know that most of you figured out what is the reason of the reachability problem.Unfortunately the control plan is OK and the real problem is in the forwarding itself. look at the below topology:
During establishing LSPs, ELSR2 will send a VPN label for CE2 to ELSR1 using MP-BGP so that when we do show ip route CE2 network we will find that the route is known via BGP and the next hop is ELSR2 P1/0 interface which is known via IGP “IS-IS or OSPF”.
For the IGP control plan LSR see that ELSR2 P1/0 interface is directly connected to it so it sends label# 3 “implicit-null” to ELSR1 due to PHP which is ON by default and can not be disabled.
Lets assume that CE1 wants to reach CE2, that IP packet will arrive to ELSR1 and it starts to build the label stack by imposing the VPN label and it will find that it received “implicit-null” from LSR as we mentioned before, so that the packet will arrive to LSR with only the VPN label which it doesn’t know anything about it so the packet will be dropped.
In the other hand what will happen if we configured the MP-BGP to be on loopbacks?
The ELSR1 will know the route via BGP with next hop loopback address which is not directly connected to LSR so that ELSR2 will send a LDP label# 3 “implicit-null” to LSR and LSR will send a LDP label “random number” to ELSR1, so that LSR will receive a labeled packet that it knows.
Hi OS !
It’s a perfect note about the PHP behaviour. Some call it PHP too soon.
I have a Comment & a Question:
you mentioned (& it’s true) that we should configure the MP-BGP on the /32 loopback int.
You had clarified the reason for using the loopback perfectly.
My Question is: Do we have to use “/32” mask ? (while PHP is ON)
Or
The more specific question is:
When we should use this specific mask & when it’s not mandatory ? (while PHP is ON)
Thanks OS for this great topic.
Hi Tarek!!
To use /32 is the best practice to avoid routing mess behavior, You know we are not talking about Cisco only we are talking standard, so you have to know that in all vendors except Cisco the LDP will label only the /32 routes… I think it is clear now.
Note: PHP is ON by default and can’t be disabled unless you did manual labeling.
OS-OS :),
This is a new information for me, about labeling technique with LDP from other vendor other than Cisco, & i think it’s more efficiently.
I was talking about cisco here. My point is something that happens in OSPF but not in IS-IS, here:
In OSPF, when advertise the loopback, it “always” advertise this network of /32 whatever the real (current) mask it was. At the same time, in Cisco (at least) LDP advertise all networks with their real (current) mask.
The Cisco router should receive the same network through both OSPF & LDP to match. in case of any mask other than /32 on the loopback, the cisco router will receive 2 different network (because it been received as a different mask)from its perspective. So, it won’t work as a MPLS LSP path.
T. H.
It is also new information for me, this is another thing that makes me fall in love wit IS-IS
🙂