AWS Direct Connect Private VIF and BGP Setup

Direct Connect replaces a VPN tunnel with a dedicated 802.1Q circuit into an AWS Direct Connect location, but the operational weight sits on the BGP relationship and the route advertisement policy. A private virtual interface (VIF) carries traffic to VPC resources over private IPs, either to a single VPC or through a Direct Connect gateway to many VPCs across accounts and Regions. This guide covers the provisioning steps that must match your router, and how AWS actually chooses between redundant VIFs.

What the two sides must agree on

• VLAN ID - chosen on the VIF, must match the subinterface on your router.
• BGP ASN - your on-premises ASN on the AWS side (1-2147483647, or a long ASN up to 4294967294) and AWS's ASN on yours.
• BGP authentication - AWS enables MD5 by default and it cannot be disabled, so the router must be configured with a matching key.
• Peer addressing - you may use RFC 1918 addressing, AWS-assigned /29s, or link-local 169.254.0.0/16. Link-local addresses are for eBGP peering only; for tunnel or VPC traffic prefer loopback or LAN addresses.

Create the private VIF

Direct Connect console > Virtual Interfaces > Create virtual interface
  Type:                Private
  Virtual interface name: dc-core1-private
  Connection:          dxcon-xxxxxxxx (the physical connection)
  Virtual interface owner: My AWS account
  Direct Connect gateway: dxgw-core
  VLAN:                210
  BGP ASN:             65010 (your on-premises ASN)
  IPv4 BGP peer:       use your own /30 or AWS-assigned /29
  Jumbo MTU:           optional (8500/9001 depending on VIF type)
  Rate limiter:        optional, dedicated connections only

MTU applies per VIF: private VIFs support 1500 or 9001, transit VIFs 1500 or 8500. Raising MTU can trigger an update to the underlying connection, which briefly disrupts every VIF on it - schedule it.

Router side (example: Cisco IOS-XE)

interface GigabitEthernet0/0/1
 description AWS-DX-200G
 no shutdown
!
interface GigabitEthernet0/0/1.210
 encapsulation dot1Q 210
 ip address 169.254.10.1 255.255.255.252
 mtu 9001
!
router bgp 65010
 neighbor 169.254.10.2 remote-as 64512
 neighbor 169.254.10.2 password <bgp-md5-key>
 address-family ipv4 unicast
  neighbor 169.254.10.2 activate
  neighbor 169.254.10.2 route-map ADVERTISE-ONPREM out
  neighbor 169.254.10.2 route-map ACCEPT-AWS in

You must explicitly advertise the on-premises prefixes AWS should learn; AWS learns nothing about your network unless you announce it. Nothing is filtered outbound by default, so a route-map that permits exactly the prefixes you own is safer than relying on the peer.

How AWS picks between redundant VIFs

The classic mistake is assuming AWS prefers the VIF with the lower local preference. AWS selects on longest prefix match first, then on the shorter AS_PATH. To steer traffic towards one VIF in a pair, make its advertised path shorter (fewer AS prepends) than the other, or advertise a more specific prefix from it. Where your own routers are concerned, the usual tie-breakers apply - see BGP Best External and Add-Path: Advertise More Paths for the full selection order.

Verification and troubleshooting

• AWS side: Virtual interface state must be available, and BGP status up; the session shows learned routes and advertised prefixes.
• Router side: the BGP session should be in Established state with MD5 set; a session that never comes up is usually a VLAN mismatch, a wrong peer address or an MD5 key mismatch - routers typically log "authentication failure".
• Data path: ping using a VIF source address, and verify the return path does not leave through a different circuit than intended.

For multi-VPC designs, terminate into a Transit Gateway and control propagation with separate route tables, as outlined in AWS Transit Gateway: Attachments and Route Tables. The same BGP building blocks apply to Azure ExpressRoute, covered in Azure ExpressRoute: Circuits, Private Peering and BGP.

原文链接：https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-private-vif.html