Why can't I use a Direct Connect connection to connect to VPC resources over a transit virtual interface?
I can't use my AWS Direct Connect connection to connect to Amazon Virtual Private Cloud (Amazon VPC) resources over a transit virtual interface.
Verify that you're advertising the correct on-premises network prefixes
Review your on-premises Direct Connect Border Gateway Protocol (BGP) router. The router must be advertising the correct on-premises prefixes towards the AWS Direct Connect BGP peer on the transit virtual interface.
Review the advertised routes on your local BGP router. Your local BGP router must include the advertised route in the local routing information base (RIB). The commands that you use to check these routes vary based on the make and model of your on-premises BGP device. For details, refer to the documentation for your device.
Note: You can advertise a maximum of 100 routes per BGP session on a transit virtual interface. This is a hard service quota that you can't change. If you exceed this service quota, then the BGP session goes into an idle state.
Verify that you're advertising the correct Amazon VPC prefixes from the Direct Connect gateway to the on-premises network
When you associate transit gateways with Direct Connect gateways, use prefixes that can you can advertise to the on-premises network through the Direct Connect gateway.
Note: If you specify any of the following prefixes, then AWS advertises it back to the on-premises network:
- A subnet prefix of a virtual private computer (VPC), such as 10.1.0.0/24 in a 10.1.0.0/16 VPC
- An entire VPC prefix
- A supernet (for example, 10.0.0.0/8)
Review your transit gateway settings
Make sure that you correctly configured your transit gateway settings:
- Follow the rules for transit gateway associations. Transit virtual interfaces use Direct Connect gateway associations with transit gateways to facilitate communication. This communication goes from the on-premises network to multiple VPCs in all AWS Regions and accounts over a single transit virtual interface. .
- Review your transit gateway routing configuration. You can configure route tables to propagate routes for any attached VPCs, virtual private networks (VPNs), or Direct Connect connections. You can also add static routes to the transit gateway route tables. When a packet comes from one attachment, the packet uses the route table that matches the destination IP address to route to another attachment.
Note: You can associate only one route table with each attachment. However, an attachment can propagate its routes to more than one route table.
- If you attached a VPC to your transit gateway, then review your Availability Zones. Make sure that you select the appropriate number of Availability Zones for the transit gateway to route traffic to resources in VPC subnets. The transit gateway uses one IP address from the subnet to create a network interface in that subnet.
- For resources in different Availability Zones, confirm that the transit gateway elastic network interface is in that Availability Zone.
Important: Availability Zones that don't have a transit gateway attachment can't reach the transit gateway. If you can route traffic from one Availability Zone but not another, then review the transit gateway network interface. The transit gateway network interface must be in that zone. For high availability, it's a best practice to turn on transit gateway network interfaces in multiple Availability Zones.
Review your Amazon VPC settings
On your Amazon VPC, make sure that you configured the following settings:
- The security groups allow inbound and outbound traffic to and from the advertised on-premises network prefixes.
- You correctly configured the network access control list (network ACL). Create one network ACL, and then associate it with all the subnets that are associated with the transit gateway. Keep the network ACL open in both the inbound and outbound directions.
- The subnet route table includes a route entry with Target set to the transit gateway ID and Destination set to the on-premises network prefix.
Verify that requests are sent and received over the desired Direct Connect connection
Note: Use these troubleshooting steps when you have the following settings:
- You configured redundant Direct Connect physical connections from the on-premises location.
- You configured one transit virtual interface per Direct Connect physical connection.
- You advertised similar on-premises prefixes over both transit virtual interfaces towards AWS.
To confirm that the Active/Passive or Active/Active configuration for your redundant connections works, take the following actions:
- Run a bidirectional traceroute. Review the Direct Connect BGP peer IP addresses to find the transit virtual interface that's used to send or receive traffic.
- Use local preference BGP community tags to achieve load balancing and route preference for incoming traffic to your network.
- To use an Active/Passive configuration in the same Region, use local preference and AS-path prepending.
Note: Local preference influences outbound traffic from your on-premises data center over a certain Direct Connect link. AS-path prepending influences inbound traffic back to your on-premises data center from AWS.