Default Route in VMC on AWS – Part 1

But wait – I thought there are no static routes in VMC on AWS?

And you would be right… there are no static routes in VMC on AWS at this time.  That means you do not have the ability to log into VMC on AWS and manually configure a static route for the environment.  However – that does not mean you can’t influence / manipulate the routes at all.

First things first – if you haven’t already reviewed my colleague’s post on networking in VMC on AWS – please do so here:

RunVMC – VMC on AWS NSX Networking

Or you could get the book Nico and Gilles wrote on the subject –

• VMware Cloud on AWS: Networking and Security
  • Gilles Chekroun – Gilles Cloud – VMC on AWS eBook
  • Nico Vebert – RunVMC – VMC on AWS eBook

… The point is, this post will not review the architecture of networking and security for VMC on AWS here.

Briefly put, the VMC on AWS SDDC will learn about routes from other environments through BGP advertisements.  Whether you connect your SDDC to another environment through IPSec VPN or through Direct Connect (DX), the route tables for VMC on AWS will be built by learning about those other environments, rather than through a manually-built route table.  So, how does one ensure routes take the path you most desire?  The answer, of course, is simple – you have to advertise them.

This may seem self-evident, but those of you who may have worked with AWS previously know that while the answer is simple, implementation may become complex.

Take the following diagram:

This is actually based on a real customer scenario I ran into this past spring – we used Palo Alto firewalls running as EC2 instances in the “Security VPC” – you can find the entire setup guide for PAN in such a scenario here.

Looks straightforward enough, right?  In the diagram above, we are placing a pair of highly available firewall instances in the “Security VPC” – therefore, it follows we will desire any internet traffic to traverse the firewall for inspection on ingress or egress… furthermore, we desire the Internet Gateway in the Security VPC to be the default route out of the environment.

This type of solution has been well vetted with a “Transit VPC” previously – however a Transit Gateway presents an opportunity to dramatically simplify a Transit VPC architecture – for a thorough discussion of Transit VPC architecture, please see Nico’s blog at RunVMC here: https://nicovibert.com/2019/07/02/aws-transit-vpc/

Similar to a Transit VPC architecture, you must manipulate routing tables to achieve the desired result.  Specifically, if it is not already evident, the following things must occur in the diagram above to ensure the default route (0.0.0.0/0) is advertised appropriately:

1. The default route must not be advertised from either the on-prem datacenter or VPC1 (in the diagram above).
   1. This may be difficult by itself – clearly this requires a thorough discussion with your networking team to ensure 0.0.0.0/0 is not advertised over your DX or VPN to the TGW.
   2. If your company owns the line / connection to the TGW, then you have control over it.
   3. If you are using a 3rd party (see this link for a list of AWS Direct Connect partners), you will have to work with them.  In my experience, they usually have limited options for what and how they advertise routes over their leased lines… Verizon, for example, may allow you to use BGP Community tagging to flag which networks are advertised.
2. The default route will have to be manually injected somewhere into the AWS routing infrastructure to ensure it is advertised appropriately to the VMC on AWS SDDC.

Essentially, you are going for something like this:

** learned routes

You will note I have not really addressed the use case for routing out of VPC1 to the internet – that is beyond the scope of this article.

In the diagram above, any network flagged with “**” is either learned or set automatically for you.  Note that the routing tables associated with the Security VPC are largely set manually, while those for the VMC SDDC are all learned routes.  This is significant – for although there is clearly more work for the networking team, the model above largely constrains the additional effort to the routing tables associated with the Security VPC and the TGW – very little else needs to be done for the cloud environment.

In my next post – Default Route in VMC on AWS – Part 2 – I will focus on exactly how these route tables are built.