cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
665
Views
10
Helpful
2
Replies
Frequent Contributor

VPNv4 routes exist in the vrf table , but can't ping it

Hello guys

i have the bellow output ,I Cant ping these VPNV4 learned routes from each PE , routes 6.x.x.x and 7.x.x.x

even though these routes exist in the vrf table , kindly help

PE-1#sh ip bgp vpnv4 vrf C1
BGP table version is 18, local router ID is 172.16.0.1
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:100 (default for vrf C1)
*> 6.6.0.0/24 172.16.16.6 1 32768 ?
*> 6.6.1.0/24 172.16.16.6 1 32768 ?
*> 6.6.2.0/24 172.16.16.6 1 32768 ?
*>i7.7.0.0/24 172.16.0.2 1 100 0 ?
*>i7.7.1.0/24 172.16.0.2 1 100 0 ?
*>i7.7.2.0/24 172.16.0.2 1 100 0 ?
*>i172.16.0.7/32 172.16.0.2 1 100 0 ?
*> 172.16.16.0/24 0.0.0.0 0 32768 i
*>i172.16.27.0/24 172.16.0.2 0 100 0 i


--------------------------------------------------------------------


PE-2ip bgp vpnv4 vrf C1
BGP table version is 14, local router ID is 172.16.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf C1)
*>i 6.6.0.0/24 172.16.0.1 1 100 0 ?
*>i 6.6.1.0/24 172.16.0.1 1 100 0 ?
*>i 6.6.2.0/24 172.16.0.1 1 100 0 ?
*> 7.7.0.0/24 172.16.27.7 1 32768 ?
*> 7.7.1.0/24 172.16.27.7 1 32768 ?
*> 7.7.2.0/24 172.16.27.7 1 32768 ?
*> 172.16.0.7/32 172.16.27.7 1 32768 ?
*>i 172.16.16.0/24 172.16.0.1 0 100 0 i
*> 172.16.27.0/24 0.0.0.0 0 32768 i

2 REPLIES 2
Hall of Fame Expert

Hello Ibrahim,

Hello Ibrahim,

in order for L3VPN ping to work you need to verify the MPLS forwarding plane.

First of all, you need to verify that between each pair of PE nodes you have complete and correct LSPs with destination the remote PE loopback.

You can use 

show mpls forwarding <remote-PE-loopback-address>

to check this.

You need to do this on each router PE or P node on the path between PE-1 and PE-2.

You need to verify also the opposite direction from PE-2 to PE-1 using appropriate commands.

Most of the times the issue is at this level. Remember that if you have a non /32 ip address on the loopback and you are using OSPF to have correct behaviuor of LDP with OSPF you need the command ip ospf network point-to-point under the loopback interface configuration.

The correct action for the penultimate router is POP tag not untagged.

If the correct LSPs are in place between PE1 -> PE2 and PE2-> PE1 you can look at the labels assigned by MP BGP for the VPNv4 prefixes.

show ip bgp vpnv4 all labels

This gives you the internal VPN label of the packet.

Hope to help

Giuseppe

Frequent Contributor

Hi bro Giuseppe

Hi bro Giuseppe

thanks for ur expert explanation 

thanks 

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards