L3VPN and peering using connected interface

R1 (PE)x----R3 (P)----xR2(PE)

 

I won't go into detail on this but thought it was worth sharing.  Typically when we peer L3VPN we use loopbacks because if we use the interface facing the P routers we end up with the Label Switch Path being broken because the VPN label is exposed too soon becuase of PHP.  This can be tweaked using route-maps to reset the next-hop to some other interface on the remote PE.  I found you can also get round this using:

 

1) OSPF point to Multipoint (Serial or Ethernet)

2) PPP (Serial or Ethernet with PPPoE)

 

In both cases the the /32 that is advertised allows the LSP to stay intact because it is preferred to the connected interface due to longest match rules.  With the PPP neighbor route we need to 'redistribute connected' to maintain the /32 LSP.

 

Nick

Comments

  • Well explained! I think I have read the same thing in the ATC as well. 

    Good luck!

  • How about changing the LDP Transport Address ?

  • How about changing the LDP Transport Address ?

    Hi Deepak

     

    Unless I am mising something changing the interface/address that LDP uses for peering (Control Plane) is not going to affect the LSP Data Plane.  If we change the BGP peering then we use a different LSP which does not have the PHP problem but I wanted to demonstrate that you can also use a different LSP by using Longer matches to avoid the PHP happening too soon and breaking L3VPN.

  • Nice work Nick. OSPF P2MP is an interesting concept. I once saw a design option by Pete Welcher using OSPF P2MP over Ethernet for active-standby WAN connections.

    AB.

  • Interesting.... thank you Nick.

    Did you ever tried a /32 tunnel interface as workaround?

  • Interesting.... thank you Nick.

    Did you ever tried a /32 tunnel interface as workaround?

     

    I have used a GRE tunnel with 'mpls ip' as long as there is an IGP route for the BGP peering.  Also you can peer using the tunnel endpoints and in this instance you don't need LDP at all.  You can configure 'mpls bgp forwarding' - this allows labeled packets to be forwarded that used BGP to exchange labels rather than LDP.

     

    Is this what you meant or did you have somethign else in mind?

    Nick 

  • yes Nick, was that i meant to peer directly with the tunnel interfaces. But when setup the tunnel you peer by unnumbering a loopback over the tunnel interface? because if you peer with an arbitrary address BGP complain about the nexthop mask which is not /32

    then just curiosity, do you disable the mpls ip on the tunnel and keep it on the hardware interface when you issue the mpls bgp forwarding?

  • yes Nick, was that i meant to peer directly with the tunnel interfaces. But when setup the tunnel you peer by unnumbering a loopback over the tunnel interface? because if you peer with an arbitrary address BGP complain about the nexthop mask which is not /32

    then just curiosity, do you disable the mpls ip on the tunnel and keep it on the hardware interface when you issue the mpls bgp forwarding?

     

    Even though BGP may complain about the address not being /32 it does not have to be a /32, just ignore the warning.  I don't think there is anyway to peer using a tunnel that is unnumbered.  The reason being that the route to the tunnel endpoint must be via another path i.e. not the tunnel itself which would mean the peering would also be via this other route and not the tunnel itself. Also the exchange of BGP labels is not the issue, nor is it affected by which IP or interface that you peer with. 

     

    You could peer with tunnels for label exchange and set the next hop to some other path so the tunnel is not part of the data plane but not if you are using unnumbered interfaces.

     

    Nick

  • I understand. Using the tunnels for labels exchange only i think is better approach because the encapsulation of the data inside GRE would add more overhead to the data-traffic. Also because the tunnel is a point to point link and the source of the data could be always considered as a penultimate hop i suppose you wont never use the LFIB because the tag is always popped out before reach the tunnel endpoint, isn't it? So probably the Pe router will process packets that will be always FIB switched. 


  • Also because the tunnel is a point to point link and the source of the data could be always considered as a penultimate hop i suppose you wont never use the LFIB because the tag is always popped out before reach the tunnel endpoint, isn't it? So probably the Pe router will process packets that will be always FIB switched. 


     

    If we are talking L3VPN then you still need the vpn label as the PE will not know which VRF the packet is destined for so it will still look in the LFIB for that, any unlabelled packets will use the FIB.  You can use a tunnel in this way to skip LDP completly and just exchange VPN labels using BGP.

     

  • I believe someone can learn a lot from those scenarios since they're not standard configurations...

    Do you have some document where to go more in detail about those alternative scenarios?

    thanks anyway

  • I don't have them documented in any detail as I am entering the final weeks before Lab attemp (succeess) #2 but you can create them easily.

     

    R1 - R2 - R3

     

    Configure ospf area 0 on all interfaces

    Create VRF A on R1 and R3 and put a pair of loopbacks in the VRF.

    Configure VPNV4 BGP peerings between R1 and R3 and using loopbacks and make sure you can ping from VRF A on R1 to VRF A on R3 so you know everything is working with a typical config.

     

    Change the BGP peerings to use the interface IP on the link facing R2 on both R1 and R3 and you should see this fail. Check the LSP and confirm VPN label exposed too soon on R2 as the problem.  Change both links to OSPF P2MP and test again, recheck the LSP.

    Once you have that working switch off LDP/MPLS on all routers (no mpls ip) and configure a tunnel between R1 and R3, change the VPNV4 to peer using the tunnel end points.  Add this to the tunnel:

    interface Tunnels

     mpls bgp forwarding

     

    Test connectivity between VRF A loopbacks.

    If you check cef, lib, lfib and BGP labels as you go hopefully you can understand better how it works.

    Nick

  • Yes i will go for sure deeply through that... thanks for the advise.

Sign In or Register to comment.