Switching, Bridging, and VXLAN

When a switch receives a frame from A to B for the first time, it does not yet know where B is, but it may still allow B to receive it successfully: it learns A's ingress port and floods the unknown-destination frame to other allowed ports. After B replies, the reverse source is also learned. This process explains how the FDB is formed, but it does not explain how loops disappear; loop control and tunnel extension require their own mechanisms.

Understand Learning and Forwarding with Three Frames

Assume ports p1, p2, and p3 all belong to VLAN 10 and allow forwarding. A is on p1, B is on p2, and C is on p3. The initial FDB is empty. The following omits local termination and special address handling:

Dynamic learning requires the port to be in a state that allows learning and passes the corresponding ingress rules; it does not unconditionally update on every frame arrival. The FDB key also includes context such as VLAN, so the same MAC address can have different locations in different VLANs. Switching devices maintain local information obtained from their own observation/control planes and should not be understood as a globally synchronized hash table automatically shared between switches.

If the destination location is the same as the ingress port, standard bridging usually filters this forwarding; Hairpinning can allow return to the same port in specific scenarios. This ingress filtering does not constitute complete loop prevention; frames returning from other links may still be forwarded again.

Flooding and Aging Do Not Mean Dropping One Packet

Unknown unicast is generally replicated to relevant ports within the same VLAN that allow flooding and are in a forwarding state; it is not unconditionally sent to all ports of the entire switch. Broadcast is also restricted by VLAN, isolation, and control policies; multicast may select egress based on MDB members and router ports according to IGMP/MLD snooping, while link-local multicast has special rules.

After dynamic FDB aging, the next frame may become an unknown unicast and be flooded, which usually still reaches the target, and does not naturally drop exactly one packet. If unknown unicast is prohibited by policy, flooding paths are restricted, or the network is congested, further analysis is required. Whether the target quickly resumes learning after receiving depends on whether it sends source frames that can be learned.

Address movement can update the location via source traffic on a new ingress, but continuous back-and-forth movement may also indicate duplicate MACs or a Layer 2 loop. Static, permanent, control-plane managed, or hardware-offloaded entries have different lifecycles and should not all be written as deleted after a fixed 300 seconds.

What can a switch learn from a single frame?

Keep the current FDB separate from the last forwarding result. Send A→B, B→A, then A→B to see how evidence enables directed forwarding. Clearing changes future lookups, not the recorded prior forwarding decision.

Linux Bridge: Software Objects Can Manage Hardware Forwarding

Linux bridge provides Layer 2 bridging; veth, TAP, physical interfaces, or VXLAN devices can all serve as related ports. For the host to participate in IP communication within this Layer 2 network, Layer 3 functionality can be configured via the bridge master device or corresponding VLAN interfaces; adding a port to the bridge does not automatically enable IP routing.

In net/bridge/br_private.h of Linux 7.2, the FDB uses a key containing MAC and VLAN ID, and associates the destination port and update information. The learning and forwarding paths are implemented in br_input.c and br_forward.c.

Linux can also offload FDB and other information to hardware via switchdev, meaning the data plane does not necessarily pass through the CPU frame by frame. Therefore, the claim that "Linux bridge is ten times slower than hardware and can only be used below 10 Gb/s" lacks universal basis; performance should be measured based on packet size, CPU/NUMA, drivers, rules, and offload capabilities. Linux switchdev model

You can first use read-only commands to check the actual state, with the device name as an example:

ip -d link show br0
bridge link show
bridge vlan show
bridge fdb show br br0
bridge mdb show

The ageing_time in the traditional bridge sysfs uses clock_t/USER_HZ representation, so you cannot directly call echo 60 60 seconds. Local br_sysfs_br.c and br_stp.c have clear conversions; when common USER_HZ=100, one minute corresponds to 6000; it is safer to confirm the input units according to the documentation of the tools used. Linux bridge interface documentation

Do Not Mix Expectations Between Bridging Filtering and Layer 3 Filtering

br_netfilter can allow some bridged traffic to enter the corresponding Layer 3 netfilter path, historically often used for iptables rules; this does not mean that pure Layer 2 forwarding naturally passes through all ip/inet rules. nftables' bridge family can directly handle the bridging layer without needing to load br_netfilter universally for it. nftables bridge filtering

During troubleshooting, you need to know whether the packet is forwarded on the bridge, sent to the local host, or enters routing, to determine the corresponding hook, rule counters, and offload paths. Hairpinning, port isolation, and VLAN filtering are different settings and cannot be replaced by a single firewall switch for all forwarding policies.

STP: Constraining Layer 2 Forwarding Without TTL Using Spanning Tree

Standard Ethernet frames do not have a hop-by-hop decrementing field like IP TTL. When redundant links form a loop, broadcast/unknown unicast replication may loop continuously, while also causing source MAC address flapping between ports. STP preserves physical redundancy and selects a loop-free forwarding topology through port roles and states; it does not rely on identifying a specific duplicate frame to automatically deduplicate.

First, select the root according to rules such as Bridge ID; non-root bridges compare the path cost to the root and subsequent tie-breaking fields to select the Root Port; each segment then selects a Designated Port. In the figure, all link costs are 10, and the direct cost to the root for both B and C is 10, while going through the other would be 20; on the B—C segment, both sides have the same root cost. Assuming B's ID is smaller, B wins the designated role, and the C side becomes a standby / non-forwarding path.

BPDUs are protocol control packets. Classic STP uses the corresponding 802.3 length/LLC encapsulation, with common DSAP/SSAP being 0x42, so you cannot write the appearing 0x0026 length as EtherType. The formats/types of STP configuration BPDUs, topology change BPDUs, and RSTP BPDUs are also not exactly the same.

RSTP accelerates secure forwarding transitions through roles, edge ports, and Proposal/Agreement on point-to-point links where applicable; it does not guarantee 1–3 seconds for all failures. Traditional STP wait timers are also affected by topology, configuration, and failure detection, so you cannot treat the convergence time of a specific default scenario as a fixed performance metric. Cisco: RSTP Mechanism

BPDU filtering, edge port settings, and protection functions should be designed according to access roles; incorrectly hiding BPDUs may preserve real loops. Whether Linux bridge enables STP or whether user-space daemons implement the required fast/multi-instance protocols should be checked; you cannot infer that loop prevention is enabled just because the interface name is bridge.

VXLAN: Solve Outer Reachability First, Then Establish Inner Adjacency

VXLAN carries inner Ethernet frames over UDP, and VTEPs are the encapsulation/decapsulation endpoints. The basic header is 8 B, the VNI occupies 24 bits, and the I flag indicates that the VNI is valid; the standard UDP destination port is 4789, and deployment still requires explicit configuration of compatible values. The VNI provides a numbering space of about 16.77 million, which does not mean hardware can guarantee accommodating the same number of active tenants.

On the A side, the local bridge first determines that the destination MAC should go through the VXLAN port, the VXLAN forwarding information then locates the remote VTEP, the outer IP routing determines the physical egress, and finally outer neighbor resolution obtains the current link next-hop MAC. The outer next-hop may be an intermediate router and does not need to be the physical MAC of the remote VTEP. After the peer strips the outer layer, it processes the inner frame based on the VNI and local forwarding configuration. RFC 7348: VXLAN

The UDP source port can carry flow hash information to help Underlay ECMP disperse different inner flows; this does not automatically provide NAT traversal negotiation. Firewalls, return paths, MTU, and allowed VTEPs all require corresponding configuration. VXLAN itself does not provide tenant content encryption or peer authentication.

MTU Settlement Using Outer IP Length

In the example without inner VLAN and IPv4 options, the inner L3 is 1500 B, plus inner Ethernet 14 B, VXLAN 8 B, UDP 8 B, and outer IPv4 20 B, totaling 1550 B outer IP packet. Inner FCS is usually not encapsulated, and outer Ethernet is outside the IP MTU. If the Underlay IP MTU is only 1500, under the same assumptions, the inner L3 can use 1450 B; for outer IPv6 basic header of 40 B, it is 1430 B.

Additional tags, extension headers, or encrypted tunnels continue to consume the budget. You cannot infer that all paths and peers are consistent just by setting the physical port MTU larger; fragmentation, dropping, and error feedback are also subject to specific protocol and implementation limitations. When small pings work but large loads fail, you must separately confirm inner and outer lengths and path behaviors.

BUM Replication and EVPN: Control Plane Reduces Unknown Information

Broadcast, unknown unicast, and multicast are often collectively referred to as BUM, but their forwarding strategies do not need to be exactly the same. VXLAN can use corresponding Underlay multicast or ingress replication schemes, where the replication targets are the relevant remote members of that VNI, not all deployed VTEPs. If one ingress needs to replicate 1 MiB of inner data to each of three remote destinations, the replicated inner data volume alone is 3 MiB, not counting outer overhead.

EVPN can distribute MAC/IP and related reachability information via BGP, providing a more explicit control plane than pure data-plane learning; it is not the same concept as switching implementations like Open vSwitch. ARP/ND suppression uses trusted and valid bindings to answer some resolution requests locally, but it cannot eliminate all broadcasts, nor can it arbitrarily give old answers after bindings expire. RFC 8365: EVPN Overlay

MAC movement, VTEP failure, replication member changes, and underlying routing convergence still need to be handled. Overlay allows Layer 2 boundaries to extend across Layer 3 networks, but it may also extend the scope of fault impact, so "tunnels extending further" cannot be directly equated with stronger isolation.

Local Forwarding and Encapsulation Model

The following only simulates the basic logic of the same VLAN, all ports allowing learning/forwarding, standard unicast, and no Hairpinning; it does not simulate real bridge concurrency, aging, or control packets.

ports = {10: {'p1','p2','p3'}, 20: {'p1','p4'}}
fdb = {}
def forward(vid, ingress, source, dest):
    assert ingress in ports[vid]
    fdb[(vid, source)] = ingress
    out = fdb.get((vid, dest))
    if out is None:
        return ports[vid] - {ingress}
    return {out} if out != ingress else set()
assert forward(10,'p1','A','B') == {'p2','p3'}
assert forward(10,'p2','B','A') == {'p1'}
assert forward(10,'p1','A','B') == {'p2'}
assert forward(20,'p4','B','A') == {'p1'}
assert fdb[(10,'B')] == 'p2' and fdb[(20,'B')] == 'p4'
assert forward(10,'p1','D','A') == set()
vni = 100
header = bytes([0x08,0,0,0]) + vni.to_bytes(3,'big') + bytes(1)
assert len(header) == 8 and header.hex() == '0800000000006400'
assert 20+8+8+14+1500 == 1550
assert 1500-(20+8+8+14) == 1450
assert 1500-(40+8+8+14) == 1430
print('Learning/flooding/same-port filtering, VLAN independent keys, VXLAN encoding, and MTU calculation passed')

Local checks do not create bridges, establish VXLAN tunnels, or inject Layer 2 frames into the production network.

Continue Reading

• Ethernet and MAC: Frames, VLAN, flow control, and aggregation.
• ARP and NDP: Neighbor resolution and reachability.
• Routing and BGP: Underlying paths and control plane.