Dropping SOME connections if health check fails.

yes, you could do something like:

when CLIENT_ACCEPTED {
  if { [LB::status pool $poolname member $ip $port] eq "down" } {
    if { [IP::addr [IP::client_addr] equals machine_A_IP] }
      discard
    }
  }
}

Uh, some of my post got truncated, I edited for clarity

Thanks! I'll give it a try.

Sounds like a gratuitous arp problem (misconfiguration maybe) between the Nokia and the BigIP, a packet trace will confirm. As a workaround, I'd recommend configuring the Nokia to use a virtual mac for the vrrp address so that auto-lasthop doesn't need to be updated.

The Nokia is configured to use VMAC VRRP adress. But this adress is only used for routing through the Nokia. The Nokia, when it sends a packet out, is using ALWAYS is interface MAC address. The gratuitous ARP is send for the Virtuall IP adress, for which the VMAC is used.

 

The tcpdump confirms that the BigIP is sending packet THROUGH the nokia, using the nexthop VMAC. It is receiving packets via the interface MAC of the Nokia (Normal comportment in VRRP Active/standby). The VMAC is only seen when you send ARP request to the Virtual IP to route trafic through it.

 

 

Hi,

 

 

Can you try and repost your entry?

Gotcha, sorry about that. Configure a lasthop pool, attach a monitor, and apply it to your default virtual server. A lasthop pool applied to a virtual will override auto-lasthop:

pool gateway-pool {
   action on svcdown reselect
   min active members 1
   monitor all gateway_icmp
   members
      172.16.31.1:any
      172.16.31.2:any
         priority 2
}
virtual gateway-vip {
   ip forward
   lasthop pool gateway-pool
   destination any:any
   mask none
   vlans private enable
}

Have tried this option yet.

 

It seems the "last hop pool" is able to change the MAC adresse of incoming trafic ONLY when autolasthop is disabled (global parameter).

 

 

This configuration is using the "autolashtop" capability a lot, because a lot of nokia VRRP FW clusters are connected to this LTM, and are connected to Internet aswell.

 

 

So, autolasthop is "mandatory" in this case.

 

Then either the behavior is wrong (ie..bug), or the documentation is wrong. In the configuration guide, it specifically states that applying a lasthop pool to a virtual server will override the auto-lasthop behavior (for that virtual server)

It will override autolasthop behavior, but only for traffic coming from the lasthop pool.

 

 

Also, if you use a lasthop pool, you need to ensure you have health monitors for the lasthop pool members. That's the only way for the LTM to know to send responses to the "other" member.