Rashmi Bhardwaj | Blog,Config & Troubleshoot

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.








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.



interface FastEthernet0/1ip address

mpls bgp forwarding

Same config for R6 :


interface FastEthernet0/0ip address

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 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 :
Router bgp 100 no bgp default route-target filter
R5 accepts the route as a result of this command and has as its next hop as show below: 

Origin codes: i – IGP, e – EGP, ? – incompleteRPKI validation codes: V valid, I invalid, N Not found

Network         Next Hop           Metric LocPrf Weight Path

Route Distinguisher: 2:2

*>i                 0   100     0 300 i

R5 now has MP-eBGP with R6 and hence sends the route to R6 changing next hop to

R6 receives the route from R5 with next-hop and propagates it to its own AS using next-hop self command.

Note: Next-Hop-Self is used as we don’t advertise subnets in any AS. So when routing update for is sent to AS 200 it will have next-hop as which should be reachable via any IGP running in AS 200.Otherwise if we didn’t use next-hop-self then R6 will use 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:


vrf definition ABCrd 2:2

route-target export 2:1

route-target import 9:1


address-family ipv4



R9#sh ip bgp vpnv4 vrf XYZ routing table entry for 9:9:, version 4

Paths: (1 available, best #1, table XYZ)

Advertised to update-groups:


Refresh Epoch 1

100 300, imported path from 2:2: (global) (metric 4) from (

Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: RT:2:1     ## Route-received with RT 2:1 set by R2 ##

Originator:, Cluster list:

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



R9 accepts the route and advertises it towards R10 via its VRF interface.

interface FastEthernet0/1

vrf forwarding XYZ

ip address



R1#ping source escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

Packet sent with a source address of


Success rate is 100 percent (5/5), round-trip min/avg/max = 316/323/336 ms


R1#traceroute source

Type escape sequence to abort.

Tracing the route to

VRF info: (vrf in name/id, vrf out name/id)

1 144 msec 132 msec 104 msec

2 [MPLS: Labels 19/23 Exp 0] 232 msec 280 msec 232 msec

3 [MPLS: Labels 19/23 Exp 0] 276 msec 264 msec 288 msec

4 [MPLS: Label 23 Exp 0] 268 msec 280 msec 256 msec

5 [MPLS: Label 23 Exp 0] 292 msec 280 msec 284 msec

6 [MPLS: Labels 19/16 Exp 0] 276 msec 276 msec 252 msec

7 [MPLS: Labels 19/16 Exp 0] 336 msec 276 msec 300 msec

8 [MPLS: Label 16 Exp 0] 228 msec 244 msec 212 msec

9 296 msec 264 msec 276 msec


Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart