Monday, March 25, 2013

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 ;)
 

No comments: