Let me start by saying that this article is Cisco-specific, though it applies to IOS, IOS-XE, and NX-OS. I’ve not used IOS-XR, so I don’t know about that one.
When using an FHRP, like HSRP or VRRP, you can’t “force” a router to cause another device to update its ARP table simply by pinging it, as you can with an actual interface IP address. This could create a situation where you want to convert a single router into two redundant routers, but you don’t have access to clear the ARP table on the other devices in the network.
Sometimes it’s not even necessary to worry about MAC changes. For example, imagine I have an ASA with an address of 10.91.50.1 pointing to 10.91.50.254 for its next-hop router. I have one router with interface Gi0/0 configured as 10.91.50.254 with a MAC address of f40f.1bbf.01b0. Let’s say I change the interface address to 10.91.50.252 and make 10.91.50.254 the VRRP address, which yields a MAC address of 0000.5e00.015b. The ASA will continue to think that 10.91.50.254 has a MAC address of f40f.1bbf.01b0, that is until its ARP cache times that entry out. And this is perfectly okay! The router will continue forwarding those packets on. When the ARP cache times out and the ASA does an ARP request for 10.91.50.254, it will learn the new VRRP MAC address of 0000.5e00.015b and all will be well.
But what if you want to test failover before you have a chance to let the ASA time-out its ARP table? Or what if you don’t have access to the ASA to see what it has in its ARP table (is it pointed to the burned-in MAC or the VRRP MAC)?
In that case, maybe we can “force” an update on the ASA (or whatever else) without having access to it. Let’s try (from the router):
When using an FHRP, like HSRP or VRRP, you can’t “force” a router to cause another device to update its ARP table simply by pinging it, as you can with an actual interface IP address. This could create a situation where you want to convert a single router into two redundant routers, but you don’t have access to clear the ARP table on the other devices in the network.
Sometimes it’s not even necessary to worry about MAC changes. For example, imagine I have an ASA with an address of 10.91.50.1 pointing to 10.91.50.254 for its next-hop router. I have one router with interface Gi0/0 configured as 10.91.50.254 with a MAC address of f40f.1bbf.01b0. Let’s say I change the interface address to 10.91.50.252 and make 10.91.50.254 the VRRP address, which yields a MAC address of 0000.5e00.015b. The ASA will continue to think that 10.91.50.254 has a MAC address of f40f.1bbf.01b0, that is until its ARP cache times that entry out. And this is perfectly okay! The router will continue forwarding those packets on. When the ARP cache times out and the ASA does an ARP request for 10.91.50.254, it will learn the new VRRP MAC address of 0000.5e00.015b and all will be well.
But what if you want to test failover before you have a chance to let the ASA time-out its ARP table? Or what if you don’t have access to the ASA to see what it has in its ARP table (is it pointed to the burned-in MAC or the VRRP MAC)?
In that case, maybe we can “force” an update on the ASA (or whatever else) without having access to it. Let’s try (from the router):
router# ping 10.91.50.1 source 10.91.50.254Unfortunately, it doesn’t let us. However, if you do an extended ping, it does let you:
% Invalid source address- IP address not on any of our up interfaces
router# pingProtocol [ip]:Target IP address: 10.91.50.1Repeat count [5]:Datagram size [100]:Timeout in seconds [2]:Extended commands [n]: yIngress ping [n]:Source address or interface: 10.91.50.254Type of service [0]:Set DF bit in IP header? [no]:Validate reply data? [no]:Data pattern [0x0000ABCD]:Loose, Strict, Record, Timestamp, Verbose[none]:Sweep range of sizes [n]:Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.91.50.1, timeout is 2 seconds:Packet sent with a source address of 10.91.50.254!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Boom, ARP table updated on remote device. I would say that the fact you can’t ping it while specifying an FHRP source interface from the command-line but you can ping specifying an FHRP source from extended ping is an oversight on behalf of the Cisco engineers. Oh well, it is what it is.
By the way, this works on IOS for both HSRP and VRRP addresses. On my Nexus 7010, version 6.2(16), you can even specify the source IP address from the command-line, instead of having to go through the extended ping interaction. For example: ping 10.200.5.218 source 10.91.50.254.
By the way, this works on IOS for both HSRP and VRRP addresses. On my Nexus 7010, version 6.2(16), you can even specify the source IP address from the command-line, instead of having to go through the extended ping interaction. For example: ping 10.200.5.218 source 10.91.50.254.
No comments:
Post a Comment