In part 1 of this article, I provide an overview of how one might update the default route for your VMC on AWS SDDC. In Part 2, I hope to explain somewhat further what is necessary to ensure your default route (0.0.0.0/0) is advertised across your AWS and VMC environment appropriately – specifically when using a Transit Gateway from AWS.
In many cases, customers will want to retain their managed edge on premises… that is to say, they will retain their firewall, inspection, and other DMZ services on prem. In this case, of course, all internet-bound traffic originating from the cloud or passing through the cloud must travel back on premises through the customer’s managed firewall and routers prior to egressing to the internet.
However, many customers are starting to think about if and how they might move everything out to VMware Cloud on AWS. In this case, frequently a greater degree of routing flexibility is required than is currently available in VMC on AWS. A “Transit VPC” architecture is a well-known and well architected design using native AWS constructs to be able to achieve just such an outcome – and VMware has many customers already leveraging just such a design. However, with the introduction of the Transit Gateway in 2018, AWS has provided a much more elegant solution to this problem.
We know, if we want to achieve the desired state as pictured above, we will need to achieve the following routing design:
The key here is the core functionality of how the Transit Gateway (TGW) works. This post will not review the tasks for creating a Transit Gateway, its attachments and route tables – for a review of exactly how to create a Transit Gateway, Attachments, etc, see:
https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html
And for a most excellent tutorial on using a TGW with VMC on AWS , see:
http://www.gilles.cloud/2018/12/aws-transit-gateway-and-vmware-cloud-on.html
Upon creation, the TGW itself has a default route table, and by default that route table automatically learns all routes connected through the Transit Gateway Attachments. It is possible to create unique route tables for each attachment, and in doing so gain control over which VPCs exchange routing information, but by default the default route table learns about anything attached.
Furthermore, there are 2 ways where routes get propagated in the AWS Transit Gateway:
- Routes propagated to/from on-premises networks: When you connect VPN, routes will propagate between the AWS Transit Gateway and your on-premises router using Border Gateway Protocol (BGP).*
- Routes Propagated to/from Amazon VPCs: When you attach an Amazon VPC to an AWS Transit Gateway or resize an attached Amazon VPC, the Amazon VPC Classless Inter-Domain Routing (CIDR) will propagate into the AWS Transit Gateway route table using internal APIs (not BGP). CIDR is a method for allocating IP addresses and IP routing to slow the growth of routing tables on routers across the Internet, and to help slow the rapid exhaustion of IPv4 addresses. Routes in the AWS Transit Gateway route table will not be propagated to the Amazon VPC’s route table. Amazon VPC owner need to create static route to send Traffic to the AWS Transit Gateway.*
* excerpt from TGW FAQ found here: https://aws.amazon.com/transit-gateway/faqs/
A couple important things to pay attention to here – “routes will propagate between the AWS Transit Gateway and your on-premises router using Border Gateway Protocol (BGP)”… This also means that routes will propagate between the AWS TGW and your VMware Cloud on AWS SDDC using BGP.
Also – “Routes in the AWS Transit Gateway route table will not be propagated to the Amazon VPC’s route table.”
AND we know that the route table(s) for the TGW will be updated with the networks for each environment, then we need to inject the default route into the appropriate place in the Transit Gateway route table.
You can use a default configuration for your Transit Gateway, or create unique route tables for each attachment. Either way, a route of 0.0.0.0/0 needs to be added to the route table associated with the attachment running from the TGW to the security VPC – so it will propagate to the on-prem datacenter and the SDDC through BGP.
Even if your target AWS / VMC environment looked like the following…
… the default route of 0.0.0.0/0 simply needs to be added to the Transit Gateway Route Table for the Attachment leading to your egress point / VPC. If your egress firewall is in VPC A above, the default route must be added to the Transit Gateway Route Table for the attachment leading to VPC A. If your egress firewall is in the Security VPC above, the default route must be added to the Transit Gateway Route Table for the attachment leading to the Security VPC, et cetera.
In Part 3, we will put this all together and show you exactly how it all works.
My Occasional IT Blog... 