Last Modified: Nov 07, 2022
Affected Product(s):
BIG-IP CGN
Known Affected Versions:
11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 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
Fixed In:
11.6.1, 11.5.4 HF2, 11.4.1 HF10
Opened: Aug 18, 2015 Severity: 2-Critical Related Article:
K05340225
TMM may core when an iRule changes the destination address of a connection to use a multicast address such as 224.0.0.1. When the BIG-IP system looks up the route, it returns an internal route with no interface designed for use with multicast traffic. LSN expects to find an interface and crashes when it attempts to use the non-existent interface.
Traffic disrupted while tmm restarts.
- CGNAT enabled and LSN pools configured on active virtual server that accepts traffic. - On the same virtual server, an iRule is configured that changes the destination IP to a multicast address in the 224.0.0.0/24 network.
There are two workarounds: -- Remove the offending iRule that is sending traffic to the 224.0.0.0/24 network. -- Prevent traffic from using that destination in the iRule.
TMM no longer cores when multicast address is set as destination IP via iRules and LSN is configured. Now, the system fails connections when the route's IFC is null, which is correct behavior.
