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

This guide focuses on a BGP EVPN campus fabric, not every campus fabric architecture. Its components include a deterministic Internet Protocol (IP) underlay, an Ethernet virtual private network (EVPN) control plane, Virtual Extensible Local Area Network (VXLAN) data-plane encapsulation, virtual routing and forwarding (VRF)-level macrosegmentation, and role-aware policy with Cisco TrustSec Security Group Tags (SGTs) where the platform supports them.

Design takeaway: use VRFs to separate routing tables and supported SGT enforcement to control role-based access. Routing separation does not make shared switches, links or power independent failure domains. Validate resilience separately.

Reference Fabric Model

Cisco Cloud Fabric uses BGP EVPN and VXLAN; the cited case study uses OSPF in the underlay and eBGP at the upstream handoff. Cisco SD-Access instead uses a LISP control plane with VXLAN and TrustSec. Segmentation concepts overlap, but controller workflows and control-plane troubleshooting are not interchangeable. The diagram is a conceptual EVPN model, not a deployable combination of both designs.

Architecture diagram

Campus Fabric Reference Model

Topology separates the data plane from EVPN control and policy sources, so troubleshooting follows evidence instead of guessing.

Read the diagram from left to right during troubleshooting. If the client cannot reach an app, do not start with "the fabric is broken." Validate access authentication, local virtual local area network (VLAN) or anycast gateway behavior, underlay loopback reachability, EVPN route advertisement, VXLAN network identifier (VNI) to virtual routing and forwarding (VRF) mapping, border route leaking, firewall policy, Domain Name System (DNS), and return path in that order.

Underlay Rules That Keep EVPN Stable

• Use point-to-point routed links wherever possible; avoid letting a campus L2 failure domain become a fabric transport dependency.
• Advertise loopbacks consistently; VXLAN tunnel endpoints and EVPN peering depend on stable reachability to those addresses.
• Set maximum transmission unit (MTU) deliberately. VXLAN adds overhead, so a fabric that "mostly works" with default MTU can fail with large payloads or storage-style application traffic.
• Keep summarization and filtering predictable. If a border or route reflector cannot see the right loopback or overlay prefix, the symptom often appears as an endpoint or policy problem.
• Use the underlay required by the selected supported design. The cited Cloud Fabric case uses OSPF; its eBGP border handoff is not an eBGP underlay. Evaluate any alternative against its own platform documentation and failure tests.

Macrosegmentation Versus Microsegmentation

Macrosegmentation separates routing domains; microsegmentation controls access between roles. Define the trust boundary first, then decide whether it needs routing separation, role policy or both. Document each shared-service exception and its enforcement point.

Need	Use VRF or virtual network (VN)	Use Security Group Tag (SGT) policy	Design Note
Guest internet access	Yes	Usually minimal	Keep it out of internal routing; inspect or Network Address Translation (NAT) at a controlled edge.
Payment Card Industry (PCI) or regulated enclave	Yes	Yes	VRF creates the routing boundary; SGTs reduce lateral movement inside it.
Employee versus contractor	Usually no	Yes	Same user VN may be acceptable if identity policy is strong and enforcement is validated.
Cameras, printers, badge readers	Sometimes	Yes	Use a separate Internet of Things (IoT) VN when routing and ownership differ; use SGTs for device-class policy.
Shared DNS, Dynamic Host Configuration Protocol (DHCP), Network Time Protocol (NTP), AD	Service VRF or firewall zone	Yes	Every route leak should have an owner, a purpose, and a validation test.

Cisco EVPN microsegmentation documentation explains how Border Gateway Protocol (BGP) EVPN VXLAN can carry microsegmentation context with TrustSec integration. For operations, ask: where is the SGT assigned, how is it propagated, where is it enforced, and what log shows a deny was caused by policy rather than routing, DNS, or authentication failure?

Control-Plane Caveats

The linked Catalyst 9300 IOS XE 17.16 microsegmentation guide restricts VXLAN-GPO to IPv4 underlays, requires device tracking on host-facing trunks, and excludes overlay multicast from SGACL enforcement. Check the exact platform and release rather than treating the SGT examples as coverage of every flow.

• EVPN route types matter. Media Access Control (MAC)/IP host reachability, subnet advertisement, and external prefix advertisement are not interchangeable operational signals.
• Anycast gateway behavior must be consistent across fabric edges. A mismatched gateway, SVI, VNI, or VRF creates symptoms that look like random endpoint failure.
• Where the selected EVPN overlay uses iBGP route reflectors, document and test their failure behavior. The diagram's EVPN RR is not a requirement for every BGP topology or an SD-Access control-plane node.
• Border nodes are policy choke points. Document every external prefix, default route, route leak, firewall handoff, and NAT boundary per VRF.
• SGT designs fail operationally when every exception becomes a new group. Keep groups tied to durable roles, not one-off tickets.

Sample Campus Slice

VRF	VNI Planning Placeholder	Example VLANs	Gateway	SGTs	Northbound Path
USER	10100	110 employee, 120 contractor	10.10.10.1, 10.10.20.1	Employee, Contractor, Admin	Firewall zone USER to shared services and internet
IOT	10200	210 camera, 220 printer, 230 facilities	10.20.10.1, 10.20.20.1	Camera, Printer, Facilities	Firewall zone IOT to video, print, and facilities apps
GUEST	10300	310 guest	10.30.10.1	Guest	NAT only; no internal route leak
SHARED	10400	410 services	10.40.10.1	DNS, DHCP, NTP, AD	Firewall-mediated access from approved VRFs

This is a planning slice, not configuration. The VNI numbers do not define the required L2/L3 mappings, and the IOT row does not yet assign a gateway for VLAN 230. Complete and validate those mappings, subnets and addresses in the source of truth before provisioning. Start with this small scope to test onboarding, enforcement, route leaking, firewall symmetry and rollback.

Validation Matrix

Test	Pass Condition	Fail Signal	Evidence to Keep
Underlay loopback reachability	Every VTEP and EVPN peer reaches every required loopback over routed paths.	VXLAN tunnels flap, EVPN routes withdraw, or traffic blackholes after link failure.	Routing table, neighbor state, traceroute, MTU test.
Endpoint move	Client moves between edge switches and keeps correct IP, gateway, SGT, and policy.	Stale MAC/IP route, wrong SGT, duplicate endpoint, or delayed convergence.	EVPN route output, endpoint database, authentication log.
VRF isolation	USER, IOT, and GUEST cannot reach each other except documented shared services.	Unexpected route leak or firewall bypass.	VRF route tables, firewall session logs, denied-flow tests.
SGT enforcement	Employee reaches approved apps; contractor and IoT classes are denied where expected.	Permit because of missing SGT, default rule, or unsupported enforcement point.	Identity Services Engine (ISE) session, SGT mapping, Security Group Access Control List (SGACL) hit counters.
Border failover	External prefixes and default routes converge without asymmetric firewall return path.	Forward path moves but return path stays pinned to the old border.	BGP state, firewall sessions, path trace from both directions.

Operational Runbook

1. Freeze the pilot scope to one building, two or three VRFs, and a small SGT matrix.
2. Record underlay links, loopbacks, VXLAN network identifiers (VNIs), VLANs, anycast gateways, route reflectors, borders, and firewall zones in a source of truth.
3. Baseline current user-to-application paths, including DNS answer, route, inspection point, NAT behavior, and return path.
4. Turn up underlay first and validate convergence and MTU before onboarding endpoints.
5. Add EVPN and VXLAN, then verify endpoint learning and movement without security policy complexity.
6. Add VRF handoff and route leaking only for named shared services.
7. Introduce SGT policy in monitor or limited-enforcement mode before default-deny expansion.
8. Run allowed-flow and denied-flow tests after every policy change.
9. Test rollback by removing the pilot route leak, restoring the previous gateway path, or moving the pilot VLAN back to its prior design.

Where Fabric Supports Zero Trust

A campus fabric does not become zero trust because VXLAN exists. It moves in that direction when identity, device posture, route domain, role tag, enforcement point, telemetry, and exception lifecycle all line up. The practical incident question is: can an engineer show why this endpoint got this access at this moment? If the answer requires guessing across five consoles, the architecture is not finished.

Security, Privacy, Legal, and Recovery Boundaries

Fabric segmentation reduces reachable paths; it does not patch endpoints, validate identities, or inspect every allowed flow. Protect ISE, route reflectors, fabric management, border control, and automation credentials as privileged infrastructure. Endpoint identity, location, posture, SGT assignment, and flow records can become sensitive employee or visitor data. Limit access, define retention, and involve privacy or labor counsel when policy or telemetry can be associated with a person.

Document platform support, software interoperability, and licensing before treating the sample design as deployable. Recovery requires more than a controller backup: retain the prior gateway and VLAN path, export policy and device configuration, identify a break-glass management route, and rehearse removing a route leak or SGT rule. During a rollback, confirm both forward and return paths; restoring reachability while leaving asymmetric firewall state is not recovery. Time endpoint relearning and application recovery as well as routing convergence, because healthy EVPN and BGP adjacencies do not prove that stateful traffic has recovered.

What Validation Does Not Prove

The validation matrix is documentation-backed and has not been executed in a TechGeeks lab for this revision. Passing an endpoint-move test does not prove convergence at production scale. A denied test flow does not prove every lateral path is blocked. Healthy EVPN routes do not prove application reachability, identity correctness, or firewall symmetry. Use representative traffic, failure injection, and retained logs before expanding the pilot.

Related TechGeeks

• Designing an AI-Ready Campus Network After Cisco Live 2026
• Campus Segmentation Design: From VLANs to Unified Fabric
• Cisco Live 2026: Network Announcements That Matter

Cisco References

• Cisco Cloud Fabric Validated Case Study
• Cisco SD-Access Design Guide
• Cisco EVPN Microsegmentation
• Cisco SD-Access solution page
• IETF RFC 8365: A Network Virtualization Overlay Solution Using EVPN

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