Technical highlights

• Adding or removing spokes does not require altering either the hub’s configuration (thanks to dial-up IPsec and BGP Neighbor Group features) or the configuration of the other spokes (thanks to the nature of hub-and-spoke topologies).
• IBGP sessions are terminated on the IPsec overlays, and hence, they are using the tunnel IPs as BGP next-hops (NH). This requires IP addresses to be configured on the tunnel interfaces. The hub can automatically allocate tunnel IPs to the spokes using the IKE Mode Config feature to simplify provisioning.
• Since the spokes establish separate IBGP sessions with the hub over each overlay, there are multiple BGP routes for each prefix. To keep all the routes available, the following two BGP features must be enabled on all participating devices (hub and spokes):
  • BGP Multipath ensures that all the available routes are installed into the routing tables
  • BGP ADD-PATH ensures that the hub between the spokes reflects all available routes
• For the correct operation of ADVPN, it is required to preserve all sites’ prefixes unchanged, including their original BGP NH values. Hence, it is impossible to replace the specific routes with summaries (unlike in a static hub-and-spoke topology). Hence, the BGP RR function is mandatory: The hub must reflect the original routes between the spokes without altering them.
• We have already mentioned the critical property of overlay stickiness that we must guarantee for proper ADVPN shortcut creation. For example, if spoke-1 sends traffic to spoke-2 using an internet overlay through the hub, the hub must select the same internet overlay for the second half of the path. Failing to preserve the overlay might result in an attempt to create an ADVPN shortcut between two physically disconnected transports (such as the internet and MPLS), and this attempt would, of course, fail. The overlay stickiness is achieved using Policy Routes (PBR) on the hub.