Last Modified: Nov 07, 2022
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
11.6.1, 11.5.4 HF2, 11.4.1 HF10
Opened: Aug 18, 2015 Severity: 2-Critical Related Article:
Related Article: K05340225
TMM may core when an iRule changes the destination address of a connection to use a multicast address such as 18.104.22.168. 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 22.214.171.124/24 network.
There are two workarounds: -- Remove the offending iRule that is sending traffic to the 126.96.36.199/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.