Last Modified: Apr 17, 2024
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2
Opened: Jun 17, 2021 Severity: 3-Major
If a static route is added via "tmsh create net route" (or equivalent configuration ingestion system), and this route's destination matches the management port's subnet, the protection that prevents the new route from being propagated to the Linux kernel will initially work, but will fail after mcpd is restarted or the system is rebooted.
The directly-connected route for the management port's subnet appearing in the Linux host's routing table is replaced, or complemented, by a new and unnecessary route. In either case, management port traffic can fail or be misrouted via a TMM interface.
- A static route whose destination matches the management port's subnet is added to the system. - The system is rebooted or mcpd is restarted.
Align your network and the BIG-IP system so that TMM does not need access to the management port's subnet (thus negating the need to create a route to that destination in the first place). If this is not possible, you can temporarily resolve the issue by using the `route` or `ip` utility on the Linux host subsystem to manually fix the routing table. However, the issue will occur again the next time mcpd or the system restarts.
None