Network Service integration with Cisco ACI Multi-Pod || Part#5

Introduction

Cisco ACI offers the capability to insert Layer 4 to Layer 7 services, for example, firewalls, load balancers, and intrusion prevention systems (IPSs), Similarly, you can integrate service nodes with Cisco ACI Multi-Pod fabrics, using the available deployment options, while the integration options can depend on the chosen design.

ACI and Network Service Integration Types:

• Using Manual configuration of bridge domains and EPGs
• Using the service grpah with device package
• Using service grapgh in unmanaged mode

Service Node Operation Mode while integrating with Cisco ACI:

Transparent (L2 Mode)

• Routed as default gateway for all end points
• Routed with L3Out peering
• Routed with PBR

Service Node Deployment models:

• Active-Active service node cluster stretched across separate pods
• Active-Standby service node stretched across sepate pods
• Indepedent active-standby service node pair per each pod

Now let's dig into details of each one of the deployment models available:

1. Active-Active service node cluster stretched across separate pods: This deployment model takes the name of “Split spanned Ether-channel” and ensures that all the nodes of the cluster “own” the same MAC/IP values so that the stretched firewall cluster appears as a single logical entity to the ACI Multi-Pod fabric. This deployment model removes any concern of creation of asymmetric traffic paths for both east-west and north-south traffic flows, as traffic will be dynamically redirected to the specific firewall node owning the connection state for that specific traffic flow. This option requires “anycast service” and PBR.

2. Active-Standby firewall pair stretched across pods: In This option can be applied to both north-south and east-west traffic flows. Pros: This option doesn't allow the creation of asymmetric traffic path that lead to communication drops. Cons: because there is a single active service noe in the multi-pod fabirc, so it introduces some inefficient traffic path because some traffic will hair-pin across the interpod (IPN), So bandwith between pods need to be consdiered will as well as latency in this design.

3. Indepedent active-standby service node pair per each pod:

This model mandates that symmetric traffic flows through the service nodes be maintained because the connection state is not synchronized between independent nodes. This requirement can be achieved with the following approaches:

• Use symmetric policy-based routing (PBR) with service nodes that are deployed in routed mode only, for both north-south and east-west security policy enforcement (recommended approach).
• If deployment of symmetric PBR is not possible, in the specific case of perimeter firewall deployments (only for north-south traffic flows), it is necessary to keep ingress and egress traffic flows optimized and symmetric. This can be achieved by enabling granular host-route advertisement toward the external Layer 3 domain to ensure that ingress traffic paths are always delivered in the “desired pod” where the destination endpoint is connected.

Summarized Table for Service Nodes deployment option with ACI Multi-Pod: