Option 2 (10B): ASBR-to-ASBR / MP-eBGP for VPNv4 - Inter-AS MPLS VPN - The whole story (3) - Updated Dec 2008
With the ASBR-to-ASBR approach, the ASBRs use MP-eBGP to peer with each other to transport VPNv4 routes between the autonomous systems, and the VPN packets are transported as labeled packets between the ASBRs, unlike Option 10A.
As we are going to see later in details, the main difference between both sub-options 2a and 2b and sub-option 2c is that simply the MP-eBGP session between the ASBRs uses the directly connected interfaces, while in option 2c the MP-eBGP peering is done using loopback interfaces. This model of multihop MP-eBGP peering is mainly used in the case of load balancing between multiple circuits between the ASBRs for more bandwidth.
This option is described in the following Cisco document:
MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
It is obvious in this method that there is no need to have per-VRF configuration on the ASBRs as was the case in the back-to-back VRF method, in this method VPNv4 prefixes are exchanged instead.
The main problem with this approach is QoS and end-to-end service delivery assurance (specifically between the ASBRs) since all the customers' traffic is traversed over a single link as labeled packets, and most probably this link is an international link with limited bandwidth capacity, this drawback is tackled with the latest addition to the inter-AS options; Option AB.
There is no requirement for TDP/LDP or any IGP to be enabled on the link connecting the two ASBRs with sub-options 2a and 2b. The MP-eBGP session between directly connected interfaces on the ASBRs enables the interfaces to forward labeled packets (since both ASBRs are aware of the VPN label thus no LDP Top label is required) - The mpls bgp forwarding command is required under the ASBR facing interface to assure this (MPLS forwarding for directly connected BGP peers.
NOTE When using eBGP (IPv4 - by using the send-label command) or MP-eBGP (VPNv4) for label exchange over a non-MPLS enabled interface, "mpls bgp forwarding" is automatically configured under the interface.
On the other hand, when peering via multihop MP-eBGP (sub-option 2c - peering with loopbacks for load balancing over multiple links) we must configure LDP between the ASBRs for proper traffic forwarding since now the peers are not directly connected, however there are a couple of work around for such need since it is insecure to have LDP between different ASes (discussed later). Be aware that the mpls bgp forwarding command alone is only good for MP-eBGP using directly connected interfaces between ASBRs (MPLS forwarding for directly connected BGP peers).
We should take care and remember a vital information, in the multihop MP-eBGP method, the only label we would need to exchange using LDP between the ASBRs is the implicit-null for the peer loopback address (PHP), since each ASBR is the penultimate hop for the other's loopback interface - this is what we will achieve later with the MPLS static label binding trick.
Actually what happens in the multihop scenario, is that a problem arises due to how the LSRs generate and bind labels for static routes, and this differs a lot if the ASBR-to-ASBR interface is multiaccess or point-to-point, below is a brief for all the cases, for more information please check the Static Routes Label Binding post.
- Multiaccess Interfaces/subinterfaces: If the static route pointed to the outgoing interface rather than the next-hop IP address, then despite what we do, the outgoing label will be No Label, and the local binding will be None, this removes the whole label stack, and accordingly the local ASBR conducts a local IP lookup and the packet will be dropped, accordingly when using multiaccess interfaces in a MPLS network never point static routes to the outgoing interfaces. On the other hand if we used a static route that points to the next-hop rather than the outgoing interface, this won't also help us unless their is an active LDP neighbor on this interface that advertises a label binding for this prefix, but since in our current scenario we use mpls bgp forwarding thus using a static route pointing to the next-hop won't also help. This brings us to our final trick; using a static label binding, and thus we configure a static route pointing to the next-hop (in order to have the local LSR binding a local label rather than None) and then configure a static label binding for the prefix (loopback IP address in this scenario).
- Point-to-point Interfaces/subinterfaces: In our current scenario (using mpls bgp forwarding), if we pointed the static route to the outgoing interface rather than the next-hop the local LSR will use a Pop Label rather than a No Label, thus we won't need a static label binding as was the case with the multiaccess interfaces, unless we pointed the static route to the next-hop, since in this case the local LSR will use an outgoing label of No Label rather than Pop Label - Moreover, with point-to-point interfaces if LDP was configured and a LDP neighbor is active on this interface we won't face any problem since in this case the local LSR will have an outgoing label of Pop Label despite how was the static route configured (unlike the multiaccess interface, where when the static route pointed to the outgoing interface, despite what we do, the outgoing label will always be No Label - and the local binding will be None, as if a connected interface).
I believe that since both ASBRs are not sharing an IGP thus there is no security concern in running LDP between them, 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 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, 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.
Just like the back-to-back VRF method the LSP is terminated on the ASBRs, since the MP-eBGP session between the ASBRs changes the next-hop and thus a new MPLS VPN label is generated on the ASBRs, accordingly the LSP is terminated on the ASBRs - Remember that in the back-to-back VRF method the LSP was also terminated on the ASBRs, and traditional IP forwarding was involved between the ASBRs.
At this point I'd like to examine the the two probabilities for the LSP layout (for more details about the suboptions check the below section):
Next-hop-self case: Three glued LSPs (LocalPE-to-LocalASBR + LocalASBR-to-RemoteASBR + RemoteASBR-to-RemotePE) - Each with its own VPN Label.
Redistribute connected case: Two glued LSPs (LocalPE-to-RemoteASBR + RemoteASBR-to-RemotePE) - Each with its own VPN Label.
NOTE In an MPLS VPN network, packet forwarding takes place only if the router specified as the BGP next-hop in the incoming BGP update is the same router that has assigned the VPN label in the MPLS VPN label stack, accordingly with Inter-AS MPLS VPN when using ASBR-to-ASBR method, a new VPN label is assigned on the ASBRs and advertised via MP-eBGP when the BGP next hop is changed.
A major thing to take care of, by default a PE router drops any incoming VPNv4 prefixes that are not imported into any locally configured VRFs (MP-BGP automatic route filtering mechanism), thus the ASBRs needs to have the required VRFs explicitly configured or we can use the no bgp default route-target filter command, the only case where this command is not required is when the ASBR is a RR, since as a RR it will store all the VPNv4 routes by default.
Option B has three sub-options which are illustrated in details in the below section:
Option 2a - Next-hop-self method
With the next-hop-self approach, each ASBR announces its self as the next-hop of the MP-eBGP routes received from the facing ASBR in the remote autonomous system when it advertises these routes inside its own AS over MP-iBGP, this is most commonly done on the MP-iBGP session(s) to its local RR(s) using the neighbor x.x.x.x next-hop-self command under the address-family vpnv4 - since most commonly RRs are used rather than full mesh MP-iBGP between the local AS PE routers.
Lets trace how many time the next-hop of the VPN routes was changed in this approach and accordingly how many time a new VPN label was generated:
- The first VPN label assigned to a VPN route was on the originator PE router in the local AS when first originating the VPN route (this PE router is its original next-hop router).
- The next stage is when the VPN route was advertised between the ASBRs, the next-hop is modified by default over the MP-eBGP session between the ASBRs, where each ASBR announces its self as the next-hop of the MP-eBGP routes advertised to the peering ASBR (instead of the originator PE router - standard eBGP rules), and accordingly a new VPNv4 label per each VPNv4 prefix has to be generated, and thus when the ASBR advertises the VPNv4 routes to the other ASBR it generates new MPLS VPN labels with them.
- The third stage is when each ASBR uses the next-hop-self in front of its local AS, it will accordingly generate a third new VPN label for each MPLS VPNv4 route, this will be the MPLS VPN label used in the peering AS for this VPNv4 routes.
This makes them 3 distinct MPLS VPN labels; the first is the original local MPLS VPN label generated by the original egress PE, and this label is used for traffic forwarding between the VPN sites in the local AS, then a second new generated label by the local ASBR when it changes the next-hop and sends the VPNv4 routes to the peering ASBR, and this label is used for traffic forwarding between the ASBRs, then finally a third MPLS VPN label generated by the remote ASBR when it changes the next-hop again to be itself when advertising the VPNv4 routes into its local AS, and this will be the label used by the remote VPN sites to reach the local MPLS VPNv4 routes through their ASBR.
To recap, always keep in mind that a new label is advertised for a BGP prefix when the next-hop changes.
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 passive-interface Loopback0 ! router bgp 1 no synchronization no bgp default route-target filter bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 10.10.34.4 remote-as 2 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 next-hop-self neighbor 10.10.34.4 activate neighbor 10.10.34.4 send-community extended exit-address-family !
Option 2b - Redistribute connected method
According to the BGP principles, the other approach than using next-hop-self on the ASBRs in the face of its local AS routers to be the next-hop of the routes received from the peering ASBR is to make the next-hop address of the peering ASBR reachable to its local AS and thus there will be no need for the next-hop-self command on the ASBRs towards their local ASes.
In other words, the receiving ASBR accepts the route without changing the next-hop attribute and accordingly any label information (the current next-hop is the remote ASBR peering address). The receiving ASBR will then use the redistribute connected command under its IGP (or passive-interface advertisement, which I personally prefer) to advertise the next-hop of the received routes from the peering ASBR to the local AS routers to have reachability to the next-hop without the need to modify the next-hop attribute.
In this method it is clear that the MPLS VPN labels are only changed once not twice as in the next-hop-self method, since now the next-hop is modified only once on the local ASBR when advertising the VPNv4 routes to the remote ASBR, and won't be modified on the remote ASBR, since the next-hop-self is not used in this case, and since the next-hop wasn't changed, thus no new VPN labels are to be generated.
NOTE BGP creates a connected host route (connected /32) for the MP-eBGP peer in the remote AS (the remote ASBR peering address - which is the next-hop of the exchanged routes) once the session that needs to be injected into the IGP of each AS comes up - All that will be done is to redistribute connected into the IGP using a route-map that match on the /32 host prefix of the peer ASBR address.
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 connected route-map ASBR passive-interface Loopback0 ! router bgp 1 no synchronization no bgp default route-target filter bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 10.10.34.4 remote-as 2 no auto-summary ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended neighbor 10.10.34.4 activate neighbor 10.10.34.4 send-community extended exit-address-family ! access-list 1 permit ip host 10.10.34.4 ! route-map ASBR permit 10 match ip address 1 !
Option 2c - eBGP between ASBRs and MP-eBGP between RRs
In this case, the MP-eBGP peering between the ASBRs is done using loopback IPs rather than directly connected interfaces (multihop MP-eBGP peering), mainly used when having multiple links between the ASBRs, with the need to load balance between the multiple links to increase the available bandwidth.
NOTE In old codes multihop MP-eBGP was not supported.
Accordingly we must enable LDP now for label exchange since the next-hops are not directly connected, and as discussed earlier the mpls bgp forwarding command alone is only good for MP-eBGP using directly connected interfaces between ASBRs (MPLS forwarding for directly connected BGP peers).
As described earlier, when the peering is done using multihop MP-eBGP then we have two options, either to enable LDP or not (in the second case we need to have mpls bgp forwarding configured since MPLS must configured under the interface):
- Using LDP between the ASBRs - not recommended unless both autonomous systems belong to the same overall authority as described earlier - If the interface is multiaccess then the static route must point to the next-hop rather than the outgoing interface, since if the route pointed to the outgoing interface, then the outgoing label will be No Label and the local label binding will be None.
- Using mpls bgp forwarding and not enabling LDP between the ASBRs, and this solution depends on the ASBR-to-ASBR interface type:
- Multiaccess Interfaces/subinterfaces between the ASBRs: If the static route pointed to the outgoing interface rather than the next-hop IP address, then despite what we do, the outgoing label will be No Label, and the local binding will be None, this removes the whole label stack, and accordingly the local ASBR conducts a local IP lookup and the packet will be dropped, accordingly when using multiaccess interfaces in a MPLS network never point static routes to the outgoing interfaces. On the other hand if we used a static route that points to the next-hop rather than the outgoing interface, this won't also help us unless their is an active LDP neighbor on this interface that advertises a label binding for this prefix, but since in our current scenario we use mpls bgp forwarding thus using a static route pointing to the next-hop won't also help. This brings us to our final trick; using a static label binding, and thus we configure a static route pointing to the next-hop (in order to have the local LSR binding a local label rather than None) and then configure a static label binding for the prefix (loopback IP address in this scenario); mpls static binding ipv4 x.x.x 255.255.255.255 output x.x.x.x implicit-null.
- Point-to-point Interfaces/subinterfaces: In our current scenario (using mpls bgp forwarding), if we pointed the static route to the outgoing interface rather than the next-hop the local LSR will use a Pop Label rather than a No Label, thus we won't need a static label binding as was the case with the multiaccess interfaces, unless we pointed the static route to the next-hop, since in this case the local LSR will use an outgoing label of No Label rather than Pop Label - Moreover, with point-to-point interfaces if LDP was configured and a LDP neighbor is active on this interface we won't face any problem since in this case the local LSR will have an outgoing label of Pop Label despite how was the static route configured (unlike the multiaccess interface, where when the static route pointed to the outgoing interface, despite what we do, the outgoing label will always be No Label - and the local binding will be None, as if a connected interface).
NOTE In the multihop MP-eBGP method, the only label we would need to exchange using LDP between the ASBRs is the implicit-null for the peer loopback address (PHP), and this is what we achieved with the MPLS static label binding trick.
NOTE When you use the mpls static binding command on newer codes you'll get the % Command accepted but obsolete, unreleased or unsupported; see documentation, but it works just fine.
NOTE When using any of the two tricks to circumvent enabling LDP in the case of multihop MP-eBGP, we must use mpls bgp forwarding, since MPLS needs to be enabled in any form on an interface to be able to process incoming labeled packets, other wise the remote ASBR will drop the labeled packets and display this log: %MPLS_PACKET-4-NOLFDSB: MPLS packet received on non MPLS enabled interface.
This case is actually a variant of options 2a and 2b, and thus we can use both approaches in this case, we can use next-hop-self or redistribute connected (or static in this case, since the peer ASBR next-hop is a static route for the loopback rather than a directly connected interface) under the IGP on the ASBRs.
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 static passive-interface Loopback0 ! router bgp 1 no synchronization no bgp default route-target filter bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 neighbor 4.4.4.4 remote-as 2 neighbor 4.4.4.4 ebgp-multihop 2 neighbor 4.4.4.4 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended exit-address-family ! ip route 4.4.4.4 255.255.255.255 10.10.34.4 ! mpls static binding ipv4 4.4.4.4 255.255.255.255 output 10.10.34.4 implicit-null !
I hope that I've been informative.
BR,
Mohammed Mahmoud.
Check Also
