Transit Gateway: can't connect 2nd TGW BGP IP

Hi Damien,

The AI-generated answer is unfortunately not correct in this instance. Both BGP sessions on the connect peer should be established in order to ensure fault tolerance. That is very clearly stated in the Transit Gateway documentation. I have a similar lab setup and both BGP peers are in fact established. I was going to suggest that you may need to enable multi-hop peering as I ran into that issue myself. However, that wouldn't explain why you can't ping the second peer through the tunnel. The only thing I can think of is to double check the mask on your router's tunnel interface. If that were incorrectly set to /30, it might explain why you can reach the 169.254.100.2 peer but not the 169.254.100.3.

The behavior you're experiencing is expected. In a Transit Gateway Connect attachment, you can establish a BGP session with only one of the Transit Gateway's inside IP addresses, not both simultaneously.

When you create a Connect peer on a Transit Gateway Connect attachment, you specify an inside CIDR block (in your case, 169.254.100.0/29). The Transit Gateway automatically assigns two IP addresses from this range for its own use. However, only one of these addresses (typically the first one, 169.254.100.2 in your scenario) is actively used for the BGP session.

The second IP address (169.254.100.3 in your case) is essentially a backup or standby address. It's not meant to be used for an active BGP session simultaneously with the first address. This design provides redundancy in case of issues with the primary IP, but it doesn't support concurrent BGP sessions to both addresses.

Your setup, where you have successfully established a BGP session with 169.254.100.2 and are able to exchange routes, is functioning as intended. The inability to ping or establish a BGP session with 169.254.100.3 is not an issue, but rather the expected behavior of the Transit Gateway Connect feature.

If you need to establish multiple BGP sessions for increased redundancy or bandwidth, you would typically create additional Connect peers within the same Connect attachment, each with its own inside CIDR block. Each of these peers would then establish a BGP session with one of the Transit Gateway's assigned IP addresses from their respective CIDR blocks.

Sources
Transit Gateway Connect attachments and Transit Gateway Connect peers in Amazon VPC Transit Gateways - Amazon VPC
AWS Transit Gateway features - Amazon Web Services
TransitGatewayConnectPeerConfiguration - Amazon Elastic Compute Cloud