How do I troubleshoot BGP connectivity on a Transit Gateway Connect attachment?

Resolution

Check the requirements for the BGP session

Take the following actions:

• Confirm that the maximum transmission unit (MTU) of the Generic Routing Encapsulation (GRE) tunnel is smaller than the external interface MTU. Subtract the GRE header of 24 bytes and outer IP address header overhead of 20 bytes from the external interface MTU.
  Note: The GRE tunnel is also known as the Transit Gateway Connect peer.
• Verify that you correctly configured the Connect peer and that it's operational between your appliance and the transit gateway.
• Check whether you use supported BGP types, such as interior BGP (iBGP) and exterior BGP (eBGP), for specific routing behavior.
• Create one or more Connect peers on a Connect attachment, and establish two BGP sessions over each Connect peer for redundancy.
  Important: It's a best practice to configure two BGP peering sessions. A Connect peer with a single BGP session might temporarily lose connectivity during AWS infrastructure maintenance.

Note: The Connect attachment doesn't support Bidirectional Forwarding Detection (BFD) and graceful restart.

For more information about requirements for a Connect attachment, see Requirements and considerations.

Check that AWS resources are in the correct state

View your Connect attachment and Connect peers to make sure that they're in the Available state.

Note: A new Connect peer remains in the Pending stat until the provision completes.

Also, confirm that the Connect peer configuration displays the Transit Gateway address, peer IP address, and inside CIDR block for the BGP.

Check BGP address and ASN configuration in AWS and on your appliance

When you don't correctly configure the IP address or Autonomous System Number (ASN) between peers, BGP neighbor formation fails.

Note: For redundancy, use two BGP peering sessions for each Connect peer. AWS creates two BGP peering sessions by default. If you have multiple Connect peers, then configure both BGP peering sessions.

First, check your Connect peer for the following configurations:

• For InsideCIDR, verify that the BGP sessions use the /29 CIDR block for peer IP addresses.
• For Peer ASN, check whether you specified an ASN or AWS assigned the default ASN.
  Note: If you don't specify an ASN when you create the Connect peer, then AWS uses the same transit gateway ASN and creates an iBGP session. This might cause unexpected routing behavior.

Then, check your appliance for the following configurations:

• Verify that you configured the tunnel interface with the first IP address from the inside CIDR block. For example, if the inside CIDR block range is 169.254.6.0/29, then configure 169.254.6.1 on the appliance tunnel.

• Verify that the transit gateway uses the second IP address from the inside CIDR block range.
  Example configuration for Cisco IOS:

  interface Tunnel0
    ip address 169.254.6.1 255.255.255.248
    tunnel source GRE OUTER IP ADDDRESS
    tunnel destination TGW TUNNEL IP
  router bgp 65001
    neighbor 169.254.6.2 remote-as 64512
    neighbor 169.254.6.2 ebgp-multihop 2
    neighbor 169.254.6.2 timers 10 30

  Note: Replace 169.254.6.1 and 169.254.6.2 with your IP addresses from the inside CIDR block. Replace TGW TUNNEL IP and GRE OUTER IP ADDRESS with your values. For eBGP, configure ebgp-multihop and set the time-to-live (TTL) value to 2.

Troubleshoot BGP neighbor states

Check your BGP summary and neighbor details on your appliance. For example, if your appliance runs Cisco IOS, then run following commands.

To view a summary of the BGP session status with all neighbors, run the following show ip bgp summary command:

show ip bgp summary

To view information about BGP and TCP connections to neighbors, run the following show ip bgp neighbors command:

show ip bgp neighbors

To view BGP debug logging, run the following debug ip bgp command:

debug ip bgp

If your BGP neighbor is in the Idle, Active, or Connect state, then complete the following steps:

1. Run the following telnet command to test connectivity to the BGP peer IP address that's configured on your transit gateway:

   telnet TGW-BGP-PEER-IP 179

   Note: Replace TGW-BGP-PEER-IP with your transit gateway's BGP peer IP address.

2. Run the tcpdump command on your appliance to monitor GRE packets and BGP traffic, such as TCP port 179.

3. Verify that GRE encapsulated packets and TCP SYN/ACK for port 179 appear.

4. If your appliance uses different or shorter BGP timers, it's a best practice to configure your appliance to match the transit gateway default settings. Set keepalive to 10 seconds and hold time to 30 seconds.

Verify route table associations and propagation

Complete the following steps:

1. Open the Amazon VPC console.
2. In the navigation pane, choose Transit gateway attachments, and then select your attachment ID.
3. On the Details tab, select the route table ID, and then check whether you associated the attachment with the correct route table.
4. For the same route table, choose the Propagations tab.
5. Verify that you turned on propagation so that the route table can accept propagation from the Connect attachment.

If routes appear in the transit gateway route table and not in the connected attachment's route table, then check your route table associations and propagation settings.

If the expected routes don't appear, then take the following actions:

• Check whether your appliance sends BGP advertisements. Also, check for export filters or route maps that might block advertisements.
• For iBGP connections, your transit gateway installs routes only when they originate from an eBGP peer. Verify that the routes that your appliance advertises over iBGP connections have an ASN, or use eBGP instead.

The default quota for dynamic routes that you can advertise from your appliance to your Connect peer is 1,000. You can adjust the quota. However, it's a best practice to limit the number of dynamic routes to 1,000 to prevent BGP instability.

Check MTU and fragmentation issues

GRE encapsulation increases packet size and causes fragmented packets. When packets fragment, BGP sessions can't establish.

To resolve this issue, take the following actions:

• Verify that you correctly set the GRE MTU on your appliance. To calculate the GRE MTU, subtract 24 bytes of GRE header and 20 bytes of IP address header (44 bytes total) from your external MTU. For example, if your external MTU is 1,500, then set your MTU to 1,456.

• To check for MTU path issues, run the following ping command from your appliance with different packet sizes and include the "don't fragment" flag -M:

  ping -M do -s 1400 TRANSIT_GATEWAY_BGP_PEER_IP

  Note: Replace 1400 with different values to find the maximum MTU size that works without fragmentation. Replace TRANSIT_GATEWAY_BGP_PEER_IP with the BGP peer IP address from your inside CIDR block range. If you configured two BGP sessions, then run the ping command for both BGP peer IP addresses.

• Run tcpdump or Wireshark on your GRE interface to check for fragmented packets. Look for IP address flags that show More Fragments and check for TCP retransmissions.

If you find MTU issues, then lower the GRE tunnel MTU on your appliance. Also, turn on maximum segment size (MSS) clamping on your appliance so that large packets don't overwhelm the path.

Related information

Connect attachments and Connect peers in AWS Transit Gateway

Transit gateway route tables in AWS Transit Gateway

AWS Transit Gateway quotas