Bug ID 976853: SNAT pool traffic-group setting may override non-floating self IP's traffic-group

Last Modified: Jan 20, 2023

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

Known Affected Versions:
14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 14.1.4,,,,,,, 14.1.5,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 15.1.3,, 15.1.4,, 15.1.5,, 15.1.6,, 15.1.7, 15.1.8,, 16.0.0,, 16.0.1,,

Opened: Dec 27, 2020
Severity: 3-Major


A non-floating self IP fails to respond to ARP on the standby system.


A standby device does not respond to ARP requests for floating IP addresses. If a SNAT is configured on the same IP as a non-floating self-ip on the standby, ARP responses will be disabled for that self-ip. Even after deleting the snat, or configuring it for another IP, ARP response for that self-ip will remain disabled. The effect of this will be that other IP devices will be unable to communicate with the self-ip after the ARP entry times out. For example: -- BIG-IP does not respond to ARP requests for the non-floating self-ip -- ConfigSync no longer working (if the affected self IP is the ConfigSync address) -- Health check traffic fails Note that simply deleting the SNAT translation will not restore service to the self-ip.


An LTM SNAT translation address has been created which matches a non-floating self IP on the system, and the SNAT is configured in a floating traffic group.


Delete the SNAT address, and then move the self-ip back to the non-floating traffic group, and disable and re-enable the arp setting. tmsh create ltm virtual-address <self-ip> arp enabled traffic-group traffic-group-local-only tmsh modify ltm virtual-address <self-ip> arp disabled tmsh delete ltm virtual-address <self-ip> Alternatively, after deleting SNAT translation, reboot the device (or restart tmm). When using this approach on multi-blade chassis devices, all blades need to be restarted.

Fix Information


Behavior Change