Explains Cisco ACI remote leaf architecture, requirements, traffic forwarding, failover, and resiliency, and provides guidance for configuring and verifying remote leaf deployments.
This chapter contains the following sections:
Remote leaf switches in the ACI fabric
Remote leaf switches extend ACI services and APIC management to remote data centers. These switches operate as part of an existing fabric pod without requiring local spine switches or APIC controllers.
Remote leaf switch hardware requirements
Identifies the supported hardware components for the remote leaf switch feature, including specific spine switches for the main data center and requirements for remote leaf switch models.
Remote leaf switch restrictions and limitations
Remote leaf switch restrictions and limitations identify the guidelines, supported features, and configuration limitations that apply to remote leaf switches in the fabric. These constraints help ensure connectivity and traffic forwarding between the main data center and remote locations.
WAN router and remote leaf switch configuration guidelines
WAN routers and remote leaf switches must meet specific configuration requirements before remote leaf discovery and incorporation into Cisco Application Policy Infrastructure Controller (APIC) management. These requirements help ensure connectivity and fabric integration for remote leaf deployments.
Configure the pod and fabric membership for remote leaf switches using the GUI
Use this configuration to enable Cisco Application Policy Infrastructure Controller (APIC) to discover the inter-pod network (IPN) router and remote leaf switches. This configuration establishes fabric membership and connectivity for remote network segments.
Direct traffic forwarding
Direct traffic forwarding enables remote leaf switches to forward traffic directly across remote locations. Feature support, default behavior, and configuration workflows depend on the software release running on the remote leaf switches.
Remote leaf switch failover and hardware requirements
Remote leaf switch failover provides pod redundancy in a Multi-Pod deployment. When a remote leaf switch loses connectivity to the spine switch in its associated pod, the switch can move to another pod to maintain connectivity. Remote leaf deployments also require supported fabric spine switches, remote leaf switch models, and software images.
Remote leaf resiliency
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.
Create remote leaf resiliency group using the GUI
Configures a remote leaf resiliency group within the fabric using the GUI. This process involves defining the group name and associating a TEP pool to group remote leaves.
Verify remote leaf resiliency configurations by using the CLI
Use this procedure to verify the BGP L2VPN EVPN, VPNv4, and VPNv6 sessions on each switch in a remote leaf resiliency group. Successful verification confirms full-mesh connectivity among the remote leaf switches.
Verify endpoint-to-endpoint communication by using the CLI
Use this procedure to verify endpoint-to-endpoint communication by checking local and remote endpoint entries in the system components. This verification confirms endpoint learning and reachability in a stretched EPG environment.
Verify L3Out-to-L3Out communication by using the CLI
Use this procedure to verify L3Out-to-L3Out communication by checking the BGP VPNv4 routing table and IP route information.
Prerequisites for downgrading remote leaf switches
Before you downgrade remote leaf switches, remove the remote leaf infrastructure policies and decommission the remote leaf nodes. These prerequisites help prevent configuration conflicts when you downgrade to a software release that does not support the remote leaf feature.