Bug ID 512485: Forwarding of flooded VXLAN-encapsulated unicast frames may introduce additional forwarding

Last Modified: Sep 13, 2023

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

Known Affected Versions:
11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 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.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2

Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3

Opened: Mar 16, 2015

Severity: 3-Major

Related Article: K17105

Symptoms

In VXLAN overlays, unicast frames are flooded (via multicast or unicast replication) when the destination MAC address is known and the remote endpoint is unknown. Upon receiving a flooded unicast frame, the BIG-IP system might forward the frame again to yet another endpoint. Eventually an additional L2 hop might be introduced between the sender and the receiver. This applies to both the multicast and the multipoint (unicast replication) configurations of VXLAN.

Impact

The introduction of an additional hop adds unnecessary latency.

Conditions

This affects deployments with three or more VXLAN endpoints.

Workaround

None

Fix Information

In this release, the system does no L2 forwarding of encapsulated frames received from one endpoint and destined to another within the same overlay (VXLAN VNI/Tunnel), so no extra hop is added.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips