Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 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
Fixed In:
15.0.0, 14.1.2.7, 14.0.1.1, 13.1.3, 12.1.4.1
Opened: Oct 15, 2018 Severity: 3-Major
In a situation when a routing entity belonging to the child route domain is searching for an egress point for a traffic flow, it's searching for a routing entry in the child domain first, then if nothing is found, it searches for it in the parent route domain and returns the best found routing entry. If the best routing entry from the parent route domain is selected, then it is held by a routing entity and is used to forward a traffic flow. Later, a new route entry is added to the child route domain's routing table and this route entry might be better than the current, previously selected, routing entry. But the previously selected entry doesn't get invalidated, thus the routing entity that is holding this entry is forwarding traffic to a less-preferable egress point. #Example: RD0(parent) -> RD1(child) routing table: default gw for RD0 is 0.0.0.0/0%0 pool member is 1.1.1.1/32%1 - Pool member searches for the best egress point and finds nothing in the routing table for route domain 1, and then later finds a routing entry, but from the parent route domain - 0.0.0.0/0%0. Later a new gw for RD1 was added - 0.0.0.0/0%1, it's preferable for the 1.1.1.1/32%1 pool member. 0.0.0.0/0%0 should be (but is not) invalidated to force the pool member to search for a new routing entry and find a better one if it exists, as in this case, with - 0.0.0.0/0%1.
If a new added route is preferable to an existing one in a different route domain, the new, preferable, route is not going to be used by a routing object that has previously selected a route. Thus, traffic flows through these routing objects to an unexpected/incorrect egress point. This might result in undesirable behavior: -- The route might be unreachable, and all traffic for a specific pool member is dropped. -- The virtual server cannot find an available SNAT address. -- Simply, the wrong egress interface is being used.
1. There is more than one route domain in the parent-child relationship. 2. There are routing entries for the parent route-domain good enough to be selected as an egress point for the routing object (for instance, pool member) which is from child route domain. 3. The routing entry from a parent route domain is selected as an egress point for the object from the child route domain. 4. New routing entry for child route domain is added.
Use either of these workaround after a new route in child domain is added. -- Recreate a route. Recreate a parent route domain's routes. Restart tmrouted daemon if routes are gathered via routing protocols. -- Recreate a routing object. - If a pool member is affected, recreate the pool member. - If a SNAT pool list is affected, recreate it. - And so on.
Routing objects are now forced to reselect a routing entry after a new route is added to the child route domain's routing table.