AWS Frequently Asked Questions (FAQs)
Click any of the FAQs in the right navigation for suggestions and resolution.
I want to configure a backup VPN connection for failover with my AWS Direct Connect connection. Any recommendations and best practices?
To configure the hardware VPN as a backup for your Direct Connect connection:
- Be sure that you use the same virtual private gateway for both Direct Connect and the VPN connection to the VPC.
- If you are configuring a Border Gateway Protocol (BGP) VPN, advertise the same prefix for Direct Connect and the VPN.
- If you are configuring a static VPN, add the same static prefixes to the VPN connection that you are announcing with the Direct Connect virtual interface.
- If you are advertising the same routes toward the AWS VPC, the Direct Connect path is always be preferred, regardless of AS path prepending.
Be sure that Direct Connect is the preferred route from your end, and not over VPN when the Direct Connect virtual interface is up in order to avoid asymmetric routing; this might cause traffic to be dropped. We always prefer a Direct Connect connection over VPN routes. For information on route priority and routing options, see the AWS topic Route Priority.
If you want a short-term or lower-cost solution, consider configuring a hardware VPN as a failover option for a Direct Connect connection. VPN connections are not designed to provide the same level of bandwidth available to most Direct Connect connections. Ensure that your use case or application can tolerate a lower bandwidth if you are configuring a VPN as a backup to a Direct Connect connection.
Bidirectional Forwarding Detection (BFD) is a network fault detection protocol that provides fast failure detection times, which facilitates faster re-convergence time for dynamic routing protocols. It is independent of media, routing protocol, and data. We recommend enabling BFD when configuring multiple AWS Direct Connect connections or when configuring a single AWS Direct Connect connection and a VPN connection as a back up to ensure fast detection and failover. You can configure BFD to detect link or path failures and update dynamic routing as Direct Connect quickly terminates BGP peering so that backup routes can kick in. This ensures that the Bidirectional Forwarding Detection (BGP) neighbor relationship is quickly torn down instead of waiting for 3 keep-alives to fail at a hold-down time of 90 seconds.
The BFD interval specifies how often we send BFD packets, the min_rx is how often a router expects to receive the packets, and the multiplier is how many we can miss before the BGP neighbor relationship is considered down.
Asynchronous BFD is automatically enabled for each Direct Connect virtual interface on the AWS side, but it does not take effect until it’s configured on your router. The Direct Connect default sets the BFD liveness detection minimum interval to 300 ms and the BFD liveness detection multiplier to 3.
Before using BFD echo mode with your network device, you must disable the sending of Internet Control Message Protocol (ICMP) and redirect messages with the no ip redirect command to avoid high CPU utilization.
When using AWS Direct Connect to transport production workloads to and from AWS, it is recommended to use dual Direct Connect Virtual Circuits, either from a single Port, a pair of physical Port connections (either discrete or LAG/LACP) in a single DC, or spread across multiple DC locations.
You can configure the following:
- Two routers to terminate the primary and secondary DX connections to avoid a single point of device failure.
- A private virtual interface on each of the DX routers that terminate to the same VPC. HA routing protocols (such HSRP, VRRF, GLBP, etc.) on two routers to allow Local servers to use multiple routers that act as a single virtual router, maintaining connectivity even if the primary router fails, because the secondary router will take over and become active, or run an internal routing protocol such as iBGP which will learn routes from Direct Connect EBGP and distribute prefixes to internal iBGP gateways.
- Active/Passive (failover). One connection is handling traffic, and the other is on standby. If the active connection becomes unavailable, all traffic is routed through the passive connection. You will need to AS path prepend the routes on one of your links for it to be the passive link. For more information, see Configure Redundant Connections with AWS Direct Connect.
The local preference attribute identifies a preferred exit point from the local autonomous system (AS). If there are multiple exit points from the AS, the local preference attribute selects the exit point for a specific route.
Influencing AWS outbound traffic using AS Path prepending
The BGP Best Path Algorithm decides how the best path to an autonomous system is selected. A common value to determine the best path is the AS Path length. When two or more routes exist to reach a prefix, the default in BGP is to prefer the route with the shortest AS path.
The secondary router will advertise a longer AS path, so traffic from VPC to your network will always be through the primary router.
When you create a public virtual interface and you specify the public peer IP addresses, it requires approval from the AWS Direct Connect team (private VIFs/VXCs do not require this authorization and are available within minutes). Before approving public IP prefixes or public ASNs, the AWS Direct Connect team needs to verify the ownership of the public IP prefixes and BGP ASN. The AWS Direct Connect team verifies ownership by confirming that the regional registry belongs to the organization name listed in your AWS account.
If the public virtual interface state is in the verifying state for more than 72 hours, check the email address registered to your AWS account. You might have received an email from the AWS Direct Connect team if the owner of the BGP ASN or one of your advertised routes does not match your account details.
If the BGP ASN or an advertised route does not match your account, you can:
Ask the IP address owner to email email@example.com stating that they authorize to have the public IP prefixes approved for the public virtual interface dxvif-xxx.
Ask the IP address owner to submit a letter of authorization written on a company letterhead or ask them to send a email authorizing the use of the public IP prefix for the public virtual interface dxvif-xxx with your AWS account. Then sign in to the account that owns the Direct Connect public virtual interface, open a case, and attach the letter of authorization to your case.
Your virtual interface status might be down because of configuration issues with the OSIOpen systems interconnection.
A model that characterizes and standardizes the communication functions of a telecommunication or computing system. Most Megaport products are Layer 2 with some of the OSI constructs pushing into Layer 3 where IP addressing information is exchanged, known as an L2/L3 service. Layer 2 or Border Gateway Protocol (BGP).
OSI Layer 2 configuration
First, verify that your OSI layer 2 is configured correctly. Verify the following details:
You have configured the correct VLAN ID with dot1Q encapsulation on your device (such as a router or switch). The VLAN ID appears in the Portal Information tab as the A-End service for your VXC.
The peer IP address configuration is identical on your device, through the Portal, and in the AWS Direct Connect console.
Any intermediate devices are configured for VLAN tagging with appropriate VLAN ID, and VLAN-tagged traffic is preserved in the AWS Direct Connect endpoint.
Your device is learning the media access control (MAC) address of the AWS Direct Connect endpoint for the configured VLAN ID from the Address Resolution Protocol (ARP) table.
Your device can ping the Amazon peer IP sourcing from your peer IP.
If the OSI layer 2 test results are positive, then confirm the BGP configuration on your device. Verify the following:
- The local ASN and remote ASN as provided in the Portal Information tab as A-End service for your VXC.
- The neighbor IP address and BGP MD5 password as provided in the Portal Information tab as A-End service for your VXC.
- Your device is not blocking ingress or egress from TCP port 179 (BGP) and other appropriate ephemeral ports.
- Your device is not advertising more than 100 prefixes to AWS by BGP. By default, AWS only accepts up to 100 prefixes using a BGP session on AWS Direct Connect.
After confirming these configurations, your virtual interface BGP status should be up.