10-29-2018 04:08 AM
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...?
Solved! Go to Solution.
12-05-2018 07:05 AM
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.
11-01-2018 01:39 AM
Just bumping this folks - Going to open a TAC case now, but figured I can't be the only one who has faced this?
11-01-2018 02:40 AM
11-05-2018 06:38 AM - edited 11-05-2018 06:40 AM
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)
11-05-2018 09:13 AM
if you are really want to make this working create static arp's records in vrfs
12-05-2018 07:05 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide