Some IP addresses unreachable through L2VPN tunnel
book
Article ID: 345922
calendar_today
Updated On:
Products
VMware NSX
Issue/Introduction
There are some L2VPN architectures which will drop network traffic that originates inside of the edge containing the L2VPN tunnel endpoint. This document describes the symptoms, explains why this occurs and what can be done to resolve the issue.
Symptoms:
An NSX-T overlay segment has been stretched using L2VPN and some L2 VPN traffic is getting dropped when crossing the tunnel. Some VMs on the NSX-T overlay are reachable from the remote side of the L2VPN, but VDR port is not reachable from the remote side of the L2VPN.
Environment
VMware NSX-T Data Center
Cause
In NSX-T versions prior to 3.2.1, the edge allocates enough egress packet buffer to account for the GRE header and IPsec header, but not for GENEVE header when packet source is the edge itself (i.e. DR interface).
When packets sourced from a remote transport node ingress on the edge via GENEVE encapsulation, the egress packet buffer accounts for the GENEVE header appropriately (i.e. ingress packet buffer influences egress packet buffer size). The problem occurs when the packets egress from the edge with GENEVE encapsulation and are sourced from a DR interface inside the same edge as the L2VPN tunnel endpoint. In this scenario, IP traffic sourced inside the edge requires GRE encapsulation, IPsec encapsulation and GENEVE encapsulation. The egress packet buffer does not allocate enough buffer for all of the headers, thus the edge drops the packet on egress. Specifically, the GENEVE header space is not accounted for.
Resolution
Upgrade to NSX-T 3.2.1.
Workaround: Change GENEVE based uplink to VLAN based uplink. (i.e. move L2VPN from T1GW to T0GW).
Additional Information
Impact/Risks: Some IP addresses are not reachable across the L2VPN stretched network. Specifically, NSX-T VDR port will generally see the most packet loss when communicating with IP addresses on the remote side of the tunnel.