A BGP peering session between a Cisco switch and an SSR LAN interface (ge-0/0/2) failed intermittently, despite successful ICMP connectivity and direct connectivity between the devices.

The investigation identified an unexpected VRRP state on the SSR HA nodes. Both nodes were reporting vrrp-active for the LAN interface, instead of having one active node and the other in standby. This occurred after the cable was moved between interfaces on node1 while the second gateway switch (Switch2) was in a factory-default state.

When node1 became active, node0 appeared to treat node1 as the owner of the LAN interface. Consequently, traffic originating from node0 toward the directly connected Cisco switch was potentially forwarded through the HA fabric to node1 rather than leaving through node0's local LAN interface.

The BGP session recovered after disconnecting the cable from node1's ge-1/0/2 interface, restoring the expected redundancy state.

Symptoms are as below.

• BGP session between the Cisco switch (198.51.100.18) and SSR (198.51.100.20) failed to establish or remained in the Active state.
• Cisco logs reported:
  • open failed: Connection timed out; remote host not responding
  • Active open failed - tcb is not available
• ICMP connectivity between the Cisco switch and SSR remained successful.
• Restarting the SSR temporarily brought up the BGP session, but it dropped again after some time.
• Both SSR nodes reported vrrp-active for the LAN interface:
  • Node0: vrrp-active
  • Node1: vrrp-active
• The BGP session initially established, exchanged OPEN and KEEPALIVE messages, and received an UPDATE from the SSR. However, the SSR subsequently stopped acknowledging packets from the Cisco switch.
• The BGP session eventually terminated after the Cisco switch hold timer expired.
• The BGP peering to the second switch (198.51.100.19) also remained down because the switch was in a factory-default state.

1. Verify the BGP configuration and connectivity

The Cisco switch was configured with the following BGP parameters:

ICMP connectivity to the SSR neighbor was successful, with 5/5 packets received and an average latency of 1 ms.

Packet capture analysis confirmed that:

• The TCP three-way handshake completed successfully.
• MD5 authentication was successful.
• BGP OPEN and KEEPALIVE messages were exchanged in both directions.
• The SSR sent an UPDATE message.
• The SSR subsequently stopped responding to the Cisco switch packets.

This indicated that the initial BGP configuration, authentication, and timer negotiation were functioning correctly. The issue occurred after the session was established.

2. Identify the unexpected VRRP state

The SSR redundancy status showed both nodes as active on the LAN interface.

AMS site:

For comparison, the Dallas site showed the expected redundancy state:

The investigation found that moving the cable from node1's ge-1/0/2 interface and reconnecting it restarted VRRP on node1. Since node1 could not communicate with node0 through the second switch, which was in a factory-default state, node1 promoted itself to active.

This resulted in both nodes reporting an active redundancy state.

3. Identify the incorrect service-path selection

The service-path output showed an unexpected forwarding path for the originate-default service.

AMS site:

• Node0: Next hop 169.254.252.2 through the HA fabric interface ge-0-5.
• Node1: Directly through its local interface ge-0-2.

Expected behavior:

• Node0 should use its local ge-0-2 interface to reach the BGP neighbor.
• Node1 should forward traffic through the HA fabric to node0, which has the direct connection to the LAN.

The Dallas site showed the expected behavior, where node0 used its local LAN interface and node1 forwarded through the HA fabric.

Additionally, node0 had a valid ARP entry for the Cisco switch (198.51.100.18), while node1 had no ARP entries for the 198.51.100.x subnet.

4. Root cause analysis

The first switch was physically connected only to node0. Initially, the TCP handshake and BGP OPEN exchange completed because packets from the Cisco switch reached node0.

However, after node1 promoted itself to active, the SSR appeared to treat node1 as the owner of the LAN interface. As a result, node0's outgoing traffic toward the Cisco switch, including TCP acknowledgements and BGP KEEPALIVE messages, was potentially forwarded through the HA fabric to node1 instead of leaving through node0's local LAN interface.

Since the Cisco switch did not receive the expected responses, the BGP session eventually expired due to the hold timer.

ICMP connectivity remained successful, which initially made the issue appear to be specific to BGP.

The BGP peering failure to 198.51.100.20 was therefore associated with the unexpected VRRP state and service-path selection. The peering to 198.51.100.19 remained down because the second switch was in a factory-default state.

5. Resolution and validation

The issue was resolved by disconnecting the cable from node1's ge-1/0/2 interface.

After removing the cable, the redundancy status returned to the expected state:

• Node0: vrrp-active
• Node1: unknown (expected when the interface is disconnected)

The originate-default service-path on node0 also showed the local ge-0-2 interface, allowing BGP communication with the directly connected neighbor through the correct interface.

6. Further validation and engineering investigation

Since this is a lab environment, further validation was requested to determine whether reconnecting the cable to node1's ge-1/0/2 interface causes the VRRP state or service-path selection to change again.

After reconnecting the cable and allowing sufficient time for the redundancy state to stabilize, collect the following outputs from both nodes:

show device-interface ge-0-2 node node0
show device-interface ge-0-2 node node1
show service-path service-name originate-default node node0
show service-path service-name originate-default node node1

Expected behavior:

• Node0 should remain vrrp-active on ge-0-2.
• Node1 should not become active when it cannot reach the directly connected switch through its own LAN interface.
• Node0's originate-default service-path should continue using its local ge-0-2 interface.
• Node1's originate-default service-path should forward through the HA fabric to node0 and then use node0's ge-0-2 interface.

If the service-path changes after reconnecting the cable, despite node1 not having reachability to the BGP neighbor, the collected outputs should be shared with the engineering team for further investigation.

If the BGP issue persists even after restoring the expected VRRP state, collect TSI files from both SSR nodes and escalate the issue to engineering.

Note: The public IP addresses (198.51.100.x) and AS numbers (65045 and 65042) used in this article are documentation placeholders. They do not represent the original deployment addresses or AS numbers.