Inter-AS MPLS L3VPN Using Back-to-Back VRF

MPLS L3VPN is indeed a great technnology to Interconnect Customer Network. The Typical MPLS L3VPN deployment is that the SP in one region, let say in Indonesia, will connect its customer across the country :)

well, let say that the customer have a representative office in the US, where the ISP A in Indonesia typically doesn't have an Infrastructure in the US, but the ISP is indeed having a connection to the ISP-B in the US.

well, the two ISP indeed should communicate each other so that they can exchange the particular routing information. The expected result is that the Customer can use the Internetworking connection between ISP-A in Indonesia and ISP-B in the US to exchange the Company's Data back and forth.

that kind 'Interconnection' between ISP-A and ISP-B can be referred as an Inter-AS MPLS L3VPN.

in this writing I want to give an overview about one of the option in order to do the Inter-AS MPLS L3VPN that is Back-to-Back VRF approach between ISP, here is the scenario:

 

·         Configure Back-to-Back VRF so that R7 can connect to R8

·         AS123 will use : as its RT Numbering on the VRF

·         AS456 will use : as its RT Numbering on the VRF

So we need to build basic configuration, where R3 will have VPNv4 peering with R2 and R6 will have VPNv4 peering with R4.

R3 ! ip vrf VPN_A  rd 14.14.3.3:1  route-target export 14.14.3.3:1  route-target import 14.14.2.2:1 ! interface FastEthernet0/1  ip vrf forwarding VPN_A  ip address 10.14.37.3 255.255.255.0 ! router bgp 123  bgp router-id 14.14.3.3  no bgp default ipv4-unicast  bgp log-neighbor-changes  neighbor 14.14.2.2 remote-as 123  neighbor 14.14.2.2 update-source Loopback0  !  address-family vpnv4   neighbor 14.14.2.2 activate   neighbor 14.14.2.2 send-community extended  exit-address-family  !  address-family ipv4 vrf VPN_A   no synchronization   redistribute rip  exit-address-family ! router rip !  address-family ipv4 vrf VPN_A   redistribute bgp 123 metric transparent   network 10.0.0.0   no auto-summary   version 2  exit-address-family ! End R2 ! ip vrf VPN_A  rd 14.14.2.2:1  route-target export 14.14.2.2:1  route-target import 14.14.3.3:1 ! router bgp 123  bgp router-id 14.14.2.2  no bgp default ipv4-unicast  bgp log-neighbor-changes  neighbor 14.14.3.3 remote-as 123  neighbor 14.14.3.3 update-source Loopback0  !  address-family vpnv4   neighbor 14.14.3.3 activate   neighbor 14.14.3.3 send-community extended  exit-address-family ! end

R6 ! ip vrf VPN_A  rd 14.14.6.6:1  route-target export 456:1  route-target import 456:1 ! interface FastEthernet0/1  ip vrf forwarding VPN_A  ip address 10.14.68.6 255.255.255.0 ! router bgp 456  bgp router-id 14.14.6.6  no bgp default ipv4-unicast  bgp log-neighbor-changes  neighbor 14.14.4.4 remote-as 456  neighbor 14.14.4.4 update-source Loopback0 !  address-family vpnv4   neighbor 14.14.4.4 activate   neighbor 14.14.4.4 send-community extended  exit-address-family  !  address-family ipv4 vrf VPN_A   no synchronization   redistribute rip  exit-address-family ! router rip  !  address-family ipv4 vrf VPN_A   redistribute bgp 456 metric transparent   network 10.0.0.0   no auto-summary   version 2  exit-address-family ! End R4 ! ip vrf VPN_A  rd 14.14.4.4:1  route-target export 456:1  route-target import 456:1 ! router bgp 456  bgp router-id 14.14.4.4  no bgp default ipv4-unicast  bgp log-neighbor-changes  neighbor 14.14.6.6 remote-as 456  neighbor 14.14.6.6 update-source Loopback0  !  address-family vpnv4   neighbor 14.14.6.6 activate   neighbor 14.14.6.6 send-community extended  exit-address-family ! end

At this point, both R3 and R6 haven’t got any prefixes from each other. R3 hasn’t gotten the 10.8.8.0/24 neither R6 which hasn’t gotten the 10.7.7.0/24 Prefix

Rack14R3#show bgp vpnv4 unicast rd 14.14.3.3:1 BGP table version is 5, local router ID is 14.14.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 14.14.3.3:1 (default for vrf VPN_A) *> 10.7.7.0/24      10.14.37.7               1         32768 ? *> 10.14.37.0/24    0.0.0.0                  0         32768 ? *> 10.14.78.0/24    10.14.37.7               1         32768 ? *> 14.14.7.7/32     10.14.37.7               1         32768 ? Rack14R6#show ip bgp vpnv4 rd 14.14.6.6:1 BGP table version is 13, local router ID is 14.14.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 14.14.6.6:1 (default for vrf VPN_A) *> 10.8.8.0/24      10.14.68.8               1         32768 ? *> 10.14.68.0/24    0.0.0.0                  0         32768 ? *> 10.14.78.0/24    10.14.68.8               1         32768 ? *> 14.14.8.8/32     10.14.68.8               1         32768 ?

Now, we’ve already created the VRF, called VPN_A on both R2 and R4, where they will act as if they connected to the CE, and we will enable IGP, OSPF, between them to exchange the Routing Information.

R2 ! interface FastEthernet0/1  desc Link to R4, other AS  ip vrf forwarding VPN_A  ip address 150.14.24.2 255.255.255.0 ! router ospf 24 vrf VPN_A  router-id 150.14.24.2  log-adjacency-changes  redistribute bgp 123 subnets  network 150.14.24.2 0.0.0.0 area 0 ! router bgp 123  !  address-family ipv4 vrf VPN_A   no synchronization   redistribute ospf 24 vrf VPN_A match internal external 1 external 2  exit-address-family ! End R4 ! interface FastEthernet0/1  desc Link to R2, other AS  ip vrf forwarding VPN_A  ip address 150.14.24.4 255.255.255.0 ! router ospf 24 vrf VPN_A  router-id 150.14.24.4  log-adjacency-changes  redistribute bgp 456 subnets  network 150.14.24.4 0.0.0.0 area 0 ! router bgp 456 !  address-family ipv4 vrf VPN_A   no synchronization   redistribute ospf 24 vrf VPN_A match internal external 1 external 2  exit-address-family ! end

So now, R3 will have the Other Customer Prefix, 10.8.8.0/24, from R2 as if R2 is directly connected to the CE, which in this Case R2 connected to the other MPLS Cloud that is acted as CE, from AS123 point of view

Rack14R3#show bgp vpnv4 unicast rd 14.14.3.3:1 BGP table version is 14, local router ID is 14.14.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 14.14.3.3:1 (default for vrf VPN_A) *> 10.7.7.0/24      10.14.37.7               1         32768 ? *>i10.8.8.0/24      14.14.2.2                1    100      0 456 i *> 10.14.37.0/24    0.0.0.0                  0         32768 ? *>i10.14.68.0/24    14.14.2.2                1    100      0 456 i * i10.14.78.0/24    14.14.2.2                1    100      0 456 i *>                  10.14.37.7               1         32768 ? *> 14.14.7.7/32     10.14.37.7               1         32768 ? *>i14.14.8.8/32     14.14.2.2                1    100      0 456 i *>i150.14.24.0/24   14.14.2.2                0    100      0 ? BGP routing table entry for 14.14.3.3:1:10.8.8.0/24, version 11 Paths: (1 available, best #1, table VPN_A)   Not advertised to any peer   456, imported path from 14.14.2.2:1:10.8.8.0/24     14.14.2.2 (metric 3) from 14.14.2.2 (14.14.2.2)       Origin IGP, metric 1, localpref 100, valid, internal, best       Extended Community: OSPF DOMAIN ID:0x0005:0x000000180200 RT:14.14.2.2:1         OSPF RT:0.0.0.0:5:1 OSPF ROUTER ID:150.14.24.2:0       mpls labels in/out nolabel/203

R6 will also have learned the prefixes from R7

Rack14R6#show ip bgp vpnv4 rd 14.14.6.6:1 BGP table version is 21, local router ID is 14.14.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 14.14.6.6:1 (default for vrf VPN_A) *>i10.7.7.0/24      14.14.4.4                1    100      0 123 i *> 10.8.8.0/24      10.14.68.8               1         32768 ? *>i10.14.37.0/24    14.14.4.4                1    100      0 123 i *> 10.14.68.0/24    0.0.0.0                  0         32768 ? *> 10.14.78.0/24    10.14.68.8               1         32768 ? *>i14.14.7.7/32     14.14.4.4                1    100      0 123 i *> 14.14.8.8/32     10.14.68.8               1         32768 ? *>i150.14.24.0/24   14.14.4.4                0    100      0 ? Rack14R6#show ip bgp vpnv4 rd 14.14.6.6:1 10.7.7.0 BGP routing table entry for 14.14.6.6:1:10.7.7.0/24, version 19 Paths: (1 available, best #1, table VPN_A)   Not advertised to any peer   123, imported path from 14.14.4.4:1:10.7.7.0/24     14.14.4.4 (metric 3) from 14.14.4.4 (14.14.4.4)       Origin IGP, metric 1, localpref 100, valid, internal, best       Extended Community: RT:456:1 OSPF DOMAIN ID:0x0005:0x000000180200         OSPF RT:0.0.0.0:5:1 OSPF ROUTER ID:150.14.24.4:0       mpls labels in/out nolabel/406

Now lets we trace the Path/Label, that should have been taken By R3 to R6 in order R7 to reach R8 Prefixes (10.7.7.0/24 à 10.8.8.0/24)

Rack14R3#show bgp vpnv4 unicast vrf VPN_A labels    Network          Next Hop      In label/Out label Route Distinguisher: 14.14.3.3:1 (VPN_A)    10.7.7.0/24      10.14.37.7      303/nolabel    10.8.8.0/24      14.14.2.2       nolabel/203    10.14.37.0/24    0.0.0.0         304/nolabel(VPN_A)    10.14.68.0/24    14.14.2.2       nolabel/204    10.14.78.0/24    14.14.2.2       305/205                     10.14.37.7      305/nolabel    14.14.7.7/32     10.14.37.7      306/nolabel    14.14.8.8/32     14.14.2.2       nolabel/206    150.14.24.0/24   14.14.2.2       nolabel/207

We have to know that the Above VPNv4 Label for prefix 10.8.8.0/24, which is 203, is Locally significant for AS123 only, because its being created by the R2 in this case

Rack14R3#show mpls forwarding-table 14.14.2.2 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 302        101        14.14.2.2/32     0             Fa0/0      150.14.13.1 Rack14R1#show mpls forwarding-table 14.14.2.2 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 101        Pop Label  14.14.2.2/32     13774         Fa0/0      150.14.12.2

Based on the output Above, The traffic will use Label [101/203],[203] and finally reach R2. Since R2 will consider connection to R4 as if it connects to the CE, the traffic from R2 to R3, 10.7.7.0/24à10.8.8.0/24, will be sent without Labels.

From the AS 456 perspective, the traffic that has been received by the R4 will entering the ‘NORMAL’ MPLS backbone again.

Rack14R4#show ip bgp vpnv4 vrf VPN_A labels    Network          Next Hop      In label/Out label Route Distinguisher: 14.14.4.4:1 (VPN_A)    10.7.7.0/24      150.14.24.2     406/nolabel    10.8.8.0/24      14.14.6.6       nolabel/607    10.14.37.0/24    150.14.24.2     405/nolabel    10.14.68.0/24    14.14.6.6       nolabel/608    10.14.78.0/24    14.14.6.6       nolabel/609    14.14.7.7/32     150.14.24.2     404/nolabel    14.14.8.8/32     14.14.6.6       nolabel/610    150.14.24.0/24   0.0.0.0         403/nolabel(VPN_A)

So R6 assign label 607 for network 10.8.8.0/24, Where R4 should use 14.14.6.6 as it next-hop.

Rack14R4#show mpls forwarding-table 14.14.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 402        501        14.14.6.6/32     0             Fa0/0      150.14.45.5 Rack14R5#show mpls forwarding-table 14.14.6.6 Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop Label      Label      or Tunnel Id     Switched      interface 501        Pop Label  14.14.6.6/32     14580         Fa0/1.56   150.14.56.6 Rack14R6#show ip bgp vpnv4 vrf VPN_A labels    Network          Next Hop      In label/Out label Route Distinguisher: 14.14.6.6:1 (VPN_A)    10.7.7.0/24      14.14.4.4       nolabel/406    10.8.8.0/24      10.14.68.8      607/nolabel    10.14.37.0/24    14.14.4.4       nolabel/405    10.14.68.0/24    0.0.0.0         608/nolabel(VPN_A)    10.14.78.0/24    10.14.68.8      609/nolabel    14.14.7.7/32     14.14.4.4       nolabel/404    14.14.8.8/32     10.14.68.8      610/nolabel    150.14.24.0/24   14.14.4.4       nolabel/403

So, based on the above output, the Traffic in the AS 456 to 10.8.8.0/24 will use label [501/607],[607] and finally goes to the R8.

Let see this verification from the CE, R7 perspective ;)

Rack14R7#show ip route rip      10.0.0.0/24 is subnetted, 5 subnets R       10.8.8.0 [120/2] via 10.14.37.3, 00:00:00, FastEthernet0/0 R       10.14.68.0 [120/2] via 10.14.37.3, 00:00:00, FastEthernet0/0      14.0.0.0/32 is subnetted, 2 subnets R       14.14.8.8 [120/2] via 10.14.37.3, 00:00:00, FastEthernet0/0      150.14.0.0/24 is subnetted, 1 subnets R       150.14.24.0 [120/1] via 10.14.37.3, 00:00:00, FastEthernet0/0 Rack14R7#ping 10.8.8.8 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds: Packet sent with a source address of 14.14.7.7 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 116/131/152 ms Rack14R7#traceroute 10.8.8.8 source loopback 0 Type escape sequence to abort. Tracing the route to 10.8.8.8   1 10.14.37.3 40 msec 32 msec 16 msec   2 150.14.13.1 [MPLS: Labels 101/203 Exp 0] 104 msec 68 msec 72 msec   3 150.14.24.2 [MPLS: Label 203 Exp 0] 60 msec 48 msec 56 msec   4 150.14.24.4 80 msec 84 msec 84 msec   5 150.14.45.5 [MPLS: Labels 501/607 Exp 0] 144 msec 124 msec 124 msec   6 10.14.68.6 [MPLS: Label 607 Exp 0] 120 msec 104 msec 108 msec   7 10.14.68.8 144 msec *  172 msec

The advantage using this VRF Back-to-Back on Inter-AS MPLS is we don’t need to exchange the Internal routing information, the SP will control its own VRF import & Export policies, and the Configuration is considered as simple.

While the drawback is that the IGP/Static Route is required between PE-PE per Customer/VRF Basis, meaning that the more Customer that want to use the Inter-AS, the more VRF Routing table and Link(s) required to do so ;)