Security Service Insertion (SSI) is an upcoming SD-Access capability that Cisco is currently making available through early access programs. As Entek IT Solutions, we received early software access to validate SSI in a controlled lab environment and to understand what actually changes in the fabric once SSI is enabled.
This article is not a launch announcement or a feature datasheet summary. It’s a technical field note based on what we observed in our lab: how Catalyst Center programs the environment, what new state appears on the switches, how LISP represents the firewall as a service, and how traffic is steered and enforced end-to-end. The screenshots included throughout are taken directly from the lab while testing this early access software.
The lab and why it matters
The lab is a small but complete SD-Access fabric consisting of edge nodes, a border node, Cisco ISE, and a Cisco Secure Firewall integrated as a security service. The fabric is orchestrated by Catalyst Center 3.1.x, and while I’m running IOS-XE 17.18.x on the fabric nodes in this lab, SSI is expected to be supported from IOS-XE 17.17.1 onwards. These version boundaries matter, because SSI functionality and the associated switch-side policy constructs are not present in earlier trains.
All policy decisions in this setup are identity-based. Endpoints authenticate via ISE (or static port assignments including SGT’s), receive Security Group Tags (SGTs), and traffic is evaluated based on SGT-to-SGT policies rather than IP addressing. The firewall is integrated through the SSI workflow in Catalyst Center and is associated with a specific virtual network.
The screenshots included with this article directly reflect this lab. No configuration shown here is theoretical.
Catalyst Center and ISE: orchestration vs policy authority
One of the key takeaways from the lab is that Catalyst Center is not acting as an active control plane for SSI at runtime. Catalyst Center’s role is orchestration: it enables SSI on the fabric nodes, defines the firewall service association to the virtual network, and pushes the relevant policy constructs into ISE.
ISE is the system that actually becomes the policy authority for steering. After Catalyst Center provisions the intent, ISE shares the steering policy and related metadata with the switches, and the fabric nodes pull and maintain that state locally. In practice this is reflected on the switches through the new SSI-related “group-policy traffic-steering” operational views, which show the switch-side policy state and the connectivity status toward the policy server.
The result is a clean separation of responsibilities: Catalyst Center defines and provisions intent, ISE distributes policy, and the switches enforce in the data plane, without requiring manual CLI “glue” between components.
New policy constructs on the switches
Once SSI is provisioned, the effect becomes visible directly on the fabric nodes. The switches expose a new set of operational views under the group-policy traffic-steering commands, which did not exist before SSI. These views show that the switches are not simply executing static configuration, but are actively maintaining steering state received from an external policy authority.
In the screenshots, the policy server list clearly shows ISE as the active server, while Catalyst Center appears only as an inactive reference. This confirms the functional separation in the design: Catalyst Center provisions intent and enables SSI, but ISE is the system that distributes the steering policy to the switches.
The switch-side output also shows the downloaded environment data, policy identifiers, and redirect counters. These counters increase as traffic matches the SSI policy, which demonstrates that enforcement is happening locally on the edge node and not being deferred to another part of the fabric. There is no interface-level policy routing involved, the steering decision is applied as fabric state.
What is particularly important here is that this policy state is maintained independently by each relevant fabric node. Once the switch has learned the policy from ISE, it can make immediate forwarding decisions without consulting another control element at runtime. This becomes critical later in the flow, because it allows the ingress edge to redirect traffic directly toward the correct service without relying on intermediate reclassification or additional hops.
The firewall becomes a LISP service
When SSI is enabled, the firewall IP address is no longer “just” an IP on a transit network. It is installed in LISP as a service EID, associated with a specific virtual network, VRF, and border RLOC. The output clearly shows the firewall registered as a Service-ETR, complete with reachability state and locator information.
This means the firewall becomes a first-class object in the SD-Access control plane. The fabric does not need static routing tricks or redirection policies to reach it. LISP is configured to knows where the service lives and how to reach it.
What happens when traffic matches an SSI policy
Once traffic is generated by an endpoint, the behavior is notably different from earlier service insertion designs.
The ingress edge node evaluates the traffic based on the source and destination SGTs. If the traffic matches an SSI steering policy, the edge node immediately encapsulates the traffic toward the firewall service using LISP & VXLAN. It does not forward the traffic normally and does not rely on another edge node to “discover” the need for redirection later in the path.
This is where the registration of SGTs in LISP becomes critical. Because SGT information is now part of the fabric control plane, the first edge already knows where the policy-relevant service is located. There is no need for SXP, and there is no need for a second hop to reclassify the traffic.
The decision is made at the point of ingress by the Edge Node connected to the endpoint.
Border node forwarding behavior
When the encapsulated traffic reaches the border node, the behavior is straightforward and predictable. The packet is decapsulated and forwarded toward the firewall using the VRF and next-hop information that was already installed by LISP. The routing table and CEF outputs show a clean service next-hop pointing to the firewall IP.
There is no recursive routing, no policy fallback, and no ambiguity about where the traffic should go. The border simply forwards traffic to a known service destination.
Firepower and TrustSec enforcement
On the firewall side, TrustSec is enabled on the interface between the border and the firewall. This allows the firewall to receive and enforce policy using SGT information without losing fabric context.
The FMC logs clearly show traffic entering and leaving on the same transit interface, effectively hairpinning within the virtual network. At the same time, the firewall has full visibility into source IP, destination IP, and source SGT, allowing identity-based policies to be enforced exactly as intended.
What is important here is that none of this breaks the fabric abstraction. From the fabric’s perspective, the firewall is just another service. From the firewall’s perspective, it receives traffic with full identity context.
Why this matters in real designs
After validating this behavior in the lab, it becomes clear that Security Service Insertion is not just an incremental improvement. It removes entire categories of complexity that previously made large-scale SD-Access security designs difficult to operate.
There is no SXP to design, scale, or troubleshoot. There is no policy-based routing on edges. There is no risk of traffic being redirected too late or along unexpected paths. The fabric makes the decision once, at ingress, based on identity, and forwards traffic directly to the correct service.
That architectural shift changes how you design security in SD-Access.
Closing thoughts
Security Service Insertion aligns SD-Access security enforcement with the way the fabric was originally intended to work: identity-driven, control-plane-aware, and deterministic. By treating security services as native fabric elements and steering traffic based on identity rather than topology, SSI takes identity-based networking to the next level in a very tangible and observable way.
This lab confirms that SSI is not a marketing construct but a genuine architectural step forward. It demonstrates how SD-Access has evolved from network-centric enforcement toward true identity-based networking, where services, policy, and forwarding decisions are consistently aligned within the fabric itself.
