cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5154
Views
25
Helpful
38
Replies

MPLS over FLEX VPN shortcut does not work - NHRP error: Could not find AVL node for vrf

Tyche
Level 1
Level 1
#  The problem:

I have configured MPLS over FlexVPN following the configuration snipet of Cisco live (page 39)
 
The spoke-to-spoke traffic shortcut is not working so all the traffic goes via the hub.
When debugging NHRP I  see the error: Could not find AVL node for vrf
 
Does anyone know what this error mean and how to fix it?
 
I am running:  Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.7(3)M3, RELEASE SOFTWARE (fc2)
 
#  Diagram  
 
R1 (spoke LAN = 10.1.10.1/24 - vrf BLUE)======== R3(hub)============R2(spoke LAN = 10.1.20.1/24 - vrf BLUE)
 
# Troubleshooting steps
 
  R2 sends ICMP traffic to R1 LAN.  R2 receives a redirect from the hub and sends back a Resolution Request.
 
r2#ping vrf BLUE 10.1.10.1 source gi0/1 repeat 3


r2#sl
Log Buffer (8192 bytes):

 NHRP: Receive Traffic Indication via Tunnel0 vrf global(0x0), packet size: 84
  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
      shtl: 4(NSAP), sstl: 0(NSAP)
      pktsz: 84 extoff: 68
  (M) traffic code: redirect(0)
      src NBMA: 198.51.100.7
      src protocol: 10.1.30.0, dst protocol: 10.1.20.1
      Contents of nhrp traffic indication packet:
         45 00 00 64 00 67 00 00 FE 01 8A 2E 0A 01 14 01
         0A 01 0A 01 08 00 64 11 00 19 00
 NHRP-DETAIL: netid_in = 1, to_us = 0
 NHRP-DETAIL: Multipath IP route lookup for 10.1.20.1 in vrf BLUE(0x1) yielded GigabitEthernet0/1, pfx:10.1.20.0/24 (netid_in:1 if_in:Tunnel0)
 NHRP: nhrp_rtlookup yielded GigabitEthernet0/1
 NHRP-DETAIL: netid_out 0, netid_in 1
 NHRP: Parsing NHRP Traffic Indication

 NHRP: Enqueued NHRP Resolution Request for destination: 10.1.10.1
 NHRP: Checking for delayed event NULL/10.1.10.1 on list (Tunnel0 vrf: BLUE(0x1))
 NHRP: No delayed event node found.
 
 R3 (hub)  receive the resolution request but is unable to respond.
The error seen is : 'NHRP: Could not find AVL node for vrf:BLUE(0x1)'
 
NHRP: Receive Resolution Request via Virtual-Access1 vrf global(0x0), packet size: 79
 (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
     pktsz: 79 extoff: 52
 (M) flags: "router auth src-stable nat ", reqid: 20
     src NBMA: 198.51.100.3
     src protocol: 10.1.30.2, dst protocol: 10.1.10.1
 (C-1) code: no error(0)
       prefix: 32, mtu: 17874, hd_time: 600
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
NHRP-DETAIL: netid_in = 1, to_us = 0
NHRP: Could not find AVL node for vrf:BLUE(0x1)
NHRP-DETAIL: Multipath IP route lookup for 10.1.10.1 in vrf BLUE(0x1) yielded Null0, pfx:10.1.10.0/24 (netid_in:1 if_in:Virtual-Access1)
NHRP: Route lookup for destination 10.1.10.1 in vrf BLUE(0x1) yielded interface Null0, prefixlen 24
NHRP: Could not find AVL node for vrf:BLUE(0x1)

 
Yet the hub does have a route for the prefix 10.1.10.0/24
 
r3#sh ip route vrf BLUE | b ^G
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
S        10.1.0.0/16 is directly connected, Null0
B        10.1.10.0/24 [200/0] via 10.1.30.1, 00:37:56
B        10.1.20.0/24 [200/0] via 10.1.30.2, 00:37:10
C        10.1.30.30/32 is directly connected, Loopback10

r3#sh ip cef vrf BLUE 10.1.10.1
10.1.10.0/24
  nexthop 10.1.30.1 Virtual-Access2 label 16-(local:18)
 
r2 never gets a reply so the shortcut does not work
 
r2#sh ip nhrp
10.1.10.1/32 (BLUE)
   Tunnel0 created 00:00:04, expire 00:03:00
   Type: incomplete, Flags: negative
   Cache hits: 2


r2#traceroute vrf BLUE 10.1.10.1 source gi0/1
Type escape sequence to abort.
Tracing the route to 10.1.10.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.30.30 61 msec 57 msec 31 msec
  2 10.1.10.1 87 msec 102 msec 124 msec
 
# Configuration Snipet on Hub 
 
vrf definition BLUE
 rd 1:1
 !
 address-family ipv4
  route-target export 1:1
  route-target import 1:1
 exit-address-family
!
vrf definition RED
 rd 1:2
 !
 address-family ipv4
  route-target export 1:2
  route-target import 1:2
 exit-address-family
!
interface Loopback1
 ip address 10.1.30.0 255.255.255.255
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback1
 ip nhrp network-id 1
 ip nhrp redirect
 mpls nhrp
 tunnel source GigabitEthernet0/2
 tunnel protection ipsec profile default
!
router bgp 1
 bgp log-neighbor-changes
 bgp listen range 10.1.30.0/24 peer-group Flex
 neighbor Flex peer-group
 neighbor Flex remote-as 1
 neighbor Flex update-source Loopback1
 neighbor Flex timers 5 15
 !
 address-family vpnv4
  neighbor Flex activate
  neighbor Flex send-community extended
 exit-address-family
 !
 address-family ipv4 vrf BLUE
  network 10.1.0.0 mask 255.255.0.0
  network 10.1.30.30 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf RED
  network 10.1.0.0 mask 255.255.0.0
 exit-address-family
 
38 Replies 38

Amazing !

I look forward to seeing your configs.

 

llll.png

last thing I missing add these command in hub and spoke please add it to your config 

aaa new

!

aaa authorization network default local 

 

that all config if you have any Q. please share here.

good luck Bro 

Hello HMH,

 

Thank you for the help.

 

When using MPLS over DVMPN we should not use LDP.

 

Please see slide 108 in the PDF below.

 

https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2017/pdf/BRKSEC-4054.pdf

 

Your solution violates this guidelines as you are using "mpls ip" in the configuration.

 

It seems others in the past have managed to get "mpls nhrp" to work:

 

https://blog.hop16.com/2014/08/dmvpn-mpls-over-dmvpn-oh-yeah.html

 

I can't see what we are missing ...

 

 

 

 

MPLS IP is replace with MPLS NHRP for DMVPN tunnel, so they work same,

MPLS over Flex "DMVPN" we not use MPLD LDP "this use for non direct connect MPLS Peer" we have direct connect through tunnel and both peer exchange the label.

Dear MHM,

From Cisco:

'IKEv2 is used instead of LDP because LDP involves establishing TCP channel with every LDP neighbor. Enabling LDP keeps the spoke-to-spoke channel active due to the LDP hello traffic thereby never bringing down the spoke-to-spoke channel. Therefore, the mpls ip command must never be executed on the tunnel interface or virtual template when configuring the MPLS over FlexVPN feature.'

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-mt/sec-flex-vpn-15-mt-book/sec-cfg-mpls-flex.html  

 

 

I will check this point in my lab

Hello MHM,

 

I just wanted to wish you a happy new year and lots of success in your certification and professional endeavors.

 

Tyche

Happy New year friend, I wish you all success in your life.
Thanks a lot friend 

Thank you dear friend
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco