Advanced Design Considerations with Direct Connect with VMware Cloud on AWS : Filtering and Summarization

This blog post will provide additional design considerations around Direct Connect and VMware Cloud on AWS.

Make sure you read the first post on the Direct Connect concepts and integration with VMware Cloud on AWS and the second post on Direct Connect and VPN as a back-up.

I’m going to do a few of these posts. These are not random questions – every time a customer, partner or colleague asks the same question twice or thrice, I reckon it’s worth documenting the answer.

The first part will be on the routing topics below:

• How do I filter routes to/from VMware Cloud on AWS?
• How do I summarize routes to/from VMware Cloud on AWS?

Can I summarize routes with VMware Cloud on AWS over Direct Connect and BGP?

Short Recap on Routing Summarization

The process of summarizing routes in IP networking means reducing the number of network advertisements and the size of the routing table. It offers efficiency and routing convergence benefits.

As an example, it means that instead of advertising the 172.16.0.0/24 and 172.16.1.0/24 prefixes, a router can simply advertise 172.16.0.0/23 which would cover both subnets above and advertise a single route instead of 2. That reduces the network advertisement chatter and reduces the size of the routing table.

If a customer wanted to aggregate the 172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24 and 172.16.3.0/24 networks, he would summarize it in a 172.16.0.0/22.

A final example below reduces the number of routes advertised and present in the routing table from 8 down to 1 through summarization.

Before Summarization:	After Summarization:
172.16.0.0/24	172.16.0.0/21
172.16.1.0/24
172.16.2.0/24
172.16.3.0/24
172.16.4.0/24
172.16.5.0/24
172.16.6.0/24
172.16.7.0/24

I am simplifying here but hopefully you get the idea.

Can I summarize routes from VMware Cloud on AWS over Direct Connect?

Today, no, this option is not available on VMware Cloud on AWS yet.

Why does it matter in the context of VMware Cloud on AWS ? Well, we currently have a limitation where VMC can only advertise a limited set amount of prefixes over BGP from VMware Cloud on AWS to a remote router: 16 prefixes.

That does not include the four management networks that are advertised regardless (read more in the official docs).

Note this limitation is only from VMC to on-premises. From on-premises to VMware Cloud on AWS, we can receive up to 100 prefixes.

While this can be raised by opening a case with VMware, it won’t scale that high (AWS has a max limit of 100 routes advertised per VIF) and summarization will be essential (as you saw in the example above, it helps us reduce the number of subnets/prefixes we advertise).

Can I filter routes with VMware Cloud on AWS over Direct Connect and BGP?

Today, VMware Cloud on AWS does not allow prefix filtering in or out. Prefix filtering is not configurable yet.

This means:

• All the networks advertised by the on-premises routers are accepted by VMware Cloud on AWS.
• VMware Cloud on AWS advertises ALL networks to on-prem.

Why does it matter?

There might be a situation where you don’t want to advertise a VMC network to your on-premises infrastructure (because it’s a different business unit or possibly for segmentation or compliance reason).

Today, the VMware Cloud on AWS gateway would advertise all networks created on VMware Cloud on AWS and, unless the on-premises BGP router applies some kind of filtering, all routes will be received.

Equally, VMware Cloud on AWS does not filter any of the networks learned from the on-premises router over DX/BGP.

The work-around we would suggest today is to apply routing advertisement control on the on-prem router.

In a traditional Cisco and BGP terminology, it means applying a ‘prefix-list‘ or ‘route-map‘ to block network advertisement learned or advertised to VMware Cloud on AWS. For example:

prefix-list VMC-IN deny 10.3.20.0/24
prefix-list VMC-IN permit 0.0.0.0/0 le 32
router bgp 65001
  neighbor X.X.X.X prefix-list VMC-IN in

In the example above, the customer does not want on-premises VMs to access 10.3.20.0/24 (for example, because on-prem is Prod and 10.3.20.0/24 is Test/Dev).

By applying a prefix-list inbound denying this specific prefix on the BGP peering session to the VMware Cloud on AWS gateway, the on-prem router will not be able to reach 10.3.20.0/24.

Note the in in the configuration above refers to routes learned from VMC.

The “permit 0.0.0.0/0 le 32” is just a way to allow any other networks through (that’s another way to say ‘permit any any’ but for network prefixes).

I hope this was useful. Thanks for reading.