Cisco ACI Multi-Site Service Integration
Starting in Release 1.2(1), there are many variants of service graph deployment in single ACI fabric. For Cisco ACI Multi-Site deployment, not all use cases are supported in current release. Supported uses are mentioned below in the document.
To support the use cases mentioned below, following topology is required for service nodes for all the use cases.
-
Each site has individual Active/Standby Service Node pair.
-
Layer 4 to Layer 7 devices are in unmanaged mode.
-
Policy based redirect (PBR) policies are required to redirect traffic to service nodes.
Supported Use Cases
East-West Intra-VRF/Non-Shared Service
This is the use case for east-west communication between endpoints in the same VRF instance across sites. EPG WEB and EPG APP are deployed across sites and the firewall (FW) needs to be inserted between them. This is a common design for traffic within the application.
Requirements:
-
Policy-based redirect (PBR) policies are required on the consumer and provider connectors of the service node.
-
Provider EPGs should have the subnet defined under it and should be unique (similar to intra-VRF route leaking). This is to ensure that the first packet does not reach to the provider's leaf switch without the policy being applied, as you want the traffic to select the service node in the consumer site always. The policies are always applied on the consumer's leaf switch. For this purpose, provider's subnet would be leaked to consumer's leaf switch.
-
Redirect policies are always applied on the consumer leaf switch, which means the FW device cluster chosen will always be local to the site of the consumer for traffic flows.
The figures below shows the example for traffic from EPG WEB to EPG APP and vice versa.
East-West Shared Service
This is the use case for east-west communication between endpoints in the different VRFs across sites. The figures shows the example, EPG WEB in VRF1 and EPG APP in VRF2 are deployed across sites and firewall needs to be inserted between them. This is a common design for the shared service use case. For example, the NFS service is shared to multiple servers in different VRFs.
Requirements:
-
PBR policies are required on the consumer and provider connectors of the service node.
-
Provider EPGs should have the subnet defined under it and should be unique (similar to intra-VRF route leaking). This is to ensure that first packet does not reach to the provider’s leaf switch without the policy being applied, as you want the traffic to select the service node in the consumer site always. The policies are always applied on the consumer’s leaf switch. For this purpose, provider’s subnet would be leaked to consumer’s leaf.
-
Redirect policies are always applied on the consumer leaf, which means the firewall (FW) device cluster chosen will always be local to the site of the consumer for traffic flows.
North-South Intra-VRF/Non-Shared Service
This is the use case for north-south communication between endpoints in the datacenter and outside. Each site has L3out accessing to EPG WEB that is deployed across sites and the firewall needs to be inserted between them. This is a common design for the web front-end that is accessible from client outside of the data center.
Requirements:
-
Both L3Out and EPG-WEB are same VRF.
-
VRF needs to be in ingress mode (which is by default). In egress mode does not work, because of asymmetric traffic flow.
-
PBR policies are needed on both connectors of the service graph.
Limitations
In Multi-Site deployments, when the contract is deployed with a service graph, Scope of the contract should be defined in such a way so that all providers are in the same scope. This creates single graph instance for all the providers.
In Release 1.2(1), Multi-Site does not support handling multiple graph instances created due to provider being in a scope that is bigger than contract scope. While deciding on the contract scope note the following:
-
If all the providers are in a single VRF, contract scope can be set to any available option.
-
If providers are in multiple VRFs, but in a single Tenant, scope should be set to “Tenant”.
-
If providers are in multiple tenants, this scenario is not supported with a single contract.
To overcome this limitation multiple contracts can be created with the same service graph attached.