Remote leaf resiliency maintains traffic forwarding and endpoint learning within a group of remote leaf switches during WAN or main pod connectivity failures. The feature uses local BGP EVPN mesh sessions between remote leaf nodes to improve network availability.
Remote leaf resiliency is a deployment model that enables a group of remote leaf switches to maintain local control-plane and data-plane operations independently of the main pod.
-
Establishes fully meshed BGP EVPN sessions between the remote leaf switches in the group.
-
Exchanges endpoint and external prefix information locally.
-
Maintains traffic forwarding during WAN or main pod connectivity failures.
Remote leaf resiliency operational details
Remote leaf resiliency provides the following capabilities:
-
Establishes local, fully meshed BGP EVPN sessions within the remote leaf resiliency group to support endpoint learning.
-
Establishes fully meshed VPNv4 and VPNv6 sessions within the remote leaf resiliency group to distribute L3Out external prefixes.
-
Uses endpoints learned through BGP EVPN within the remote leaf resiliency group for data forwarding.
-
Uses endpoints learned through COOP between remote leaf sites and the main pod.
The following limitations apply to remote leaf resiliency groups:
-
You cannot configure a remote leaf TEP pool in more than one remote leaf resiliency group.
-
You cannot configure remote leaf TEP pools from different pods in the same remote leaf resiliency group.
Perform migration to or from a remote leaf resiliency group during a maintenance window.
Remote leaf architecture challenges
The current remote leaf architecture depends on the spine switches in the main pod for APIC connectivity and control-plane and data-plane operations.
This architecture has the following constraints:
-
Remote leaf endpoint (EP) learning depends on the control plane associated with the main pod.
-
Remote leaf L3Out external prefixes depend on the BGP configuration associated with the main pod.
-
A loss of connectivity to the spine switches in the main pod can disrupt traffic forwarding on remote leaf nodes.
Remote leaf resiliency
Remote leaf resiliency uses a group of multiple remote leaf switches. After the group is created, the remote leaf switches form fully meshed BGP EVPN sessions to exchange endpoint and external prefix information. A WAN or main pod failure does not affect traffic within the remote leaf resiliency group.
In a remote leaf resiliency deployment, the remote leaf switches in the group communicate by using a standards-based BGP EVPN approach instead of a Cisco proprietary protocol.
Remote leaf resiliency provides the following capabilities:
-
Establishes local, fully meshed BGP EVPN sessions within the remote leaf resiliency group to support endpoint learning.
-
Establishes fully meshed VPNv4 and VPNv6 sessions within the remote leaf resiliency group to distribute L3Out external prefixes.
-
Uses endpoints learned through BGP EVPN within the remote leaf resiliency group for data forwarding.
-
Uses endpoints learned through COOP between remote leaf sites and the main pod.
Perform migration to or from a remote leaf resiliency group during a maintenance window.
Remote leaf resiliency group limitations
The following limitations apply to remote leaf resiliency groups:
-
You cannot configure a remote leaf TEP pool in more than one remote leaf resiliency group.
-
You cannot configure remote leaf TEP pools from different pods in the same remote leaf resiliency group.