The controller shows a site-to-site link gray, with no throughput or performance data between two sites, and the device itself shows no EVPN connection at all. This is the layered checklist that finds the fault fastest — TNP, then DTLS, then the SD-WAN route — with the exact display commands for each layer, plus what to check once a connection has actually formed but its state still won't reach UP.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A gray link on the controller just means two sites aren't exchanging data yet — it doesn't tell you which of several completely different underlay problems is actually causing it.
An EVPN connection between two SD-WAN sites depends on two things existing before it can form at all: the two sites have to have learned each other's TNP (Tunnel Network Point), which itself depends on DTLS being established between the CPE and the RR, and the two sites have to have learned a route to each other — specifically an SD-WAN route, not just any reachable path. Checking these in order — TNP, then DTLS, then the route — finds the actual broken layer far faster than jumping straight to a packet capture.
What follows is the diagnostic order this is built on, drawn from the Huawei AR router's own SD-WAN/EVPN fault-classification model, the checks and commands for each layer, what to look at once a connection has actually formed but its state still isn't UP, and a set of FAQ answers pulled from the same maintenance material. For the IPSec/GRE tunnel logic underneath a more conventional branch VPN instead of SD-WAN, see IPSec VPN Tunnel Won't Come Up? and VPN Tunnel Up but Ping Fails.
SD-WAN link failures split into two shapes on the controller: no EVPN connection exists between two sites at all, or a connection exists but its state won't reach UP.
Placing the symptom on this tree first tells you whether you're troubleshooting TNP/DTLS/routing, or a narrower NAT-hole-punching or Keepalive problem on a connection that already exists.
Diagram labels are kept in English for engineering clarity.
The left branch is what to work through when the connection doesn't exist at all — layer by layer, TNP first. The right branch is a narrower question about a connection that already formed but can't finish coming up, and it usually points at the NAT path or the Keepalive, not TNP or the route.
Five layers, each with its own display command — the fault tree above tells you which one to start at.
If TNP isn't UP, DTLS never even gets triggered on that link — start here before anything else.
<Huawei> display site-tnp 29 verbose
// V300 -- confirms whether the TNP's underlying interface protocol is Up;
// with NAT traversal off, TNP state depends only on interface protocol state
<Huawei> display evpn site-tnp 29 verbose
// V600 equivalent
<Huawei> tracert -p 3478
// checks whether the path blocks the NAT probe portCPE-to-RR TNP is learned over DTLS, so if TNP won't come up and NAT traversal isn't the issue, DTLS is the next layer to check.
<Huawei> display dtls peer-connection status
// V300 -- CLOSE = established; INIT / REGISTERING = not established
<Huawei> display dtls client connection
// V600 equivalent
<Huawei> tracert -p 55100
// DTLS uses port 55100 -- check whether a firewall in the path is blocking itEVPN needs two things to form: the destination site's TNP, and a route to that site that's specifically an SD-WAN route — not just any reachable path.
<Huawei> display smart-policy-route spr-index-table all
// V300 only -- confirms whether an SD-WAN route to the destination site exists
<Huawei> display saved-configuration
// Tunnel / BGP entries present here after a reboot = save was executed on an
// SD-WAN device that should never have allowed it (R19C00) -- factory-reset and re-onboardTNP, DTLS and the route all check out, but the connection still doesn't form — this is what's left.
<Huawei> display evpn connection verbose
// current connection count vs. spec -- Full-Mesh + a low-end model can exceed it
<Huawei> display site-tnp 29 verbose
// Current Conn Ref Count = 0 -> this end has no business route from the peer site
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 received-routes
<Huawei> display bgp evpn all routing-table peer 10.0.0.2 advertised-routes
// received-routes on the branch/RR, advertised-routes on the RR -- confirms
// whether the business route was actually reflected onwardA narrower question: display evpn connection now shows something, but its state won't reach UP.
<Huawei> display connection 12345
// V300 -- ConnStatus: Invalid / Init / NatParse / CheckConn / Pending / Active
// stuck at NatParse specifically = NAT hole punching failed
<Huawei> display evpn connection 12345 verbose
// V600 equivalent; SourcePublicPort / DestPublicPort -- compare both ends
// for an asymmetric NAT translating the two directions inconsistently
<Huawei> display fe slot 0 fe-id 0 table connect-encap 12345
// SEND_KA_CNT / RECV_KA_COUNT -- send-without-receive on one side points at
// the network in between, not the CPEOnce the layers above have told you where the problem sits, these six account for most of what's actually wrong.
SYMPTOMTNP state won't reach UP on a specific link, even though the interface itself is Up.
CAUSEWith NAT traversal off, TNP state tracks only the interface's own protocol state — so turning NAT traversal on for a link that doesn't actually have NAT triggers a probe with no reason to succeed cleanly, and leaving it off for a link that does have NAT skips a probe the link actually needs. Either mismatch blocks TNP from confirming UP.
FIXMatch the NAT traversal setting to what's actually on the WAN path, per link, on the controller's WAN link view — not one blanket setting applied to every site.
SYMPTOMTwo RR sites, neither behind NAT, still can't get their EVPN connection to UP.
CAUSEThis is a documented real case — both RR sites had Public addresses manually configured, and the values were swapped: RR1's Public address was set to RR2's interface address, and RR2's was set to RR1's. The address looked plausible on each device individually, which is exactly why a config review didn't catch it.
FIXConfirm neither RR site actually needs a manually configured Public address at all (no NAT in the path usually means it shouldn't be set); if one is required, verify it against the peer's actual interface address rather than assuming it was copied correctly.
SYMPTOMIn a Full-Mesh SD-WAN network, one site — usually the lower-end model — can reach some sites but not others, with no obvious per-link fault.
CAUSEFull-Mesh means every site tries to build an EVPN connection to every other site in the network; a device model carries a hard connection-count spec, and a low-end CPE in a large Full-Mesh deployment can simply run out of room before every site is connected.
FIXCheck display evpn connection verbose against the model's rated connection count; if the site count has grown past what the deployed hardware supports, resize the site's model or route that site through an RR/Hub instead of expecting full mesh.
SYMPTOMTwo branch sites' connection state machine sits at NatParse indefinitely; the underlay is reachable and port 4500 is open.
CAUSETwo specific NAT combinations don't hole-punch successfully no matter how else the network is configured: one end behind Port Restricted Cone NAT with the other behind Symmetric NAT, or both ends behind Symmetric NAT.
FIXThis isn't a configuration fix, it's a network-design constraint. Confirm the NAT type on each site's edge device, and where the combination is unsupported, route that pair's traffic through an RR/Hub instead of expecting a direct site-to-site connection.
SYMPTOMEVPN connection state cycles Up/Down repeatedly with nothing obviously wrong on the underlay, bandwidth, CPU or link duplex.
CAUSEA documented real case: one side's TNP still references a peer TNP the other side has already replaced — the far end shows two of its own TNPs connected to the near end's single TNP, while the near end only shows that one TNP connected back. The stale reference keeps triggering renegotiation.
FIXreset connection site-tnp on V300, or reset evpn site-tnp on V600, clears the residue and lets both ends re-learn a consistent TNP relationship.
SYMPTOMIn a dual-gateway deployment, the two CPEs disagree about link state — one shows its local link Up while the peer shows the corresponding extended link Down, or the reverse.
CAUSEThe Interlink between the two dual-gateway CPEs is meant to synchronize link state between them; if display ms-channel shows Connected on one CPE and Disconnected on the other for the same Interlink, the link is running one-way — synchronization messages are only getting through in one direction.
FIXConfirm the mismatch with display ms-channel on both CPEs, then check heartbeat counters with two display ms-channel-static calls five seconds apart — TX increasing but RX not (or the reverse) narrows it to a physical connection or cabling problem on the Interlink itself, not the SD-WAN configuration.
Pulled straight from the field — the ones worth having an answer ready for.
Check TNP state first (display site-tnp / display evpn site-tnp verbose) — if it's not UP, nothing past this point matters yet. If TNP is UP, check DTLS next (CLOSE means established). If DTLS is fine, check for a route to the destination site specifically as an SD-WAN route (display smart-policy-route spr-index-table all on V300). Only once all three check out does it make sense to look at connection count, NAT/address misconfiguration, or a one-sided link.
Yes — a connection existing at all means TNP and the SD-WAN route are already fine on both sides. What's left is underlay reachability, whether both sides actually built the connection (compare display evpn connection site-id on each end), NAT hole punching (ConnStatus stuck at NatParse), or a Keepalive that isn't making it through in one direction.
NatParse is the hole-punching stage of the connection state machine (Invalid → Init → NatParse → CheckConn → Pending → Active); getting stuck there points at underlay reachability, port 4500 being blocked somewhere in the path, a NAT device translating the two directions inconsistently (compare SourcePublicPort on one end against DestPublicPort on the other), or a fundamentally unsupported NAT-type combination between the two ends.
Underlay packet loss, a dual-gateway Interlink port that's Down, a WAN interface stuck in half-duplex, traffic exceeding the link's bandwidth, CPU overload on the device (check display cpu-usage for a core at 100%), link-latency jitter tripping an aggressively tuned fault-detection timer, or TNP residue where one side references a peer TNP the other side no longer has.
Compare Current Conn Ref Count in display site-tnp {site-id} verbose on both ends first; 0 means this end has no business route from the peer at all. Then check display bgp evpn all routing-table peer ip received-routes on the branch and the RR, and advertised-routes on the RR, to find whether the business route was received and actually reflected onward — a receive-side route-policy whitelist that doesn't cover the peer's real subnet is the most common silent cause.
Not necessarily. A TNP that's Down on one CPE never gets synchronized to its dual-gateway peer, so a count difference caused specifically by a Down TNP not being reflected across is normal and expected. It only becomes a real fault if every TNP involved shows Up on both CPEs and the counts still disagree — at that point, cycling the physical interface (shutdown / undo shutdown) is the next step, and if that doesn't resolve it, escalate with logs from both CPEs' display ms-channel-static and a debugging connection all capture.
This note is built around the Huawei AR/NetEngine AR-series SD-WAN EVPN fault-classification model — the TNP/DTLS/route layering and the display site-tnp / display evpn connection / display dtls / display ms-channel commands, plus the field cases behind them, drawn from the same maintenance documentation covering SD-WAN scenarios specifically. Command names differ slightly between the V300 and V600 command sets; both are given side by side above wherever they diverge. It doesn't cover controller-side configuration screens in full, application-recognition or path-selection failures, or the packet-loss-specific diagnostics that live in a separate chapter of the same source material.
Tell us which layer it's stuck at — TNP, DTLS, or the SD-WAN route — plus the display site-tnp / display evpn connection output, and we'll help you read it.