Closed snofrar closed 2 days ago
dmitryperets
commented
3 days ago Hi,
Yes, you are right in your analysis.
There can be two solutions that I can think of:
dmitryperets
commented
3 days ago FYI the solution based on Dynamic BGP and ADVPN 2.0 (in release/7.4) is cleaner, so I would recommend it for multi-regional deployments going forward.
snofrar
commented
2 days ago Hi,
Thank you very much for your answer.
If you don't mind I would like to ask a couple of question to confirm them
Regarding Intraregion: if nets from site1-H1 need reacheability to nets of site1-H2, an ibgp can be established and also adding the set auto-discovery forwarder/sender/receiver, correct ?
Regarding Interregion: if it is expanded to more regions and each region with dual hub, although ebgp it is recommended a full mesh between all hubs or we can rely in the ibgp between hubs ?
I see that in advpn2.0 you don't establish dual ipsec tunnels interregion per bgp neighbor, is it because it overcomes previous issue ?
Best regards
dmitryperets
commented
2 days ago Regarding Intraregion: if nets from site1-H1 need reacheability to nets of site1-H2, an ibgp can be established and also adding the set auto-discovery forwarder/sender/receiver, correct ?
I don't think you need to enable auto-discovery-* on those Hub-to-Hub tunnels. We actually support it in Jinja: https://github.com/fortinet-solutions-cse/sdwan-advpn-reference/wiki/04-Overlay-Customization#hub-to-hub-tunnels-within-the-region
At the moment, we build IBGP and advertise strictly only the Hub LAN prefixes. To avoid using that peering for Spoke-to-Spoke communication (so we do not support a case when Spoke-1 loses all connection to Hub-1, while Spoke-2 loses all connection to Hub-2). I am planning to add an enhancement for this case, but only for the release/7.4 with Dynamic BGP.
Regarding Interregion: if it is expanded to more regions and each region with dual hub, although ebgp it is recommended a full mesh between all hubs or we can rely in the ibgp between hubs ?
We recommend full-mesh EBGP between regions, because it helps you to better handle routing loops. With IBGP it would be tricky, as you would need to do all the filtering manually (think of an advertisement REG1-Hub1 -> REG2-Hub1 -> REG1-Hub2... EBGP will automatically discard it, but IBGP won't..). Again, with release/7.4 and Dynamic BGP, it is now much more flexible, because you don't have to preserve BGP next-hops. So it allows us to go to even more complex topologies, in theory we can build any kind of topology between the regions. Although our Jinja doesn't go that far at the moment.
I see that in advpn2.0 you don't establish dual ipsec tunnels interregion per bgp neighbor, is it because it overcomes previous issue ?
ADVPN 2.0 abolishes the requirement to establish 1:1 mapping between Spoke-to-Hub and Hub-to-Hub overlays. So yes, you can have INET+MPLS for Spoke-to-Hub, but only MPLS for Hub-to-Hub - and you will still be able to build any shortcut between the regions - either over INET or over MPLS. No need for 1:1 mapping and no need for the overlay stickiness anymore. This - together with Dynamic BGP - makes multi-regional configuration much more flexible indeed.
snofrar
commented
2 days ago Hello
Thank you for these clear guidelines. Now all the pieces match
ADVPN2.0 improves shortcuts and also simplifies the config, it avoids 1:1 mapping and having the option to use RR allows customers to maintain certain bgp atributes.
Hub-to-Hub communication could be simplified also but as usually customers have the DC at these sites, a traffic steering between them is also needed and therefore a full mesh is still useful but without the complexity of 1:1
EBGP vs IBGP topic: taking into account that hub-to-hub neigbors are Non-Clients of a RR, it means that each hub will reflect all prefixes to the spokes (RR clients) and not to the rest of the hubs, avoiding rooting loops, a bigger picture of what is documented in SDWAN for Enterpresis, but I don't know if I am missing something....
Best regards
dmitryperets
commented
2 days ago EBGP vs IBGP topic: taking into account that hub-to-hub neigbors are Non-Clients of a RR, it means that each hub will reflect all prefixes to the spokes (RR clients) and not to the rest of the hubs, avoiding rooting loops, a bigger picture of what is documented in SDWAN for Enterpresis, but I don't know if I am missing something....
Depends on several things... If you don't need to support inter-regional ADVPN, then yes, no problem. If you need to support inter-regional ADVPN and you are on 7.2 (as in the linked article), then you have to preserve unchanged BGP next-hops end-to-end, also between the regions. Hence, you have to reflect also between the regions. Hence, you have problems with routing loops.
But if you do it on 7.4 with Dynamic BGP, then you don't have to reflect, and you could live also with IBGP. But maybe a better question to ask would be: "Why not EBGP?".
Anyhow, these questions might require a more tailored answer, depending on your specific project. Here in our Jinja Orchestrator we follow an approach which we consider the most unified and generic - that is, IBGP within the region and EBGP between the regions, with or without ADVPN.
Hello,
First of all congratulations for this amazing work.
I am testing the BGP On Loopback topology for 7.2 and I have noticed the following issue
If a first shorctut is establisedh between site1-1 and site2-H1 (traffic from spoke to another regional hub resources) when the site2-1 tries to reach site1-1 there is a packet loss (more than 20 seconds) because traffic goes site2-1 -> site2-H1 -> shortuct_to_site1-1 instead of going to the other regional hub.
After this timeout a shortcut is successfully established between site2-1 and site1-1
Could be possible to overcome this packet loss adding tag from Hub-to-Hub connection and enabling "tag-resolve-mode merge" in the hubs ?
Thank you and best regards