MPLS Inter AS Option C


Inter AS Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks (VPN next-hop prefixes). Labels are exchanged using IPv4 session with the send-label option.

MPLS Inter AS Option C

  • Option C takes away the heavy reliance on ASBRs. In this option the ASBRs are only used to exchange the PE loopback routes using eBGP IPv4 sessions.
  • To maintain the end to end LSP, labels are send using BGP instead of LDP or RSVP. For other PEs to have reachability to the next-hops, they redistribute these labeled prefixes into to IGP.
  • ASBRs only contain the addresses of remote PEs for BGP next-hop reachability of VPN routes.
  • Usually Option C is implemented with Multihop eBGP VPN session between Route Reflectors, but it doesn't have to be only RR, it could also be PEs. PEs from one carrier can have sessions to other PEs in the other carrier using a full mesh.
  • The major scalability improvement of using Option C is that now the ASBRs don't have to keep labels for all VPNv4 prefixes, but rather move that to the Router Reflectors. These should already have the scalability to hold that many routes.
  • Option C is the most scalable of the Inter AS options.
  • Also referred to as 2547bis Option C.

Routing Between ASBRs

  • ASBR are only running IPv4 unicast, but then will also be sending labels (send-labels). This session is used to create a transport label.
    • One option is to have Route Reflectors establish a VPNv4 peering using the loopbacks learned from the IPv4 unicast session (above).
    • Another option is to have a full mesh of PEs - not very scalable but still supported.
  • These loopback prefixes received from eBGP have to be redistributed into IGP for other PEs to resolved the VPNv4/6 next-hop between ASes.
  • Make sure to configure eBGP multihop for the eBGP VPNv4 session between RRs.
  • Because the router reflectors have an eBGP peering, they will reset the next-hop to themselves splitting the LSP into two segments (to RR and then to PE). The way to solve that is to set the set the next-hop-unchanged option between the router reflectors. neighbor x.x.x.x next-hop-unchanged. It will use the next hop of the original PE and preserve a single LSP. Make sure that the PE loopback are advertised over the ASBRs's IPv4 unicast session.

Label Distribution

  • eBGP IPv4 is used to send transport labels between ASes on the ASBRs.
  • ASBRs have to send the transport label (send-label) otherwise all labels will be stripped. Routes will be present but forwarding will not work for L3VPNs.
  • There are two ways configuring label distribution:
    • eBGP IPv4 between ASBRS, redistributed to local IGP to distribute based on LDP.
    • eBGP IPv4 between ASBRS, using iBGP sessions to other PEs and Ps devices to distribute using iBGP.
  • XR doesn't need address-family ipv4 unicast, but rather address-family ipv4 labeled-unicast.
  • On XR, MAKE SURE that the ASBRs peering for labeled-unicast session you have a /32 host route for a connected neighbor. IOS does this automatically.
  • Allocate-label all command can be modified with a RPL to select only the RR loopback to generate a label or all other PEs if using setting the unchanged next hop.

Configuration Steps

  • Setup eBGP IPv4 sessions between ASBRs. On IOS (send-label) on XR (allocate-label all) and (address-family ipv4 labeled-unicast).
  • Send extended community and send-labels.
  • Advertise only PE's/RRs loopback /32 networks between the ASBRs for reachability of next-hop.
  • Setup an eBGP VPNv4/6 session between Route Reflectors of each service provider, make sure to configure eBGP multi-hop.
  • Set the next-hop-unchanged on eBGP session between RR, without that the LSP will terminate on the RR and then be sent to the PE (split LSP). which is unnecessary.
  • On ASBRs running IOS-XR make sure to add a host static router to the ASBR peer. Without that label forwarding won't work.

Additional Resources

RFC 4364—BGP/MPLS IP Virtual Private Networks (VPNs)
Inter-AS MPLS L3VPN – Option C – BGP + Label - Darren's Blog (Dual CCIE #38070 (R&S, SP) and JNCIE-SP #2227)


rating: 0+x
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License