BGP VPNv4 Troubleshooting Commands

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&lt

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