Last Modified: Jun 30, 2021
See more info
Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 11.6.4, 11.6.5, 126.96.36.199, 188.8.131.52, 184.108.40.206, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
Opened: Sep 08, 2015
Related AskF5 Article: K31269311
The BIG-IP system's management port drops egress Ethernet multicast traffic. You may experience this issue if you employ certain routing techniques in the network segment the management port connects to. For example, you may experience this issue if the BIG-IP system's default gateway on the management network is a pair of Check Point Secure Gateways configured in Load Sharing Multicast Mode. In this case, the IP address of the default gateway resolves to a L2 multicast address and, because of this issue, the BIG-IP system's management port ends up dropping traffic destined the default gateway.
As a result of this issue, certain destinations or certain services will not be reachable via the BIG-IP system's management port.
No special conditions are required to trigger this issue. However, only customers with unusual routing configurations are likely to actually notice this issue.
The Linux host configures a single-interface bridge over the management port to make certain tasks simpler. This issue has been shown to go away when multicast snooping is disabled for said bridge. You can disable multicast snooping for the management bridge by running the following command: # echo 0 > /sys/class/net/mgmt/bridge/multicast_snooping On a VIPRION chassis, the aforementioned command would have to be run on each blade. The command is not permanent and the change is lost after a reboot of the system. To make the change permanent, you can add the command to the /config/startup file.