Friday, November 4, 2016

MPLS L3 VPN Inter AS Option C Multihop EBGP VPNv4 Peering

In our last post we took a look at Option B where we had R1 and XR1 form a VPNv4 BGP peering and exchange labels, the LSP is then end to end and not broken up at the ASBRs. 

In this post we will take a look at Option C or  Multihop EBGP VPNv4 Peerings between the different ASs Route Reflectors. Not to be mistaken, we are not form RR peerings between the RRs rather using the RR as a way to propagate routing info from the remote ASs into the local AS. The configuration is pretty straightforward for the most part, it's more a matter of understanding the individual functions and the role each serves that will help bring this config altogether.

The PE-PE connectivity is the first piece, which is going to be between BGP ASN 1000 and BGP ASN 50693, this will be done in the global table with some minor modifications made later. I'm using a different topology than the last couple Inter AS rollouts but the process is the same:

R3 and XR4 need to form EBGP IPv4 Unicast peerings with each other. The send-label config is used to send BGP routes plus BGP labels to the remote PE, XR4 in this case. The labeled-unicast on XR4 does the same thing as the send-label, adds a BGP label.

R3:
router bgp 50693
 neighbor 143.0.0.14 remote-as 1000
 !
 address-family ipv4
  neighbor 143.0.0.14 activate
  neighbor 143.0.0.14 send-label

XR4:
router bgp 1000
neighbor 143.0.0.3
  remote-as 50693
  address-family ipv4 labeled-unicast
   route-policy PASS in
   route-policy PASS out

As soon as this peering is up and running, we move to the next step of advertising the route reflector loopbacks of BGP ASN 1000 and 50693 into IPv4 BGP in their respective ASN.

XR4:
RP/0/0/CPU0:XR4#sh run router bgp
router bgp 1000
 address-family ipv4 unicast
  network 4.4.4.4/32
  network 114.114.114.114/32

R4:
router bgp 1000
address-family ipv4
 network 4.4.4.4 mask 255.255.255.255

R3
router bgp 50693
address-family ipv4
 network 1.1.1.1 mask 255.255.255.255

Now, we should see on R4 and XR4, the 1.1.1.1/32 in BGP

XR4:
show route
B    1.1.1.1/32 [20/30] via 143.0.0.3, 20:35:22
B        1.1.1.1 [20/20] via 13.4.0.13, 00:10:41

One of the issues I ran into with having 2 BGP external connections is that the AD of eBGP is 20 and OSPF is 110. So I ended up having to shutdown the connection between  XR3 and R4. 

What needs to happen next is the IGP needs to redistribute the BGP Loopback /32 address into IGP. We'll use some filtering to make sure only the loopbacks are learned.

XR4:
prefix-set BGP
  1.1.1.1/32
end-set
!
route-policy BGP_TO_IGP
  if destination in BGP then
    pass
  endif
end-policy
!
router ospf 1
 redistribute bgp 1000 route-policy BGP_TO_IGP

R3:
router isis 1
 redistribute bgp 50693 route-map BGP_TO_IGP
ip prefix-list BGP seq 5 permit 4.4.4.4/32
ip prefix-list BGP seq 10 permit 114.114.114.114/32
route-map BGP_TO_IGP permit 10
 match ip address prefix-list BGP

Now to verify that R1, R4 and XR4 are learning the remote RR loopback(s).
R1:
sh ip route
i L2     4.4.4.4 [115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113
                 [115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12
i L2     114.114.114.114
           [115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113
           [115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12

XR4 is a bit unique, but it still works ;)
show route
B    1.1.1.1/32 [20/30] via 143.0.0.3, 20:42:58

R4:
show ip route
O E2     1.1.1.1 [110/1] via 10.4.14.14, 20:43:16, GigabitEthernet1.414

Now, the next step here is to verify that R1, R4 and XR4 can ping/trace to and from each other's loopback addresses.

R1:
R1#ping 4.4.4.4 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/8/24 ms
R1#ping 114.114.114.114 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 114.114.114.114, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/5/18 ms

R4#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/20 ms

XR4:
RP/0/0/CPU0:XR4#ping 1.1.1.1 source 114.114.114.114
Fri Nov  4 21:33:53.914 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Alright! Now we can form the eBGP VPNv4 Multihop peerings!
R1:
router bgp 50693
 neighbor 4.4.4.4 remote-as 1000
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 114.114.114.114 remote-as 1000
 neighbor 114.114.114.114 ebgp-multihop 255
 neighbor 114.114.114.114 update-source Loopback0
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
  neighbor 114.114.114.114 activate
  neighbor 114.114.114.114 send-community extended
 exit-address-family

R4:
router bgp 1000
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 1.1.1.1 remote-as 50693
 neighbor 1.1.1.1 ebgp-multihop 255
 neighbor 1.1.1.1 update-source Loopback0
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
exit-address-family


XR4:
router bgp 1000
 neighbor 1.1.1.1
  remote-as 50693
  ebgp-multihop 255
  update-source Loopback0
  address-family vpnv4 unicast
   route-policy PASS in
   route-policy PASS out
   next-hop-unchanged

Let's verify that the BGP peerings are formed and exchanging routes.

R1:
sh bgp vpnv4 unicast all summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4         1000    1407    1419      515    0    0 20:52:56        4
114.114.114.114 4         1000    1259    1394      515    0    0 20:48:00        4

R4:
sh bgp vpnv4 unicast all summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4        50693    1420    1408      519    0    0 20:53:32       24

XR4:
sh bgp vpnv4 unicast summary
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
1.1.1.1           0 50693    1421    1275     1223    0    0 20:49:06         24

Now that we have routes being learned and propagated we can now begin the next step, which is setting up XR4 for the XR specific configuration.

R3 on the peering to XR4 needs to have the "send-label" configuration under the IPv4 unicast AFI.

R3:
router bgp 50693
address-family ipv4
  neighbor 143.0.0.14 send-label

XR4:
router static
 address-family ipv4 unicast
  143.0.0.3/32 GigabitEthernet0/0/0/0.143

Needed for a /32 host route to the next hop towards R3, hence the 143.0.0.3/32 configuration. 

XR4:
router bgp 1000
 address-family ipv4 unicast
  allocate-label all

To trigger BGP to allocate labels for all global routes

We should be good to go at this point, routes should be propagated and LSPs should be built. Lets see what R7 and R5 see as route counts via BGP

R7:
show ip bgp summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
14.7.0.14       4         1000    3012    3285      273    0    0 2d01h          18

R5:
show ip bgp summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
54.0.0.4        4         1000    1641    1624       99    0    0 1d00h           6

Great! Now lets trace from R9 to R7 and see the output:
R9#traceroute 7.7.7.7 source lo0 num
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 12.9.0.12 2 msec 1 msec 0 msec
  2 10.11.12.11 [MPLS: Labels 111017/24 Exp 0] 9 msec 8 msec 7 msec
  3 10.1.11.1 [MPLS: Labels 55/24 Exp 0] 28 msec 31 msec 32 msec
  4 10.1.13.13 [MPLS: Labels 130027/24 Exp 0] 32 msec 31 msec 32 msec
  5 10.13.3.3 [MPLS: Labels 56/24 Exp 0] 71 msec 77 msec 21 msec
  6 143.0.0.14 [MPLS: Labels 24000/24 Exp 0] 22 msec 21 msec 22 msec
  7 10.4.14.4 [MPLS: Label 24 Exp 0] 22 msec 21 msec 21 msec
  8 10.4.14.14 [MPLS: Label 24025 Exp 0] 22 msec 21 msec 21 msec
  9 14.7.0.7 [AS 7] 21 msec *  74 msec

As you can see the LSP is maintained, it changes when the Inter AS link comes into play on hop 8, the VPNv4 label changes from 24 to 24025. But that is an expected outcome. What we do see but is a sub optimal path is that R4, or hop 7 is in the data plane. The reason behind that is the next hops via bgp vpnv4 unicast is R1, R4 and XR4. Since the VPNv4 next hop is the remote AS RR, that is where the LSP will terminate for 7.7.7.7, at least in this particular case. 

We can change this by issuing the next-hop-unchanged under the VPNv4 unicast AFI.
R1
router bgp 50693
address-family vpnv4
  neighbor 4.4.4.4 next-hop-unchanged

R4
router bgp 1000
address-family vpnv4
  neighbor 1.1.1.1 next-hop-unchanged

XR4
router bgp 1000
neighbor 4.4.4.4
address-family vpnv4 unicast
 next-hop-unchanged

Now we can retrace from R9 to R7 and see the difference
R9#traceroute 7.7.7.7 source lo0 num
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 12.9.0.12 1 msec 1 msec 1 msec
  2 10.11.12.11 [MPLS: Labels 111018/24025 Exp 0] 9 msec 8 msec 9 msec
  3 10.1.11.1 [MPLS: Labels 54/24025 Exp 0] 29 msec 32 msec 37 msec
  4 10.1.2.2 [MPLS: Labels 17/24025 Exp 0] 22 msec 31 msec 31 msec
  5 10.2.3.3 [MPLS: Labels 57/24025 Exp 0] 32 msec 39 msec 23 msec
  6 14.7.0.7 [AS 7] 21 msec *  8 msec

Notice now that the VPNv4 label of 24025 is now maintained end to end. This is the expected output since we aren't having to leave one LSP and join another one, we are no longer terminating on R4 and then using LDP between R4 and XR4 to label switch the VPNv4 label to XR4. 

As you can see, this is a rather involved configuration. I didn't bother showing the base setup of IGP/LDP, VPNv4 peerings, VRF configuration or the PE-CE routing. It is assumed you already know how to do that. 

Thanks for stopping by!
Rob Riker, CCIE #50693

No comments:

Post a Comment