Issues with auto last hop, HSRP and peer-gateway
Hello Devs! How's everybody today? I'm trying to solve an issue we're having with a pair o viprions dual attached to two Cisco Nexus 7000. The thing is that both Nexus run HSRP and peer-gateway. Big-Ip has a transit network with nexus and both nexus have another transit network to a firewall. What is happening is some returnig traffic is coming from N7K-2 instead of N7K-1 (because of vPC and peer-gateway). And since auto last hop is enabled, F5 is complaining a lot and some connections are being reset. Which is bad. I read through KB9487, KB2211 and KB8290. Disabling auto last hop seems to fix the issue but it seems very drastic. What got my attention is that Last Hop Pool takes precedence over Auto Last Hop when one of the last hop pool members have died. But my question is: Considering all last hop pool members are UP, what would happen if auto last hop was expecting traffic from last hop pool member 1 and received traffic from last hop pool member 2. Would it accept it (since it's a valid last hop pool member) or it would revert back to auto last hop behavior? Thanks! Rafael
HSRP and VRRP Optimization
Problem this snippet solves: This iRule provides a manageable solution for load balancing to any number of any sized HSRP/VRRP groups of routers or firewalls. The problem is simple to understand (explained officially in Solution 9487) in that the individual HSRP/VRRP routers/firewalls in a group transmit packets using the hardware MAC address which is what populates the lasthop entry for those connections. The problem is that during an HSRP router failover all the currently open connections will have the lasthop MAC address set to the hardware MAC address of the failed router and will attempt to send the data related to those flows to that MAC address. This will cause all current connections to timeout and in general diminishes the value of HSRP/VRRP groups. The solution is to populate the lasthop entry for each new connection with the relevant virtual MAC address as opposed to the hardware MAC address. In this case the active router responding to the virtual MAC address will receive the traffic which is the correct solution. Code : ## data-group ## ltm data-group internal RouterA { records { 00:17:0f:2a:10:4a { data "00:00:0C:07:AC:02 test" } 00:17:0f:17:cf:80 { data "00:00:0C:07:AC:04 test" } } type string } ## iRule ## when CLIENT_ACCEPTED { set entry [class lookup [format %s [LINK::lasthop]] RouterA] if { $entry ne "" } { lasthop [lindex $entry 1] [lindex $entry 0] } } Tested this on version: 10.0