common concepts

• L4-7 service insertion common concepts
• service function(s)
• Service Type: firewall, ADC.

service device

• L4-7 Logical Device aka L4-7 Cluster Device, is composed of Concrete Devices, has a relationship with the Service Type, has L4-7 Service Device Interfaces aka cluster Interfaces; consumer-side interfaces and provider-side interfaces.
• Service Bridge Domains

service graph

• Service Graph management modes
• Service Graph template: used in Standard Service Graphs and in Service Graph Redirects (PBR)

multi-node service insertion with service graphs

• failover traffic management
• active-active firewall cluster:
  • L1, L2 or go-through mode: not supported
  • go-to mode:
    • active-active firewall cluster in multi-site design
    • active-active firewall cluster in single-pod and multi-pod designs
• active-standby firewall cluster:
  • in ACI single-pod designs
    • go-to mode
  • in ACI multi-pod designs
    • with VRF sandwich and L3Outs
    • go-to mode
  • in ACI multi-site designs
    • with Standard Service Graphs
    • with Service Graph Redirect

aka Network Stitching. This is the manual method to insert L4-7 services; VLANs, EPGs and bridge domains are manually created, and EPGs are manually assigned to the L4-7 device interfaces, statically with Static Path Binding or dynamically with a VMM domain. If we have to insert more than one L4-7 device, repeat the above process as much as there are devices to integrate.

L4-7 device vs L4-7 Device

An L4-7 device in the manual stitching context is one firewall, one ADC, etc. A L4-7 Device in Service Graphs is the Logical Device, which might contain one or more Concrete Devices.

If I configure the IP default gateways of the (Provider, Consumer) pair on ACI and attach an L4-7 Device to ACI, IP routing traffic involving the (Provider, Consumer) pair will bypass the Service Device due to routing in ACI itself. To circumvent that, there are three known methods to force traffic toward the L4-7 Device.

Method 1: NAT on the L4-7 Device

Method 2: SGR (no NAT on the L4-7 Device)

Method 3: VRF Sandwich and L3Outs

No NAT on the L4-7 Device.

These are common concepts for Standard Service Graphs and Service Graph Redirects. Service Graph with L4-7 Device in Go-To mode == L3 Service Graph. L4-7 Device in Go-To mode and the SGT has PBR enabled == L3 PBR Node.

Concepts

L4-7 Service Graph

A Service Graph requires the existence of one or more [[ACI Contracts|Contract]]s between a (Provider, Consumer) pair, whether they are EPGs or ESGs. Service Graphs are extensions of ACI Contracts; They leverage the concept of Provider EPG and Consumer EPG. Instead of manual stitching of L4-7 services, ACI can manage service devices just like it manages network policies, including automatic provisioning and removal of services when needed. Service Graph is a concept. requires the Service Graph Template

Stretched HA Firewall

Cisco supports a stretched Active-Standby firewall system if:

• ACI operates in layer 2,
• the firewall operates as the IP default gateway for the endpoints or the firewall operates in Transparent mode or the active and standby nodes are connected with an L3Out.

Independent HA Firewalls

If I have to deploy Active-Standby Firewalls, Cisco recommends to deploy them as independent HA firewalls in the ACI sites (i.e. not across the intersite link)

One concrete device per firewall –> 2 concrete devices under the L4-7 device.

If I have a two-arm firewall design: For all Concrete Devices within a L4-7 Device I must map all Concrete Interfaces of the same direction to the Cluster Interfaces ( #PersoNote symmetrical interface mapping):

• add one Cluster Interface for the Consumer side and associate it with all Consumer-side interfaces of all [[#Concrete Device]]s,
• add one Cluster Interface for the Provider side and associate it with all Provider-side interfaces of all [[#Concrete Device]]s.

If I have a one-arm firewall design: add one Cluster Interface that includes both Concrete Interfaces of the firewalls. #verifyThis

Failover traffic is not managed by L4-7 Service Graphs

See the document ACI Service Graph Design Guide for ACI 5.2 and Later.pdf, page=50.

With the ‘out-of-band’ method

Use the dedicated firewall failover link ports and firewall stateful failover link ports, or designate some ports for that role; Failover traffic and stateful failover traffic are said to be managed ‘out-of-band’

With the ‘in-band’ method

i.e. use the physical network of the data traffic for failover and stateful failover traffic too. When the firewall is attached to ACI, the physical network path of firewall traffic is the ACI fabric.

EPG-to-EPG PBR contract in ACI multi-site with independent HA-firewalls: I must define the BD subnet also under the consumer EPG and set the no Gateway SVI flag.

Contract Enforcement vs PBR Contract Enforcement vs PBR Policy Enforcement Contract enforcement == zoning rules are deployed to a leaf X. So leaf X takes action on the contract-matched traffic based on the deployed zoning rules. Leaf X is determined according to the Contract Policy Enforcement Locations table in the document ACI Contract Guide White Paper, page=20.

There are three ways to manage L4-7 services when we use service graphs. So if no service graph is inserted, we do not talk about these management modes!

[!Abstract] Unless otherwise specified, when Service Graphs are mentioned, then I am referring to the Unmanaged Mode.

Service Graph in Managed Mode (deprecated concept)

aka Service Policy mode: horizontal integration; requires a Device Package.

Device Package

adding a Device Package

[!TLDR] Personal Observation I find few sources discussing standard SG and more literature discussing SGR. It seems to me that Cisco is pushing toward SG with PBR whenever a design involves L4-7 Service Devices.

aka Service Graph with Policy-Based Redirect, Service Graph Redirect. I call it SGR. One-Node SGR: Service Graph with one PBR Node.

Concept of a multi-node Service Graph

the concept of node in the terms ‘single-node SG’ or ‘multi-node SG’ refers to the L4-7 Devices in the SG. So, the term ‘multi-node Service Graph’ refers to a Service Graph with multiple L4-7 Devices, where each L4-7 Device could be: