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.
TOPOLOGY:
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.
Example:
R5:
mpls bgp forwarding
Same config for R6 :
R6:
mpls bgp forwarding
end
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 9.9.0.1 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 9.9.0.1/32 9.9.0.2 0 100 0 300 i
R5 now has MP-eBGP with R6 and hence sends the route to R6 changing next hop to 9.9.56.5.
R6 receives the route from R5 with next-hop 9.9.56.5 and propagates it to its own AS using next-hop self command.
Note: Next-Hop-Self is used as we don’t advertise 9.9.56.0/30 subnets in any AS. So when routing update for 9.9.0.1 is sent to AS 200 it will have next-hop as 9.9.0.6 which should be reachable via any IGP running in AS 200.Otherwise if we didn’t use next-hop-self then R6 will use 9.9.56.5 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:
R2:
route-target export 2:1
route-target import 9:1
!
address-family ipv4
exit-address-family
R9:
Paths: (1 available, best #1, table XYZ)
Advertised to update-groups:
1
Refresh Epoch 1
100 300, imported path from 2:2:9.9.0.1/32 (global)
9.9.0.6 (metric 4) from 9.9.0.7 (9.9.0.7)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:2:1 ## Route-received with RT 2:1 set by R2 ##
Originator: 9.9.0.6, Cluster list: 9.9.0.7
mpls labels in/out nolabel/19
rx pathid: 0, tx pathid: 0x0
vrf definition XYZ
rd 9:9
route-target export 9:1
route-target import 2:1
!
address-family ipv4
exit-address-family
!
R9 accepts the route and advertises it towards R10 via its VRF interface.
interface FastEthernet0/1
vrf forwarding XYZ
ip address 9.9.109.9 255.255.255.0
OBJECTIVE: TO BE ABLE TO PING FROM LOOPBACK OF R1 TO LOOPBACK OF R10
VERIFICATION:
Sending 5, 100-byte ICMP Echos to 9.9.0.10, timeout is 2 seconds:
Packet sent with a source address of 9.9.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 316/323/336 ms
R1#traceroute 9.9.0.10 source 9.9.0.1
Type escape sequence to abort.
Tracing the route to 9.9.0.10
VRF info: (vrf in name/id, vrf out name/id)
1 9.9.12.2 144 msec 132 msec 104 msec
2 9.9.23.3 [MPLS: Labels 19/23 Exp 0] 232 msec 280 msec 232 msec
3 9.9.34.4 [MPLS: Labels 19/23 Exp 0] 276 msec 264 msec 288 msec
4 9.9.45.5 [MPLS: Label 23 Exp 0] 268 msec 280 msec 256 msec
5 9.9.56.6 [MPLS: Label 23 Exp 0] 292 msec 280 msec 284 msec
6 9.9.67.7 [MPLS: Labels 19/16 Exp 0] 276 msec 276 msec 252 msec
7 9.9.78.8 [MPLS: Labels 19/16 Exp 0] 336 msec 276 msec 300 msec
8 9.9.109.9 [MPLS: Label 16 Exp 0] 228 msec 244 msec 212 msec
9 9.9.109.10 296 msec 264 msec 276 msec
ABOUT THE AUTHOR
I am here to share my knowledge and experience in the field of networking with the goal being – “The more you share, the more you learn.”
I am a biotechnologist by qualification and a Network Enthusiast by interest. I developed interest in networking being in the company of a passionate Network Professional, my husband.
I am a strong believer of the fact that “learning is a constant process of discovering yourself.”
– Rashmi Bhardwaj (Author/Editor)
