BGP VPNv4 Troubleshooting Commands .

Let's do it,,,,

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

1 2 3 4 5 6 7

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

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.

1 2 3 4 5 6 7 8 9 10 11 12

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

1 2 3 4 5 6 7 8 9 10 11 12 13

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.

1 2 3 4

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

1 2 3 4 5 6 7 8 9 10

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

1 2 3 4 5 6 7 8 9 10 11 12

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

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.
------------------------------------------------------------------------------------------------

• When BGP is not behaving correctly, a "trick" to temporarily stop peering with a neighbor is to use the following command:

  router bgp 194
neighbor<ipaddress>
password xxx

  Since the other router doesn't have the same password, the two routers will stop talking to one another, without you having to do anything else. Later, when the problem is resolved, simply remove the line to reestablish peerage.
• To see what routes you're getting from an AS, use the command

  show ip bgp regexp <regluar-expression-for-an-AS>

• To see what routes you're getting from a neighbor, do

  show ip bgp vpnv4 vrf tr neighbors 192.43.217.133 received-routes
show ip bgp vpnv4 vrf nlr neighbors 192.43.217.138 received-routes
show ip bgp vpnv4 vrf nlr neighbors 216.24.184.25 received-routes

• To see a quick status of all BGP, on a !non-vrf router and a vrf router,

  show ip bgp summary
show ip bgp vpnv4 vrf tr summary

• To see BGP routes, in the default table or an explicit VRF,

  show ip bgp
show ip bgp vpnv4 vrf tr

• To see what routes you're getting from a neighbor, use one of these

  show ip bgp neighbor <IP-address-of-neighbor> routes
show ip bgp vpnv4 vrf tr neighbor 192.43.217.133

• To see what routes you're sending to a neighbor, use the command

  show ip bgp neighbor <IP-address-of-neighbor> advertised-routes

• To clear a BGP session:

  clear ip bgp <ip-address of neighbor>

• To find out who owns, say, Autonomous System number 44, go to http://www.arin.net/ and type AS44. Or get file ftp://rs.arin.net/netinfo/asn.txt. Or Web to http://www.arin.net/docs.html.
• To see what's happening with BGP, use the commands

  terminal monitor
debug ip bgp events

• To show all the networks sourced by this AS

  show ip bgp regexp ^$