This post is in continuation to last post on “Inter-AS Communication Scenario across Service Providers” where we discussed on “Option A – VRF-VRF” method in which the two autonomous systems of different service providers can interact to provide service to same customer locations. In this section , we will understand Option B-2A via Next-Hop-Self method of AS-AS communication.
Just to summarize – The need for Inter-AS communication arises when one service provider is having its customer base around the globe but doesn’t have connectivity all around the globe.In such cases the service provider take help of regional service provider to cater to their customer traffic in that region.
As a part of this document we will go ahead and configure Next-Hop -Self method between two AS and will leave the rest options for upcoming posts.
ROUTER INFORMATION AS BELOW –
In the above topology R1 represents router at customer Site 1 and R10 represents router at customer site 2 in two different region.
Service Provider 1(AS100) with the help of Service provider 2 (AS200) is able to cater to its customer site in a region in which it doesn’t have presence but service provider 2 has.
In order to achieve this an MP-eBGP neighbourship is created between the AS gateways R5 and R6 using vpnv4 address-family.
You will notice one thing as soon as we enable the MP-eBGP between the two AS gateways command “mpls bgp forwarding” automatically gets enabled on R5 & R6 respective interfaces facing each other.
mpls bgp forwarding
Same config for R6 :
mpls bgp forwarding
3 LSP’s are created in this topology :
- R2 to R5 LSP
- R5 to R6 LSP
- R6 to R9 LSP
Few points to note for LSP as well which we need to understand:
- when R2 propagates route of R1 loopback it imposes two labels – one VPN label and on top of it LDP label.
- When this route update reaches R5, it strips the LDP label as LSP ends, changes the VPN label as next-hop is changed and sends it to R6.
- R6 swaps the VPN label it received from R5 with its own VPN label as again next hop is changed and adds its LDP label over it and then propagates the route.
- R9 receives the route with only with VPN label based on which it identifies the VPN in which it has to forward the routing update.Once identified it strips VPN label and sends update to R10.
Note: Similar flow will follow for update of R10 loopback towards R1 in reverse direction.
Now the routing update for customer prefixes would be as follows:
- R1 advertises its loopback 126.96.36.199 to R2.
- R2 receives this route in its VRF ABC interface and installs the route in ABC VRF table.
- R2 sends the route to R3 which installs it in its BGP table (RR accepts routes with all RTs by default).
- R3 will reflect the route to R5 which is a PE but doesn’t have customer VRF so by default it won’t accept the route. To overcome this default behavior we have to issue below command under router BGP on R5 :
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:2
*>i 188.8.131.52/32 184.108.40.206 0 100 0 300 i
R5 now has MP-eBGP with R6 and hence sends the route to R6 changing next hop to 220.127.116.11.
R6 receives the route from R5 with next-hop 18.104.22.168 and propagates it to its own AS using next-hop self command.
Note: Next-Hop-Self is used as we don’t advertise 22.214.171.124/30 subnets in any AS. So when routing update for 126.96.36.199 is sent to AS 200 it will have next-hop as 188.8.131.52 which should be reachable via any IGP running in AS 200.Otherwise if we didn’t use next-hop-self then R6 will use 184.108.40.206 as next-hop while advertising the update in its own AS which then would be unreachable.
- Now R6 advertises the route to R7 which is RR in its own AS.
- R7 further advertises the route to R9 which is importing RD exported from R2 i.e. 2:1 as shown below:
route-target export 2:1
route-target import 9:1
Paths: (1 available, best #1, table XYZ)
Advertised to update-groups:
Refresh Epoch 1
100 300, imported path from 2:2:220.127.116.11/32 (global)
18.104.22.168 (metric 4) from 22.214.171.124 (126.96.36.199)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:2:1 ## Route-received with RT 2:1 set by R2 ##
Originator: 188.8.131.52, Cluster list: 184.108.40.206
mpls labels in/out nolabel/19
rx pathid: 0, tx pathid: 0x0
vrf definition XYZ
route-target export 9:1
route-target import 2:1
R9 accepts the route and advertises it towards R10 via its VRF interface.
vrf forwarding XYZ
ip address 220.127.116.11 255.255.255.0
OBJECTIVE: TO BE ABLE TO PING FROM LOOPBACK OF R1 TO LOOPBACK OF R10
Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds:
Packet sent with a source address of 22.214.171.124
Success rate is 100 percent (5/5), round-trip min/avg/max = 316/323/336 ms
R1#traceroute 126.96.36.199 source 188.8.131.52
Type escape sequence to abort.
Tracing the route to 184.108.40.206
VRF info: (vrf in name/id, vrf out name/id)
1 220.127.116.11 144 msec 132 msec 104 msec
2 18.104.22.168 [MPLS: Labels 19/23 Exp 0] 232 msec 280 msec 232 msec
3 22.214.171.124 [MPLS: Labels 19/23 Exp 0] 276 msec 264 msec 288 msec
4 126.96.36.199 [MPLS: Label 23 Exp 0] 268 msec 280 msec 256 msec
5 188.8.131.52 [MPLS: Label 23 Exp 0] 292 msec 280 msec 284 msec
6 184.108.40.206 [MPLS: Labels 19/16 Exp 0] 276 msec 276 msec 252 msec
7 220.127.116.11 [MPLS: Labels 19/16 Exp 0] 336 msec 276 msec 300 msec
8 18.104.22.168 [MPLS: Label 16 Exp 0] 228 msec 244 msec 212 msec
9 22.214.171.124 296 msec 264 msec 276 msec