New and Changed Information
Cisco APIC Release Version |
Feature |
Description |
---|---|---|
3.2(1x) |
Anycast Service Support |
Anycast services are supported in the Cisco ACI fabric. A typical use case is to support ASA firewalls in the pods of a multipod fabric, but Anycast could be used to enable other services, such as DNS servers or printing services. |
About Anycast Services
Anycast services are supported in the Cisco ACI fabric. A typical use case is to support Cisco Adaptive Security Appliance (ASA) firewalls in the pods of a multipod fabric, but Anycast could be used to enable other services, such as DNS servers or printing services. In the ASA use case, a firewall is installed in every pod and Anycast is enabled, so the firewall can be offered as an Anycast service. One instance of a firewall going down does not affect clients, as the requests are routed to the next, nearest instance available. You install ASA firewalls in each pod, then enable Anycast and configure the IP address and MAC addresses to be used.
APIC deploys the configuration of the Anycast MAC and IP addresses to the leaf switches where the VRF is deployed or where there is a contract to allow an Anycast EPG.
Initially, each leaf switch installs the Anycast MAC and IP addresses as a proxy route to the spine switch. When the first packet from the Anycast Service is received, the destination information for the service is installed on the leaf switch behind which the service is installed. All other leaf switches continue to point to the spine proxy. When the Anycast service has been learned, located behind a leaf in a pod, COOP installs the entry on the spine switch to point to the service that is local to the pod.
When the Anycast service is running in one pod, the spine receives the route information for the Anycast service present in the pod through BGP-EVPN. If the Anycast service is already locally present, then COOP caches the Anycast service information of the remote pod. This route through the remote pod is only installed when the local instance of the service goes down.
Guidelines and Limitations for Anycast Services
Follow these guidelines and limitations when configuring and using Anycast services:
-
Anycast is supported on Cisco Nexus 9000 Series switches with model numbers that end in EX, and later (for example, N9K-C93180LC-EX).
-
Up to 2000 Anycast services are supported per fabric.
-
A service node is used for Anycast services in the pod where the policy is applied.
-
Prior to the 4.1 release, you must disable the IP aging policy.
-
Anycast can be configured on application EPGs or through Layer 4 to Layer 7 Services (with or without Policy-Based Redirect (PBR)). For the "without PBR" use case, the traffic must be routed on Cisco Application Centric Infrastructure (ACI) fabric.
Note
Routed traffic in this case means the leaf switch routes traffic to an Anycast IP/MAC. Bridged traffic means that the switch leaf performs Layer 2 forwarding, based on the destination MAC. For example, if the consumer endpoint and firewall with Anycast service are in the same bridge domain, and the firewall is a gateway of the consumer endpoint, it is Layer 2 forwarding on Cisco ACI.
-
You can use PBR with Anycast services starting with the Cisco Application Policy Infrastructure Controller (APIC) release 3.2(4) with the following considerations:
-
A PBR service node that is used for Anycast services must not be the consumer or provider bridge domain. The consumer and provider bridge domain can be the same.
-
An inter-VRF contract cannot be used if vzAny consumes the contract.
-
Anycast services are not supported with the following features and options:
-
Cisco ACI Multi-Site management
-
Remote leaf switches
To use Anycast service, you must meet the following considerations about service nodes:
-
The service nodes must be connected to bridge domains, not L3Outs.
-
The service nodes must act as one logical device providing the same IP/MAC and connection handling.
-
The service node must not have duplicate IP detection capability.
-
If the service node is a two-arm design, the service device must be able to bring down the interface if the other side is down.
-
In each pod, all local service nodes (member of one service) must be connected to the same single leaf pair (vPC).
-
The Anycast IP and MAC must not be an existing static endpoint.
Note |
If you configure an Anycast MAC and IP address using the addresses for an existing static endpoint, the configuration is pushed from the Cisco APIC to the switch and no fault is generated, but the switch does not install the Anycast addresses in the hardware. Deleting the static endpoint does not resolve the problem. You must delete both the static endpoint and the Anycast configurations and reconfigure the Anycast addresses. |
The following functions for traffic load-balancing to individual service nodes are not required for Anycast services:
-
ECMP
-
Symmetric policy-based redirect
-
Pod ID Aware Redirection
-
IP SLA Monitoring Policies
-
Redirect Health Groups
Configuring Anycast Services Using the GUI
There are three ways to configure Anycast services using the Cisco APIC GUI:
-
Anycast Service Behind an EPG Subnet
-
Anycast Service as part of a Layer 4 to Layer 7 Service Graph with Policy-Based Redirect (PBR)
-
Anycast Service as part of a Layer 4 to Layer 7 Service Graph without PBR
Before you begin
-
The tenant, application profile, and application EPG have been created.
-
The node group and L3Out policies have already been created.
-
The Interpod Network (IPN) is already configured.
-
Multipod is configured.
-
In each pod, the spine switch used to connect to the IPN is also connected to at least one leaf switch.
-
ASA firewalls are installed in each pod.
Procedure
Step 1 |
For an Anycast Service behind an application EPG subnet, perform the following steps:
|
Step 2 |
For an Anycast Service in an L4-L7 service graph with PBR, perform the following steps: |
Step 3 |
For an Anycast Service in an L4-L7 service graph without PBR, perform the following steps:
|
Configuring Anycast Services Using the NX-OS Style CLI
These examples show how to configure Anycast services in three methods, using the NX-OS style CLI:
-
Behind an EPG.
-
As part of a Layer 4 to Layer 7 Service Graph with Policy Based Redirect (PBR)
-
As part of a Layer 4 to Layer 7 Service Graph without PBR
Before you begin
-
The tenant, application profile, and application EPG have been created.
-
The node group and L3Out policies have already been created.
-
The Interpod Network (IPN) is already configured.
-
Multipod is configured.
-
In each pod, the spine switch used to connect to the IPN is also connected to at least one leaf switch.
-
ASA firewalls are installed in each pod.
Procedure
Step 1 |
Configure Anycast services behind an EPG subnet, using the following commands: |
Step 2 |
Configure Anycast for Layer 4 to Layer 7 services with PBR, using the following commands: |
Step 3 |
Configure Anycast for Layer 4 to Layer 7 services without PBR, with the following commands: |
Example
The following example configures Anycast services behind EPG1:
apic1# configure
apic1(config)# tenant anycast1-it
apic1(config-tenant)# application AP0
apic1(config-tenant-app)# epg epg-1
apic1(config-tenant-app-epg)# endpoint ip 1.2.3.4/32 anycast 00:11:22:33:44:55
The following example configures Anycast services in a Layer 4 to Layer 7 service redirection policy:
apic1# configure
apic1(config)# tenant t1
apic1(config-tenant)# svcredir-pol N1Ext
apic1(svcredir-pol)# anycast enable
apic1(svcredir-pol)# redir-dest 2000::25 00:00:00:00:00:07
The following example configures Anycast services in a Layer 4 to Layer 7 service without PBR:
apic1# configure
apic1(config)# tenant t1
apic1(config-tenant)# l4l7 graph WebGraph contract default
apic1(config-graph)# service N1
apic1(config-service)# connector provider
apic1(config-connector)# subnet-ip 50.50.50.50/32 subnet-ctrl no-default-gateway
apic1(config-subnet-ip)# mac-address 00.00.00.00.00.50
Configuring Anycast Services Using the REST API
These examples show how to configure Anycast services in three methods:
-
Behind an EPG.
-
As part of a Layer 4 to Layer 7 Service Graph with Policy Based Redirect (PBR)
-
As part of a Layer 4 to Layer 7 Service Graph without PBR
Before you begin
-
The tenant, application profile, and application EPG have been created.
-
The node group and L3Out policies have already been created.
-
The Interpod Network (IPN) is already configured.
-
Multipod is configured.
-
In each pod, the spine switch used to connect to the IPN is also connected to at least one leaf switch.
-
ASA firewalls are installed in each pod.
Procedure
Step 1 |
To configure Anycast services behind an EPG, send a post with XML such as the following example: Example:
|
Step 2 |
To configure Anycast services as part of a Layer 4 to Layer 7 service graph with PBR, send a post with XML such as the following example: Example:
|
Step 3 |
To configure Anycast services as part of a Layer 4 to Layer 7 service graph without PBR, send a post with XML such as the following example: Example:
|