Catalyst Campus Fabric: eBGP, EVPN, VXLAN, and the Path to Macro and Microsegmentation

Campus networks are moving from large Layer 2 domains and hand-built VLAN policy toward fabric designs where reachability, segmentation, and policy are more explicit. On Catalyst platforms, that discussion now spans SD-Access, Catalyst Center, and BGP EVPN VXLAN campus fabric designs.

Design takeaway: use VRFs or virtual networks for large separation boundaries, then use SGTs and group-based policy for finer access control inside those boundaries. Do not create a VRF for every role.

What The Fabric Is Doing

Cisco Cloud Fabric validated design describes a campus fabric built on a Layer 3 routed underlay, VXLAN overlays, and MP-BGP EVPN as the control plane. In plain language, the underlay gives the fabric resilient IP transport. EVPN distributes endpoint and network reachability. VXLAN carries overlay traffic. VRFs preserve segmentation boundaries.

That is a major shift from a traditional campus where VLANs often stretch farther than they should and policy is scattered across ACLs, firewall interfaces, and switchport conventions. The fabric model makes the campus more like a structured multi-tenant network, even when the tenants are internal groups such as corporate users, IoT, guests, facilities, and shared services.

Macrosegmentation: Big Boundaries First

Cisco SD-Access design guidance describes macrosegmentation with virtual networks or VRFs. This is the big separation layer: Campus, Guest, IoT, OT, PCI, Facilities, or other domains that should not share a default routing table.

• Use macrosegmentation for regulatory boundaries, major trust zones, and operationally distinct domains.
• Keep the VN or VRF count small enough to operate.
• Plan shared services carefully, because inter-VRF communication needs explicit route leaking or firewall policy.
• Document the north-south path for each VN before adding more segmentation.

The common design mistake is overusing macrosegmentation. If every department becomes a VRF, border handoffs, route leaking, firewall contexts, troubleshooting, and lifecycle management become painful. VRFs are powerful, but they are not a substitute for a policy model.

Microsegmentation: Policy Inside The Boundary

Cisco EVPN microsegmentation documentation shows how BGP EVPN VXLAN can integrate Cisco TrustSec for microsegmentation and group-based policy. The important pieces are classification, propagation, and enforcement. An endpoint gets a Security Group Tag. The fabric propagates that context. SGACL policy controls what a source group can do to a destination group.

This is where segmentation becomes practical. Employees, contractors, printers, cameras, badge readers, building systems, and admin workstations do not all need separate VRFs. They often need identity-aware rules inside a larger VN. That is microsegmentation.

• Classify users and devices through 802.1X, MAB, static mapping, or profiling.
• Propagate SGT context through the fabric using supported mechanisms such as VXLAN-GPO where applicable.
• Enforce group-based policy at the right points in the network.
• Keep the SGT matrix meaningful; hundreds of groups usually become unmanageable.

How This Progresses Toward Zero Trust

A mature campus fabric does not become zero trust because VXLAN exists. It progresses toward zero trust because access is separated into layers: authenticated identity, device classification, macro boundary, micro policy, and continuous visibility.

A good adoption path starts with the underlay and fabric stability, then a small number of macro domains, then visibility with ISE and analytics, then a limited SGT policy matrix, then broader enforcement. Default-deny may be the long-term goal, but many organizations need a monitored default-permit phase while they learn real traffic patterns.

The practical test is simple: can you explain why a device is in a segment, what it is allowed to reach, where that policy is enforced, and how you would prove it during an incident? If yes, the fabric is doing more than moving packets. It is becoming a security control plane.

Design Detail: EVPN Fabric Is A Policy Transport, Not Just An Overlay

The reason Catalyst campus fabric matters is that it lets the campus carry more than VLAN reachability. With a routed underlay, EVPN control plane, VXLAN overlay, VRF macrosegmentation, and TrustSec SGT microsegmentation, the campus can represent both topology and policy. That is a step toward treating the LAN as a security-aware fabric rather than a collection of switchports.

The underlay should stay simple: point-to-point routed links, deterministic convergence, consistent MTU, and clean failure domains. The overlay is where endpoint reachability and segment identity live. VRFs create the large lanes. SGTs create the role-based controls inside those lanes.

The operational challenge is visibility. Engineers need to troubleshoot underlay reachability, EVPN route distribution, VNI/VRF mapping, anycast gateway behavior, SGT classification, SGT propagation, and SGACL enforcement. A fabric design without a troubleshooting model is not finished.

Implementation Drill-Down

• Keep macrosegments few: Corporate, Guest, IoT, OT, PCI, or Shared Services where justified.
• Use SGTs for roles and device classes instead of creating a VRF for every department.
• Document where enforcement happens and how SGTs are assigned.
• Test border handoff, shared-services access, and route leaking before adding more segments.
• Build operational runbooks for underlay, overlay, and policy-plane troubleshooting.

Design And Implementation Notes

The safest way to adopt this is to treat it as an architecture change with measurable operating outcomes, not as a single feature toggle. The checklist below is intentionally practical. It is the difference between a successful pilot and a confusing production surprise.

• Begin with inventory and ownership. Know the sites, users, devices, applications, policy domains, and support teams before changing the architecture.
• Pilot with one bounded use case. A branch, campus building, cloud app, user group, or lab fabric is easier to validate than an enterprise-wide rollout.
• Measure before and after. Capture latency, path, authentication behavior, policy hits, user experience, incident count, and operational workload.
• Document rollback. Every change should have a known previous state, a restoration method, and a test that proves the rollback worked.
• Review the design with both network and security teams. Most of these Cisco Live 2026 announcements sit directly between connectivity and enforcement.
• For security controls, define the default behavior clearly: monitor, warn, block, isolate, or require approval. Ambiguous enforcement creates painful outages.

Architecture Blueprint

A useful Catalyst campus fabric with eBGP, EVPN, VXLAN, VRFs, and TrustSec SGT policy design should be written as an operating blueprint before it is treated as a product deployment. The blueprint needs to say what is being connected, what is being protected, who owns the policy, how evidence will be collected, and what the team will do when the first test does not behave like the demo.

Start by building an inventory of underlay links, loopbacks, VNIs, VRFs, border nodes, shared services, endpoint groups, SGT assignments, and SGACL policy. The inventory should be boring, searchable, and reviewed by both network and security owners. This is the foundation for every later decision because ambiguous inventory turns automation, AI recommendations, and segmentation policy into guesswork.

Layer	Decision	Implementation Detail
Scope	Define the first production slice for Catalyst campus fabric with eBGP, EVPN, VXLAN, VRFs, and TrustSec SGT policy.	Use one building or lab pod with two macrosegments, a small SGT matrix, shared-services access, and documented border handoff so the team can validate real behavior without broad blast radius.
Policy	Write the policy in business language before translating it into platform controls.	The practical control surface is VRF macrosegmentation for large trust zones and SGT microsegmentation for role-based policy inside those zones.
Telemetry	Decide which evidence proves success and which evidence proves failure.	Collect underlay routing, EVPN routes, VXLAN tunnel state, endpoint movement, SGT propagation, SGACL hits, and border traffic before and after the pilot.
Rollback	Make the previous state recoverable and test that recovery path.	restore the previous routed or VLAN design for the pilot scope and remove route leaking or policy handoff created for testing.
Ownership	Assign owners for design, implementation, approval, operations, exceptions, and review.	No exception should exist without a person, expiration date, and reason it is still needed.

Deployment Runbook

The runbook below is intentionally more detailed than a product checklist. It is meant to keep the implementation grounded in design intent, operational visibility, and recovery planning. This is especially important for the Cisco Live 2026 announcements because many of them cross traditional network, security, cloud, and operations team boundaries.

1. Write a one-page design statement for Catalyst campus fabric with eBGP, EVPN, VXLAN, VRFs, and TrustSec SGT policy that names the business problem, success criteria, pilot scope, and teams involved.
2. Complete the inventory for underlay links, loopbacks, VNIs, VRFs, border nodes, shared services, endpoint groups, SGT assignments, and SGACL policy and mark which systems are authoritative sources of truth.
3. Draw the current-state path from user or device to application, including identity, DNS, routing, inspection, segmentation, and logging points.
4. Draw the target-state path and explicitly call out what changes for policy, routing, traffic steering, telemetry, and support ownership.
5. Define the pilot as one building or lab pod with two macrosegments, a small SGT matrix, shared-services access, and documented border handoff and freeze the scope until the team has repeatable validation results.
6. Capture a baseline using underlay routing, EVPN routes, VXLAN tunnel state, endpoint movement, SGT propagation, SGACL hits, and border traffic so the post-change result can be compared against something real.
7. Stage the configuration, policy, or workflow in the smallest supported unit and peer-review it with both network and security stakeholders.
8. Run positive tests for allowed behavior and negative tests for traffic or access that should remain blocked.
9. Execute the rollback test: restore the previous routed or VLAN design for the pilot scope and remove route leaking or policy handoff created for testing. Do this before expanding the rollout, not after the first outage.
10. Hold a review meeting after the pilot and decide whether to expand, redesign, keep in observe-only mode, or retire the approach.

Validation And Acceptance Tests

Validation should prove more than basic reachability. The goal is to prove that the design behaves correctly during normal operation, during failure, and during support troubleshooting. These acceptance tests should become part of the change record and the operations handoff.

• Underlay convergence is deterministic and observable.
• EVPN reachability and VXLAN encapsulation are stable during endpoint moves.
• Macrosegments are isolated except for explicitly documented shared services.
• SGT policy allows required flows and denies lateral movement in a repeatable test plan.

• Confirm that monitoring shows the intended state and not merely device uptime.
• Confirm that an operator can explain a failed test without guessing which console to open next.
• Confirm that a blocked flow is blocked for the right policy reason, not because of an accidental route, DNS, or authentication failure.
• Confirm that exception handling has a named owner, expiration date, and review cadence.

Operational Ownership Model

For Catalyst campus fabric with eBGP, EVPN, VXLAN, VRFs, and TrustSec SGT policy, ownership should be split deliberately. Network teams usually own forwarding, topology, routing, switching, wireless, and transport behavior. Security teams usually own access policy, inspection, identity requirements, data handling, and response expectations. Cloud, endpoint, and application owners may also own part of the user-to-app path. The implementation needs a RACI-style model even if the organization does not formally call it that.

• Design owner: accountable for the architecture and for keeping the diagram current.
• Implementation owner: accountable for configuration, rollout sequencing, and rollback steps.
• Policy owner: accountable for access decisions, security posture, and exceptions.
• Operations owner: accountable for monitoring, incident response, and day-two procedures.
• Business owner: accountable for accepting user-impact tradeoffs and risk decisions.

Common Pitfalls

• Starting with the tool before defining the operating model.
• Skipping source-of-truth cleanup and then expecting automation to understand intent.
• Creating too many segments, groups, dashboards, or exceptions too early.
• Treating compensating controls as permanent replacements for lifecycle work.
• Failing to assign a clear owner for policy, telemetry, exceptions, and rollback.
• Rolling out enforcement before enough traffic observation has happened.

Cisco References

• Cisco Cloud Fabric Validated Case Study
• Cisco SD-Access Design Guide
• Cisco EVPN Microsegmentation
• Cisco SD-Access solution page

Related foundation post: Cisco Live 2026: Network Announcements That Matter.