10-03-2012 05:53 PM - edited 03-07-2019 09:16 AM
I'm battling an interesting issue on a pair of 7206 NPE-G1 routers running 15.0(1)M9. I've not tried doing active/standby gateways before where static NAT was involved, but I *think* I understand it as applied here.
The routers involved have HSRP on both the WAN and the LAN-side interfaces, and NAT across the pair with identical NAT statements on each. To force a full failover in case link is lost on a single interface, there's a track running for each HSRP interface on its opposite (LAN versus WAN) on the primary router, decrementing its priority and letting the standby router know that it's time to preempt when the primary goes down.
All pretty basic. Router A is primary/active, B is standby.
The issue I'm running into is that following an HSRP failover from A to B, UDP streams from WAN-side devices destined for the inside global IP address (2.2.2.10 in my example below) are interrupted. Running a pcap, I can see that the UDP packets are destined for the global IP address using the BIA for the WAN interface on A, even after the failover to B. Since A is offline, this explains why the stream is interrupted.
It is my understanding that the standby router, when it becomes the active, should push a gratuitous ARP to let devices in the WAN broadcast domain know that it now owns the relevant IP addresses. This does not appear to take place. If a device ARP's asking for the NAT interface following a failover, then router B obliges and everything continues, but since we're talking UDP streams, that doesn't always take place. I can force the streams to resume by sending an ARP request from the device originating the UDP stream, at which point router B responds with an ARP reply and the stream is redirected to the new MAC address, but this isn't something easily automated.
Interestingly, of the three static NAT entries I have configured, only the first (2.2.2.10) is in use. There are no NAT translation entries for the second two entries, as I've never gotten that far. Though I do not see a gratuitous ARP for the first address, I *do* see gratuitous ARPs for the second two. Why should this be?
<--- Router A --->
track 1 interface GigabitEthernet0/2 line-protocol
!
track 2 interface GigabitEthernet0/1 line-protocol
!
interface GigabitEthernet0/1
description LAN
ip address 1.1.1.2 255.255.255.0
ip nat inside
ip virtual-reassembly
load-interval 30
duplex full
speed auto
media-type rj45
no negotiation auto
no cdp enable
standby version 2
standby 1 ip 1.1.1.1
standby 1 priority 110
standby 1 preempt
standby 1 name HSRP1
standby 1 track 1 decrement 50
service-policy output Router-Uplinks
!
interface GigabitEthernet0/2
description WAN
ip address 2.2.2.3 255.255.255.224
ip nat outside
ip virtual-reassembly
load-interval 30
duplex full
speed auto
media-type rj45
no negotiation auto
no cdp enable
standby version 2
standby 2 ip 2.2.2.2
standby 2 priority 110
standby 2 preempt
standby 2 name HSRP2
standby 2 track 2 decrement 50
service-policy output Router-Uplinks
!
no ip classless
ip forward-protocol nd
!
!
ip nat inside source static 1.1.1.40 2.2.2.10 redundancy HSRP1
ip nat inside source static 1.1.1.4 2.2.2.11 redundancy HSRP1
ip nat inside source static 1.1.1.123 2.2.2.12 redundancy HSRP1
ip route 0.0.0.0 0.0.0.0 2.2.2.1
<--- Router B --->
interface GigabitEthernet0/1
description LAN
ip address 1.1.1.3 255.255.255.0
ip nat inside
ip virtual-reassembly
load-interval 30
duplex full
speed auto
media-type rj45
no negotiation auto
no cdp enable
standby version 2
standby 1 ip 1.1.1.1
standby 1 preempt
standby 1 name HSRP1
!
interface GigabitEthernet0/2
description WAN
ip address 2.2.2.4 255.255.255.224
ip nat outside
ip virtual-reassembly
load-interval 30
duplex full
speed auto
media-type rj45
no negotiation auto
no cdp enable
standby version 2
standby 2 ip 2.2.2.2
standby 2 preempt
standby 2 name HSRP2
!
no ip classless
ip forward-protocol nd
!
!
ip nat inside source static 1.1.1.40 2.2.2.10 redundancy HSRP1
ip nat inside source static 1.1.1.4 2.2.2.11 redundancy HSRP1
ip nat inside source static 1.1.1.123 2.2.2.12 redundancy HSRP1
ip route 0.0.0.0 0.0.0.0 2.2.2.1
Solved! Go to Solution.
10-17-2012 12:17 PM
Hello Evan,
Really interesting, thanks for the updated.
Mark the question as answered so future users can learn from your problem.
Regards
10-17-2012 11:20 AM
Curiously, the configuration worked after a reboot of the chassis following a crash dump triggered by physically unplugging one of the ports in the course of troubleshooting. Now the unsolicited/gratuitous arps are occuring as expected, and everything is fine.
Resolved.
10-17-2012 12:17 PM
Hello Evan,
Really interesting, thanks for the updated.
Mark the question as answered so future users can learn from your problem.
Regards
12-07-2017 09:30 PM
Hi,
why you created HSRP2 in this configuration. because you have not call any ware in this configuration.
2nd query is . if you added both interface in Tracking than why you create HSRP for outside interface.
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