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:
Post a Comment