7.2 Multi Region Deployment - LAN and Loopback Summaries - Reasoning for LAN summaries

[mavbig]

Hi,

I have a question regarding the LAN summaries described in the wiki here: https://github.com/fortinet-solutions-cse/sdwan-advpn-reference/wiki/04-Overlay-Customization#lan-and-loopback-summaries

As I understand, every region needs to have their own lan summary address defined, so traffic between regions passes correctly. But are you assuming here that every topology/setup has all their hub and spokes networks within a region defined in a corresponding supernet?

Can this be modified to support just a redistribute between the BGP as per region? Because the hub learns all the routes from the connecting spokes, so it knows the networks, why not just announced it to the other hubs in the other regions?

Many thanks!

[dmitryperets]

Hi,

The downside would be a big number of routes. Essentially, all your Hubs and all your Spokes will have to learn all the individual prefixes from all the regions, without summarization. This is similar to how we would do it before Dynamic BGP, because inter-regional ADVPN required all the individual prefixes to be advertised end-to-end. So it is not worse than before, it's just that with Dynamic BGP we thought we could do better.

But I see your point... Not always you can summarize the LAN networks so nicely. We can add this as an option - for example, if no lan_summary is defined, then we simply let BGP readvertise the routes. Would that make sense?

[mavbig]

Hi, yeah I see the point, but I guess it's manageable if you only announce the summary addresses of the spokes, for example:

Spoke LANs: 10.10.10.0/24 10.10.20.0/24 10.10.30.0/24

Then announce blackhole route 10.10.0.0/16 to the Hub, so in the end there is only one route per spoke, which in terms of routing table entries/size is quite reasonable in my opinion to distribute between the regions.

To add this to the template would be quite nice I think, at least from what I see in our customer networks. I'm just thinking about the needed change to achieve this, it should just work by adjusting the route map and the policy routes for the stickiness I guess

[dmitryperets]

Hi,

Effectively, we can achieve the requested behavior by simply removing the route-map-out from the Hub-to-Hub tunnels. So everything will be advertised between the regions "as is".

I prefer to implement something a little bit more sophisticated, adding the following pieces:

• I will add some logic to avoid readvertising the prefixes down to the local Spokes. Since we are focusing on the Dynamic BGP design, we do not advertise specific LAN prefixes down to the Spokes anymore. So the Hubs will learn everything, but the Spokes really don't have to. And if we don't require the Spokes to learn from their fellow Spokes within the region, then it makes even more sense not to learn from the other regions.

• I will nevertheless add a route-map-out, to set a non-zero BGP MED to whatever the Hubs advertise to each other (over Hub-to-Hub peering). This will help to support Spoke-to-Hub shortcuts (their support is added in #29). When there is a Spoke-to-Hub shortcut, the Hub learns the LAN prefix both directly from the Spoke (via Dynamic BGP) and from the remote Hub (as per this request). Both routes will come from EBGP, and both will come from the same AS. So we'll need a MED to make sure that we prefer the one coming directly from the Spoke.

I hope the above makes sense. I'll do some testing and push it somewhere in October (after merging #29).