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.
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 188.8.131.52 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 :
R5 now has MP-eBGP with R6 and hence sends the route to R6 changing next hop to 184.108.40.206.
R6 receives the route from R5 with next-hop 220.127.116.11 and propagates it to its own AS using next-hop self command.
Note: Next-Hop-Self is used as we don’t advertise 18.104.22.168/30 subnets in any AS. So when routing update for 22.214.171.124 is sent to AS 200 it will have next-hop as 126.96.36.199 which should be reachable via any IGP running in AS 200.Otherwise if we didn’t use next-hop-self then R6 will use 188.8.131.52 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: