Peering between PE routers using loopback

[Adnan Khan]

Can anyone explain is peering of MPiBGP between PE routers is mandetory using loopback interface or we can stablish neighbor using physical interface as well.?

[Akash Agrawal]

Hi Adnan,

For MPiBGP you need to have BGP session over loopback ips. Say suppose you form a BGP session over physical interface in below topology, next hop on PE2 router for prefix received from PE1 router would be wan ip between P and PE1. During packet forwarding IGP label would be for wan ip advertised by P router and VPN label will be exposed on P router and will be dropped on P router.

CE1-------PE1--------P--------PE2-------CE2

Regards,

Akash

[Peter Paluch · Accepted solution]

Hello Adnan,

Peering using loopbacks is not absolutely required, however, using any other physical interface can result in POPping the topmost MPLS label prematurely - one router too soon, leading to loss of connectivity. A loopback interface is a network that is, so to say, "behind the router" regardless of the physical interface used to reach the router. Therefore, the MPLS PHP operation is performed on the pen-ultimate router before this network, but if the router with the loopback is the ultimate router then its immediate neighbors are the pen-ultimate neighbors, and the PHP operation will work as expected.

If you used a physical interface to create iBGP peerings, packets arriving through this interface would be POPped on the pen-ultimate router before this interface, but as your neighbor on this interface is not the pen-ultimate but rather the ultimate router, the label would actually be popped on the neighbor of your neighbor - exposing the lower labels if present, thereby confusing your neighbor.

So using the loopback interface to peer iBGP peers, apart from the stability point of view, is very helpful to make sure the PHP operation will be performed appropriately.

Best regards,

Peter

[Adnan Khan]

Thanks
Akash and peter.

[Haris Hilmi Abdul Rahim]

Hi Peter, just out of curiosity, is it possible that I still use physical interface but make it work by disabling PHP? 

Thanks,

Haris

[Peter Paluch]

Hello Haris,

Thanks for the interesting question!

The answer is, unfortunately, no, it would not work.

Assume a simple topology of CE1 - PE1 - P1 - P2 - PE2 - CE2. BGP peering is established between PE1 and PE2 using their physical interfaces, so PE1 references the IP address of PE2 on the P2/PE2 link, and PE2 references the IP address of PE1 on the PE1/P1 link. PHP is disabled and explicit-null label is used in its place.

If a packet from CE1 to CE2 is received on PE1, two labels are imposed: The bottom label will be set to the label advertised in BGP from PE2 to PE1 referencing the PE2/CE2 network, the top label will be set to the label learned from P1 referencing the P2/PE2 network.

When this packet arrives from PE1 to P1, the top label is examined. Because P1 is the penultimate hop to the P2/PE2 network, if PHP was in use, the top label would simply be popped. With PHP disabled, the top label will instead be replaced with an explicit-null label, and the packet will be forwarded to P2.

P2 examines the received labeled packet, and finds an explicit-null label on the top of the label stack. The explicit-null label would ordinarily be removed, and the resulting packet would be handed off either to IPv4 or IPv6 routing table (there are two different values for an explicit-null label; value 0 identifies the IPv4 explicit-null, value 2 identifies the IPv6 explicit-null). This is how the explicit-null label is meant to be used. However, on this packet, even after removing the explicit-null label, there still is the bottom label, and P2 knows this because the explicit-null top label had its 'S' bit (bottom-of-stack) set to 0, saying it is not the last one and that there is another label underneath.

Because of this, P2 knows that even though it can remove the top explicit-null label, there is another label underneath, and so the resulting packet can not be processed in the IPv4/IPv6 routing table even though the explicit-null label requires doing so. Therefore, it simply drops the entire packet.

RFC 3032 puts it down very clearly:

           i. A value of 0 represents the "IPv4 Explicit NULL Label".
              This label value is only legal at the bottom of the label
              stack.  It indicates that the label stack must be popped,
              and the forwarding of the packet must then be based on the
              IPv4 header.

         iii. A value of 2 represents the "IPv6 Explicit NULL Label".
              This label value is only legal at the bottom of the label
              stack.  It indicates that the label stack must be popped,
              and the forwarding of the packet must then be based on the
              IPv6 header.

So if an explicit-null label is only legal at the bottom of the stack, having it actually put as the top label directly violates the requirement stated in this RFC.

If you think of it, replacing the PHP with an explicit-null is never going to recover your network from an unreachability condition. From the standpoint of a router receiving a packet, either it is its neighbor who removes the top label (PHP) so the router gets the resulting packet without the top label right away, or it is the router itself who gets the packet with an explicit-null label and removes it because this is the required operation with an explicit-null label. Aside from indicating what routing table should be used to handle the underlying packet, an explicit-null label does not say anything more specific about the further path of the packet. In any case, what is going to be processed at the router is the resulting packet after popping the top label, and in both cases, it may be one hop too soon.

Best regards,
Peter