This article focuses specifically on normal-range VLANs (1–1005) and how to make them span multiple switches, so that, for example, VLAN 10 in Building A behaves as the exact same Layer 2 network as VLAN 10 in Building B.

What Is a VLAN, Conceptually?

Physically, all your devices might be plugged into the same switch (or chain of switches). But logically, a VLAN groups switch ports into separate broadcast domains. Devices in VLAN 10 cannot directly communicate at Layer 2 with devices in VLAN 20, even if they’re plugged into the same physical switch — a router (or Layer 3 switch) is required to pass traffic between VLANs.

Analogy

Think of a large office building with one shared elevator system (the physical switch), but separate secured floors (VLANs) that require a security badge (routing) to move between them. Two people on the same floor can walk to each other’s offices freely (same VLAN = same broadcast domain), but moving to a different floor requires going through security (a router).

VLAN Ranges

This article focuses on normal-range VLANs (2–1001), which is what the CCNA exam blueprint specifically references.

Step-by-Step: Configuring VLANs Spanning Multiple Switches

Topology

graph TB
    subgraph SW1["Switch 1 - Building A"]
        PC1["PC1 - VLAN 10"]
        PC2["PC2 - VLAN 20"]
    end
    subgraph SW2["Switch 2 - Building B"]
        PC3["PC3 - VLAN 10"]
        PC4["PC4 - VLAN 20"]
    end
    SW1 ---|"Trunk Link (802.1Q)"| SW2

The goal: PC1 (VLAN 10, SW1) should be able to communicate at Layer 2 with PC3 (VLAN 10, SW2), while remaining completely isolated from PC2 and PC4 (VLAN 20), even though all four devices share the same physical trunk link between switches.

Step 1: Create the VLANs on Both Switches

SW1(config)# vlan 10
SW1(config-vlan)# name SALES
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# name ENGINEERING
SW1(config-vlan)# exit

SW1(config)# vlan 10
SW1(config-vlan)# name SALES
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# name ENGINEERING
SW1(config-vlan)# exit

SW2(config)# vlan 10
SW2(config-vlan)# name SALES
SW2(config-vlan)# exit
SW2(config)# vlan 20
SW2(config-vlan)# name ENGINEERING
SW2(config-vlan)# exit

SW2(config)# vlan 10
SW2(config-vlan)# name SALES
SW2(config-vlan)# exit
SW2(config)# vlan 20
SW2(config-vlan)# name ENGINEERING
SW2(config-vlan)# exit

Important: VLAN numbers must match across switches for devices to be considered part of the same VLAN — the VLAN name is just a label for humans and doesn’t need to match, but best practice is to keep names consistent too, to avoid confusion.

Step 2: Assign Access Ports to VLANs

On SW1:

SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# exit

SW1(config)# interface GigabitEthernet0/2
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20

SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# exit

SW1(config)# interface GigabitEthernet0/2
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20

On SW2:

SW2(config)# interface GigabitEthernet0/1
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 10
SW2(config-if)# exit

SW2(config)# interface GigabitEthernet0/2
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 20

SW2(config)# interface GigabitEthernet0/1
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 10
SW2(config-if)# exit

SW2(config)# interface GigabitEthernet0/2
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 20

Step 3: Configure the Trunk Link Between Switches

This is the crucial step that lets VLANs “span” multiple switches — without a properly configured trunk, VLAN 10 on SW1 and VLAN 10 on SW2 would be entirely isolated islands with no way to communicate.

SW1(config)# interface GigabitEthernet0/24
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20

SW1(config)# interface GigabitEthernet0/24
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20

SW2(config)# interface GigabitEthernet0/24
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 10,20

SW2(config)# interface GigabitEthernet0/24
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 10,20

(See the dedicated interswitch connectivity article for full trunking details, native VLAN considerations, and DTP behavior.)

How Traffic Actually Flows Across the Trunk

sequenceDiagram
    participant PC1 as PC1 (VLAN 10, SW1)
    participant SW1
    participant SW2
    participant PC3 as PC3 (VLAN 10, SW2)
    PC1->>SW1: Untagged frame (access port)
    SW1->>SW1: Tag frame with VLAN 10 (802.1Q)
    SW1->>SW2: Tagged frame sent across trunk
    SW2->>SW2: Read VLAN tag, strip it
    SW2->>PC3: Untagged frame delivered (access port, VLAN 10)

Notice that the 802.1Q tag only exists on the trunk link itself. The end devices (PC1 and PC3) never see or generate tags — tagging is purely a switch-to-switch mechanism.

Verification Commands

show vlan brief

Confirms VLANs exist and shows which access ports belong to each VLAN (trunk ports are not listed here since they carry multiple VLANs):

SW1# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/3, Gi0/4, Gi0/5
10   SALES                            active    Gi0/1
20   ENGINEERING                      active    Gi0/2

SW1# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/3, Gi0/4, Gi0/5
10   SALES                            active    Gi0/1
20   ENGINEERING                      active    Gi0/2

show interfaces <interface> switchport

Confirms an individual port’s VLAN assignment and mode:

SW1# show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Access Mode VLAN: 10 (SALES)

SW1# show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Access Mode VLAN: 10 (SALES)

show interfaces trunk

Confirms VLANs 10 and 20 are actually being carried across the trunk (covered in detail in the interswitch connectivity article):

SW1# show interfaces trunk
Port        Mode    Encapsulation  Status        Native vlan
Gi0/24      on      802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/24      10,20

SW1# show interfaces trunk
Port        Mode    Encapsulation  Status        Native vlan
Gi0/24      on      802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/24      10,20

show mac address-table vlan 10

Confirms which MAC addresses the switch has learned within VLAN 10 specifically — useful for confirming end-to-end Layer 2 connectivity:

SW1# show mac address-table vlan 10
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
10      aaaa.bbbb.0001    DYNAMIC     Gi0/1
10      cccc.dddd.0002    DYNAMIC     Gi0/24

SW1# show mac address-table vlan 10
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
10      aaaa.bbbb.0001    DYNAMIC     Gi0/1
10      cccc.dddd.0002    DYNAMIC     Gi0/24

The second entry (learned via Gi0/24, the trunk port) confirms the switch has learned about a VLAN 10 device on the other switch — proof the VLAN is genuinely spanning across the trunk.

End-to-End Connectivity Test

Ultimately, the simplest verification is a ping test between two devices in the same VLAN on different switches:

C:\Users\PC1> ping 192.168.10.20

Pinging 192.168.10.20 with 32 bytes of data:
Reply from 192.168.10.20: bytes=32 time=1ms TTL=128

C:\Users\PC1> ping 192.168.10.20

Pinging 192.168.10.20 with 32 bytes of data:
Reply from 192.168.10.20: bytes=32 time=1ms TTL=128

If PC1 (VLAN 10, SW1, IP 192.168.10.10) can successfully ping PC3 (VLAN 10, SW2, IP 192.168.10.20), and both are on the same subnet, this confirms the VLAN genuinely spans both switches correctly.

Comparison Table: Access Port vs. Trunk Port

Common Mistakes When Spanning VLANs

1. Forgetting to create the VLAN on the second switch. VLANs are locally significant to each switch’s database unless you use VTP (VLAN Trunking Protocol) to synchronize them — and even then, VTP has version-specific quirks. Many organizations avoid VTP altogether and manually replicate VLAN configuration for tighter control.
2. Forgetting to allow the VLAN across the trunk. Even if VLAN 10 exists on both switches, if the trunk’s allowed VLAN list doesn’t include 10, traffic won’t pass.
3. Assigning the wrong VLAN to an access port, resulting in a device that can’t reach others in its intended VLAN.
4. IP addressing mismatches — remember, VLANs are a Layer 2 concept; you still need consistent Layer 3 subnetting (same subnet on both switches’ VLAN 10 ports) for IP communication to succeed.

Best Practices

1. Use a consistent VLAN numbering scheme across your entire organization (e.g., VLAN 10 = Sales everywhere, VLAN 20 = Engineering everywhere) to reduce confusion.
2. Document VLAN-to-subnet mappings clearly (e.g., VLAN 10 = 192.168.10.0/24) so Layer 2 and Layer 3 designs stay aligned.
3. Avoid VLAN 1 for user traffic. Reserve it as the default/native VLAN only, and place real traffic in explicitly created VLANs.
4. Prune unnecessary VLANs from trunks using switchport trunk allowed vlan to reduce unnecessary broadcast propagation across the network.
5. Verify both configuration AND live state. show running-config shows intended configuration; show vlan brief, show interfaces trunk, and show mac address-table show what’s actually happening — always check both.

Troubleshooting Checklist

1. Does the VLAN exist on both switches? (show vlan brief)
2. Is the access port’s VLAN assignment correct? (show interfaces switchport)
3. Is the VLAN included in the trunk’s allowed list on both ends? (show interfaces trunk)
4. Is the trunk actually up and trunking (not stuck in access mode)?
5. Are the two end devices in the same IP subnet, with correct default gateways?
6. Has the switch actually learned the remote device’s MAC address in the correct VLAN? (show mac address-table vlan <id>)

Summary

Making a VLAN “span” multiple switches requires three coordinated pieces: the VLAN must exist with the same VLAN ID on every switch involved, end devices must be assigned to that VLAN via access ports, and the VLAN must be explicitly permitted across every trunk link connecting the switches. Once all three pieces are in place, devices in the same VLAN — regardless of which physical switch they’re plugged into — behave as if they’re on the same local network segment, and devices in different VLANs remain isolated at Layer 2 even when sharing the same physical infrastructure.

Further Reading

• Cisco: VLAN Configuration Guide
• IEEE 802.1Q VLAN Standard
• Cisco: Understanding VLAN Trunk Protocol (VTP)
• Cisco Command Reference: show vlan

The post How to Configure and Verify VLANs (Normal Range) Spanning Multiple Switches appeared first on Abdul Wahab Junaid.

What Threat Grid Actually Does

Cisco Threat Grid is a malware analysis and threat intelligence platform that combines dynamic and static analysis (commonly called sandboxing) with a massive, continuously updated threat intelligence database. When a suspicious file enters your network — through email, web download, or a file share — Threat Grid detonates it in an isolated virtual environment and observes exactly what happens: registry changes, network calls, process spawning, file drops, and privilege escalation attempts.

The output isn’t just a binary “malicious” or “clean” verdict. You get a behavioral score, a detailed report, and correlation against a global feed of indicators of compromise (IOCs) gathered from Cisco’s Talos intelligence group and millions of other samples analyzed worldwide.

Threat Grid integrates natively with several other Cisco products, which is honestly one of its biggest strengths:

• Cisco Secure Email (formerly ESA) — attachments get detonated before delivery
• Cisco Secure Endpoint (formerly AMP for Endpoints) — file trajectory and retrospective detection
• Cisco Firepower/Secure Firewall — network-based file inspection
• Cisco Umbrella — DNS-layer correlation with sandbox verdicts

Networking and Security Fundamentals Before You Start

Before touching the console, it helps to understand where Threat Grid sits in the security stack. Traditional perimeter defenses — firewalls, IPS signatures — operate on known patterns. Sandboxing operates on behavior. This distinction matters because modern malware is often polymorphic; the hash changes every time it’s compiled, but the behavior (dropping a payload into %APPDATA%, beaconing to a C2 server, disabling Windows Defender) tends to stay consistent.

Threat Grid sits either in the cloud (Cisco-hosted) or as an on-premises appliance (Threat Grid Appliance, TGA), depending on your compliance requirements. Financial and healthcare organizations often need the on-prem appliance because samples never leave their network boundary — this matters if you’re handling files that could contain sensitive customer data even when benign.

Deployment Architecture Planning

Before implementation, map out your architecture:

1. Sample submission sources — which devices will forward files (email gateway, firewall, endpoint agents)
2. Network segmentation — the sandbox environment needs internet access to observe real malware behavior (C2 beaconing, download attempts), so it must sit in a controlled DMZ, isolated from production
3. Bandwidth planning — file submission and report retrieval consume bandwidth; plan for peak submission volume
4. Licensing — Threat Grid licensing is typically bundled with Secure Endpoint, Secure Email, or purchased standalone with sample-volume tiers

Step-by-Step Implementation

Step 1: Choose Cloud or On-Premises Appliance

For cloud deployment, you simply need an organization account provisioned through the Cisco Secure portal and API keys. For on-premises, you’re racking a physical or virtual Threat Grid Appliance (TGA5504 or the VM-based OVA).

For the appliance, initial setup is via the OPAdmin (Operations Portal Admin) console:

https://<TGA-management-IP>/opadmin

Default login on first boot is opadmin with the password printed on the appliance pull-tab or set during OVA deployment.

Step 2: Configure Network Interfaces on the Appliance

The TGA has three logical interfaces you must configure correctly:

• Admin interface — management access
• Clean interface — for legitimate outbound update traffic
• Dirty interface — dedicated egress for sandboxed malware to “call home” safely, fully isolated from your production network

opadmin# configure network
opadmin(config-net)# interface admin
opadmin(config-net-admin)# ip address 10.10.10.5 255.255.255.0
opadmin(config-net-admin)# gateway 10.10.10.1
opadmin(config-net-admin)# exit
opadmin(config-net)# interface dirty
opadmin(config-net-dirty)# ip address 192.168.99.5 255.255.255.0
opadmin(config-net-dirty)# gateway 192.168.99.1
opadmin(config-net-dirty)# exit
opadmin(config-net)# commit

The dirty interface routing is critical — it must have unrestricted (but monitored) internet egress. If you sandbox malware and it can’t reach out to its C2 infrastructure, you’ll get an incomplete behavioral picture. Many first-time implementations fail here because network security teams reflexively lock down every interface, defeating the entire purpose of the dirty network.

Step 3: Integrate Threat Grid with Cisco Secure Firewall (Firepower)

On your Firepower Management Center (FMC), enable Threat Grid as your malware and file analysis cloud connection:

1. Navigate to System > Integration > Cloud Services
2. Enable Cisco Success Network and Threat Grid Cloud
3. Under Policies > Access Control > Malware & File Policy, create a new file policy

For CLI-based verification on the managed FTD device:

> show cloud-connector status
Cloud Connector Status: Enabled
Threat Grid Integration: Active
Last Sample Submission: 2026-07-28 14:22:03 UTC

Configure a File Policy rule to send unknown SHA256 files for dynamic analysis:

File Policy: Malware-Detection-Policy
Rule 1:
  Application Protocol: Any
  Direction: Any
  File Type Category: Executables, PDF files, Office Documents
  Action: Block Malware
  Advanced: Spero Analysis for MSEXE, Dynamic Analysis (Threat Grid) enabled

Step 4: Integrate with Cisco Secure Email

On the Email Security Appliance (ESA), enable File Analysis under the mail policies:

esa.example.com> mailconfig
Choose the operation you want to perform:
- SETUP - Configure global settings
> setup

Enable File Reputation and File Analysis? [Y]: Y
Threat Grid Cloud URL: https://panacea.threatgrid.com
API Key: <your-org-api-key>

Then verify:

esa.example.com> filereputationconfig

File reputation service: Enabled
File analysis service: Enabled
Cloud server: panacea.threatgrid.com
Connection status: Connected

Step 5: Integrate with Cisco Secure Endpoint (AMP for Endpoints)

In the Secure Endpoint console (securex.us.security.cisco.com or your regional console):

1. Go to Management > Policies
2. Edit your endpoint policy
3. Under File Analysis, set unknown executable behavior to “Auto-submit low prevalence executables”
4. Ensure the connector is at least version 7.x for full sandbox submission support

On an endpoint, verify connector status via CLI:

C:\Program Files\Cisco\AMP\> sfc.exe -c
Connector GUID: a1b2c3d4-....
Threat Grid Submission: Enabled
Cloud: US-East
Policy Serial: 4521

Step 6: API-Based Sample Submission (Custom Integration)

For SOC teams building custom workflows, Threat Grid exposes a REST API. Submitting a sample manually for testing:

curl -H "Authorization: Bearer <API_KEY>" \
  -F "sample=@suspicious_file.exe" \
  -F "private=true" \
  https://panacea.threatgrid.com/api/v3/samples

Retrieving the analysis report once processing completes:

curl -H "Authorization: Bearer <API_KEY>" \
  https://panacea.threatgrid.com/api/v3/samples/<sample-id>/analysis.json

Expected JSON output includes a threat_score (0–100), behavioral indicators, and network artifacts observed during detonation.

Verification and Testing

Use the EICAR test file or, better, Cisco’s own documented safe test samples to confirm the pipeline works end-to-end without submitting live malware into your lab.

Check appliance health:

opadmin# show status
System Status: Operational
Disk Usage: 42%
Queue Depth: 3 samples pending
Last Successful Analysis: 2026-07-29 09:14:11 UTC

Check integration logs on FMC:

> show file-events | include Dynamic Analysis
2026-07-29 09:10:02 | Dynamic Analysis Submitted | invoice_2026.doc | SHA256: 9f8a...
2026-07-29 09:12:45 | Dynamic Analysis Result | Score: 95 | Verdict: Malicious

Real-World Enterprise Scenario

Picture a mid-size financial services company receiving roughly 40,000 emails daily. Before Threat Grid, their email gateway relied purely on reputation and signature filtering — effective against known threats but blind to a new banking trojan variant delivered via a macro-enabled invoice document. After integrating Threat Grid with their ESA, every unrecognized attachment gets detonated automatically. The sandbox observes the macro spawning PowerShell, which then attempts to download a second-stage payload from a newly registered domain — a classic malicious pattern. The file gets quarantined before it ever reaches an inbox, and the IOC (the malicious domain) is automatically pushed to their Umbrella DNS policies to block it network-wide, even for machines that might already be compromised through other vectors.

This is the real value: one detonation event generates protection across multiple layers of the security stack simultaneously.

Best Practices

• Isolate the dirty network completely. Never let it touch production VLANs, even accidentally through misconfigured routing.
• Tune your file policies. Sandboxing every single file type kills performance and creates alert fatigue. Focus on high-risk categories: executables, Office documents with macros, PDFs, and archives.
• Set retrospective alerting. Files judged clean today can be reclassified malicious tomorrow as global intelligence updates — make sure retrospective detection notifications are enabled in Secure Endpoint.
• Regularly review the dirty interface bandwidth. Malware beaconing behavior can spike egress traffic; monitor it like any other segment.
• Rotate API keys used for custom integrations every 90 days.

Common Configuration Mistakes

1. Blocking the dirty interface’s internet access — defeats dynamic analysis entirely; malware just sits idle with nothing to observe.
2. Forgetting to renew appliance SSL certificates, which silently breaks cloud intelligence sync.
3. Submitting files with private=false unintentionally, sharing potentially sensitive internal documents with the broader community sample pool.
4. Not correlating verdicts across products — treating Threat Grid as a standalone tool instead of feeding its output into firewall and DNS policy automatically.
5. Ignoring appliance disk capacity, which fills up quickly under high sample volume and silently drops new submissions.

Performance Tuning

• Increase the sample analysis VM pool on the appliance if you’re consistently seeing queue depth above 10–15 pending samples during peak hours.
• Use file-type pre-filtering upstream (on the firewall or email gateway) so only genuinely ambiguous files reach the sandbox, reducing unnecessary load.
• For high-throughput environments, consider a clustered TGA deployment rather than a single appliance.

Troubleshooting

Samples stuck in “pending” indefinitely: Check dirty interface connectivity first — this is the number one cause. Run opadmin# show network dirty to confirm the interface is up and has a valid route.

Integration shows “disconnected” on FMC or ESA: Usually an API key mismatch or expired certificate. Regenerate the API key from the Threat Grid organization admin panel and re-enter it.

High false-positive rate: Review your sandbox VM images — outdated or unpatched sandbox OS images can trigger unusual behavior unrelated to the actual sample, skewing scores.

FAQs

Does Threat Grid replace traditional antivirus? No. It complements signature-based detection by catching unknown and zero-day threats that signatures miss. Run both in tandem.

Can Threat Grid analyze non-Windows files? Yes, more recent appliance versions support Android APKs and limited macOS analysis alongside the traditional Windows sandbox VMs.

How long does a typical analysis take? Most samples complete dynamic analysis in 5–15 minutes, though this depends on queue depth and whether the malware employs sandbox-evasion delay tactics.

Is cloud or on-premises better? Cloud is faster to deploy and requires no hardware maintenance. On-premises is necessary when compliance mandates that files never leave your network boundary.

Summary

Cisco Threat Grid closes a real gap that signature-based tools can’t cover: unknown, zero-day, and evasive malware that behaves maliciously but doesn’t match any existing pattern. Implementing it properly means understanding the dirty-network architecture, integrating it thoughtfully across your email, firewall, and endpoint products, and tuning file policies so you’re sandboxing the right files without drowning your SOC in noise. Done right, it turns a single malicious file detonation into network-wide protection within minutes.

References

• Cisco Threat Grid Appliance Administrator Guide — cisco.com/c/en/us/support/security/amp-threat-grid-appliances
• Cisco Secure Firewall Management Center Configuration Guide — cisco.com/c/en/us/support/security/defense-center
• Cisco Secure Endpoint User Guide — cisco.com/c/en/us/support/security/amp-endpoints
• Cisco Threat Grid API Documentation — Cisco DevNet portal

The post How to Implement Cisco Threat Grid for Advanced Threat Analysis and Malware Detection appeared first on Abdul Wahab Junaid.

Understanding Intent-Based Networking

Before diving into setup steps, it’s worth understanding the paradigm shift. Traditional networking is imperative — you log into each device and type the exact commands needed. Intent-based networking is declarative — you define a policy (“this VLAN needs this QoS treatment across the whole campus”) and DNA Center translates that into the appropriate configuration for every switch, router, and wireless controller in scope, then continuously verifies the network matches that intent.

DNA Center’s architecture rests on a few pillars:

• Design — network hierarchy, sites, IP address pools, and templates
• Policy — group-based access control, application policies, and segmentation
• Provision — pushing configuration to devices based on design and policy
• Assurance — continuous telemetry and AI-driven analytics validating the network is behaving as intended

Networking Fundamentals You Need First

DNA Center leans heavily on a few underlying technologies you should understand before deployment:

• Cisco SD-Access uses LISP (Locator/ID Separation Protocol) for the control plane and VXLAN for the data plane, decoupling a device’s identity from its location — this is what enables consistent policy enforcement as users roam across the campus.
• Cisco TrustSec provides Security Group Tags (SGTs) for identity-based segmentation instead of traditional VLAN-based ACLs.
• NETCONF/RESTCONF and YANG models are the underlying protocols DNA Center uses to push structured configuration to devices, replacing screen-scraped CLI automation.

Pre-Deployment Planning

Before racking anything, map out:

1. Physical appliance sizing — DNA Center ships as a physical appliance (DN2-HW-APL series) or scalable cluster; sizing depends on device count (small: <1,000 devices, medium: up to 5,000, large: up to 25,000+)
2. Network hierarchy — Areas, Buildings, and Floors need to mirror your actual physical topology for accurate assurance and location-based analytics
3. IP address pool planning — SD-Access fabric requires dedicated pools for underlay and overlay networks
4. Device readiness — minimum IOS-XE versions required for full DNA Center management (generally 16.x or later; verify per platform)

Step-by-Step Implementation

Step 1: Initial Appliance Configuration

Connect to the appliance console and run the initial configuration wizard:

Welcome to Cisco DNA Center Configuration Wizard

Enter Enterprise DHCP server: 10.1.1.10
Enter Enterprise DNS server(s): 10.1.1.10, 10.1.1.11
Enter Cluster Virtual IP: 10.1.1.50
Enter Network Adapter for Enterprise: eth0
Enter Network Adapter for Management: eth1
Configure NTP server: 10.1.1.5

After the wizard completes and services initialize (this can take 30–60 minutes on first boot), access the GUI at https://<cluster-VIP>.

Step 2: Define Your Network Hierarchy

Under Design > Network Hierarchy, build out your site structure:

Global
 └─ Area: North-America
     └─ Building: HQ-Campus
         ├─ Floor: Floor-1
         ├─ Floor: Floor-2
         └─ Floor: Floor-3
     └─ Building: Branch-Chicago

This isn’t cosmetic — assurance analytics, wireless heatmaps, and fabric provisioning are all scoped to this hierarchy.

Step 3: Configure Network Settings and Credentials

Under Design > Network Settings, define:

AAA Server: ISE (10.1.1.20)
Shared Secret: <configured>
NTP Server: 10.1.1.5
DHCP Server: 10.1.1.10
DNS Server: 10.1.1.10
Syslog Server: 10.1.1.30
SNMP Credentials: Read/Write community strings
CLI Credentials: netadmin / <encrypted>

Devices must be reachable via SSH and SNMP with these credentials for discovery to succeed.

Step 4: Discover Devices

Navigate to Provision > Inventory > Discovery, and configure an IP range or CDP-based discovery seed:

Discovery Name: Campus-Discovery-01
Discovery Type: CDP
Seed IP: 10.1.1.1
CDP Level: 16
Preferred Management IP: Use Loopback

Run discovery and verify devices land in inventory:

show network-device count
Total Devices Discovered: 142
Reachable: 140
Unreachable: 2

On the actual device CLI, confirm SNMP and SSH are correctly enabled to support this:

switch(config)# snmp-server community DNACread RO
switch(config)# ip ssh version 2
switch(config)# username netadmin privilege 15 secret <password>

Step 5: Assign Devices to Sites

Once discovered, assign each device under Provision > Inventory to its corresponding site in the hierarchy. This step is mandatory before any provisioning or SD-Access fabric work can proceed.

Step 6: Build the SD-Access Fabric

Under Provision > Fabric Sites, create a fabric domain:

Fabric Name: Campus-Fabric-01
Associated Site: HQ-Campus

Designate fabric roles for your devices:

• Control Plane Node — typically a core switch or dedicated appliance running LISP
• Border Node — connects the fabric to the external network (internet, data center)
• Edge Node — access layer switches where endpoints connect

Device: Core-SW-01 → Role: Control Plane + Border
Device: Access-SW-01 → Role: Edge Node
Device: Access-SW-02 → Role: Edge Node

Underlying LISP configuration pushed automatically resembles:

router lisp
 locator-set RLOC-Campus
  10.1.1.1 priority 1 weight 100
 !
 instance-id 4099
  service ipv4
   eid-table vlan 10
   map-server
   map-resolver

You don’t type this manually — DNA Center generates and pushes it — but understanding what’s happening under the hood is critical for troubleshooting.

Step 7: Define Virtual Networks and Segmentation

Under Policy > Virtual Network, create VNs mapped to business intent, such as separating IoT devices, guest traffic, and corporate endpoints:

Virtual Network: VN-Corporate
Virtual Network: VN-IoT
Virtual Network: VN-Guest

Then define group-based access control policies under Policy > Group-Based Access Control:

Source SGT: Employees (SGT 10)
Destination SGT: Servers (SGT 20)
Access Contract: Permit-HTTPS-Only

This pushes SGACL policy to devices via TrustSec, enforcing segmentation without needing per-device ACLs.

Step 8: Provision and Verify

Push the fabric configuration:

Provision > Fabric Sites > Campus-Fabric-01 > Provision Devices

Verify fabric status on the actual switch:

switch# show fabric edge summary
Fabric Role: Edge Node
Fabric Status: Enabled
Control Plane Reachability: Reachable
VNI Count: 3

Check LISP registration:

switch# show lisp session
Sessions for VRF default, total: 1, established: 1
Peer                          State    Up/Down     In/Out
10.1.1.1                      Up       02:14:33    142/138

Real-World Enterprise Scenario

Consider a healthcare campus with 30 buildings, thousands of medical IoT devices, guest Wi-Fi for patients, and strict compliance requirements around segmenting clinical devices from general corporate traffic. Manually maintaining VLAN-based segmentation across that many access switches would require constant, error-prone updates every time a device moves or a new building comes online.

With DNA Center and SD-Access, the organization defines a “Clinical-IoT” virtual network once. As infusion pumps and monitoring equipment connect anywhere across the campus — even as biomedical staff physically relocate equipment between floors — the fabric automatically applies consistent segmentation and policy based on the device’s group membership rather than its physical port. Assurance dashboards flag any device experiencing packet loss or onboarding failures in real time, letting the network team fix issues before clinical staff even notice a problem.

Best Practices

• Start with a pilot fabric site before rolling SD-Access out campus-wide; validate policy behavior in a controlled segment first.
• Keep IOS-XE versions consistent across fabric devices to avoid feature mismatches during provisioning.
• Use Assurance proactively, not just reactively — set up daily health score reviews rather than waiting for a ticket.
• Document your SGT and VN mapping outside of DNA Center too, since audits often need this at a glance.
• Back up the DNA Center database regularly; a controller failure without backups means rebuilding your entire intent model from scratch.

Common Configuration Mistakes

1. Skipping site hierarchy planning, leading to a flat, unusable structure that has to be rebuilt later.
2. Mismatched SSH/SNMP credentials across the fleet, causing partial discovery failures that are tedious to debug device-by-device.
3. Assigning fabric roles without underlay connectivity verified first — the underlay (basic IP reachability) must work before the LISP/VXLAN overlay can succeed.
4. Not isolating a test fabric site, pushing fabric-wide changes directly into production and causing outages.
5. Ignoring certificate warnings during appliance setup, leading to broken trust between DNA Center and ISE for pxGrid integration.

Performance Tuning

• Right-size your DNA Center cluster from the start; undersized single-node deployments struggle with device counts beyond their rated capacity.
• Stagger telemetry collection intervals in Assurance settings for very large device counts to avoid overwhelming the collector.
• Use software image management (SWIM) golden images and scheduled maintenance windows for firmware upgrades rather than manual per-device upgrades.

Troubleshooting

Devices stuck in “Unreachable” during discovery: Verify SNMP community strings and SSH credentials match exactly what’s configured on the device; also check ACLs blocking DNA Center’s management IP.

Fabric provisioning fails at LISP registration: Confirm underlay routing (typically ISIS or OSPF) is fully converged between control plane and edge nodes before fabric provisioning.

Assurance shows “Health Score: Poor” with no obvious cause: Check for interface errors, high CPU, or an outdated IOS-XE version — Assurance heavily weights these in its scoring algorithm.

FAQs

Does DNA Center support non-Cisco devices? Discovery and basic inventory work for some third-party SNMP-capable devices, but full intent-based provisioning and SD-Access fabric features are Cisco-device specific.

Can I run DNA Center virtually instead of on physical appliances? Cisco offers a virtual appliance option for smaller deployments and lab/PoC environments, though production-scale deployments typically use the physical DN2-HW-APL cluster.

How is DNA Center licensed? Through Cisco DNA subscription tiers (Essentials, Advantage, Premier), which also gate feature availability like SD-Access and advanced Assurance analytics.

What happens if the DNA Center cluster goes down — does the network stop working? No. Already-provisioned configuration remains on devices and continues functioning; you lose centralized management and new provisioning capability until the controller is restored.

Summary

Cisco DNA Center represents a genuine shift in how enterprise networks get built and maintained — from manually typing configuration into hundreds of individual devices to defining intent once and letting the controller handle consistent, policy-driven provisioning across the fabric. The learning curve involves understanding SD-Access, LISP, VXLAN, and TrustSec concepts underneath the GUI, but the operational payoff — consistent segmentation, faster troubleshooting through Assurance, and dramatically reduced configuration drift — is substantial for any network beyond a handful of devices.

References

• Cisco DNA Center Installation Guide — cisco.com/c/en/us/support/cloud-systems-management/dna-center
• Cisco SD-Access Solution Design Guide — cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access
• Cisco DNA Center Assurance User Guide — cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center
• Cisco TrustSec Configuration Guide — cisco.com/c/en/us/solutions/enterprise-networks/trustsec

The post How to Set Up Cisco DNA Center for Network Automation and Intent-Based Networking appeared first on Abdul Wahab Junaid.

Understanding CUCM’s Role in the Voice Architecture

CUCM is the call processing engine of a Cisco IP telephony deployment. It handles call setup, teardown, routing, feature invocation (hold, transfer, conference), and endpoint registration for IP phones, softphones, and gateways. It doesn’t carry voice traffic itself — that’s the job of the media (RTP) stream flowing directly between endpoints or through a media resource — CUCM handles the signaling layer using protocols like SCCP (Skinny Client Control Protocol) and SIP.

VoIP Fundamentals Before Configuration

A few core concepts underpin everything you’ll configure:

• Signaling vs. Media: CUCM controls call signaling (SIP/SCCP); actual voice packets flow as RTP streams, often directly between phones once the call is established.
• Codecs: G.711 offers the best quality but consumes the most bandwidth (~64 kbps plus overhead); G.729 compresses audio to around 8 kbps, ideal for WAN links but with a slight quality tradeoff.
• QoS: Voice traffic is extremely sensitive to jitter and latency (ITU recommends under 150ms one-way latency, under 30ms jitter). Without proper DSCP marking and priority queuing, voice quality degrades badly under network congestion.
• Dial Plan: The logical structure that determines how digits dialed by a user get routed — internally, to voicemail, or out to the PSTN via a gateway or SIP trunk.

Pre-Deployment Planning

1. Cluster sizing — determine how many CUCM nodes you need (Publisher + Subscribers) based on endpoint count and redundancy requirements
2. Codec and bandwidth planning — especially critical for branch offices connected over limited WAN links
3. Dial plan design — partition and calling search space (CSS) structure needs to be mapped before phones start getting configured
4. PSTN connectivity — SIP trunk to a provider, or traditional PRI/gateway-based trunking

Step-by-Step Implementation

Step 1: Initial CUCM Installation and Cluster Setup

CUCM is deployed as a virtual appliance (OVA) on ESXi. After OS installation via the platform installation wizard, the Publisher node is configured first:

Administrator Login Configuration:
  Username: ccmadmin
  Password: <strong-password>

Network Configuration:
  Hostname: cucm-pub-01
  IP Address: 10.2.1.10
  Subnet Mask: 255.255.255.0
  Gateway: 10.2.1.1
  DNS: 10.1.1.10

NTP Server: 10.1.1.5 (mandatory — CUCM is extremely NTP-sensitive)

Subscriber nodes are added afterward via System > Server in CUCM Administration, pointing to the Publisher for database replication.

Step 2: Configure Core System Settings

Log into CUCM Administration at https://cucm-pub-01/ccmadmin. Under System > CallManager Group, define your CallManager Group for redundancy:

CallManager Group Name: HQ-CM-Group
Members: cucm-pub-01, cucm-sub-01

Under System > Date/Time Group and System > Region Information > Region, define your codec regions:

Region: HQ-Region
Max Audio Bit Rate: G.711 (within site)
Region: WAN-Branch-Region
Max Audio Bit Rate: G.729 (across WAN link)

Step 3: Configure Device Pools

Device pools bundle together region, CallManager group, date/time group, and other settings applied to phones:

Device Pool Name: HQ-DevicePool
CallManager Group: HQ-CM-Group
Date/Time Group: HQ-DateTime
Region: HQ-Region
Media Resource Group List: HQ-MRGL

Step 4: Build the Dial Plan — Partitions and Calling Search Spaces

This is where most poorly planned deployments start showing cracks. Partitions group dialable patterns; Calling Search Spaces (CSS) determine which partitions a device can reach.

Route Partition: PT-Internal
Route Partition: PT-Voicemail
Route Partition: PT-Local-PSTN
Route Partition: PT-LongDistance
Route Partition: PT-International

Calling Search Space: CSS-Employee
  Partitions: PT-Internal, PT-Voicemail, PT-Local-PSTN, PT-LongDistance

Calling Search Space: CSS-Executive
  Partitions: PT-Internal, PT-Voicemail, PT-Local-PSTN, PT-LongDistance, PT-International

Calling Search Space: CSS-Lobby-Phone
  Partitions: PT-Internal

This structure lets you restrict a lobby phone to internal-only calls while executives get full international dialing — all through CSS/partition combinations rather than per-device restriction lists.

Step 5: Configure Route Patterns and Route Groups for PSTN Access

Assuming a SIP trunk to your carrier:

SIP Trunk Configuration:
  Trunk Name: SIP-Trunk-Carrier01
  Destination Address: 203.0.113.10
  Destination Port: 5060
  SIP Trunk Security Profile: Non-Secure-SIP-Trunk

Route Group: RG-PSTN-Primary
  Member: SIP-Trunk-Carrier01

Route List: RL-PSTN-Outbound
  Route Group: RG-PSTN-Primary

Route Pattern: 9.@
  Partition: PT-Local-PSTN
  Gateway/Route List: RL-PSTN-Outbound
  Discard Digits: PreDot

The 9.@ pattern is the classic “dial 9 to get an outside line” pattern, with the @ macro matching the North American Numbering Plan automatically.

Step 6: Configure IP Phones

Phones can be added manually, via bulk administration (BAT), or through auto-registration (not recommended for production due to security concerns). Manual configuration:

Phone Type: Cisco 8865
MAC Address: SEP001A2B3C4D5E
Device Pool: HQ-DevicePool
Calling Search Space: CSS-Employee
Directory Number: 4001
  Partition: PT-Internal
  Voicemail Profile: VM-Default
  Call Forward All: Voicemail

Verify phone registration status via CLI on CUCM:

admin:show cluster nodes
admin:utils diagnose test

admin:show tech phones registered
Phone SEP001A2B3C4D5E registered to cucm-pub-01
Status: Registered
IP Address: 10.2.5.44
Protocol: SCCP

Step 7: Configure QoS Marking End to End

CUCM automatically marks signaling and media with DSCP values, but your network infrastructure must honor and trust these markings. On the access-layer switch:

switch(config)# mls qos
switch(config-if)# interface GigabitEthernet1/0/1
switch(config-if)# switchport voice vlan 110
switch(config-if)# mls qos trust device cisco-phone
switch(config-if)# mls qos trust cos

At the WAN edge router, apply priority queuing for voice traffic:

router(config)# class-map match-all VOICE
router(config-cmap)# match dscp ef
router(config)# policy-map WAN-QOS
router(config-pmap)# class VOICE
router(config-pmap-c)# priority percent 20
router(config)# interface Serial0/0/0
router(config-if)# service-policy output WAN-QOS

Verify DSCP marking is present on outgoing voice traffic using a packet capture or:

router# show policy-map interface Serial0/0/0
  Class-map: VOICE (match-all)
    5000 packets, 320000 bytes
    Priority: 20% (200 kbps), burst 5000 bytes

Step 8: Configure Media Resources (Conferencing, MOH, Transcoding)

Music On Hold Server: MOH-Server-01
Conference Bridge: CFB-Software-01
  Max Sessions: 48
Transcoder: XCODE-Gateway-01

Media Resource Group: MRG-HQ
  Members: MOH-Server-01, CFB-Software-01

Media Resource Group List: HQ-MRGL
  Priority 1: MRG-HQ

Real-World Enterprise Scenario

Consider a company with a headquarters and three branch offices connected via a WAN with limited bandwidth. Without proper region configuration, all calls default to G.711, and during a Monday morning surge of branch-to-HQ calls, the WAN link saturates, causing choppy audio company-wide. After implementing region-based codec selection (G.729 across the WAN link, G.711 for local calls) combined with LLQ (low latency queuing) on the WAN routers, voice quality issues disappear even during peak call volume, because voice packets get prioritized ahead of bulk data transfers and the codec itself uses a fraction of the bandwidth.

Best Practices

• Always configure redundant CallManager groups — a single point of failure for call processing is unacceptable in production.
• Use SRST (Survivable Remote Site Telephony) on branch routers so phones retain basic calling capability if WAN connectivity to the central CUCM cluster drops.
• Standardize on CSS/Partition naming conventions early — retrofitting a poorly named dial plan across thousands of phones is painful.
• Enable device-level and phone-level security profiles (TLS/SRTP) rather than leaving trunks and phones on non-secure profiles.
• Monitor via Real-Time Monitoring Tool (RTMT) proactively rather than waiting for user complaints.

Common Configuration Mistakes

1. Skipping NTP configuration — CUCM is extremely time-sensitive; clock drift breaks certificate validation and call detail record accuracy.
2. Using a single flat CSS for all devices, eliminating any meaningful call restriction capability.
3. Forgetting to trust QoS markings on access switches, causing voice packets to be treated as best-effort traffic.
4. Not planning codec regions, leading to G.711 traffic saturating WAN links.
5. Auto-registering phones in production, creating a security gap where any device plugged into a voice VLAN gets a directory number.

Performance Tuning

• Use G.729 selectively — only where bandwidth is genuinely constrained, since it does have measurable quality tradeoffs versus G.711.
• Enable Call Admission Control (CAC) via locations to prevent oversubscribing limited-bandwidth WAN links during high call volume.
• Tune RTMT alert thresholds for CPU, memory, and call processing metrics rather than relying on defaults.

Troubleshooting

Phones stuck in “Registering” state: Check DHCP option 150 (TFTP server address) delivery and verify the phone can reach CUCM on TCP 2000 (SCCP) or 5060 (SIP).

One-way audio: Almost always a NAT/firewall traversal issue with the RTP stream, or asymmetric routing between endpoints — check media resource and region path config.

Calls dropping after exactly 32 seconds: Classic symptom of an ALG (Application Layer Gateway) interfering with SIP signaling on a firewall — disable SIP ALG/fixup.

FAQs

Is CallManager the same as CUCM? Yes — “CallManager” is the legacy name; Cisco Unified Communications Manager (CUCM) is the current official product name.

Can CUCM integrate with Microsoft Teams? Yes, through Cisco’s Unified Communications integrations and SIP trunking, though native feature parity depends on the specific integration approach used.

How many phones can a single CUCM cluster support? Cluster capacity varies by OVA sizing template, ranging from a few hundred to tens of thousands of endpoints across a properly sized multi-node cluster.

Do I need separate voice VLANs? Yes, strongly recommended — separating voice and data VLANs simplifies QoS policy and improves security segmentation.

Summary

Configuring CUCM properly means thinking beyond just getting phones to register — it requires deliberate dial plan architecture, codec and region planning matched to your WAN topology, and end-to-end QoS that your network infrastructure actually honors. Skipping any of these fundamentals is exactly how organizations end up with the classic “the new phone system sounds worse than the old one” complaint. Get the foundation right, and CUCM delivers the flexibility and features that made IP telephony worth the migration in the first place.

References

• Cisco Unified Communications Manager Administration Guide — cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager
• Cisco Collaboration System Solution Reference Network Designs (SRND) — cisco.com/c/en/us/solutions/collaboration
• Cisco QoS Design Guide for Voice — cisco.com/c/en/us/td/docs/solutions/Enterprise/QoS_SRND
• Cisco SRST Configuration Guide — cisco.com/c/en/us/support/unified-communications/unified-survivable-remote-site-telephony

The post How to Configure Cisco CallManager for IP Telephony and VoIP Deployment appeared first on Abdul Wahab Junaid.

What Unity Express Is (and Isn’t)

Unity Express is a voicemail and auto-attendant solution embedded in a Cisco Integrated Services Router (ISR) — either as a Network Module (NM), Advanced Integration Module (AIM), or in later generations, a virtualized service module. It integrates with Cisco Unified Communications Manager Express (CME) or full CUCM to provide:

• Voicemail box per extension
• Auto-attendant (AA) call routing menus
• Basic unified messaging (voicemail-to-email)
• Simple IVR scripting for branch-level call handling

It’s important to understand what CUE is not: it’s not designed for large-scale enterprise deployments (that’s Unity Connection’s job), and it has hard capacity limits depending on the hardware module — typically topping out around 250 mailboxes on higher-end modules.

Fundamentals: How CUE Fits Into the Call Flow

When a call comes into a branch office and isn’t answered, CUCM Express (or CUCM) forwards it to CUE using SCCP or SIP integration, depending on your deployment. CUE then plays the appropriate greeting, records the message, and — if unified messaging is configured — forwards that message as a WAV attachment via SMTP to the user’s email inbox.

The two integration modes matter a lot for how you configure things:

• SCCP Integration — traditional, tightly coupled with CUCME, phones’ Messages button lights up natively
• SIP Integration — more flexible, works with either CUCME or full CUCM, increasingly the preferred modern approach

Pre-Deployment Planning

1. Determine your integration mode (SCCP vs. SIP) based on whether you’re running CUCME or full CUCM at the site
2. Mailbox capacity planning against your hardware module’s supported limits
3. SMTP relay availability if you want voicemail-to-email unified messaging
4. Storage sizing — voicemail messages consume flash/disk space on the module; plan retention policies accordingly

Step-by-Step Implementation

Step 1: Verify Module Installation and Initial Access

Once the CUE module is physically installed in the router, verify it’s recognized:

router# show interface | include Service-Engine
Service-Engine1/0 is up, line protocol is up

router# service-module service-Engine 1/0 status
Service Module is Cisco service-Engine1/0
Service Module supports session via TTY line
Service Module is in Steady state

Access the CUE module’s own CLI via a session:

router# service-module service-Engine 1/0 session
Trying 10.1.1.1, 2066 ... Open

CUE-Module> enable
CUE-Module# configure terminal

Step 2: Configure Basic Network Settings on the CUE Module

CUE-Module(config)# ip address 10.1.1.1 255.255.255.0
CUE-Module(config)# ip default-gateway 10.1.1.254
CUE-Module(config)# ip domain-name company.local
CUE-Module(config)# ip name-server 10.1.1.10
CUE-Module(config)# clock timezone CST -6
CUE-Module(config)# ntp server 10.1.1.5

Step 3: Configure CUCM Express Integration (SCCP Mode)

On the router hosting CUCM Express, define the CUE module as a voicemail service:

router(config)# telephony-service
router(config-telephony)# max-ephones 48
router(config-telephony)# max-dn 96
router(config-telephony)# voicemail 4000
router(config-telephony)# max-conferences 8
router(config-telephony)# exit

router(config)# ephone-dn 1
router(config-ephone-dn)# number 4000
router(config-ephone-dn)# name Voicemail

On the CUE module side, configure the SCCP integration parameters:

CUE-Module(config)# ccn subsystem sccp
CUE-Module(config-sccp)# ip source-address 10.1.1.1 port 2000
CUE-Module(config-sccp)# max-ephones 48
CUE-Module(config-sccp)# max-dn 96
CUE-Module(config-sccp)# exit

Step 4: Alternative — SIP Integration Mode

For SIP-based integration (recommended for newer deployments or full CUCM environments):

CUE-Module(config)# ccn subsystem sip
CUE-Module(config-sip)# gateway address 10.1.1.254 port 5060
CUE-Module(config-sip)# max-sessions 8
CUE-Module(config-sip)# exit

On CUCM, configure the CUE module as a SIP trunk destination for voicemail routing:

SIP Trunk Name: SIP-Trunk-CUE
Destination Address: 10.1.1.1
Destination Port: 5060

Voicemail Pilot: 4000
Voicemail Profile: VM-Branch-Default
  Voicemail Pilot: 4000

Step 5: Configure Voicemail Boxes

Back on the CUE module CLI, define subscribers (mailbox owners):

CUE-Module(config)# username jsmith create
CUE-Module(config-user)# phonenumber 4001
CUE-Module(config-user)# firstname John
CUE-Module(config-user)# lastname Smith
CUE-Module(config-user)# email jsmith@company.local
CUE-Module(config-user)# pin 135790
CUE-Module(config-user)# exit

Bulk provisioning for larger branch sites is possible via CSV import through the GUI (https://<CUE-IP>/ccn), which is far more practical than manual entry beyond a handful of users.

Step 6: Configure Unified Messaging (Voicemail-to-Email)

CUE-Module(config)# ccn subsystem sip
CUE-Module(config-sip)# exit
CUE-Module(config)# mailbox owner jsmith
CUE-Module(config-mailbox)# notification-preference imap
CUE-Module(config-mailbox)# exit

CUE-Module(config)# smtp server address 10.1.1.15 port 25
CUE-Module(config)# smtp server timeout 30

Verify SMTP connectivity for message forwarding:

CUE-Module# test smtp-server
Connecting to 10.1.1.15:25 ... Success
SMTP handshake: OK

Step 7: Configure Auto-Attendant (AA)

Auto-attendant scripts route incoming calls through menu options (e.g., “Press 1 for Sales, Press 2 for Support”). Using the built-in default script:

CUE-Module(config)# ccn application AABranchMain
CUE-Module(config-application)# description "Branch Main Auto Attendant"
CUE-Module(config-application)# script "aa.aef"
CUE-Module(config-application)# parameter "MaxRetry" "3"
CUE-Module(config-application)# parameter "operExtn" "4000"
CUE-Module(config-application)# parameter "welcomePrompt" "AABranchWelcome.wav"
CUE-Module(config-application)# exit

CUE-Module(config)# ccn trigger sip phonenumber 4100
CUE-Module(config-trigger)# application AABranchMain
CUE-Module(config-trigger)# enabled
CUE-Module(config-trigger)# exit

Custom greeting prompts get uploaded through the CUE GUI under Voice Mail > Prompts, since recording high-quality WAV prompts via CLI isn’t practical.

Step 8: Verification and Testing

Check overall module status:

CUE-Module# show ccn subsystem sccp
SCCP Subsystem is READY
Number of active calls: 3
Number of registered ephones: 46/48

CUE-Module# show voice mail status
Voicemail System Status: In Service
Total Mailboxes: 46
Storage Used: 210MB / 1024MB

Test a mailbox greeting playback and confirm SMTP delivery by leaving a test voicemail and checking the recipient’s inbox for the WAV attachment.

Real-World Enterprise Scenario

A regional insurance company with 15 small branch offices, each with 20–40 employees, needed voicemail without the cost of provisioning full Unity Connection licensing at every site. Deploying CUE modules integrated with CUCME at each branch gave every employee a functioning voicemail box with email notification, and a simple auto-attendant handled after-hours calls routing to the appropriate regional on-call number. Because CUE runs directly on the branch router hardware they already had for WAN connectivity, there was no additional server hardware to rack, patch, or maintain at each site — a meaningful operational win for a company without dedicated branch-level IT staff.

Best Practices

• Enforce strong PIN policies for voicemail boxes — default or weak PINs are a common toll-fraud vector when auto-attendants allow external transfer options.
• Regularly monitor storage utilization — full mailboxes silently stop accepting new messages, frustrating users who don’t realize why callers can’t leave voicemail.
• Keep auto-attendant menus short — more than 4–5 options per menu frustrates callers; use nested menus sparingly.
• Back up the CUE configuration and mailbox data before any IOS or module firmware upgrade.
• Disable unused features like external call transfer from auto-attendant if not explicitly required, reducing toll-fraud exposure.

Common Configuration Mistakes

1. Mismatched max-ephones/max-dn values between CUCME and the CUE module, causing registration failures.
2. Forgetting SMTP relay authentication requirements, silently breaking voicemail-to-email even though local voicemail still works fine.
3. Weak or default PINs left unchanged, creating security exposure.
4. Not planning storage capacity, leading to full mailboxes during high call volume periods like holidays.
5. Overly complex auto-attendant trees that frustrate callers instead of helping them.

Performance Tuning

• Adjust max-sessions for SIP integration based on actual concurrent voicemail/AA usage patterns rather than defaults.
• Periodically archive or purge old voicemail messages according to a defined retention policy to keep storage headroom healthy.
• Use G.729 codec for voicemail prompts on bandwidth-constrained WAN links if CUE is centralized rather than local to the branch.

Troubleshooting

Messages button on phones doesn’t light up: Check the SCCP integration’s max-dn/max-ephones alignment and confirm the voicemail pilot number matches on both CUCME and CUE.

Voicemail-to-email not arriving: Test SMTP connectivity directly from the module (test smtp-server) and check for relay authentication or firewall blocking port 25 outbound.

Auto-attendant plays default prompt instead of custom greeting: Confirm the custom WAV file was uploaded correctly and referenced by the correct filename in the application’s welcomePrompt parameter — filename mismatches are the most common cause.

FAQs

Is Cisco Unity Express still sold and supported? CUE reached end-of-sale status for most hardware platforms; existing deployments remain supported per Cisco’s standard lifecycle policy, but new deployments increasingly favor cloud-based or Unity Connection solutions — check current Cisco EoL bulletins before new purchases.

Can CUE integrate with full CUCM instead of just CUCM Express? Yes, via SIP integration, CUE can serve as a branch voicemail solution even when the call processing is handled by a centralized CUCM cluster.

What’s the maximum mailbox capacity? It depends on the specific hardware module (NM, AIM, or service module variant) — ranges generally span from around 6 to 250 mailboxes.

Does CUE support visual voicemail? Limited support depending on phone model and firmware; it’s primarily an audio-based voicemail system with basic web access rather than a full visual voicemail experience.

Summary

Cisco Unity Express fills a specific and valuable niche: dependable, low-maintenance voicemail and auto-attendant functionality for branch offices that don’t need the scale of a full Unity Connection deployment. The setup process comes down to getting the SCCP or SIP integration correctly aligned between CUCME/CUCM and the module, provisioning mailboxes with sane security policies, and testing unified messaging delivery end to end. Once configured, it tends to run quietly in the background for years with minimal intervention — exactly what a branch office needs.

References

• Cisco Unity Express Administration Guide — cisco.com/c/en/us/support/unified-communications/unity-express
• Cisco Unified CME and CUE Integration Guide — cisco.com/c/en/us/support/unified-communications/unified-communications-manager-express
• Cisco Unity Express End-of-Life Bulletins — cisco.com/c/en/us/products/eos-eol-listing
• Cisco Voice and Unified Communications Command Reference — cisco.com/c/en/us/td/docs/voice_ip_comm

The post How to Set Up Cisco Unity Express for Voicemail and Unified Messaging appeared first on Abdul Wahab Junaid.

Understanding WPA and WPA2 Fundamentals

WPA (Wi-Fi Protected Access) was introduced as an interim fix for WEP’s well-documented vulnerabilities, using TKIP (Temporal Key Integrity Protocol) for encryption. WPA2 followed with full 802.11i compliance, replacing TKIP with AES-CCMP, a considerably stronger encryption standard. In 2026, TKIP should be considered legacy-only — if you’re deploying new wireless infrastructure, you want WPA2-AES at minimum, ideally with a migration path toward WPA3.

There are two authentication modes that matter:

• WPA2-Personal (PSK) — a single pre-shared key shared across all devices; appropriate for small networks or guest access, but doesn’t scale securely for larger organizations since everyone shares one key
• WPA2-Enterprise (802.1X) — uses RADIUS-based authentication with individual user credentials, typically via EAP methods like PEAP or EAP-TLS; this is what serious enterprise deployments should use

Core Protocol Operations

Understanding the 4-way handshake matters for troubleshooting later. When a client associates to an AP:

1. The AP sends an ANonce (a random value) to the client
2. The client generates its own SNonce, derives a Pairwise Transient Key (PTK), and sends the SNonce back with a MIC (Message Integrity Code)
3. The AP verifies the MIC, derives its own PTK, and sends the Group Temporal Key (GTK) for broadcast/multicast traffic
4. The client confirms receipt and the encrypted session begins

This handshake is also the mechanism that made KRACK attacks possible in older WPA2 implementations — a good reason to keep AP and client firmware current.

Pre-Deployment Planning

1. Choose Personal vs. Enterprise mode based on your environment — enterprise networks with more than a handful of users should almost always use 802.1X
2. RADIUS infrastructure — Cisco ISE or a third-party RADIUS server needs to be in place before configuring Enterprise mode
3. SSID and VLAN mapping — decide whether corporate, guest, and IoT traffic need separate SSIDs mapped to separate VLANs
4. Certificate infrastructure — required if using EAP-TLS for the strongest authentication method

Step-by-Step Implementation

Step 1: Access the Wireless LAN Controller

Log into the WLC GUI (https://<WLC-management-IP>) or via CLI:

(Cisco Controller) >show sysinfo
Manufacturer's Name.............. Cisco Systems Inc.
Product Name..................... Cisco Controller
Version.......................... 8.10.185.0

Step 2: Configure WPA2-Personal (PSK) — Simpler Deployments

Under WLANs > Create New, define the SSID:

WLAN ID: 2
Profile Name: Branch-Guest
SSID: CompanyGuest

Under the Security > Layer 2 tab:

Layer 2 Security: WPA+WPA2
WPA2 Policy: Enabled
WPA2 Encryption: AES
Auth Key Mgmt: PSK
PSK Format: ASCII
Pre-Shared Key: <strong-passphrase-min-12-chars>

Equivalent CLI configuration:

(Cisco Controller) >config wlan create 2 Branch-Guest CompanyGuest
(Cisco Controller) >config wlan security wpa akm psk enable 2
(Cisco Controller) >config wlan security wpa akm psk set-key ascii <passphrase> 2
(Cisco Controller) >config wlan security wpa wpa2 ciphers aes enable 2
(Cisco Controller) >config wlan security wpa wpa1 disable 2
(Cisco Controller) >config wlan enable 2

Important: explicitly disable WPA1/TKIP unless you have legacy devices that genuinely require it — mixed-mode WPA/WPA2 support weakens your overall security posture by keeping the older, broken cipher available.

Step 3: Configure WPA2-Enterprise (802.1X) — Recommended for Corporate SSIDs

First, define the RADIUS server on the WLC under Security > RADIUS > Authentication:

(Cisco Controller) >config radius auth add 1 10.1.1.20 1812 ascii <shared-secret>
(Cisco Controller) >config radius auth enable 1

Create the corporate WLAN:

(Cisco Controller) >config wlan create 1 Corporate-WiFi CorporateSSID
(Cisco Controller) >config wlan security wpa akm 802.1x enable 1
(Cisco Controller) >config wlan security wpa wpa2 ciphers aes enable 1
(Cisco Controller) >config wlan security wpa wpa1 disable 1
(Cisco Controller) >config wlan radius_server auth add 1 1
(Cisco Controller) >config wlan enable 1

Via GUI, under Security > AAA Servers, ensure the RADIUS server is properly associated with the WLAN, and under Security > Layer 2:

Layer 2 Security: WPA+WPA2
Auth Key Mgmt: 802.1X

Step 4: Configure VLAN Mapping and Interface Assignment

Map the SSID to the correct VLAN interface:

(Cisco Controller) >config interface create Corp-VLAN10 10
(Cisco Controller) >config interface address dynamic-interface Corp-VLAN10 10.5.10.1 255.255.255.0 10.5.10.254
(Cisco Controller) >config wlan interface 1 Corp-VLAN10

On the upstream switch, ensure the trunk to the AP/WLC carries the appropriate VLANs:

switch(config)# interface GigabitEthernet1/0/24
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 10,20,110

Step 5: Configure ISE (or RADIUS Server) for 802.1X Authentication

On Cisco ISE, define the network device (WLC) and policy:

Network Device Name: WLC-HQ-01
IP Address: 10.1.1.5
Shared Secret: <matches WLC config>

Authentication Policy:
  Condition: Wireless_802.1X
  Allowed Protocols: PEAP, EAP-TLS

Authorization Policy:
  Condition: AD-Group Equals "Corp-Employees"
  Result: PermitAccess, VLAN 10

Step 6: Configure Fast Transition (802.11r) for Roaming (Optional but Recommended)

For environments with VoWiFi or latency-sensitive applications where users roam between APs:

(Cisco Controller) >config wlan security ft enable 1
(Cisco Controller) >config wlan security ft over-the-air enable 1

This reduces re-authentication delay during roaming from potentially hundreds of milliseconds down to under 50ms, which matters significantly for voice quality on wireless handsets.

Step 7: Verification

Check WLAN configuration:

(Cisco Controller) >show wlan 1
WLAN Identifier.................................. 1
Profile Name...................................... Corporate-WiFi
Network Name (SSID)............................... CorporateSSID
Status............................................ Enabled
Security
  802.11 Authentication:........................ Open System
  Static WEP Keys................................ Disabled
  Wi-Fi Protected Access (WPA/WPA2)............... Enabled
    WPA (SSN IE)................................. Disabled
    WPA2 (RSN IE)................................. Enabled
      TKIP Cipher................................ Disabled
      AES Cipher.................................. Enabled
    Auth Key Management
      802.1x....................................  Enabled

Check client association and encryption status:

(Cisco Controller) >show client summary
Number of Clients................................ 148

MAC Address       AP Name        WLAN  Auth   Protocol   Status
aa:bb:cc:11:22:33 AP-Floor2-01   1     Yes    802.11ac   Associated

(Cisco Controller) >show client detail aa:bb:cc:11:22:33
Encryption Cipher................................ CCMP (AES)
WPA2 Auth Key Mgmt............................... 802.1X

Real-World Enterprise Scenario

A university campus with tens of thousands of students and staff needed to secure their wireless network without forcing IT to manage individual PSKs for every device — an operationally impossible task at that scale. Deploying WPA2-Enterprise with 802.1X, integrated with their existing Active Directory via ISE, meant students authenticated with their existing university credentials. When a student graduated or a staff member left, their access was revoked centrally through AD account deactivation — no need to rotate a shared network-wide passphrase that thousands of other users would have needed to be informed about, which is exactly the operational nightmare PSK-based deployments create at scale.

Best Practices

• Never use WPA2-Personal for large organizations — a shared PSK across hundreds or thousands of users is a security and operational liability; anyone who leaves the organization still knows the key unless you rotate it network-wide.
• Disable WPA1/TKIP entirely unless supporting genuinely legacy hardware that cannot be upgraded.
• Use EAP-TLS over PEAP where certificate infrastructure allows it — certificate-based authentication is significantly stronger than credential-based PEAP.
• Separate SSIDs by trust level — corporate, guest, and IoT devices should never share the same SSID or VLAN.
• Enable 802.11r for voice/latency-sensitive environments, but test compatibility with older client devices first, as some legacy clients handle fast transition poorly.
• Regularly rotate PSKs for any Personal-mode SSIDs still in use (guest networks, IoT segments).

Common Configuration Mistakes

1. Leaving mixed WPA/WPA2 mode enabled long after there’s any legitimate need for WPA1/TKIP client support, weakening the overall cipher suite.
2. Weak or short PSKs on guest networks — always enforce a minimum of 12+ characters with complexity.
3. Misconfigured RADIUS shared secrets between WLC and ISE, causing silent authentication failures that are hard to diagnose without checking both sides.
4. Forgetting VLAN trunk configuration upstream, resulting in clients authenticating successfully but getting no DHCP lease because the VLAN isn’t actually carried to the WLC.
5. Not testing roaming behavior before rolling out 802.11r broadly, especially with mixed-vendor client device fleets.

Performance Tuning

• Use band steering to push capable clients to 5GHz/6GHz where interference is typically lower and throughput higher.
• Tune RF profiles (power and channel settings) via RRM (Radio Resource Management) rather than static channel assignment in most enterprise deployments.
• For high-density environments, consider disabling lower basic data rates (1, 2, 5.5 Mbps) to reduce airtime consumed by legacy-rate management frames.

Troubleshooting

Clients see the SSID but fail to authenticate: Check RADIUS shared secret match between WLC and ISE/RADIUS server first — this is the single most common 802.1X failure point. Use show radius summary on the WLC to confirm the server is reachable and responding.

Client connects but gets no IP address: Verify VLAN trunking upstream and that the dynamic interface on the WLC is correctly mapped and has a functioning DHCP scope.

Intermittent disconnections during roaming: Check for channel overlap or excessive co-channel interference via RRM reports; also verify 802.11r configuration consistency across all APs in the same mobility group.

4-way handshake failures in packet captures: Usually indicates a PSK mismatch (Personal mode) or a client-side supplicant configuration issue (Enterprise mode) — verify against a known-working device first to isolate whether it’s infrastructure or endpoint-side.

FAQs

Should I still be deploying WPA2 in 2026, or move straight to WPA3? Where hardware and client compatibility allow, WPA3 is the better choice going forward, offering stronger protection against offline dictionary attacks via SAE (Simultaneous Authentication of Equals). Many enterprise deployments run WPA2/WPA3 transition mode during migration to support older client devices while pushing capable devices to the newer standard — check Cisco’s current WLC and AP release notes for your platform’s WPA3 support status.

What’s the practical difference between WPA2-Personal and WPA2-Enterprise for a small office? For under a dozen trusted devices, Personal mode with a strong, regularly rotated PSK is often sufficient. Once you’re managing dozens or hundreds of users with turnover, Enterprise mode’s per-user authentication and centralized revocation become operationally necessary.

Does enabling 802.1X slow down initial connection time? Slightly, due to the RADIUS authentication round-trip, though this is generally imperceptible to users and further minimized when combined with fast transition (802.11r) for subsequent roams.

Can I run WPA2-Personal and WPA2-Enterprise SSIDs simultaneously on the same APs? Yes — this is common practice, typically with a Personal-mode guest SSID and an Enterprise-mode corporate SSID broadcast from the same physical access points, mapped to different VLANs.

Summary

Implementing WPA2 security properly on Cisco wireless infrastructure comes down to a few non-negotiables: disable legacy TKIP wherever possible, use Enterprise mode with 802.1X and a proper RADIUS/ISE backend for any organization beyond trivial size, and make sure your VLAN and interface mapping actually delivers traffic where it belongs after authentication succeeds. The protocol fundamentals — the 4-way handshake, AES-CCMP encryption, RADIUS-based authorization — aren’t just academic details; understanding them is what makes the difference between a quick fix and hours of guessing when authentication issues inevitably show up in a live environment.

References

• Cisco Wireless LAN Controller Configuration Guide — cisco.com/c/en/us/support/wireless/wireless-lan-controller-software
• Cisco ISE Administrator Guide — cisco.com/c/en/us/support/security/identity-services-engine
• Wi-Fi Alliance WPA3 Specification — wi-fi.org/discover-wi-fi/security
• Cisco Enterprise Mobility Design Guide — cisco.com/c/en/us/td/docs/wireless/controller/technotes

The post How to Implement WPA/WPA2 Security on Cisco Wireless Networks: Complete Configuration Guide appeared first on Abdul Wahab Junaid.

Why Guest Isolation Matters

A guest network exists to give visitors, contractors, and customers internet access without giving them a path into anything that matters — file servers, printers, internal applications, VoIP infrastructure, or other connected clients. Without proper isolation, a guest network becomes an open door. A compromised guest laptop sitting on the same broadcast domain as corporate devices can run ARP spoofing, scan for open shares, or simply eavesdrop on unencrypted traffic.

Secure isolation in a Cisco wireless deployment typically means three things working together:

1. Logical separation — guest traffic lives in its own VLAN and often its own tunnel, never touching internal VLANs.
2. Client isolation (P2P blocking) — guest devices can’t see or talk to each other, only to the upstream gateway.
3. Policy enforcement — a captive portal, rate limiting, and firewall rules that restrict where guest traffic can go.

Networking Fundamentals Before You Configure Anything

VLANs and Traffic Segmentation

Every WLAN (the SSID broadcast to clients) on a Cisco WLC maps to an interface, and that interface maps to a VLAN. If your guest SSID and your corporate SSID share the same interface/VLAN, you have already failed at isolation regardless of anything else you configure. The first rule is: guest gets its own VLAN, its own subnet, its own DHCP scope, and ideally its own upstream firewall zone.

The Foreign/Anchor Controller Model

In multi-site or campus deployments, Cisco’s traditional (AireOS) architecture uses Guest Anchoring. Here’s the idea: your internal WLCs (the “foreign” controllers) sit inside the corporate network at branch sites. A dedicated WLC — the “anchor” — sits in the DMZ. Guest traffic is picked up by the foreign controller at the access point, then tunneled over an Ethernet-over-IP (EoIP) or CAPWAP mobility tunnel straight to the anchor controller in the DMZ, without ever touching the internal network in between. The anchor then breaks the traffic out to the internet from the DMZ.

This is the gold standard for secure isolation because guest traffic is never locally switched inside the corporate network at all — it’s tunneled in an encapsulated form until it reaches the DMZ.

Client Isolation (P2P Blocking)

Separately from VLAN segmentation, Cisco controllers support P2P (peer-to-peer) blocking, which prevents wireless clients on the same WLAN from communicating directly with each other at Layer 2, even if they’re on the same VLAN and subnet. For guest networks this is almost always mandatory — you don’t want a guest in the lobby able to see another guest’s shared folder or print jobs.

Captive Portal / Web Authentication

Guest access almost always pairs with a captive portal — a webpage guests must interact with (accept terms, enter a code, register an email) before the WLC opens the ACL to allow real traffic. Cisco supports internal (hosted on the controller) and external (hosted on ISE or a third-party portal) web authentication.

Lab Topology

For this walkthrough, assume:

• Cisco WLC (AireOS 8.10, e.g. a 5520 or vWLC) as the foreign controller, management IP 10.10.1.5
• A second WLC in the DMZ as the anchor, IP 192.168.200.5
• Guest VLAN 900, subnet 172.16.90.0/24 on the anchor side
• Access points already joined to the foreign controller
• A mobility group already established between foreign and anchor

Step 1: Create the Guest VLAN and Interface (Anchor Controller)

On the anchor WLC, create the dynamic interface for the guest VLAN.

(Cisco Controller-Anchor) > config interface create guest-vlan900 900
(Cisco Controller-Anchor) > config interface address dynamic-interface guest-vlan900 172.16.90.2 255.255.255.0 172.16.90.1
(Cisco Controller-Anchor) > config interface port guest-vlan900 1
(Cisco Controller-Anchor) > config interface dhcp dynamic-interface guest-vlan900 primary 172.16.90.1

Verify:

(Cisco Controller-Anchor) > show interface summary

Expected output should list guest-vlan900 with the correct IP, VLAN tag, and port.

Step 2: Configure the Mobility Group Between Foreign and Anchor

On both controllers, they must be members of each other’s mobility list.

On the foreign controller:

(Cisco Controller) > config mobility group member add 00:1a:2b:3c:4d:5e 192.168.200.5

On the anchor:

(Cisco Controller-Anchor) > config mobility group member add 00:aa:bb:cc:dd:ee 10.10.1.5

Verify mobility status — this is the single most common point of failure in anchor deployments:

(Cisco Controller) > show mobility summary

Expected output:

Mobility Protocol Port........................ 16666
Default Mobility Domain....................... CorpMobility
Mobility Keepalive Interval.................... 10
Mobility Keepalive Count....................... 3
Mobility Group Members configured.............. 2
Mobility Control Message DSCP Value............ 0

Controllers configured in the Mobility Group
IP Address       MAC Address        Group Name    Multicast IP  Status
10.10.1.5        00:aa:bb:cc:dd:ee  CorpMobility  0.0.0.0       Up
192.168.200.5    00:1a:2b:3c:4d:5e  CorpMobility  0.0.0.0       Up

If status shows “Control and Data Path Down” instead of “Up,” check that UDP 16666 (control) and IP protocol 97 (EoIP data, or UDP 16667 for CAPWAP mobility) are permitted between the two controller IPs through any intermediate firewall.

Step 3: Create the Guest WLAN on the Foreign Controller

(Cisco Controller) > config wlan create 5 GuestWiFi GuestWiFi
(Cisco Controller) > config wlan security wpa disable 5
(Cisco Controller) > config wlan security web-auth enable 5
(Cisco Controller) > config wlan mobility anchor add 5 192.168.200.5
(Cisco Controller) > config wlan exclusionlist 5 180
(Cisco Controller) > config wlan peer-blocking enable 5
(Cisco Controller) > config wlan broadcast-ssid enable 5
(Cisco Controller) > config wlan enable 5

The mobility anchor add command is what tells the foreign controller: any client joining WLAN ID 5 gets tunneled straight to the anchor at 192.168.200.5 instead of being locally switched.

Step 4: Configure the Anchor’s Copy of the Same WLAN

The WLAN ID, SSID name, and profile name must match exactly on the anchor.

(Cisco Controller-Anchor) > config wlan create 5 GuestWiFi GuestWiFi
(Cisco Controller-Anchor) > config wlan interface 5 guest-vlan900
(Cisco Controller-Anchor) > config wlan security web-auth enable 5
(Cisco Controller-Anchor) > config wlan mobility anchor add 5 192.168.200.5
(Cisco Controller-Anchor) > config wlan peer-blocking enable 5
(Cisco Controller-Anchor) > config wlan enable 5

Notice the anchor also lists itself as an anchor for WLAN 5 — this is required syntax in AireOS; it tells the anchor “traffic for this WLAN terminates and is switched locally here.”

Step 5: Enforce Client (P2P) Isolation

Peer-blocking was already enabled above, but confirm the enforcement mode:

(Cisco Controller-Anchor) > config wlan peer-blocking drop 5

Options are drop (silently discard inter-client traffic), forward-upstream (send it to the upstream router to let an ACL decide), or disable. For guest networks, drop is the simplest and most secure choice.

Step 6: Build the Pre-Authentication and Post-Authentication ACLs

Before authentication, guests need access only to the portal and DNS. After authentication, restrict them to the internet only — never to internal RFC1918 ranges.

(Cisco Controller-Anchor) > config acl create Guest-PreAuth
(Cisco Controller-Anchor) > config acl rule add Guest-PreAuth 1
(Cisco Controller-Anchor) > config acl rule action Guest-PreAuth 1 permit
(Cisco Controller-Anchor) > config acl rule protocol Guest-PreAuth 1 17
(Cisco Controller-Anchor) > config acl rule destination port range Guest-PreAuth 1 53 53
(Cisco Controller-Anchor) > config acl rule add Guest-PreAuth 2
(Cisco Controller-Anchor) > config acl rule action Guest-PreAuth 2 deny
(Cisco Controller-Anchor) > config acl rule destination address Guest-PreAuth 2 10.0.0.0 255.0.0.0
(Cisco Controller-Anchor) > config acl rule add Guest-PreAuth 3
(Cisco Controller-Anchor) > config acl rule action Guest-PreAuth 3 deny
(Cisco Controller-Anchor) > config acl rule destination address Guest-PreAuth 3 172.16.0.0 255.240.0.0
(Cisco Controller-Anchor) > config acl rule add Guest-PreAuth 4
(Cisco Controller-Anchor) > config acl rule action Guest-PreAuth 4 deny
(Cisco Controller-Anchor) > config acl rule destination address Guest-PreAuth 4 192.168.0.0 255.255.0.0
(Cisco Controller-Anchor) > config acl rule add Guest-PreAuth 5
(Cisco Controller-Anchor) > config acl rule action Guest-PreAuth 5 permit
(Cisco Controller-Anchor) > config acl apply Guest-PreAuth

Apply it to the WLAN as the pre-auth (web-auth) ACL:

(Cisco Controller-Anchor) > config wlan security web-auth acl-type webauth
(Cisco Controller-Anchor) > config wlan security web-auth exclude Guest-PreAuth 5

The three “deny” rules covering the private RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) — with the guest’s own subnet carved out ahead of them if it happens to fall inside one of those ranges — are what actually prevent a guest, even after authenticating, from ever reaching internal hosts. The final “permit any” lets everything else (i.e., the internet) through.

Step 7: Configure the Captive Portal

For an internal (controller-hosted) portal:

(Cisco Controller-Anchor) > config wlan security web-auth webauth-type internal 5
(Cisco Controller-Anchor) > config custom-web webauth_type internal
(Cisco Controller-Anchor) > config custom-web redirectUrl https://portal.example.com/welcome

For an external portal (ISE, Cloudpath, or a splash-page vendor):

(Cisco Controller-Anchor) > config wlan security web-auth webauth-type external 5
(Cisco Controller-Anchor) > config wlan security web-auth server-precedence 5 radius local ldap

Step 8: Rate Limiting Guest Bandwidth

Prevent guest usage from saturating the internet circuit using per-client bandwidth contracts:

(Cisco Controller-Anchor) > config qos wlan-bandwidth-contract 5 average-data-rate down 10000
(Cisco Controller-Anchor) > config qos wlan-bandwidth-contract 5 average-data-rate up 5000

Values are in kbps — this example caps each guest client to 10 Mbps down / 5 Mbps up.

Verification and Testing

Confirm the WLAN is active and correctly anchored:

(Cisco Controller) > show wlan 5

Look for Mobility Anchor List populated with the DMZ controller’s IP.

Confirm a test client’s session:

(Cisco Controller-Anchor) > show client summary
(Cisco Controller-Anchor) > show client detail <MAC address>

The client detail output should show Mobility Role: Export Foreign on the foreign controller side and Mobility Role: Export Anchor on the anchor side, along with the correct VLAN interface and WebAuth status of PASS after portal login.

Enterprise Deployment Considerations

In a real enterprise rollout, a few things separate a lab config from a production one:

• Redundant anchors: run at least two anchor controllers in the DMZ so a single controller failure doesn’t take guest Wi-Fi down across every branch.
• NAT at the DMZ edge: the anchor’s guest interface typically sits behind a NAT boundary so guest source IPs never appear on the internal routed network.
• Centralized authentication logging: point web-auth through ISE so every guest session is logged with a MAC address, timestamp, and sponsor (if using sponsor-approved guest access) for compliance and incident response.
• Bandwidth and session limits: cap concurrent guest sessions per SSID to avoid a single busy lobby from starving other floors.
• Separate SSID for BYOD vs. true guest: many enterprises run three tiers — corporate, BYOD (authenticated but internal), and guest (fully isolated) — don’t collapse these into one policy.

Common Configuration Mistakes

• Forgetting to add the mobility anchor on both controllers — it must be configured on the foreign controller (pointing to the anchor) and on the anchor itself (pointing to itself).
• Using the same VLAN for guest and a “quarantine” or IoT network — isolation should never be shared.
• Leaving peer-blocking disabled, which lets two guest devices on the same SSID talk to each other directly.
• Placing the anchor controller’s management interface reachable from the internet — it should only be reachable from a controlled management network.
• Not restricting DNS — guests with unrestricted DNS can sometimes tunnel data through DNS queries even when other ports are blocked.
• Applying the ACL only in one direction — Cisco WLC ACLs are stateless by default in some releases, so both inbound and outbound rules must be explicit.

Troubleshooting Checklist

• Client stuck in WebAuth Pending: check that the pre-auth ACL permits DNS and HTTP/HTTPS to the portal address before authentication.
• Client shows Anchor Deny or never appears on the anchor: verify mobility group status and that the WLAN ID, profile name, and SSID name match exactly on both controllers.
• Guest gets an IP but no captive portal redirect: confirm the DHCP scope’s DNS server is one the pre-auth ACL permits, and that the redirect URL is reachable.
• Guests can ping internal hosts: re-check the ACL ordering — ACL rules on Cisco WLCs are evaluated top-down, so a broad “permit any” placed above the deny-RFC1918 rules will bypass isolation entirely.

FAQs

Does guest anchoring require a dedicated hardware controller in the DMZ? No — a virtual WLC (vWLC) or a Catalyst 9800 in embedded wireless mode can serve as the anchor, as long as it has a routed path to the DMZ segment and mobility connectivity to the foreign controllers.

Can I skip anchoring and just use a local VLAN with ACLs? For a single-site, single-controller deployment, yes — local guest VLAN with tight ACLs at the upstream firewall is a valid, simpler pattern. Anchoring becomes valuable specifically when you have multiple sites/controllers and want all guest traffic to break out from one controlled DMZ point rather than at every branch’s local internet circuit.

How do I handle guest devices roaming between access points? Because the client’s mobility role is anchored to the DMZ controller, roaming between APs on different foreign controllers is handled transparently — the client’s session state moves with it, and the anchor relationship is preserved.

Is 802.1X ever used for guest networks? Rarely for anonymous guests, but yes for sponsor-based or partner access where each guest gets unique RADIUS credentials tied to an identity, often issued through Cisco ISE’s guest portal.

Summary

Secure guest Wi-Fi on Cisco infrastructure comes down to layering three controls: put guest traffic on its own VLAN and, ideally, tunnel it to a dedicated anchor controller in the DMZ; block peer-to-peer communication between guest clients; and enforce ACLs that block access to private address space both before and after portal authentication. None of these individually is enough — it’s the combination that gives you real isolation. Once the anchor/foreign mobility relationship and ACLs are verified with show mobility summary and show client detail, the setup is stable and requires very little ongoing maintenance beyond periodic portal and certificate renewal.

References

• Cisco: Wireless LAN Controller Guest Access — https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/113606-wlc-guest-anchor-config.html
• Cisco: Wireless Controller Configuration Guide (Mobility Groups) — https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-10/config-guide/b_cg810.html
• Cisco: Catalyst 9800 Series Wireless Controller Guest Access Configuration Guide — https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_wl_17_1_cg.html

The post How to Configure Guest Access on Cisco Wireless Networks with Secure Isolation appeared first on Abdul Wahab Junaid.

Understanding the Split-MAC Architecture

Cisco enterprise wireless uses a split-MAC design under CAPWAP (Control and Provisioning of Wireless Access Points). The access point (AP) handles real-time 802.11 functions — beaconing, ACK frames, retransmission — while the controller handles everything else: authentication, mobility, RF management, QoS policy, and encryption key management. This split is why a lightweight AP is useless without a controller to join, and why controller configuration is where almost all the actual policy lives.

Traffic between AP and WLC travels over two CAPWAP tunnels:

• Control tunnel (UDP 5246) — carries management traffic: join requests, configuration, RF reports.
• Data tunnel (UDP 5247) — carries the actual client data frames, encapsulated from the AP back to the controller.

Understanding this matters because most early-stage troubleshooting (“AP won’t join,” “clients associate but get no IP”) traces back to one of these two tunnels being blocked somewhere in the network path.

Core Building Blocks of a WLAN

Before touching the CLI, understand the four objects that make up any WLAN configuration on a Cisco controller:

1. Dynamic Interface — the VLAN/IP the WLAN’s traffic is mapped to on the controller.
2. WLAN Profile — the logical container defining SSID name, profile name, and WLAN ID.
3. Security Policy — WPA2/WPA3-Personal, WPA2/WPA3-Enterprise (802.1X), or open/web-auth.
4. RF/AP Group — which physical APs broadcast this WLAN, and under what radio policy.

Lab Topology

• Cisco 5520 WLC or vWLC running AireOS 8.10 (management IP 10.10.1.5)
• Alternatively, a Catalyst 9800-CL running IOS-XE 17.9
• Access points already discovered and joined via DHCP Option 43 or DNS
• Core switch trunking VLANs 10 (corporate), 20 (voice), and 900 (guest) down to the WLC’s uplink port

Part 1: AireOS (Classic WLC) Configuration

Step 1 — Create the Dynamic Interface

(Cisco Controller) > config interface create Corp-Data 10
(Cisco Controller) > config interface address dynamic-interface Corp-Data 10.10.20.5 255.255.255.0 10.10.20.1
(Cisco Controller) > config interface port Corp-Data 1
(Cisco Controller) > config interface dhcp dynamic-interface Corp-Data primary 10.10.20.10

Verify:

(Cisco Controller) > show interface summary

Interface Name                  Port Vlan Id  IP Address      Type    Ap Mgr
-------------------------------- ---- -------- --------------- ------- ------
Corp-Data                        1    10       10.10.20.5      Dynamic No
management                       1    1        10.10.1.5       Static  Yes

Step 2 — Create the WLAN

(Cisco Controller) > config wlan create 10 CorpWiFi CorpWiFi
(Cisco Controller) > config wlan interface 10 Corp-Data

Step 3 — Configure Security (WPA2/WPA3-Enterprise with 802.1X)

(Cisco Controller) > config wlan security wpa akm 802.1x enable 10
(Cisco Controller) > config wlan security wpa wpa2 enable 10
(Cisco Controller) > config wlan security wpa wpa2 ciphers aes enable 10
(Cisco Controller) > config wlan radius_server auth add 10 1812 1 shared-secret
(Cisco Controller) > config wlan radius_server auth enable 10

For a simpler PSK-based branch office SSID instead:

(Cisco Controller) > config wlan security wpa akm psk enable 10
(Cisco Controller) > config wlan security wpa akm psk set-key ascii MyStrongPassphrase123! 10

Step 4 — Enable QoS, Band Selection, and Broadcast

(Cisco Controller) > config wlan qos 10 platinum
(Cisco Controller) > config wlan band-select allow 10
(Cisco Controller) > config wlan broadcast-ssid enable 10

Platinum QoS is typically reserved for voice; data SSIDs usually use Silver or Bronze. Use the level appropriate to the traffic type.

Step 5 — Assign to an AP Group (Optional but Recommended)

Rather than broadcasting every SSID from every AP, use AP groups to scope WLANs to specific floors or buildings.

(Cisco Controller) > config wlan apgroup create FloorTwoAPs
(Cisco Controller) > config wlan apgroup interface-mapping add FloorTwoAPs 10 Corp-Data
(Cisco Controller) > config ap group-name FloorTwoAPs AP-F2-01
(Cisco Controller) > config ap group-name FloorTwoAPs AP-F2-02

Step 6 — Enable the WLAN

(Cisco Controller) > config wlan enable 10

Step 7 — Verify

(Cisco Controller) > show wlan 10

Expected output (trimmed):

WLAN Identifier................................. 10
Profile Name..................................... CorpWiFi
Network Name (SSID).............................. CorpWiFi
Status............................................ Enabled
MAC Filtering..................................... Disabled
Interface......................................... Corp-Data
Security
   802.11 Authentication:........................ Open System
   Wi-Fi Protected Access (WPA/WPA2/WPA3)......... Enabled
      WPA2 (AES)................................. Enabled
      Auth Key Management
        802.1x.................................... Enabled

Part 2: Catalyst 9800 (IOS-XE) Configuration

The 9800 platform uses IOS-XE CLI syntax and separates configuration into policy profiles, WLAN profiles, and policy tags — a more modular model than AireOS.

Step 1 — Create the WLAN

9800(config)# wlan CorpWiFi 10 CorpWiFi
9800(config-wlan)# security wpa akm dot1x
9800(config-wlan)# security wpa wpa2 ciphers aes
9800(config-wlan)# no shutdown
9800(config-wlan)# exit

Step 2 — Create the Policy Profile (maps WLAN to VLAN)

9800(config)# wireless profile policy Corp-Policy
9800(config-wireless-policy)# vlan 10
9800(config-wireless-policy)# no shutdown
9800(config-wireless-policy)# exit

Step 3 — Create a RADIUS Server and AAA Method

9800(config)# radius server ISE1
9800(config-radius-server)# address ipv4 10.10.1.20 auth-port 1812 acct-port 1813
9800(config-radius-server)# key MySharedSecret123
9800(config-radius-server)# exit
9800(config)# aaa new-model
9800(config)# aaa group server radius ISE-GROUP
9800(config-sg-radius)# server name ISE1
9800(config-sg-radius)# exit
9800(config)# aaa authentication dot1x ISE-METHOD group ISE-GROUP

Attach the method list to the WLAN:

9800(config)# wlan CorpWiFi
9800(config-wlan)# security dot1x authentication-list ISE-METHOD

Step 4 — Create the Policy Tag and Bind Everything Together

9800(config)# wireless tag policy Corp-PolicyTag
9800(config-policy-tag)# wlan CorpWiFi policy Corp-Policy
9800(config-policy-tag)# exit

Step 5 — Apply the Policy Tag to Access Points

9800(config)# ap F4CF.E2XX.XXXX
9800(config-ap-tag)# policy-tag Corp-PolicyTag
9800(config-ap-tag)# exit

Or apply to a whole AP filter/site tag for bulk deployment.

Step 6 — Verify

9800# show wlan summary
9800# show wireless tag policy detailed Corp-PolicyTag
9800# show ap tag summary

Expected show wlan summary output:

Number of WLANs: 1

ID  Profile Name  SSID       Status  Security
--  ------------  ---------  ------  --------------
10  CorpWiFi      CorpWiFi   UP      [WPA2][802.1x]

Real-World Enterprise Scenario: Multi-SSID Office Deployment

A typical mid-size office needs at least three WLANs:

Each maps to its own dynamic interface/VLAN, and CorpVoice specifically needs Cisco Centralized Key Management (CCKM) enabled for fast roaming so handsets don’t drop calls moving between APs:

(Cisco Controller) > config wlan security wpa akm cckm enable 20

Optimization: RF and Band Steering

For dense deployments, tune the RF profile to reduce co-channel interference and push clients to 5 GHz:

(Cisco Controller) > config 802.11a channel global auto
(Cisco Controller) > config 802.11a txPower global auto
(Cisco Controller) > config wlan band-select allow 10
(Cisco Controller) > config band-select cycle-count 2
(Cisco Controller) > config band-select cycle-threshold 200

On the 9800, RF profiles are configured under ap dot11 5ghz rf-profile and applied via RF tags, giving per-building control over channel width, minimum RSSI, and DCA (Dynamic Channel Assignment).

Common Configuration Mistakes

• Forgetting no shutdown on IOS-XE WLAN and policy profile objects — unlike AireOS, they’re created in a shutdown state by default.
• Mismatched VLAN trunking — the switchport connecting to the WLC or AP must trunk every VLAN referenced by a dynamic interface/policy profile, or clients will associate but never get a DHCP lease.
• Using the same RF/AP group for all SSIDs on a large campus, causing unnecessary broadcast overhead on APs that don’t need every SSID.
• Skipping CCKM/802.11r on voice SSIDs, leading to audible gaps during handset roaming.
• Not setting a strong enough RADIUS shared secret or mismatching it between the WLC and the RADIUS server — this is the most common single cause of 802.1X clients failing authentication silently.

Troubleshooting

Check AP join status:

(Cisco Controller) > show ap join stats summary all

Check a specific client’s association and authentication state:

(Cisco Controller) > show client detail <MAC address>

Look for Policy Manager State: RUN — anything stuck at AUTHCHECK, DHCP_REQD, or WEBAUTH_REQD tells you exactly which stage is failing.

On IOS-XE:

9800# show wireless client mac-address <MAC address> detail
9800# show wireless client summary

Enable client debug (use sparingly in production, it’s verbose):

9800# debug wireless mac <client-mac> trace

FAQs

How many WLANs can a Cisco controller support? AireOS controllers typically support up to 512 WLANs system-wide, but only 16 can be broadcast simultaneously per AP radio due to beacon overhead — this is why AP groups matter for scoping.

What’s the difference between a WLAN profile and an SSID? The SSID is the broadcast network name clients see; the WLAN profile is the internal controller object (with its own ID and settings) that can, in some setups, share the same SSID name across multiple profiles for different AP groups.

Do I need a separate controller per site? No — a single controller (physical or virtual) can manage APs across multiple sites over a WAN, as long as CAPWAP control/data ports are reachable, though latency-sensitive designs sometimes prefer local controllers per site.

Should I use AireOS or Catalyst 9800 for a new deployment? Cisco has moved all new feature development to IOS-XE/Catalyst 9800; new deployments should default to 9800 unless there’s a specific compatibility reason to stay on legacy AireOS hardware.

Summary

Setting up a Cisco wireless LAN comes down to defining four things correctly and consistently: the VLAN/interface the traffic lands on, the WLAN profile itself, the security policy governing how clients authenticate, and the AP scope that determines where the SSID is actually broadcast. AireOS and Catalyst 9800 use different CLI syntax and object models — the 9800’s policy-tag/policy-profile separation is more modular — but the underlying concepts are identical. Once configured, show wlan, show client detail, and AP join statistics are your primary tools for confirming the deployment is healthy.

References

• Cisco: Wireless LAN Controller Configuration Guide, Release 8.10 — https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-10/config-guide/b_cg810.html
• Cisco: Catalyst 9800 Series Wireless Controller Software Configuration Guide — https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_wl_17_1_cg.html
• Cisco: CAPWAP Configuration Guide — https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_capwap.html

The post How to Set Up Wireless LANs with Cisco Wireless Controllers: Step-by-Step Configuration appeared first on Abdul Wahab Junaid.

What NetFlow Actually Is

A flow is defined by a unique combination of seven key fields (the “seven-tuple”):

1. Source IP address
2. Destination IP address
3. Source port
4. Destination port
5. Layer 3 protocol (TCP, UDP, ICMP, etc.)
6. Type of Service (ToS) byte
7. Input interface

Every packet matching the same seven-tuple within an active flow window is counted into that single flow record instead of being logged individually. The router (or switch) builds these records in a local flow cache, then periodically exports them — via UDP, typically — to a flow collector, a server running analysis software like Cisco Stealthwatch, SolarWinds NTA, ntopng, or an open-source tool like nfdump.

This is fundamentally different from SPAN/port mirroring (which copies full packets) or SNMP (which gives interface-level counters only). NetFlow sits in between: far more detail than SNMP, far less overhead than full packet capture.

NetFlow Versions

• NetFlow v5 — fixed fields, IPv4 only, still widely used for its simplicity and broad tool support.
• NetFlow v9 — template-based, supports IPv6, MPLS, and custom fields.
• Flexible NetFlow (FNF) — Cisco’s modern implementation, built on v9 templates, letting you define exactly which fields to match and collect per flow monitor. This is the standard for any IOS-XE deployment today and is what this guide focuses on.
• IPFIX — the IETF-standardized evolution of NetFlow v9, supported alongside FNF on newer platforms.

Core Building Blocks of Flexible NetFlow

1. Flow Record — defines which fields are used to key a flow (match) and which are just collected (collect).
2. Flow Exporter — defines where and how flow data is sent (destination IP, port, transport, version).
3. Flow Monitor — ties a record and exporter together into a single monitoring policy, plus cache behavior (timers, size).
4. Flow Sampler (optional) — for very high-traffic interfaces, samples 1-in-N packets instead of processing every packet, reducing CPU load.

Lab Topology

• Cisco ISR 4331 router running IOS-XE 17.6, hostname R1
• WAN interface: GigabitEthernet0/0/0, IP 203.0.113.1
• LAN interface: GigabitEthernet0/0/1, IP 10.10.10.1
• Flow collector at 10.10.10.50, listening on UDP 2055

Step 1: Define the Flow Record

R1(config)# flow record CORP-RECORD
R1(config-flow-record)# description IPv4 traffic flow record
R1(config-flow-record)# match ipv4 tos
R1(config-flow-record)# match ipv4 protocol
R1(config-flow-record)# match ipv4 source address
R1(config-flow-record)# match ipv4 destination address
R1(config-flow-record)# match transport source-port
R1(config-flow-record)# match transport destination-port
R1(config-flow-record)# match interface input
R1(config-flow-record)# match flow direction
R1(config-flow-record)# collect routing next-hop address ipv4
R1(config-flow-record)# collect interface output
R1(config-flow-record)# collect counter bytes
R1(config-flow-record)# collect counter packets
R1(config-flow-record)# collect timestamp sys-uptime first
R1(config-flow-record)# collect timestamp sys-uptime last

match fields define the flow key (what makes two packets part of the same flow); collect fields are additional data gathered but not used to distinguish flows.

Step 2: Define the Flow Exporter

R1(config)# flow exporter CORP-EXPORTER
R1(config-flow-exporter)# destination 10.10.10.50
R1(config-flow-exporter)# transport udp 2055
R1(config-flow-exporter)# source GigabitEthernet0/0/1
R1(config-flow-exporter)# export-protocol netflow-v9
R1(config-flow-exporter)# template data timeout 60

Using the physical interface’s IP as the export source ensures the collector always sees flow data coming from a consistent, predictable address, which matters for collector-side filtering and firewall rules.

Step 3: Define the Flow Monitor

R1(config)# flow monitor CORP-MONITOR
R1(config-flow-monitor)# description Main traffic monitor
R1(config-flow-monitor)# record CORP-RECORD
R1(config-flow-monitor)# exporter CORP-EXPORTER
R1(config-flow-monitor)# cache timeout active 60
R1(config-flow-monitor)# cache timeout inactive 15

• Active timeout — how long a still-ongoing flow is allowed to run before it’s exported anyway (prevents long-lived flows like a large file transfer from never being reported).
• Inactive timeout — how long the cache waits after the last packet of a flow before considering it finished and exporting it.

Step 4: Apply the Flow Monitor to Interfaces

Apply on the WAN interface, capturing both directions of traffic:

R1(config)# interface GigabitEthernet0/0/0
R1(config-if)# ip flow monitor CORP-MONITOR input
R1(config-if)# ip flow monitor CORP-MONITOR output
R1(config-if)# exit

For IPv6 traffic, a separate flow record/monitor referencing match ipv6 fields is needed and applied with ipv6 flow monitor.

Step 5: Verify NetFlow Is Capturing Data

R1# show flow monitor CORP-MONITOR statistics

Expected output (trimmed):

Cache type:                             Normal (Platform cache)
Cache size:                            10000
Current entries:                          124
High Watermark:                          201

Flows added:                            8452
Flows aged:                             8328
   - Active timeout       (  60 secs)     212
   - Inactive timeout     (  15 secs)    8116

Check the live cache contents directly:

R1# show flow monitor CORP-MONITOR cache format table

Expected output (trimmed):

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  IP PROT  bytes  pkts
10.10.10.15      93.184.216.34    54221          443            6        45812  38
10.10.10.22      203.0.113.55     51422          80             6        2044   6

Confirm the exporter is actually sending packets out:

R1# show flow exporter CORP-EXPORTER statistics

Expected output (trimmed):

Client send statistics
  Client: Flow Monitor
    Records added:                                       8452
      - sent:                                             8452
    Bytes added:                                         608544
      - sent:                                            608544

If “sent” stays at zero while “added” climbs, the router is generating flows but failing to export them — almost always a routing or ACL problem between the router and collector.

Sampling for High-Throughput Interfaces

On a busy core or edge interface (multi-gigabit), full NetFlow can add meaningful CPU load. Use a flow sampler to process only a fraction of packets:

R1(config)# sampler CORP-SAMPLER
R1(config-sampler)# mode random 1 out-of 100
R1(config)# interface GigabitEthernet0/0/0
R1(config-if)# ip flow monitor CORP-MONITOR sampler CORP-SAMPLER input

This samples 1 in every 100 packets and extrapolates flow statistics — acceptable for trend and top-talker analysis, not for exact byte-accurate billing.

Real-World Enterprise Scenario: Identifying a Bandwidth Hog

A branch office WAN circuit is consistently near capacity during business hours. With NetFlow already exporting to a collector:

1. Pull top talkers by bytes over the last hour from the collector UI or via nfdump-style query.
2. Cross-reference the top source IP against DHCP leases to identify the device.
3. Check destination ports — a flow to TCP 443 sustained for hours at high byte counts often indicates cloud backup or video streaming rather than malicious activity, while unusual destination ports or a fan-out pattern (one host talking to hundreds of external IPs) suggests something worth investigating further, such as a compromised host doing reconnaissance or exfiltration.
4. Apply a QoS policy or ACL to that host/application once identified, rather than blindly throttling the whole circuit.

This is the core value proposition of NetFlow: it turns “the link is full” into “here is exactly which host and application is responsible,” without ever needing a packet capture.

Performance Tuning

• Increase cache size on routers with high flow counts to avoid premature cache eviction: flow monitor CORP-MONITOR → cache size 65536.
• Reduce active timeout (e.g., to 30 seconds) if you need near-real-time visibility for security use cases, at the cost of more export traffic.
• Use hardware-accelerated NetFlow where available (e.g., on ASR or Catalyst platforms with dedicated flow ASICs) rather than software (CPU-based) flow export on high-throughput links.
• Limit collected fields to what you actually analyze — every additional collect field increases per-flow cache memory usage across potentially tens of thousands of concurrent flows.

Common Configuration Mistakes

• Applying the flow monitor only in the input direction, missing outbound traffic entirely (most designs need both directions applied, one per interface, to see full bidirectional flow data on a routed interface).
• Forgetting that Flexible NetFlow record/monitor/exporter objects must all be created before they can reference each other — the CLI will reject a monitor referencing a record that doesn’t exist yet.
• Not accounting for asymmetric routing — if inbound and outbound traffic take different paths through different routers, no single device sees the complete flow, skewing analysis.
• Overloading a low-end router’s CPU by running full (unsampled) NetFlow on a very high-bandwidth interface.
• Forgetting to permit UDP 2055 (or whatever export port is chosen) through any firewall sitting between the router and the collector.

Troubleshooting Checklist

• No flows appearing on collector: verify routing to the collector (ping 10.10.10.50 from the router), confirm the exporter source interface has a valid route, and check show flow exporter … statistics for “sent” vs. “added” mismatches.
• Flows show but fields are all zero: check the flow record’s match/collect statements — a typo or unsupported field combination on certain platforms silently produces incomplete templates.
• High CPU after enabling NetFlow: check show processes cpu sorted for the NetFlow-related process and consider enabling a sampler.
• Collector shows old/stale templates only: template refresh intervals (template data timeout) may be too long relative to how often the collector expects fresh templates — lower the timeout.

FAQs

Does NetFlow capture packet payloads? No — NetFlow only records metadata about flows (addresses, ports, byte/packet counts, timing). It never captures the actual packet contents, which is one reason it’s lighter-weight and generally has fewer privacy implications than full packet capture.

What’s the difference between NetFlow and sFlow? sFlow (used mostly on switches from vendors like Arista and older Cisco Nexus platforms) samples packets at the interface level and is protocol-agnostic; NetFlow builds full flow records in a cache and exports summarized data, giving more precise per-flow statistics at the cost of more router resources.

Can NetFlow run on a switch instead of a router? Yes — many Catalyst switches (9300, 9400, 9500 series) support Flexible NetFlow in hardware; the same record/exporter/monitor model applies, though field support varies by platform ASIC.

How much bandwidth does NetFlow export traffic itself use? Typically well under 1% of monitored traffic, since only summarized records are sent, not full packets — though this scales with the number of unique flows, not the byte volume, so a network with many short-lived flows can generate more export overhead than one with a few large flows.

Summary

NetFlow configuration on modern Cisco IOS-XE routers boils down to four objects: a flow record defining what to match and collect, an exporter defining where to send it, a monitor tying the two together with cache timers, and interface-level application in both traffic directions. Once running, show flow monitor … statistics and show flow exporter … statistics are the two commands that confirm the pipeline is healthy end to end. From there, NetFlow becomes the primary tool for answering “who is using the bandwidth and why” without resorting to full packet captures.

References

• Cisco: Flexible NetFlow Configuration Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fnetflow/configuration/xe-16/fnf-xe-16-book.html
• Cisco: NetFlow Overview — https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html
• Cisco: IPFIX and NetFlow Version 9 — https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html

The post How to Configure NetFlow on Cisco Routers for Network Traffic Monitoring and Analysis appeared first on Abdul Wahab Junaid.

Why You Can’t Just Plug In and Capture

Ethernet switches forward frames based on MAC address tables — a switch sends a unicast frame only out the port where the destination MAC lives, not to every port. That’s the entire point of switching versus using a hub. It means a packet capture tool plugged into a random switch port sees only its own traffic and broadcast/multicast frames — nothing else. SPAN exists specifically to override that behavior for one or more designated ports, copying their traffic to a separate monitoring port without disrupting normal switching.

SPAN Terminology

• Source port/VLAN — the traffic you want to capture (a physical port, port-channel, or entire VLAN).
• Destination port — the port where a capture device (packet analyzer, IDS sensor) is connected. This port stops normal switching behavior and becomes dedicated to receiving mirrored traffic.
• Local SPAN — source and destination are on the same physical switch.
• RSPAN (Remote SPAN) — source and destination are on different switches, connected via a special RSPAN VLAN that carries mirrored traffic across a trunk.
• ERSPAN (Encapsulated Remote SPAN) — Cisco proprietary, encapsulates mirrored traffic in GRE so it can be routed across Layer 3 boundaries to a remote destination, even off-site.

Fundamentals: Ingress, Egress, and Both

Every SPAN session lets you choose direction per source:

• rx (ingress) — traffic entering the source port.
• tx (egress) — traffic leaving the source port.
• both — the default if unspecified, captures both directions.

This matters a lot for interpreting captures — mirroring only rx on an uplink port shows you what’s coming from downstream devices, while tx shows what the switch is sending out to them. For full visibility into a conversation, both is typically what you want, understanding you’ll see some frames duplicated if source and destination of a conversation are both being monitored on the same session.

Lab Topology

• Cisco Catalyst 9300 switch, hostname SW1
• Source: Gi1/0/5 (a server uplink you want to monitor)
• Destination: Gi1/0/24 (packet analyzer / IDS sensor)
• For RSPAN: a second switch SW2 with the sensor attached, connected to SW1 via a trunk carrying VLAN 999 (dedicated RSPAN VLAN)

Part 1: Local SPAN Configuration

Step 1 — Create the SPAN Session

SW1(config)# monitor session 1 source interface GigabitEthernet1/0/5 both
SW1(config)# monitor session 1 destination interface GigabitEthernet1/0/24

To mirror an entire VLAN instead of a single port:

SW1(config)# monitor session 1 source vlan 10 both

To mirror multiple sources into the same session:

SW1(config)# monitor session 1 source interface GigabitEthernet1/0/5 - 6 both

Step 2 — (Optional) Preserve Encapsulation or Allow Ingress Traffic on the Destination

By default, the destination port drops any traffic it receives from the connected device (it’s receive-only for normal switching purposes). If your analyzer also needs to send traffic out that port (uncommon, but needed for some inline tools), allow ingress:

SW1(config)# monitor session 1 destination interface GigabitEthernet1/0/24 ingress vlan 10

Step 3 — Verify

SW1# show monitor session 1

Expected output:

Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/5
Destination Ports      : Gi1/0/24
    Encapsulation       : Native
    Ingress             : Disabled

At this point, anything plugged into Gi1/0/24 running Wireshark (or tcpdump on a Linux box) sees a full copy of traffic entering and leaving Gi1/0/5.

Part 2: RSPAN Configuration (Cross-Switch Capture)

Step 1 — Create the RSPAN VLAN on Both Switches

SW1(config)# vlan 999
SW1(config-vlan)# name RSPAN-VLAN
SW1(config-vlan)# remote-span
SW1(config-vlan)# exit

SW2(config)# vlan 999
SW2(config-vlan)# name RSPAN-VLAN
SW2(config-vlan)# remote-span
SW2(config-vlan)# exit

The remote-span keyword is what makes VLAN 999 behave specially — switches will flood traffic tagged with this VLAN without normal MAC learning, since mirrored traffic isn’t meant to be “learned” as if it were a real host.

Step 2 — Ensure the Trunk Between Switches Carries VLAN 999

SW1(config)# interface GigabitEthernet1/0/48
SW1(config-if)# switchport trunk allowed vlan add 999

Repeat the equivalent on SW2’s uplink toward SW1.

Step 3 — Configure the Source Session on SW1 (where the monitored traffic lives)

SW1(config)# monitor session 2 source interface GigabitEthernet1/0/5 both
SW1(config)# monitor session 2 destination remote vlan 999

Step 4 — Configure the Destination Session on SW2 (where the analyzer is connected)

SW2(config)# monitor session 2 source remote vlan 999
SW2(config)# monitor session 2 destination interface GigabitEthernet1/0/24

Step 5 — Verify on Both Switches

SW1# show monitor session 2
SW2# show monitor session 2

On SW1, expect Type: Remote Source Session. On SW2, expect Type: Remote Destination Session.

Part 3: ERSPAN Configuration (Layer 3, GRE-Encapsulated)

ERSPAN is used when the analyzer is on a completely different part of the network reachable only via routing (common with centralized IDS/NDR platforms like Cisco Stealthwatch or a SPAN aggregation appliance). Supported on higher-end platforms (Catalyst 9000 with the right license/hardware, Nexus, ASR).

Source Switch Configuration

SW1(config)# monitor session 3 type erspan-source
SW1(config-mon-erspan-src)# source interface GigabitEthernet1/0/5 both
SW1(config-mon-erspan-src)# destination
SW1(config-mon-erspan-src-dst)# erspan-id 100
SW1(config-mon-erspan-src-dst)# ip address 192.168.50.10
SW1(config-mon-erspan-src-dst)# origin ip address 192.168.10.1
SW1(config-mon-erspan-src-dst)# end

192.168.50.10 is the remote analyzer/collector’s IP; 192.168.10.1 is the source switch’s own routed interface used as the GRE tunnel’s origin.

Destination Side (Analyzer Reachable via Routed Network)

If the destination is another Cisco switch re-presenting ERSPAN traffic to a local port:

SW2(config)# monitor session 3 type erspan-destination
SW2(config-mon-erspan-dst)# destination interface GigabitEthernet1/0/24
SW2(config-mon-erspan-dst)# source
SW2(config-mon-erspan-dst-src)# erspan-id 100
SW2(config-mon-erspan-dst-src)# ip address 192.168.50.10
SW2(config-mon-erspan-dst-src)# end

More commonly, the destination is a purpose-built collector appliance or virtual machine that natively decapsulates ERSPAN/GRE — in that case no destination-side switch config is needed at all, just IP reachability to 192.168.50.10.

Real-World Enterprise Scenario: Feeding an IDS Sensor

A common production pattern is mirroring an entire VLAN or a firewall’s inside interface to a Cisco Secure IDS / Snort / Suricata sensor for passive threat detection:

SW1(config)# monitor session 4 source vlan 10 , 20 rx
SW1(config)# monitor session 4 destination interface GigabitEthernet1/0/24

Using rx only (rather than both) on VLAN sources here specifically avoids doubling the traffic volume the sensor must process, since with VLAN-based sources every ingress frame into that VLAN is already captured regardless of which port it entered on.

Performance and Capacity Considerations

• SPAN destination ports typically shouldn’t run at a lower link speed than the aggregate of the sources feeding them, or frames get dropped under load. Mirroring two full-duplex gigabit sources into one gigabit destination port can oversubscribe it during high traffic bursts — plan destination bandwidth accordingly, or use a 10G destination port for multiple 1G sources.
• Catalyst platforms have a limited number of concurrent monitor sessions (commonly 2-8 local/RSPAN sessions per switch, platform-dependent) — check the specific model’s datasheet before assuming unlimited sessions are available.
• SPAN and RSPAN sessions add negligible CPU load on modern switches since mirroring happens in hardware ASICs, but ERSPAN (GRE encapsulation) can be more resource-intensive depending on platform.

Common Configuration Mistakes

• Forgetting that a SPAN destination port loses its normal switching function entirely — plugging a regular device into a destination port results in that device having no network connectivity.
• Not allowing the RSPAN VLAN on every trunk link between source and destination switches, breaking the mirror silently.
• Using both direction on VLAN-wide sources, which doubles traffic unnecessarily since ingress into a VLAN already implies egress somewhere else in that VLAN.
• Exceeding the platform’s maximum simultaneous SPAN session count and having later sessions silently fail or overwrite earlier ones.
• Mirroring a trunk port without realizing 802.1Q tags will appear in the capture, which can confuse an analyzer expecting untagged frames — plan for this in Wireshark/tcpdump filters.

Troubleshooting Checklist

• No traffic seen at the analyzer: confirm show monitor session <id> shows the session as active, check that the destination interface isn’t administratively down, and confirm no ACL or port-security is blocking traffic on that port.
• RSPAN not working across switches: verify VLAN 999 (or your chosen RSPAN VLAN) is allowed on every trunk in the path with show interfaces trunk, and confirm remote-span is configured on the VLAN on every switch in the path, not just source and destination.
• Traffic seen but incomplete: check whether the session direction (rx/tx/both) matches what you actually need, and confirm you’re not hitting the platform’s maximum source port/session limits.
• ERSPAN not reaching destination: verify basic IP reachability between origin and destination IPs (ping), and confirm no upstream firewall is blocking GRE (IP protocol 47).

FAQs

Does SPAN affect switch performance for normal traffic? On modern Catalyst hardware, no — mirroring is done in the switching ASIC, so normal forwarding on source ports is unaffected. The exception is oversubscribing the destination port itself, which can cause mirrored frames to be dropped, but this never impacts the original live traffic.

Can I mirror traffic to a port that’s also a normal access or trunk port? No — once configured as a SPAN destination, a port is dedicated to that role and stops participating in normal Layer 2 forwarding, spanning-tree, and (by default) doesn’t accept inbound traffic either.

What’s the difference between SPAN and a TAP? SPAN is a switch feature that copies traffic in software/ASIC logic and can drop frames under oversubscription; a TAP is a physical inline device that copies every bit at the physical layer with zero chance of drops, but requires physical insertion into the cable path and doesn’t scale as easily to monitoring many ports at once.

Can I run SPAN and NetFlow at the same time on the same interface? Yes — they operate independently and are commonly run together, with NetFlow providing lightweight ongoing visibility and SPAN reserved for targeted, deeper investigation when needed.

Summary

SPAN, RSPAN, and ERSPAN all solve the same core problem — getting a copy of switched traffic to an analysis tool that wouldn’t otherwise see it — at increasing levels of geographic reach. Local SPAN handles same-switch capture, RSPAN extends that across switches within a Layer 2 domain using a dedicated VLAN, and ERSPAN goes further still by encapsulating traffic in GRE for delivery across a routed network. In every case, the pattern is the same: define your source (port or VLAN, with direction), define your destination, and verify with show monitor session. Plan destination port bandwidth and platform session limits ahead of time, and you’ll have reliable, production-safe visibility whenever deep packet analysis is needed.

References

• Cisco: Catalyst 9300 Series Switches Configuration Guide — SPAN and RSPAN — https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-x/configuration_guide/span/b_spanrspanerspan_17_1_2013_e_9300_cg.html
• Cisco: Configuring ERSPAN — https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_0100.html
• Cisco: SPAN, RSPAN, and ERSPAN Overview and Restrictions — https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html

The post How to Implement Port Mirroring (SPAN) on Cisco Switches for Traffic Analysis appeared first on Abdul Wahab Junaid.