Troubleshoot AWS Direct Connect BGP Session Flaps And Routing Issues

AWS Direct Connect provides predictable private connectivity, but a BGP session can still become unstable when the physical circuit, VLAN tagging, timers, or route policy is misaligned. A session that repeatedly transitions between Established and Idle can interrupt traffic, trigger failover, and make hybrid applications appear unreliable.

Routing problems are different from session flaps. BGP may remain established while prefixes are rejected, suppressed, or selected through an unexpected path. Effective troubleshooting separates link health, BGP negotiation, and route selection instead of changing several variables at once.

The fastest approach combines AWS Direct Connect status information with router logs, interface counters, BGP tables, and packet-flow tests. Capture the exact time of each event so AWS metrics and on-premises evidence can be correlated.

Recognize The Failure Pattern

A BGP session that drops at regular intervals often points to a transport or timer problem. Irregular resets may indicate interface errors, a carrier issue, an overloaded router, or an authentication mismatch after a configuration change. Review the BGP reset reason rather than treating every Idle state as an AWS-side failure.

A session can also remain established while applications lose access. This usually indicates a routing issue, such as a missing VPC or on-premises prefix, an incorrect transit gateway route, an overly restrictive route map, or an unexpected preferred path. Test both directions because a route advertised from AWS does not guarantee that return traffic can reach the source network.

Check The Physical And Virtual Connection

Start in the AWS Direct Connect console by checking the connection state, virtual interface state, and recent events. Confirm that the expected virtual interface is associated with the correct connection, VLAN, gateway, and AWS Region. A private VIF, transit VIF, and public VIF have different routing roles, so validating the VIF type prevents incorrect assumptions.

On the customer router, inspect the Ethernet or optic interface, CRC errors, input drops, carrier transitions, duplex settings, and negotiated speed. For hosted connections, confirm that the provider has delivered the correct VLAN and cross-connect. A rising error counter or repeated carrier transition should be resolved before changing BGP policy.

Check MTU and encapsulation settings across the path as well. A basic ping may succeed while larger packets fail because of fragmentation or an inconsistent jumbo-frame configuration. Test with the DF bit where supported, and verify that VLAN tagging is present exactly once.

Validate BGP Parameters And Timers

Compare the AWS virtual interface configuration with the customer-edge router. The local ASN, peer ASN, BGP neighbor address, VLAN, and optional MD5 authentication must match. An incorrect ASN commonly produces a clear negotiation failure, while a wrong neighbor address or VLAN may appear as a transport problem.

Review BGP keepalive and hold timers on both sides. Aggressive timers can cause a session to reset during short congestion events, CPU spikes, or control-plane delays. Use compatible values and confirm that the router is not missing keepalives because of a busy process, control-plane policing rule, or firewall policy.

Inspect the BGP log for notification codes, hold-time expiration, cease messages, administrative resets, and maximum-prefix events. Also verify that the router has sufficient memory and CPU for the number of routes received. A maximum-prefix limit can reset or shut down a neighbor when an unexpected route advertisement appears.

Separate Session Health From Route Selection

Once the neighbor is Established, examine the received and advertised route views. Confirm that the expected CIDR blocks are present, that they are accepted by inbound policy, and that they are installed in the routing table. A prefix can be visible in BGP but rejected by an import policy or excluded because a more specific route wins.

For AWS-to-on-premises traffic, verify route propagation through the virtual private gateway or transit gateway and inspect the relevant VPC route tables. For on-premises-to-AWS traffic, confirm that the router advertises the correct private networks and that AWS accepts those advertisements. Check for overlapping CIDRs, summarized routes that hide specific networks, and stale static routes.

Use traceroute, TCP tests, and flow logs where available to identify the actual path. Compare the selected BGP path with local preference, weight, MED, AS-path length, and route-map behavior. If two Direct Connect links are intended for resilience, confirm that the preferred and backup paths are deliberately configured rather than determined by an unintended attribute.

Symptom	Likely Area	Evidence To Collect	Typical Corrective Action
Session resets at fixed intervals	Timers or keepalives	BGP logs, CPU history, hold-time values	Align timers and remove control-plane delay
Session stays down after circuit change	VLAN or neighbor settings	VIF details, interface counters, neighbor address	Correct tagging, ASN, peer IP, or authentication
AWS prefix is not reachable	Advertisement or gateway routing	BGP received routes, route tables, propagation status	Advertise, permit, and propagate the required CIDR
Traffic uses the wrong link	Route policy	Local preference, MED, AS path, route maps	Define primary and backup path attributes
Connection drops during load	Physical or capacity issue	Errors, utilization, packet drops, provider events	Resolve optics or circuit faults and assess capacity

Use Evidence From Both Ends

Router commands should show neighbor uptime, last reset reason, negotiated capabilities, accepted prefixes, advertised prefixes, and the selected best path. Save this output during a failure and after recovery. Comparing the two states often reveals whether the issue is a route-policy change or a complete transport interruption.

AWS-side evidence should include Direct Connect events, virtual interface status, CloudWatch metrics, and the timestamps of any circuit or provider incident. Align these records with switch logs, firewall events, and carrier tickets. If the AWS connection remains available while the VIF resets, focus on the BGP and customer-edge configuration rather than assuming the physical circuit failed.

A packet capture can help when the router reports hold-time expiry without an obvious cause. Look for missing TCP/179 traffic, TCP resets, authentication failures, or an intermediate firewall filtering BGP. BGP should normally be permitted only between the defined peer addresses, but security controls must allow the established session to remain open.

Apply Focused Remediation Steps

Make one controlled change at a time and record the before-and-after state. Avoid clearing every BGP process during an incident unless necessary; a soft policy refresh can validate route-map changes with less disruption. If a hard reset is required, perform it on the backup path first when the design permits.

Use these remediation priorities:

• Resolve interface errors, optical faults, VLAN mismatches, and carrier alarms before tuning BGP.
• Confirm ASN, peer address, authentication, timers, and maximum-prefix settings on both devices.
• Validate advertised and received prefixes through the correct VIF, gateway, and route tables.
• Make primary and backup path selection explicit with documented local preference, MED, or AS-path policy.
• Add monitoring for BGP state, route count, interface errors, utilization, and reset events.

After recovery, test failover in both directions. Withdraw the preferred route or disable the primary circuit during a maintenance window, then verify convergence time, return-path behavior, and application connectivity. Record the final configuration and the evidence that proves the intended path is being used.

Review the Direct Connect connection, virtual interface, router logs, and route tables together rather than relying on a single status indicator. A disciplined comparison of timestamps, prefixes, and path attributes usually turns an intermittent BGP problem into a specific configuration, transport, or capacity issue. Apply the checks above to your runbook and validate each change during a controlled failover test.