Option 3 (10C): Multi-Hop MP-eBGP Between RR and eBGP Between ASBRs - Inter-AS MPLS VPN - The whole story (4) - Updated Dec 2008
This approach is considered to be the most scalable, since when compared with Option 2(10B), the ASBRs need not learn all the VPNv4 prefixes, since now the MP-eBGP session will be established between the RRs (which already have all the VPNv4 prefixes by default) rather than the ASBRs, and the ASBRs will only be responsible of exchanging the next-hop addresses of the VPNv4 prefixes via eBGP.
Although I believe each AS having reachability to all the internal next-hops in the other AS has an implicit security concern, however practically speaking this option is normally deployed only when both autonomous systems belong to the same overall authority, such as a global Layer 3 MPLS VPN service provider with autonomous systems in different regions of the world.
NOTE In old IOS codes multihop MP-eBGP was not supported.
This option is described in the following Cisco document:
MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
In this approach, simply the RRs are going to exchange the VPNv4 routes, while the ASBRs will exchange the next-hops (IPv4) information piggybacked with its labels in order to complete the creation of a label switched path from the ingress local PE router to the egress remote PE router.
This is the only approach where the LSP path is not broken and the original MPLS VPN label is used all the way, since the next-hop of the VPN4 routes is not changed along the path.
According to RFC 3107 "Carrying Label Information in BGP-4" networks configured with MP-eBGP multihop must have a label switched path (LSP) between nonadjacent routers. The neighbor x.x.x.x send-label command is required under the eBGP configuration between the ASBRs to enable the exchange of IPv4 label between the two peers plus the mpls bgp forwarding command under the ASBR-to-ASBR interface to maintain MPLS forwarding for directly connected BGP peers (be aware of the multihop eBGP between the ASBRs approach that we have described earlier).
If we were using an IGP or static routes then we could have enabled LDP on the inter-as link (like what we do with CSC using IGP and LDP), but since we are running an eBGP session over which we are advertising the next-hop addresses then we must make sure we also advertise the labels along with it using the send-label option since LDP does not advertise labels for BGP learned routes - Be aware that if there is no outgoing label for BGP next-hops then packets between Inter-AS VPNs will be discarded by the ASBRs.
NOTE When using eBGP for label exchange (using the send-label option) over a non-MPLS enabled interface, mpls bgp forwarding is automatically configured under the interface.
NOTE The neighbor x.x.x.x send-label command enables a router to use BGP to distribute MPLS labels along with the IPv4 routes to a peer router.
When BGP (eBGP and iBGP) distributes a route, it can also distribute an MPLS label that is mapped to that route. The MPLS label mapping information for the route is carried in the BGP update message that contains the information about the route (piggybacked). If the next hop is not changed, the label is preserved. When you issue the neighbor send-label command on both BPG routers, the routers advertise to each other that they can then send MPLS labels with the routes (Using AFI/SAFI: 1/4 in the Open message). If the routers successfully negotiate their ability to send MPLS labels, the routers add MPLS labels to all outgoing BGP updates.
Now to the next step, the next-hop addresses of the remote AS PEs learned via eBGP between the ASBRs must be redistributed into the IGP of the local AS via the redistribute bgp command in order for the next-hops in the remote AS to be reachable on all the local AS routers (P and PE routers). They must be advertised first by eBGP on the remote ASBR via network commands - the prefixes should be in the routing table of the their local ASBR via IGP and thus will be advertised via eBGP to the remote ASBR - or we can simply redistribute the IGP (plus filtering for security) into BGP on the local ASBR since the local AS next-hops are already learned via the local AS IGP.
Actually to exchange the loopbacks of the PE routers between the ASs we have two options (one of them is the one described earlier, but I do like the second option since most probably the ASBR will already be running iBGP with the local PE routers - most probably through a RR - thus this option would be easier configuration wise):
- On the local ASBR redistribute the IGP into the BGP (using a route-map for filtering only the local PEs loopbacks), then on the remote ASBR redistribute these loopbacks from BGP to the IGP (also using a route-map) - In this case the label binding will be done via LDP (since the routes are now IGP not BGP).
- On the local ASBR redistribute the IGP into the BGP (using a route-map for filtering only the local PEs loopbacks - or simply use network commands on the ASBR), then on the remote ASBR enable it to send IPv4 + label to all its PE routers (or most commonly to its RR and its RR should be also sending IPv4 + label to all the PE routers).
NOTE There is a major issue to take into consideration though, in the first option the label stack will be two labels (LDP Label + VPN Label), while in the second option the label stack will be three labels (LDP Label + BGP Label + VPN Label) - You need to consider the label stack depth for MTU issues.
Now to the final step, configuring the MP-eBGP peering between the RRs in the different ASes. A very crucial command to be used on both RRs is the neighbor x.x.x.x next-hop-unchanged command, and thus the next-hop is not changed when the VPNv4 routes are exchanged between the RRs (since we are talking about a MP-eBGP session thus the next-hop would have been changed by default), and accordingly the VPNv4 prefixes labels are not changed since the next-hop is not changed, and accordingly the remote AS uses the same MPLS VPN label as the local AS unlike Option 2 where the next-hop was changed and new MPLS VPN labels were generated breaking the LSP.
A practical logic in using the next-hop-unchanged between the RRs lies in the fact that they should never be involved in the data/forwarding plane, and thus they must never be the next-hop for any routing updates, rather the original PE routers should be kept as the next-hops in order to be used on the data/forwarding plane - now it is very obvious why should the /32 peering (next-hop) addresses of the PE routers be advertised to the remote AS via the eBGP between the ASBRs.
Option 3 can practically have 2 sub-options, the first is the directly connected approach (eBGP peering between ASBRs using physical addresses) and the second is the multihop eBGP approach (eBGP peering between ASBRs using loopback addresses), and as described before in Option 2 this mainly depends if there are multiple circuits between the ASBRs with the need to load-balance between them for more bandwidth.
Remember that as in Option 2c (multihop MP-eBGP between ASBRs), when using multihop eBGP between the ASBRs we must enable LDP on the ASBR-to-ASBR link (or use the work around solutions described earlier in Option 2c - Check Option 2 for more details). As I illustrated earlier I believe that since both ASBRs are not sharing an IGP thus there is no security concern in running LDP between the ASBRs since they will never insert label information learned from the other ASBR if they have no exact routes in their routing table, more over we can filter labels between the ASBRs - But for sure not having an IGP or LDP between difference SPs is the most secure situation.
Practically speaking this option is normally deployed only when both autonomous systems belongs to the same overall authority, such as a global Layer 3 MPLS VPN service provider with autonomous systems in different regions of the world, accordingly I believe that in such case enabling LDP between the ASBRs won’t be an issue, other wise it is not a recommended solution.
RR configuration example:
! interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface ATM1/0.1 point-to-point description Connection to P1 ip address 10.10.27.7 255.255.255.0 ip router isis mpls ip ! router isis net 49.0001.0070.0700.7007.00 is-type level-2-only metric-style wide set-overload-bit log-adjacency-changes passive-interface Loopback0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 1 neighbor 3.3.3.3 update-source Loopback0 neighbor 8.8.8.8 remote-as 2 neighbor 8.8.8.8 ebgp-multihop 255 neighbor 8.8.8.8 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended neighbor 1.1.1.1 route-reflector-client neighbor 3.3.3.3 activate neighbor 3.3.3.3 send-community extended neighbor 3.3.3.3 route-reflector-client neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended neighbor 8.8.8.8 next-hop-unchanged exit-address-family !
ASBR configuration example:
! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface ATM1/0.1 point-to-point description Connection to P1 ip address 10.10.23.3 255.255.255.0 ip router isis mpls ip ! interface ATM2/0.1 point-to-point description Connection to ASBR2 ip address 10.10.34.3 255.255.255.0 mpls bgp forwarding ! router isis net 49.0001.0030.0300.3003.00 is-type level-2-only metric-style wide log-adjacency-changes redistribute bgp 1 route-map ASBR passive-interface Loopback0 ! router bgp 1 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 neighbor 10.10.34.4 remote-as 2 neighbor 10.10.34.4 send-label no auto-summary ! ip prefix-list ASBR seq 1 permit 6.6.6.6/32 ! route-map ASBR permit 10 match ip address prefix-list ASBR !
I hope that I've been informative.
BR,
Mohammed Mahmoud.
Check Also
