Enhance Dynamic BGP support with remote-as-filter (7.4.5+) and allow Spoke-to-Hub shortcuts #29
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the following changes:
Use
remote-as-filter
to generate a unified neighbor-group DYN_EDGE on the Spokes, ready to accept dynamic BGP sessions from all the regions (IBGP and EBGP). This replaces the earlier method (generating a separate neighbor-group per region on all Spokes)Add a new optional variable
spoke2hub_advpn
(global or per-profile) to support Spoke-to-Hub shortcuts in multiregional deployments. When enabled, we will generate the neighbor-group DYN_EDGE also on the Hubs (using theremote-as-filter
as well), to accept dynamic EBGP sessions from remote Spokes. We will advertise the regional LAN summary, as well as Hub's LAN over this session.The route-map-out used on external peering in the multiregional deployment is renamed from "HUB2HUB_OUT" to "REGION_OUT", and it is now applied not only to the Hub-to-Hub peering, but also to the new DYN_EDGE peering on the Hubs (for the Spoke-to-Hub shortcuts).
When generating the neighbor-range on the Hubs (for the local IBGP sessions), we now prefer to use the local regional summary (if configured), rather than the global lo_summary. If the regional lo_summary is not configured (in a single-regional deployment), we will keep using the global lo_summary as before.