Guidelines and limitations for ACI border gateways

ACI border gateways support Cisco Nexus 9000 Series FX and later platforms that have 32 GB of RAM. FX2 platforms are not supported.

ACI border gateway functionality requires dedicated leaf nodes. ACI border gateway nodes cannot also function as border leaf switches for tenant L3Outs.

Cisco ACI forwards Layer 2 multicast traffic as broadcast, unknown unicast, and multicast (BUM) traffic.

In Cisco APIC Release 6.1(1), stretched VRFs must be in unenforced mode. Beginning with Cisco APIC Release 6.1(2), you can configure stretched VRFs in enforced mode and use endpoint security groups (ESGs) to apply security policies.

ACI border gateways support a single ACI fabric, which can be a Multi-Pod fabric. Beginning with Cisco ACI Release 6.2(1), multiple independent ACI fabrics can communicate through border gateways.

Beginning with Cisco APIC Release 6.1(2), you must assign the ACI fabric a unique site ID for the EVPN domain by using the vxlanSiteId configuration.

Before Cisco ACI Release 6.1(4), the VNIs for a bridge domain or VRF must be symmetrical across the Cisco ACI and Cisco NX-OS fabrics. Beginning with Cisco ACI Release 6.1(4), you can configure a normalized VNI for the remote EVPN fabric.

If the same IPN or ISN device supports both ACI Multi-Pod or Multi-Site connectivity and VXLAN intersite connectivity, isolate the networks in separate VRFs.

In Cisco APIC Release 6.1(1), stretched VRFs must use a non-VLAN-based Layer 3 VNI configuration. Beginning with Cisco APIC Release 6.1(2), you can configure an NX-OS Layer 3 VNI by using either a VLAN-based or non-VLAN-based configuration.

To use the ACI border gateway feature, all nodes in the fabric must run the same software version. For Cisco ACI Release 6.1(4), all nodes must run Release 6.1(4).

In each pod, select the same spine nodes as the internal route reflectors and the Multi-Pod spine nodes.

Back-to-back connections between a Cisco ACI VXLAN border gateway and a Cisco NX-OS border gateway are not supported.

Beginning with Cisco APIC Release 6.1(4), Cisco ACI advertises all endpoints that belong to a bridge domain in the VRF only if the bridge domain is stretched.

When you upgrade from Cisco APIC Release 6.1(1) to Release 6.1(4), configure the site ID, clear the existing faults, and wait for BGP to converge before you continue.

When you use load-balancer source network address translation (SNAT) without stretching the service bridge domain to a border gateway, place the load-balancer servers at the ACI site. Uplift the service EPG to a service ESG, and configure a contract between the internal leg and the provider SGT at the NX-OS site.

Beginning with Cisco ACI Release 6.1(5), changing a common data-plane tunnel endpoint (DPTEP) IP address across sites causes traffic loss. To restore traffic, reset the BGP EVPN session.

Beginning with Cisco APIC Release 6.1(5), assign each ACI fabric a unique site ID by using the vxlanSiteId configuration. Changing a common site ID causes traffic loss.

Cisco ACI tracks storm control statistics for each hardware slice. If multiple DCI links on the same slice connect to peer VXLAN EVPN fabrics, Cisco ACI reports the statistics on the DCI link that most recently came up.

Local proxy ARP responses are sent with the bridge domain SVI MAC address as the source. If the two fabrics use different values, endpoints in the stretched bridge domain resolve different gateway MAC addresses and traffic fails after a move between fabrics.

Local proxy ARP applies only to traffic for endpoints that the border gateway has learned locally. The border gateway does not perform local proxy ARP for traffic that transits it between two remote fabrics.

Beginning with Cisco ACI Release 6.2(3), if you configure a border gateway stretch for a VRF or bridge domain that Cisco Nexus Dashboard Orchestrator (NDO) already stretches through the spine-based ACI Multi-Site path, Cisco ACI accepts the configuration but does not activate the border gateway path. The border gateways do not exchange EVPN routes for that VRF or bridge domain, and traffic continues to use the spine-based ACI Multi-Site path. This is to prevent a loop through the stretched VRF and bridge domains.

The following features and configurations are not supported:

• SPAN with an ACL.

• An ERSPAN destination that is a local endpoint or prefix.

• The BGP route server model before Cisco ACI Release 6.2(2).

• Deployment of stretched VRFs or bridge domains on ACI remote leaf switches.

• Extension of bridge domains associated with microsegmentation EPGs.

• IGMP snooping and Layer 3 multicast across domains.

• Inter-VRF traffic flows before Cisco ACI Release 6.1(4).

• Advertisement of leaked routes to peers.

Cisco APIC Release 6.1(1) does not support ingress or egress route maps for EVPN peers. This support begins with Cisco APIC Release 6.1(2).

If a VXLAN EVPN domain is policy-unaware, policy-based redirect (PBR) supports only Layer 3 Go-To-mode devices connected to the ACI fabric.

Beginning with Cisco APIC Release 6.1(4), when an ACI fabric connects to a policy-aware remote VXLAN fabric running Cisco NX-OS Release 10.5(3), the ACI border gateway nodes ignore policy or class information received from the remote fabric.

Cisco ACI Release 6.1(4) and Cisco NX-OS Release 10.5(3) are the minimum supported releases for policy-aware interoperability.

An external subnet selector must be a supernet of the prefixes learned from the L3Out peer. Overlapping prefix selectors are not supported.

When you configure VRF route leaking for a VXLAN-stretched VRF, use the leak internal prefix option.

If you change the remote VNI of a bridge domain to match the remote VNI of the VRF and then revert the change, endpoints might be missing from the Council of Oracles Protocol (COOP) database. Reset the EVPN sessions to restore the endpoints.