Bug ID 1572545: Upgrade from version 14.X to version 15.X may encounter problems with L2 forwarding for some of the flows.

Last Modified: Oct 04, 2024

Affected Product(s):
BIG-IP Install/Upgrade, LTM(all modules)

Known Affected Versions:
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, 15.1.10.5, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4

Opened: Mar 27, 2024

Severity: 3-Major

Symptoms

L2 forwarding issues may be encountered for some flows. Due to this, there can be hinderances in the traffic flow towards server.

Impact

Traffic drop is observed when packets are sent towards server.

Conditions

Flow 1: Client(L3 Net1)--- (vg2)--> BIG-IP --(vg1)--> Gateway --(vg1)--> BIG-IP (again) --(vg2)--> server(L3 Net2) 1. Client and server are in same vlan but not in same subnet. 2. Gateway is in another vlan, it is the gateway for both client and server. 3. connection.vlankeyed is disabled. 4. After an upgrade from 14.X to 15.X, traffic returning from gateway towards the server is dropped Flow 2: Client --(VG1)--> BIG-IP --(nonVgVlan1)--> IPS --(nonVgVlan2)--> BIG-IP (again) --(VG2)--> Server 1. Client traffic over transparent vlan-group towards Server is intercepted by a standard virtual server and sent to IPS on a non-vlan-group vlan. 2. connection.vgl2transparent is enabled 3. When traffic is sent from BIG-IP to IPS, the destination MAC will be the MAC address of a server (ARL non local) and the source MAC is still the original client MAC which is breaking the returning traffic from IPS. 4. The expectation here is traffic leaving from BIG-IP to IPS should have BIG-IP nonVgVlan1 MAC address as source MAC.

Workaround

For this workaround, ensure "nw_l2_transparent license enabled". 1. For Flow 1, keep connection.vgl2transparent disabled and add the following config: ltm virtual VG_transparent { destination <SERVER> ip-protocol tcp l2-forward mask 255.255.255.255 profiles { fastL4 { } } rules { t-nexthop } source 0.0.0.0/0 translate-address enabled translate-port enabled vlans { vg2 } vlans-enabled } ltm rule t-nexthop { when CLIENT_ACCEPTED { nexthop vg1 transparent } when SERVER_CONNECTED { nexthop vg2 transparent } } 2. For Flow 2, keep connection.vgl2transparent disabled.

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips