Bug ID 540571: TMM cores when multicast address is set as destination IP via iRules and LSN is configured

Last Modified: Nov 07, 2022

Affected Product(s):
BIG-IP CGN(all modules)

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 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 network.


There are two workarounds: -- Remove the offending iRule that is sending traffic to the network. -- Prevent traffic from using that destination in the iRule.

Fix Information

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.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips