We have a classical hub-spoke FlexVPN design. recently, i observed a strange behaviour where, when two spokes ping eachothers customer facing network, create two NHRP entries. Lets have a look at router A
RouterA#show ip interface brief | include Loo|Vlan10|Tunnel1|Dial
Dialer1 80.89.219.37 YES IPCP up up
Loopback0 172.20.220.1 YES NVRAM up up
Tunnel1 172.18.0.205 YES NVRAM up up
Vlan10 172.16.220.2 YES NVRAM up up
RouterA#show running-config interface tunnel 1
interface Tunnel1
description VPN
vrf forwarding LAN
ip address negotiated
ip mtu 1400
ip nhrp network-id 1
ip nhrp shortcut virtual-template 1
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source Dialer1
tunnel destination dynamic
tunnel vrf DSL
tunnel protection ipsec profile SECURE
end
RouterA#show running-config interface virtual-template1
interface Virtual-Template1 type tunnel
description VPN
vrf forwarding LAN
ip unnumbered Tunnel1
ip mtu 1400
ip nhrp network-id 1
ip nhrp shortcut virtual-template 1
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel vrf DSL
tunnel protection ipsec profile SECURE
end
So Loopback is for management, Tunnel1 is for the VPN and Vlan10 is the customer network. All spokes have the same setup (they get configured via Script and we audit the config afterwards). So the only difference are the IP's. Lets look at router B for the IP part only:
RouterB#show ip interface brief | include Loop|Vlan10|Tunnel1|0/0/0
GigabitEthernet0/0/0 91.25.155.170 YES manual up up
Loopback0 172.20.200.1 YES NVRAM up up
Tunnel1 172.18.0.148 YES NVRAM up up
Vlan10 172.16.200.2 YES NVRAM up up
So when i ping from RouterA to RouterB, the NHRP entries are getting created:
RouterA#ping vrf LAN 172.16.200.2 source 172.16.220.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.220.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/52/100 ms
RouterA#show ip nhrp
172.16.200.0/23 (LAN) via 172.18.0.148 <------ Goes via Tunnel1 aka Hub but should go via virtual-access3
Tunnel1 created 00:00:19, expire 00:09:40
Type: dynamic, Flags: router rib nho
NBMA address: 91.25.155.170
172.18.0.148/32 (LAN) via 172.18.0.148 <------- This entry points to the VPN interface of RouterB but goes thru the wrong interface
Tunnel1 created 00:00:19, expire 00:09:40
Type: dynamic, Flags: router nhop rib nho
NBMA address: 91.25.155.170
172.18.0.148/32 (LAN) via 172.18.0.148 <------- This entry points to the VPN interface of RouterB and goes thru the correct interface
Virtual-Access3 created 00:00:19, expire 00:09:40
Type: dynamic, Flags: router implicit nhop rib nho
NBMA address: 91.25.155.170
172.16.220.0/24 (LAN) via 172.18.0.205 <------- This entry is the local network (Vlan10) on RouterA, dont know why this points to the VPN interface to RouterB
Virtual-Access3 created 00:00:19, expire 00:09:40
Type: dynamic, Flags: router unique local
NBMA address: 80.89.219.37 <---- WAN IP of RouterA
(no-socket)
So in my understanding, traffic for destination 172.16.200.0/23 should go via 172.18.0.148 (rule #1) and traffic to 172.18.0.148/32 should then go via Virtual-Access3 (rule #3) which should circumvent the hub router. But why is there rule #2 that prevents rule#3 from being useful? When i do a traceroute, i can see that the traffic that is destined to RouterB goes via the Hub, even though there is an active direct VPN connection open:
RouterA#traceroute vrf LAN 172.16.200.2
Type escape sequence to abort.
Tracing the route to RouterB.company.local (172.16.200.2)
VRF info: (vrf in name/id, vrf out name/id)
1 172.18.0.1 8 msec 8 msec 8 msec <--------- Goes via Hub
2 172.18.0.148 20 msec * 20 msec
RouterA#get vpn
ID Remote Public IP runtime SPI (Index) Hostname Initiator remote Tunnel IP Interface
-- ---------------- ----------- ---------------- -------- --------- ------------ ----------------
1 91.25.155.170 1m12s 0F356CC6324774AC RouterB Myself 172.18.0.148 Virtual-Access3
2 212.25.31.77 13h49m45s 3CD4DB1EF8F31956 HubA Myself 172.18.0.1 Tunnel1
3 195.141.222.179 13h49m48s E6160C14E0D2FC34 HubB Myself 172.19.0.1 Tunnel2
get vpn is not an official command, but a script that gets me all necessary information out of the device. Can anyone give me any advice on what is misconfigured? Dont know for how long this issue persists, as no user has complained so far because we operate within europe and have very low latency even while turning on the hub. But i really want this to get fixed. We are running C1113-8PLTEEA routers as spoke with firmware 17.09.02a
