It’s been a while since last post but recently I faced quite
nice challenge which I believe is worth sharing.
Problem statement
We have Aviatrix backbone created between 3 regions with 2 Transit GWs each. Of course good, well known full mesh transit peering is there, providing us the shortest path between spokes (which is a good thing in general) plus some resiliency if one path goes down. But what about the case where we have some external connections (some flat SDWAN network) which then injects the exact same more specific prefix (i.e. 10.1.1.0/24).
Ideally from GW1 perspective – Flow1 would provide us the best path (lowest latency as it stays in the same region. Flow2 on the other hand adds some latency to the traffic as it crosses the region. I’m not saying this is ideal design but there are circumstances which forced us to have it. Let’s try to fix it.
OPTION 1 - Exclude CIDRs
What we can do is to stop advertising prefixes learned from
all external connections towards all other regions. That should do the trick
but …
Is it scalable? Sure not – we need to specify every single prefix on individual transit peering link.
OPTION 2 - AS-PATH prepending
I’m not saying this is ideal solution but one advantage of using it is – do it once and it will be applied to all other prefixes.
Let’s take a look at the following diagram
- By default we do AS-PATH prepend x3
- Regional Transit GWs shouldn’t have prepending at all (0)
- In case of SDWAN failure in Region1 we want it to fallback to region 2 (by lowering prepending to 2)
HOW to do that?
Now here comes the question – how to do that? With IaC definitely
through Terraform right?
There is one amazing guy who wrote most of the Aviatrix TF modules – Dennis H. Long time ago he developed quite a decent module – mc-transit-peering
It builds full mesh transit peering in a very short manner by just executing the following code:
As smart as it is – it’s not that very flexible to achieve what we need. We could go for native resource for peering – “aviatrix_transit_gateway_peering” – but that would be quite a bit of coding and prone to mistakes.
I thought about making the module slightly better so here is what I was working on (with some Dennis’s help to address already deployed environments … – big THX Dennis I really appreciate it)
Quite neat way of achieving the same goal.
Take a look on GITHUB – I hope Dennis will approve the Pull Request and it will be available on official module soon.