Unable to ping over VRF to gateway on same device

[sjewhurst]

Hi folks,

I've a bit of an odd scenario here, so hopefully this makes sense.

I have VLAN 100 which is our Management VLAN. It runs between two ASR920s and is trunked to the rest of the network. The Management interfaces on these devices also connect back to that LAN, so essentially the topology looks like this:

Device 2 can ping everything in the 192.168.1.0/24 LAN and has a default route for the Mgmt-intf VRF via 192.168.1.1 which it can use to reach the rest of the network (RADIUS Servers, for example).

Device 1 can ping everything in the 192.168.1.0/24 LAN except 192.168.1.1 - the Gateway.

Device 1 is currently the HSRP Active, so I have a feeling it's got something to do with the traffic being forwarded out a VRF interface and being received on another.

It was working for a short period of time when we migrated to this design and then stopped. I can't figure out what's going wrong but it's stopping that device authenticating to the RADIUS Server (I have to login with local creds after a 30s timeout).

Configuration is pretty straight forward:

interface g0
 vrf forwarding Mgmt-intf
 ip address 192.168.1.40 255.255.255.0
 cdp enable
!
interface BDI 100
 vrf forwarding MANAGEMENT
 ip add 192.168.1.2 255.255.255.0
 standby 1 ip 192.168.1.1
 standby 1 priority 105
!

and some outputs:

core-new#ping vrf Mgmt-intf 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

core-new#ping vrf Mgmt-intf 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

core-new#sh arp vrf MANAGEMENT
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1            -   0000.0c07.ac01  ARPA   BDI100
Internet  192.168.1.2            -   00ea.bd5e.133f  ARPA   BDI100
Internet  192.168.1.3          216   00ea.bd50.f5bf  ARPA   BDI100
Internet  192.168.1.40           1   00ea.bd5e.1338  ARPA   BDI100
Internet  192.168.1.41          23   00ea.bd50.f5b8  ARPA   BDI100

This feels kind of like buggy behaviour...?

[sjewhurst]

Just bumping this folks - Going to open a TAC case now, but figured I can't be the only one who has faced this?

[a.alekseev]

ping vrf Mgmt-intf 192.168.1.1
sh ip arp vrf Mgmt-intf
sh ip arp vrf MANAGEMENT

[sjewhurst]

core1-new#sh arp vrf Mgmt-intf
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1            0   Incomplete      ARPA
Internet  192.168.1.2           45   00ea.bd5e.133f  ARPA   GigabitEthernet0
Internet  192.168.1.3          224   00ea.bd50.f5bf  ARPA   GigabitEthernet0

core2-new#sh arp vrf Mgmt-intf
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1          205   0000.0c07.ac01  ARPA   GigabitEthernet0
Internet  192.168.1.2           47   00ea.bd5e.133f  ARPA   GigabitEthernet0
Internet  192.168.1.3            0   Incomplete      ARPA

core1-new#sh arp vrf MANAGEMENT
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1            -   0000.0c07.ac01  ARPA   BDI100
Internet  192.168.1.2            -   00ea.bd5e.133f  ARPA   BDI100
Internet  192.168.1.3          216   00ea.bd50.f5bf  ARPA   BDI100
Internet  192.168.1.40           1   00ea.bd5e.1338  ARPA   BDI100
Internet  192.168.1.41          23   00ea.bd50.f5b8  ARPA   BDI100

It doesn't seem to resolve for the Virtual IP. Core2 is also unable to ping the IP of its BDI100 interface:

core2-new#ping vrf Mgmt-intf 192.168.1.3 so g0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.41
.....
Success rate is 0 percent (0/5)

[a.alekseev]

if you are really want to make this working create static arp's records in vrfs 

[sjewhurst · Accepted solution]

Yes static ARP did fix the problem, but may not have held during a changeover. It seems this seems to be an odd issues between the Control Plane interface (g0) and the actual forwarding plane. It had TAC scratching their heads. In the end I worked around it by changing the VRF RADIUS traffic was sourced from.