Published on · Updated on
Reworked the fault isolation steps for physical links, VLANs, BGP, routing, metrics, and encryption.
Troubleshoot AWS Direct Connect in order: physical connection, VLAN and peer reachability, BGP, then routes to the workload. A physical connection can be up while a virtual interface or BGP session is down; an established BGP session can still lack the route needed by an application. Direct Connect traffic is not encrypted in transit by default. For the differences between Direct Connect and IPsec Site-to-Site VPN, see Direct Connect vs. Site-to-Site VPN.
Record the connection ID, virtual interface ID and type, Region, timestamps, affected source and destination prefixes, and whether the failure is a full outage, one direction, one VPC, or one application. In the Direct Connect console, compare the connection state, virtual interface state, and BGP session state. These are separate signals.
To inspect the control-plane state with the AWS CLI, replace the example IDs and Region with your own:
aws directconnect describe-connections \
--connection-id dxcon-example \
--region us-east-1
aws directconnect describe-virtual-interfaces \
--virtual-interface-id dxvif-example \
--region us-east-1The first command reports whether the physical connection is up. The virtual interface details include its type, VLAN, peer addresses, BGP state, and attachment. The AWS CLI references document connection inspection and virtual interface inspection.
If the connection state is down or unstable, start with the cross-connect and your provider before changing routing. Confirm that the cross-connect is complete, compare its ports with the current Letter of Authorization and Connecting Facility Assignment (LOA-CFA), and check that your router is powered on and its port is active. Verify the optical transceivers, port speed, duplex, and negotiation settings against the requirements for that Direct Connect location. For speeds above 1 Gbps, auto-negotiation must be disabled; for 1 Gbps, AWS says the correct setting depends on the endpoint.
Ask the colocation provider to verify the optical signal across the cross-connect and check both ends of the fiber. Rolling the Tx/Rx strands can resolve a polarity mismatch. In CloudWatch, inspect ConnectionState, ConnectionLightLevelTx, ConnectionLightLevelRx, and ConnectionErrorCount. Compare signal levels with AWS's current guidance for the connection speed; use the OpticalLaneNumber dimension when the connection reports lane-specific readings. ConnectionErrorCount is the current MAC-level error metric and includes CRC errors; the old ConnectionCRCErrorCount metric is no longer used. Metrics are published at five-minute intervals by default. A one-minute CloudWatch period can be requested, but the update frequency is not guaranteed to be shorter than five minutes. See the AWS guides for physical troubleshooting and Direct Connect CloudWatch metrics.
If the physical link is up but the virtual interface is down, check Layer 2. Confirm that the router uses the VLAN ID shown for the virtual interface and that 802.1Q tagging carries it across every intermediate device. VLAN IDs must be unique on the connection and in the range 1–4094. For a hosted connection, the Direct Connect partner assigns the VLAN; you cannot change it on the virtual interface.
Configure the AWS and customer peer IP addresses on the VLAN subinterface, not the physical interface. For IPv4, check the router's ARP table for the AWS peer's MAC address; for IPv6, check neighbor discovery and the neighbor table. Investigate stale entries and clear the relevant cache if needed. Then test whether the router can reach the AWS peer IP. AWS's Layer 2 troubleshooting steps follow this same order. The peer-IP test checks the virtual interface link; it does not prove that a VPC workload route is present.
If the physical link and Layer 2 are healthy but BGP is down, compare the customer and AWS ASNs, both peer IP addresses, address family, and MD5 key with the values shown in the Direct Connect console or downloaded router configuration. AWS enables MD5 for Direct Connect BGP sessions; a mismatched key or peer configuration prevents the session from establishing. Protect the configuration file because it can contain the authentication key.
Confirm that firewalls and router ACLs permit the BGP TCP session to the peer on port 179 and its return traffic, including high-numbered source ports where required by your firewall design. Do not troubleshoot these peer packets with VPC security groups or subnet network ACLs: those controls apply to traffic at VPC resources, not to the Direct Connect BGP peering session. Review your router's BGP logs and the AWS virtual interface status. If you configured Bidirectional Forwarding Detection (BFD), check its configuration and logs as well.
In CloudWatch, VirtualInterfaceBgpStatus reports whether the BGP session is up. Review VirtualInterfaceBgpPrefixesAccepted (routes AWS accepted from the BGP peer) and VirtualInterfaceBgpPrefixesAdvertised (routes AWS sent to the peer) when the session is established but the expected routes are missing. AWS lists the full troubleshooting sequence in its Layer 3/4 Direct Connect guide.
An established BGP session proves that the peers are connected; it does not prove that any expected route was advertised, accepted, selected, propagated, or installed at every routing layer. Check the customer router's received and advertised routes, the AWS BGP route details, and the AWS route tables that carry the workload traffic in both directions.
| Virtual interface | Intended path | Checks when traffic fails |
|---|---|---|
| Private | Private IP connectivity to a VPC through a virtual private gateway or Direct Connect gateway. | Confirm the VPC route to each on-premises prefix has the virtual private gateway as its target, either explicitly or through route propagation. If using a Direct Connect gateway, check its association with the intended virtual private gateway and the prefixes advertised to your router. |
| Transit | Connectivity to Transit Gateways associated with a Direct Connect gateway. | Check the Direct Connect gateway association and its allowed prefixes advertised to on-premises, the Transit Gateway route-table association and propagation, and the VPC route tables on both sides. See Transit Gateway route-table associations and propagation. |
| Public | Connectivity to AWS public services and public AWS IP addresses. | Check that your advertised prefixes are public, belong to you, and are routable. Verify that AWS public prefixes arrive at your router. A public VIF is not a general internet transit path and does not provide private VPC routing. |
For private and transit VIFs, the default limit for routes advertised from on-premises to AWS is 100 per BGP session for each address family (IPv4 and IPv6). Prefix controls can increase that allocation to 1,000 per family. If the session exceeds its configured allocation, it can enter the idle state. Public VIFs have a 1,000-route limit. Check the account's configured prefix allocation and the current Direct Connect quotas before summarizing routes or changing advertisements.
For a private VIF connected to a virtual private gateway, confirm the VPC route table has a route to each required on-premises prefix through that gateway or has route propagation enabled. For a transit VIF, route propagation in the Transit Gateway table is separate from each VPC subnet route table. For VGW-based paths, VPC route tables have a separate quota of 100 propagated routes per table, which cannot be increased; non-propagated routes have a default quota of 500 per address family, adjustable up to 1,000. Transit Gateway tables have their own quotas. See the current VPC quotas and Transit Gateway quotas. A missing route at any layer or a missing return route can create a one-way failure. AWS's routing troubleshooting guide covers the private-VIF route checks.
Once routes exist, check the workload's security group, subnet network ACL, host firewall, and application listener for the actual application protocol and port. Security groups are stateful; network ACLs are stateless and need rules for request and return traffic. These workload controls can block application packets even while the Direct Connect physical link and BGP session remain healthy.
VPC Flow Logs on the relevant workload ENI can help show whether VPC-side IP flows were accepted or rejected. They do not diagnose the Direct Connect optical link or BGP peer session, and an accepted record does not prove that the application handled the request. For broader metric and dashboard checks, see the AWS network dashboard troubleshooting guide.
Direct Connect does not encrypt traffic in transit by default. If your security requirement calls for encryption, an AWS Site-to-Site VPN over Direct Connect provides IPsec tunnels. MACsec is available only for supported connections and locations; it protects a point-to-point Layer 2 link between the customer router and the Direct Connect location, not an end-to-end path across all network segments. If MACsec is enabled, check ConnectionEncryptionState (1 means encryption is up; 0 means it is down) and confirm the configured mode: must_encrypt stops traffic if MACsec cannot be established, while should_encrypt can fall back to unencrypted traffic. AWS documents these Direct Connect encryption options and MACsec behavior.
If the checks do not isolate the failure, give AWS Support and your provider the connection and VIF IDs, timestamps with time zone, connection and BGP states, VLAN and peer-IP details, relevant router logs, route tables and prefixes, and CloudWatch metrics. Include the test source and destination and say which layer has been verified. Keep secrets such as BGP authentication keys out of tickets and packet captures.