Multipoint GRE or mGRE L3VPN is an interesting variant that can be used to interconnect PE routers together. This assumes that the PE routers have reachability to each other. The goal is to create a GRE tunnel between the PE routers to connect the L3VPN in the event that an end to end LSP isn't available.
The topology below is the same as the CSC topology with the exception that there is no label exchange between the ASBRs, R5, R6, R11, R12 and XR4. The individual MPLS cores have their LSPs built but they are not end to end between the PE routers. This is only supported on IOS.
The first test is verify that we have traceroute/ping reachability between the PE loopbacks in the disparate SPs.
R1#traceroute 192.0.2.3 source loopback 0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.3
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.17.7 [MPLS: Label 38 Exp 0] 9 msec
100.64.18.8 [MPLS: Label 25 Exp 0] 5 msec
100.64.17.7 [MPLS: Label 38 Exp 0] 5 msec
2 100.64.85.5 [MPLS: Label 28 Exp 0] 15 msec
100.64.75.5 [MPLS: Label 28 Exp 0] 15 msec
100.64.85.5 [MPLS: Label 28 Exp 0] 15 msec
3 100.64.56.6 19 msec 10 msec 10 msec
4 100.64.106.10 [MPLS: Labels 17/50 Exp 0] 12 msec 17 msec 21 msec
5 100.64.112.11 [MPLS: Label 50 Exp 0] 18 msec 19 msec 42 msec
6 100.64.112.12 21 msec 9 msec 11 msec
7 100.64.129.9 [MPLS: Label 18 Exp 0] 9 msec 21 msec 18 msec
8 100.64.39.3 20 msec * 11 msec
You can see that hop 3 and hop 6 don't have labels associated with them. This will prevent an end to end LSP from being formed.
R1#ping 192.0.2.3 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.3, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/11/17 ms
The ping works and so does the traceroute. This tells us that reachability is in place.
To fix this issue we will leverage a pretty cool technique designed to extend the L3VPN between the PE routers. The L3VPN profile, is created and then tied to the VPNv4 configuration.
R1
l3vpn encapsulation ip L3VPN
transport ipv4 source Loopback0
protocol gre key 50693
!
route-map RM_L3VPN permit 10
set ip next-hop encapsulate l3vpn L3VPN
!
router bgp 50693
neighbor 192.0.2.3 remote-as 50693
neighbor 192.0.2.3 update-source Loopback0
!
address-family vpnv4
neighbor 192.0.2.3 activate
neighbor 192.0.2.3 send-community extended
neighbor 192.0.2.3 route-map RM_L3VPN in
R3
l3vpn encapsulation ip L3VPN
transport ipv4 source Loopback0
protocol gre key 50693
!
router bgp 50693
bgp log-neighbor-changes
neighbor 192.0.2.1 remote-as 50693
neighbor 192.0.2.1 update-source Loopback0
!
address-family vpnv4
neighbor 192.0.2.1 activate
neighbor 192.0.2.1 send-community extended
neighbor 192.0.2.1 route-map RM_L3VPN in
exit-address-family
!
route-map RM_L3VPN permit 10
set ip next-hop encapsulate l3vpn L3VPN
At first when I set this configuration up, traffic from R2 and R4 didn't pass, it just died at the PE. I had to remove the VPNv4 iBGP peering in each SP region from the route reflector. I simply removed the neighbor configuration from the global BGP configuration and retried, it worked when I did that.
R1#sh bgp vpnv4 unicast all | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CSC)
*> 100.64.21.0/24 0.0.0.0 0 32768 i
*>i 100.64.34.0/24 192.0.2.3 0 100 0 i
*> 192.0.2.2/32 100.64.21.2 0 0 65002 i
*>i 192.0.2.4/32 192.0.2.3 0 100 0 65004 i
This output shows that there is now a VPNv4 peering between R1 and R3, R3 is advertising R4's loopback to R1.
R1#sh bgp vpnv4 unicast all 192.0.2.4/32
BGP routing table entry for 1:1:192.0.2.4/32, version 81
Paths: (1 available, best #1, table CSC)
Advertised to update-groups:
13
Refresh Epoch 3
65004
192.0.2.3 (metric 20) (via default) (via Tunnel0) from 192.0.2.3 (192.0.2.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/17
rx pathid: 0, tx pathid: 0x0
The original label allocated by VPNv4 is still there, label 17, but you'll see that we're learning this over Tunnel 0 from R3 or 192.0.2.3.
R1#show derived-config interface tunnel0
Building configuration...
Derived configuration : 151 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip redirects
ipv6 enable
tunnel source Loopback0
tunnel mode gre multipoint
tunnel key 50693
R1#sh ip route vrf CSC 192.0.2.4
Routing Table: CSC
Routing entry for 192.0.2.4/32
Known via "bgp 50693", distance 200, metric 0
Tag 65004, type internal
Last update from 192.0.2.3 on Tunnel0, 01:58:42 ago
Routing Descriptor Blocks:
* 192.0.2.3 (default), from 192.0.2.3, 01:58:42 ago, via Tunnel0
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65004
MPLS label: 17
MPLS Flags: MPLS Required
On R1 in the VRF CSC RIB, we expand the route learned from R3 and see that label 17 was applied and the outgoing interface is tunnel 0 with a next hop of 192.0.2.3 or R3's loopback interface. The (default) means that the next hop is in the default RIB. At this point, we should have reachability.
R2#traceroute 192.0.2.4 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.4
VRF info: (vrf in name/id, vrf out name/id)
1 100.64.21.1 [AS 50693] 4 msec 4 msec 1 msec
2 100.64.34.3 [AS 50693] [MPLS: Label 17 Exp 0] 10 msec 11 msec 12 msec
3 100.64.34.4 [AS 50693] 11 msec * 14 msec
We see a rather short traceroute to R4s loopback. At first I thought this was a fluke and didn't believe it. So I pinged it instead and it worked. No fluke, what threw me off was a transport label only label stack. This is expected as R1 is directly connected to R3 and therefore only a VPN label would be needed to get to R3 which then would pop off the VPN label and forward traffic down to R4.
R2#ping 192.0.2.4 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.4, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/59/208 ms
Since the ping worked, we know that reachability is in place.
No comments:
Post a Comment