Practice Exams:

Campus Fabric Changes Segmentation

 

Traditional campus segmentation is closely tied to topology. A VLAN belongs to a set of access ports, a subnet belongs to that VLAN, an ACL is attached somewhere in the path, and moving a user or device can mean extending Layer 2 or redesigning policy. That model works, but it couples identity, reachability, and enforcement to where the endpoint happens to connect.

Cisco SD-Access changes that relationship. The current 350-401 ENCOR coverage includes the components and concepts of SD-Access, including the fabric control plane and data plane. The design matters because segmentation is no longer expressed only as “which subnet are you in?” The fabric can separate large routing domains with virtual networks and apply finer policy with scalable group tags that follow the endpoint’s role.

The result is not that VLANs disappear or IP addresses stop mattering. It is that they are no longer the only language available for security boundaries. The campus can carry policy based on identity and group membership while the underlay focuses on transport.

Traditional segmentation mixes several jobs together

A VLAN often carries multiple meanings at once: broadcast domain, IP subnet, location, security boundary, and operational ownership. That overlap can be convenient in a small network because one construct solves several problems. At scale, it creates friction. A security team may want the same policy for contractors in every building, while the network topology puts those contractors into many different local subnets.

ACLs can enforce policy across those subnets, but the rule set tends to grow around addresses and topology. Moving an application or changing an IP plan can force security-policy changes that have nothing to do with the trust relationship itself. Troubleshooting becomes an exercise in discovering where the policy is attached and which address objects represent the user today.

The broader CCNP Enterprise design problem is therefore not “replace VLANs.” It is separate connectivity constructs from business policy where doing so reduces operational coupling.

Virtual networks provide macro-segmentation

In SD-Access, virtual networks provide a large isolation boundary comparable in purpose to VRFs. Devices in different virtual networks occupy separate routing domains unless policy deliberately connects them. That is macro-segmentation: a coarse boundary for groups that should not share normal forwarding state.

Examples might include corporate users, building automation, laboratories, payment systems, or guest access. The right grouping depends on risk and operations. Creating a virtual network for every small department can reproduce the same complexity that the fabric was meant to reduce. Macro-segmentation should represent durable trust or routing boundaries, not the organizational chart of the month.

The enterprise network design perspective helps here because segmentation choices affect route exchange, shared services, border policy, and failure domains as well as security.

Scalable group tags create policy inside a virtual network

Not every security relationship needs a separate routing table. Within a virtual network, scalable group tags can identify the role or trust group associated with traffic. Policy can then allow or deny communication between groups without encoding every endpoint IP address into the rule.

This is micro-segmentation at a policy level. An employee workstation and a managed printer may live in the same virtual network but receive different group identities. The policy can say which services the employee group may reach on the printer group. If an employee moves to another fabric edge, the group relationship can remain the same even though the endpoint’s point of attachment changes.

That concept connects naturally to network-security depth such as communication and network security: the objective is to enforce least-necessary communication based on trust relationships rather than on convenient topology alone.

Identity becomes part of forwarding policy

Group-based segmentation works only if the network can assign identity reliably. Cisco Identity Services Engine commonly participates by classifying users and devices and associating them with groups based on authentication, posture, device type, or other context. The fabric then transports the tag so enforcement points do not have to infer identity from an IP address.

That makes identity infrastructure part of the availability and correctness story. If classification is wrong, the network can enforce the wrong policy perfectly. If a device falls into an unknown group, the default policy determines whether that failure is safe or permissive. Design should explicitly define onboarding, fallback, exception, and remediation behavior.

The Cisco 300-715 SISE context is relevant because secure access is not merely authentication at the door; identity has to become usable policy throughout the session lifecycle.

The underlay should be boring so the overlay can be expressive

A fabric still needs physical connectivity and IP reachability between fabric nodes. That underlay is where conventional routing provides stable transport. The overlay then carries endpoint reachability and segmentation information independently of the physical path. Keeping those responsibilities separate is a major architectural advantage.

If an access switch needs to reach a remote endpoint, the fabric does not have to extend the endpoint’s original Layer 2 segment across every intermediate switch. Instead, the overlay encapsulates traffic across the routed underlay. The physical network can remain focused on resilient IP forwarding while the overlay represents virtual networks and endpoint location.

This separation is one reason SD-Access appears in ENCOR enterprise networking: the design combines traditional routing fundamentals with a different way of carrying endpoint and policy state.

Policy mobility changes the operational question

In a topology-bound campus, moving an endpoint can change which ACL, VLAN, or gateway it encounters. In a fabric, the goal is for the endpoint’s identity and policy to remain consistent as attachment changes. That is powerful for users who roam between buildings, wireless and wired access, or devices that are frequently relocated.

The operational question becomes “What identity and group did the endpoint receive?” rather than only “Which port and VLAN is it on?” Troubleshooting tools and runbooks must evolve accordingly. Engineers need visibility into authentication, endpoint registration, virtual network, scalable group, fabric edge, and the policy contract between source and destination groups.

That added state is not a reason to avoid fabric; it is a reason to make the state observable. Abstraction helps only when operators can inspect what the controller believes.

Shared services test the quality of the segmentation design

Most segmented environments still need DNS, DHCP, identity, logging, management, patching, internet access, and other shared services. If every virtual network requires a unique handcrafted path to every shared service, the segmentation model can become an operational burden.

Design shared-service access deliberately. Decide which services should be reachable across virtual networks, where policy is enforced, and whether traffic must pass through a firewall or another inspection point. Avoid turning a “shared” network into a hidden bypass that defeats the separation established elsewhere.

The best segmentation designs make exceptions more explicit, not more mysterious. A shared service should have a documented reason, controlled path, and observable policy relationship.

Segmentation reduces blast radius only when defaults are safe

Macro- and micro-segmentation are useful because they can contain compromise, misconfiguration, and accidental reachability. But the effect depends on default behavior. If unknown groups can communicate broadly, if policy exceptions accumulate indefinitely, or if administrators bypass the group model with IP ACLs whenever a ticket is urgent, the intended isolation erodes.

Define default deny or default limited behavior where the business can support it, and make exception ownership clear. Review group-to-group policy as relationships rather than as thousands of address entries. Track unused rules and temporary exceptions. Segmentation should reduce the number of implicit trust paths, not just move them into a controller.

Security architecture becomes easier to reason about when the permitted relationships can be described in business terms such as “managed workstations may reach these application services” rather than “these twenty-three subnets may reach those seventeen subnets.”

Fabric segmentation is a different mental model, not just automation

It is easy to describe SD-Access as automation for campus networks, but the deeper shift is in what the network represents. The underlay provides resilient transport. The overlay carries virtualized reachability. Virtual networks provide broad isolation. Scalable group tags express identity-based policy within those routing domains. The controller coordinates state that would otherwise be distributed across many manual configurations.

That model improves flexibility only if the organization is ready to operate the identity, controller, and policy layers with the same discipline it applies to routing. A bad group assignment or an overly broad contract can be just as consequential as a bad ACL.

Campus fabric changes segmentation because it lets policy follow who or what the endpoint is instead of depending primarily on where it plugs in. The technology is valuable when that decoupling makes trust boundaries clearer, movement safer, and operations more consistent across the enterprise.

Migration strategy matters because most enterprises do not replace the campus in one event. Fabric and non-fabric domains often coexist, which means policy may cross borders where group-based identity has to map back into VRFs, firewalls, or conventional ACLs. The migration design should state which boundary is authoritative for segmentation during each phase and how tags or virtual networks are translated when traffic leaves the fabric.

Brownfield coexistence also changes troubleshooting. A packet can be permitted by fabric policy and then denied by a legacy firewall, or allowed through the legacy path but assigned the wrong group at fabric ingress. Operations teams need a shared model of the complete path rather than separate “fabric” and “security” views that each end at the handoff.

Policy reviews should also include unused groups and stale contracts. Identity-based segmentation can become just as cluttered as ACLs if old exceptions are never retired. Periodic cleanup keeps the logical policy model aligned with the real organization and reduces the number of paths engineers must consider during an incident.

Related Posts

• Why Network Segmentation Still Stops Real Attacks

• Least Privilege as an Architecture Principle

• Availability Sets, Zones, and Scale Sets Solve Different Problems

• Entra Groups, Roles, and Access Reviews in Everyday Administration

• Spanning Tree Still Matters in a World of Faster Switches

• Network Automation Starts With Structured Data, Not Python

• Why Enterprise Fabrics Need VXLAN and LISP

• TrustSec: Segmentation by Identity, Not Address

• Design a VPC That Preserves Future Options

• Backups Are Not a Disaster-Recovery Plan