When working with MPLs Layer 3 VPN a lot of people get stuck with the verification, simply because they don’t know the bgp vpnv4 troubleshooting commands.
This post will step through some of the verification you can use to verify the routes end to end through a simple MPLS Layer 3 vpn topology.
The topology I will be using is below and is a very simple 3 router core with one vrf and ospf being the CE to PE protocol on each side.
I have created vrf ONE on Router 3 and on Router 5, OSPF 1 Area 0 is running between R3,R4,R5 and R3 is peering with MP-BGP to R5
All your troubleshooting commands will now need to include vpnv4 and the commands do get quite long. Here are my top bgp vpnv4 troubleshooting commands.
BGP VPNv4 troubleshooting commands
Before we start with the troubleshooting commands lets just verify everything is working, I will jump onto R1 and ping R6 loopback
R1#ping 6.6.6.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/63/76 ms R1#
Ok this works and prove the VPN is working, now we will go through some of the troubleshooting commands so you can see how to spot problems.
sh ip route vrf (name)
To see the routes within the VRF on Router 3 you run the command sh ip route vrf ONE
R3#sh ip route vrf ONE Routing Table: ONE Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/11] via 10.0.13.1, 00:33:37, FastEthernet0/0 6.0.0.0/32 is subnetted, 1 subnets B 6.6.6.6 [200/11] via 5.5.5.5, 00:12:21 10.0.0.0/24 is subnetted, 2 subnets C 10.0.13.0 is directly connected, FastEthernet0/0 B 10.0.56.0 [200/0] via 5.5.5.5, 00:12:21 R3#
This will show you the routes that have been learnt in from R1 and any routes coming from the VRF on R5
As you can see we have the route 6.6.6.6 for the loopback of R6.
The command sh bgp vpnv4 unicast vrf ONE should show the same output.
R3#sh bgp vpnv4 unicast vrf ONE BGP table version is 19, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ONE) *> 1.1.1.1/32 10.0.13.1 11 32768 ? *>i6.6.6.6/32 5.5.5.5 11 100 0 ? *> 10.0.13.0/24 0.0.0.0 0 32768 ? *>i10.0.56.0/24 5.5.5.5 0 100 0 ?
Now if we change the route-target export value on R3 to stop exporting the routes, you can see on R5 the routes from R1 will disappear.
This is the output of sh bgp vpnv4 unicast vrf ONE with the correct configuration
R5#sh bgp vpnv4 unicast vrf ONE BGP table version is 31, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ONE) *>i1.1.1.1/32 3.3.3.3 11 100 0 ? *> 6.6.6.6/32 10.0.56.6 11 32768 ? *>i10.0.13.0/24 3.3.3.3 0 100 0 ? *> 10.0.56.0/24 0.0.0.0 0 32768 ? R5#
You can see there is a route for 1.1.1.1 – now we can stop this in a number of ways but one way is to change the route-target import value on R5. So R1 will be exporting 3:5 and if we change the import value on R5 to something different we will stop getting the route.
R5(config)#ip vrf ONE R5(config-vrf)#no route-target import 3:5 R5(config-vrf)#route-target import 3:6 R5(config-vrf)#
Now we didn’t actually have to add a new value, removing the current value would do the job
Looking on R5 now with <strong>sh bgp vpnv4 unicast vrf ONE</strong> you can see that the 1.1.1.1 route has gone
R5#sh bgp vpnv4 unicast vrf ONE BGP table version is 33, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ONE) *> 6.6.6.6/32 10.0.56.6 11 32768 ? *> 10.0.56.0/24 0.0.0.0 0 32768 ?
If you wanted to troubleshoot this issue you would probably first check if R1 was actually advertising the route. Under normal BGP you would just use the command sh ip bgp neighbor 5.5.5.5 advertised-routes. Withing vpnv4 the command changes a bit to be
sh bgp vpnv4 unicast all neighbors 5.5.5.5 advertised-routes
If we run this on R3 you will see we are advertising the route
R3#sh bgp vpnv4 unicast all neighbors 5.5.5.5 advertised-routes BGP table version is 9, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ONE) *> 1.1.1.1/32 10.0.13.1 11 32768 ? *> 10.0.13.0/24 0.0.0.0 0 32768 ? Total number of prefixes 2
So if we were troubleshooting this issue we would know the routes are being advertised by R3 so we would turn our attention to R5 and verify the route-target import values are correct, which we know they are not!
I will change the the route-import value back and will also enable a debug.
debug bgp vpnv4 unicast updates this will let you see bgp updates within the vpnv4 process
R5(config)#ip vrf ONE R5(config-vrf)#no route-targe import 3:6 R5(config-vrf)#route-target import 3:5 R5#debug bgp vpnv4 unicast updates BGP updates debugging is on for address family: VPNv4 Unicast BGP table version is 33, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - inte rnal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf ONE) *> 6.6.6.6/32 10.0.56.6 11 32768 ? *> 10.0.56.0/24 0.0.0.0 0 32768 ? R5# *Mar 1 01:07:45.879: BGP(2): 3.3.3.3 rcvd UPDATE w/ attr: nexthop 3.3.3.3 , origin ?, localpref 100, metric 0, extended community RT:3:5 OSPF DOMAIN ID:0x0005:0x0000000A0200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.13.3:0 *Mar 1 01:07:45.895: BGP(2): 3.3.3.3 rcvd 100:1:10.0.13.0/24 *Mar 1 01:07:45.903: BGP(2): 3.3.3.3 rcvd UPDATE w/ attr: nexthop 3.3.3.3 , origin ?, localpref 100, metric 11, extended community RT:3:5 OSPF DOMAI N ID:0x0005:0x0000000A0200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.13.3:0 *Mar 1 01:07:45.911: BGP(2): 3.3.3.3 rcvd 100:1:1.1.1.1/32<
Here you can see the route coming back in again.
The final command I am going to share is clearing the bgp vpnv4 process
Under ipv4 bgp you would use the clear ip bgp * command to bounce your neighbors, under vpnv4 the command changes to
clear bgp vpnv4 unicast *
You can specify the neighbor if you were in production but within a lab environment using the * is fine.
I hope these bgp vpnv4 troubleshooting commands have been helpful and if you would like anything explained further leave a comment below.
Roger
Rogers' CCIE Journey | About Roger | Contact | Twitter | Linkedin
Leave a Reply