Municipal operators see DF-bit related drops and fragmentation symptoms for VXLAN-encapsulated traffic. What is the preferred data-plane approach?
Select an answer to reveal the explanation.
Short Explanation
Fragmenting tunnel packets across the underlay is like shipping a sofa in unmarked pieces through three different couriers—things go missing. Prefer correct MTU so VXLAN stays whole end to end. Don’t build the city fabric on reassembly luck.
Full Explanation
When municipal operators see DF-bit related drops and fragmentation symptoms for VXLAN-encapsulated traffic, the preferred data-plane approach is to size the path so VXLAN packets avoid underlay fragmentation rather than depending on fragmented overlay transport. Fragmentation of encapsulated traffic is fragile and often interacts poorly with Don’t Fragment behavior and middleboxes on county paths.
Forcing underlay routers to fragment every VXLAN packet and reassemble on each spine is not best practice. Disabling path MTU discovery city-wide and raising inner TTL instead does not fix outer-packet sizing. Clearing the DF bit on tenant HTTP only while ignoring UDP 4789 sizing leaves the actual encapsulated path unprotected.
Exam caveat: provision MTU so outer packets traverse intact from ingress VTEP to egress VTEP; treat DF/fragmentation symptoms as MTU engineering first.
Operational check: ensure fabric jumbo MTU end-to-end for VTEP pairs, reproduce the DF/fragmentation symptom with large frames, remediate MTU, and confirm VXLAN flows no longer fragment or drop under the same test size. Coordinate with firewall teams so middleboxes do not clamp or drop large UDP/4789 packets unexpectedly.