Mixed deployment
Backward compatibility between the new RR-less Dynamic BGP design and the more traditional RR-based design relies on the standard behavior of the IBGP protocol: IBGP automatically readvertises prefixes between the RR-clients and non-clients.
We can therefore split the Dial-Up BGP configuration on the Hubs into two different neighbor-groups:
-
One neighbor-group will be used for the Spokes with the Dynamic BGP feature configured. The BGP RR will be disabled on this group.
-
Another neighbor-group will be used for the Spokes without the Dynamic BGP feature. The BGP RR will be enabled on this group.
The following diagram illustrates the route exchange between two Spokes using the two different ADVPN support methods:
-
Both Spokes advertise their LAN prefixes to the Hub using IBGP.
-
The LAN prefix 10.0.2.0/24 is reflected to "site1-1" (non-client to RR-client), and the LAN prefix 10.0.1.0/24 is reflected to "site1-2" (RR-client to non-client).
-
When an ADVPN shortcut comes up, no dynamic BGP session is established, because Dynamic BGP is not configured on "site1-1".
-
However, both sides recursively resolve the BGP NH of the remote LAN prefix through the shortcut, thanks to the /32 loopback route injected by IKE (the
exchange-ip-addrv4feature).
In other words, both Spokes use the traditional RR-based mechanism to recursively resolve the routes' next-hops through the shortcuts.
At the same time, "site1-2" can use Dynamic BGP to communicate to other Spokes that have Dynamic BGP enabled. Similarly, "site1-1" can use the traditional mechanism to communicate to other Spokes that do not have Dynamic BGP enabled.
In summary, any Spoke-to-Spoke connectivity is possible in this mixed deployment.