NSX Tier-0 BGP Neighbour Down: Read the Session State Before Resetting Anything

An NSX 4.2 Tier-0 gateway peers with an external router over BGP. An alarm says a BGP neighbour is down, the Tier-0 BGP neighbour list shows a status other than up, or routes from the physical network have gone. The usual reflex is to clear the BGP session or bounce the uplink. A reset replaces the state that tells you which side failed, and it can drop routes that are still working on other neighbours.

This guide shows how to record one neighbour's session on each Edge node, read what the state means, and match it to Broadcom's documented causes. The result is a dated finding for the NSX, network and peer-router owners.

This guide is based on source research only. Nothing in it was run. Edge names, addresses and AS numbers below are fictional.

Scope

This guide applies to:

• NSX 4.2.x;
• one Tier-0 gateway in its default VRF;
• IPv4 BGP to an external router on the same VLAN uplink (one hop).

Out of scope: Tier-0 VRF gateways, EVPN, BGP over IPsec VPN (Broadcom has separate KBs for its Idle and Connect cases), Federation, IPv6 sessions and multi-hop peering. Whether the right subnets are advertised once the session is up is covered in NSX Tier-1 Segment Has No Upstream Route, which excludes BGP itself.

What Broadcom documents

Two things follow for diagnosis:

• The state of each session is readable without changing anything. get bgp neighbor summary and get bgp neighbor are display commands; clear bgp resets sessions.
• With no source address selected, one neighbour means one session per Tier-0 SR. Configure BGP says the gateway then sets up a peering session on each Tier-0 SR, and the session on an SR without an interface in the neighbour's subnet stays down. Which Edge nodes host the SR, and whether each SR was meant to have that interface, has to be recorded, not assumed.

Before you start

• Read access to NSX Manager: Networking > Tier-0 Gateways > the gateway > BGP > BGP Neighbors (status per neighbour), and the alarm with its Edge node and time.
• Edge CLI read access on every Edge node in the Tier-0's Edge cluster, or output provided by the NSX owner.
• The Edge logs for the period: /var/log/frr/frr.log, /var/log/syslog, and the bgp-flap files on 4.2.x (KB 439484). An Edge support bundle holds the same files.
• The neighbour's configuration in NSX: address, remote AS, source addresses, BFD, timers, admin state (KB 369185 shows the API read).
• The peer router owner's view: their BGP state and last error for the NSX address, their timers and BFD settings, and their logs for the same time.
• The change record for the Edge, uplink segment, VLAN, ToR and peer router.

Do not run clear bgp, the debug rescan workaround, an Edge maintenance mode change, a firewall change or a peer reset while you collect this. Each one replaces the evidence, and some withdraw routes on sessions that still work.

Step 1: record each session

For the Tier-0, record the gateway name, NSX version and build, Edge cluster, HA mode (active-standby or active-active), the observation time with time zone, and the owner's design record of which SRs should have an uplink in the neighbour's subnet, or a note that no design record exists.

Then, on each Edge node in the Edge cluster, first check whether it hosts this Tier-0's service router. The Verify BGP page runs get logical-routers and finds the entry of type SERVICE_ROUTER_TIER0 and its VRF number. An Edge with no such entry for this Tier-0 is marked not applicable for fields B to F. On each Edge that hosts it, enter the SR context with vrf <number> before reading fields C, D and F, as that page shows.

Then once for the neighbour:

A ping from inside the SR VRF is an active test, not part of this record. If the owner runs it, record source, target and result separately. A failed ping can mean a VLAN mismatch (KB 339392); a successful one does not clear a TCP 179 block, and ICMP may be filtered.

Step 2: match the record

Check every row and record each that applies, per Edge node. A row whose evidence is missing is a candidate; a row you could not check is "not checked".

Authentication and timers need both ends. Record whether authentication is enabled and its method, and whether the owners confirm the passwords match; never copy a password into the record. KB 339392 lists a timers mismatch among the most common reasons, but these sources do not describe how two different configured values are reconciled. A difference in timers is therefore a candidate for the owners, not a fault on its own.

Worked example (fictional)

Tier-0 t0-prod, NSX 4.2.2, active-active, NSX local AS 64512. Edge cluster ec-01 has edge-01, edge-02 and edge-03. Neighbour 192.0.2.1 (the peer router, AS 64500), remote AS 64500 configured in NSX, no source address selected, BFD on. The design record gives the SRs on edge-01 and edge-02 an uplink in 192.0.2.0/24. Observed 4 November 08:15 AEDT. Change record: ToR tor-a port-channel members replaced 3 November 22:00.

Reading it:

• edge-01's session is fine; the neighbour is not down as a whole.
• On edge-02 the session was Established, then received Hold Timer Expired at 22:30 while the Edge was sending keepalives: the KB 439484 row applies. It is now Active with no messages received: the "was Established before" row applies.
• The 22:30 drop is half an hour after the 22:00 ToR work. The timing is consistent with that work; this record does not prove it, because the peer's view (I) is missing.

The finding handed on: "On t0-prod, the session from edge-02 (192.0.2.12) to 192.0.2.1 dropped at 22:30 AEDT on 3 November after edge-02 received Hold Timer Expired from the peer while sending keepalives. It has been Active with BFD down since, as read at 08:15 on 4 November. edge-01's session is Established. The peer's view has not been collected." Do not clear the session to see if it comes back; the network owner checks the path from edge-02's uplink through tor-a.

Troubleshooting

Acceptance checks

1. NSX version, Tier-0, HA mode and observation time are recorded.
2. Field A is recorded for every Edge node in the Edge cluster. Fields B to G2 are recorded for every Edge that hosts the Tier-0 SR, not only the alarmed one, and non-hosting Edges are marked not applicable.
3. H, I, J and K are recorded, or marked "not available". Both AS numbers, both addresses and the authentication status are recorded for each end, with no password copied.
4. Every Step 2 row is marked applies, candidate, not applicable or not checked; more than one can stand.
5. A cause is stated only where the row's evidence is present; timing alone is stated as "consistent with".
6. No clear bgp, rescan, maintenance mode, firewall, BFD, timer or peer change was made while collecting.
7. Any fix is handed to its owner, and recovery is confirmed by its own read of C on every Edge.

Risk notes

• Clearing a session takes it down, and KB 369185 says a down neighbourship withdraws the peer's routes (inference: until it re-establishes).
• The SR's state follows its neighbours as configured. Configure BGP: "With only BGP configured, if all BGP neighbors go down, the service router's state will be down." With BGP and BFD configured, it is all BGP and BFD neighbours.
• The 4.2.2 rescan workaround uses debug mode on the Edge. It is the NSX owner's change, under their process.
• Tier-0 gateway firewall defaults of Drop or Reject block BGP and BFD unless allowed (Configure BGP).

These are source-documented behaviours. Expert review and a lab check are still needed before any change to an NSX environment.

Learning notes

• With no source address selected, a BGP neighbour in NSX is one session per Tier-0 SR. Read every Edge that hosts the SR, and mark the others not applicable.
• Active or Connect means the TCP session is not completing; Established with BFD down is a different problem.
• Hold Timer Expired received from the peer, while the Edge log shows keepalives sent, makes the path and the peer the first places to look (KB 439484). The log shows that keepalives were sent, not that they arrived, so it neither clears NSX's configuration nor shows where packets were lost.
• Timer, AS and authentication differences need both ends' views; a difference in timers is a candidate, not a verdict.

References

Related articles

• NSX Tier-1 Segment Has No Upstream Route, for route advertisement once BGP is up.
• NSX Traceflow Says Delivered but the Application Still Fails, for what a synthetic trace proves.