LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

CCNA: Network Security Fundamentals

39 min read Networking Deep Dives
ccnanetworkingsecurityport-securitydhcp-snoopingdai802.1xciscoios
Contents

Network security at the CCNA level is less about firewalls and more about discipline. The hardest problems to defend against are not the exotic zero-days — they are the attacks that exploit the fundamental trust assumptions baked into Ethernet and IP at Layer 2. ARP has no authentication. DHCP has no authentication. A switch, by default, will forward traffic to any MAC address it learns without question. An attacker who gets physical access to a switch port, or who plugs in a laptop in a conference room, immediately has a foothold that a perimeter firewall does nothing to stop.

This post walks through the Layer 2 and management-plane security features you need to understand for the CCNA exam and, more importantly, for designing access layers that are not embarrassingly easy to compromise. The features covered — port security, DHCP snooping, Dynamic ARP Inspection, IP Source Guard, 802.1X, and management plane hardening — build on each other in a layered defense. Each section includes real IOS/IOS-XE syntax, the verification commands that matter, and the failure modes that will bite you in production if you do not anticipate them.

The Threat Landscape at Layer 2

Every network engineer at some point gets the reassuring mental model that security lives at Layer 3 and above: ACLs on routers, firewall policies, intrusion detection systems. What that mental model misses is that by the time a packet reaches Layer 3, the switch has already made several trust decisions that can completely undermine everything above them.

Consider how a switch actually works. A switch maintains a CAM table (Content Addressable Memory table, also called the MAC address table) that maps MAC addresses to physical ports. When a frame arrives, the switch looks up the destination MAC in the CAM table and forwards it out the appropriate port. If the destination MAC is not in the table, the switch floods the frame out every port in the VLAN — this is called unknown unicast flooding and it is entirely by design. It allows switches to work in a plug-and-play fashion without any configuration.

An attacker who sends a continuous stream of frames with randomized source MAC addresses can fill the CAM table — which has a finite size, typically ranging from around 8,000 entries on a low-end switch to 128,000+ on a core switch — until it overflows. Once the CAM table is full, the switch can no longer learn new MAC-to-port associations, and it starts flooding all traffic to all ports. At that point, the attacker’s network card in promiscuous mode captures every frame traversing the switch: this is MAC flooding, or CAM table overflow. Tools like macof in the Kali Linux distribution can generate 155,000 MAC entries per minute, exhausting most switch CAM tables in seconds. The switch has effectively been turned into a hub.

The DHCP protocol has a similar problem. DHCP is unauthenticated by design: any host on a broadcast domain can send a DHCPDISCOVER, and any device that responds with a DHCPOFFER can potentially become the DHCP server for that segment. A rogue DHCP server handing out attacker-controlled gateway and DNS addresses is trivially simple to set up and immediately allows a man-in-the-middle scenario where every new client on the segment routes its traffic through the attacker’s machine.

DHCP starvation is the companion attack. An attacker sends rapid DHCPDISCOVER messages with spoofed MAC addresses, exhausting the DHCP server’s address pool. New legitimate clients cannot get addresses. The attacker then brings up their own DHCP server to fill the gap, pointing clients at a rogue gateway.

ARP is worse. ARP (Address Resolution Protocol) maps an IP address to a MAC address, and it has absolutely no verification mechanism. Any host can send a gratuitous ARP reply — an unsolicited ARP response — claiming to be the gateway. Hosts on the segment will update their ARP cache without question. The attacker now sits between every host and the router: a classic man-in-the-middle. Victims continue to browse the web while the attacker reads or modifies every packet. Tools like arpspoof, ettercap, and bettercap automate this trivially.

None of these attacks require sophisticated tools or deep expertise. They are the bread and butter of a network penetration test against a hardened-only-at-the-perimeter network. The features in the rest of this post exist specifically to shut them down at the access layer, before the traffic ever reaches a router or firewall.

Port Security

Port security is the most basic Layer 2 security feature and the right starting point conceptually. The premise is simple: lock down which MAC addresses are allowed to send traffic on a given switchport.

By default, a switchport will learn any MAC address that sends traffic on it, up to the CAM table limit, with no restrictions. Port security lets you say: this port may only be used by a specific MAC address (or a limited number of MAC addresses), and if anything else shows up, take a defined action.

Static vs. Sticky MAC Addresses

You can configure allowed MAC addresses in two ways: statically, by typing them in, or dynamically via sticky learning. Static configuration is straightforward:

switchport port-security mac-address 0050.7966.6800

This is precise but operationally painful at scale. You need to know every device’s MAC address before connecting it. Sticky MAC is the practical alternative. When you enable sticky learning, the switch dynamically learns MAC addresses on the port and immediately writes them into the running configuration as if they had been statically configured:

switchport port-security mac-address sticky

The first device that sends traffic on the port gets its MAC address locked in. This is extremely useful during initial deployment: plug in a device, let it get learned, then save the config. The running configuration will contain something like:

switchport port-security mac-address sticky 0050.7966.6800

The critical operational point that trips people up: sticky learned addresses are written to the running configuration, not the startup configuration. If the switch reloads without a copy running-config startup-config (or write memory), all sticky-learned addresses are lost and the process starts over. On a production switch, you should either manually save the config after deployment or automate this with an EEM applet. Forgetting this leads to a post-reboot support ticket where suddenly nothing has network access.

Violation Modes

Port security has three violation modes that determine what happens when a frame arrives from an unauthorized MAC address:

Mode Action on Violation Syslog/SNMP Trap Violation Counter Increments Port State
protect Drop unauthorized frames No No Remains up
restrict Drop unauthorized frames Yes Yes Remains up
shutdown Err-disable the port Yes Yes Goes down (err-disabled)

Protect mode is the quietest: unauthorized frames are dropped silently. No log messages, no SNMP traps, no counter increments. This is almost never the right choice in a managed environment because violations happen with no visibility — you cannot distinguish between “everything is fine” and “someone is actively attacking this port.” Protect exists primarily for scenarios where you genuinely want to ignore the situation and keep the port up, such as a lab or demo environment.

Restrict mode drops unauthorized frames but generates syslog messages and SNMP traps, and increments the violation counter. The port stays up and legitimate devices continue working. This is appropriate when you want visibility into violations but cannot tolerate an access port going down automatically — think hospital environments or manufacturing floors where a port dropping could interrupt operations.

Shutdown mode err-disables the port. It goes completely down. Any device on the port loses connectivity. This is the most secure option and the default in IOS if you do not explicitly specify a mode. It is appropriate for environments where you can accept brief user impact in exchange for certainty that unauthorized devices cannot communicate. An err-disabled port stays down until manually recovered or until the errdisable recovery timer fires.

Basic Configuration

Here is a complete port security configuration for an access port with sticky MAC, a maximum of two MAC addresses, and restrict violation mode:

interface GigabitEthernet0/1
 description Access-Port-User-Facing
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 switchport port-security
 switchport port-security maximum 2
 switchport port-security mac-address sticky
 switchport port-security violation restrict
 spanning-tree portfast
 spanning-tree bpduguard enable
 no cdp enable
 no shutdown

The switchport port-security command alone enables port security with its defaults: maximum 1 MAC, violation shutdown, dynamic (non-sticky) learning. You must explicitly override the defaults to change them. Also note that port security only works on access ports and manually configured trunk ports — it does not work on dynamic-auto or dynamic-desirable ports (DTP negotiation must be disabled or the port set to a static mode first).

Setting maximum to 2 is useful for a cubicle drop where a user has a desktop and a USB hub or VoIP phone that has its own MAC address on the data VLAN. Setting it to 1 with sticky is the tightest configuration for a single-user workstation.

Verification

show port-security

This gives a summary table across all interfaces: the maximum allowed addresses, current address count, security violation count, and security action.

show port-security interface GigabitEthernet0/1

This gives per-interface detail: port status (SecureUp, SecureDown, SecureShutdown), violation mode, maximum addresses, current addresses, and the violation count.

show port-security address

This shows the complete port security address table: each learned MAC, whether it is sticky or static, and which interface and VLAN it is bound to.

show interfaces GigabitEthernet0/1 status

An err-disabled port shows err-disabled in the status column. This is often the first command you run when users report that a port is down after a violation.

Recovering from Err-Disable

The manual recovery procedure is simple:

interface GigabitEthernet0/1
 shutdown
 no shutdown

This cycles the port out of err-disabled state. If the offending device is still connected, it will immediately trigger another violation and re-enter err-disabled. Remove the offending device first.

For automated recovery, you can configure the switch to automatically re-enable err-disabled ports after a timer:

errdisable recovery cause psecure-violation
errdisable recovery interval 300

This will automatically attempt to re-enable a port that went err-disabled due to a port security violation after 300 seconds (5 minutes). Be cautious with auto-recovery in high-security environments: if the attacker’s device is still plugged in, the port will re-enable, immediately go back to err-disabled, and repeat in a loop every 5 minutes. That is not great from a security standpoint, but it may be preferable to operations staff being paged at 2am for every violation.

Limitations

Port security’s fundamental limitation is that it authenticates MAC addresses, and MAC addresses are trivially spoofable. An attacker who observes valid traffic from a port (using a hub or passive tap upstream) can clone the authorized MAC address and bypass port security entirely. This is why port security is considered a deterrent against casual unauthorized access rather than a strong authentication mechanism. For environments that need genuine device authentication, 802.1X is the appropriate technology, and it is covered later in this post.

DHCP Snooping

DHCP snooping is a switch feature that acts as a firewall between DHCP clients and DHCP servers. It enforces which switchports are allowed to send DHCP server responses, preventing rogue DHCP servers from poisoning clients with false gateway and DNS information.

The Attack DHCP Snooping Prevents

The rogue DHCP server attack is straightforward: an attacker plugs a device running a DHCP server daemon (isc-dhcpd, dnsmasq, or any number of alternatives) into a switch port. When clients send DHCPDISCOVER broadcasts, both the legitimate server and the rogue server race to respond. Whichever DHCPOFFER arrives first wins. The rogue server sets itself (or a separate device) as the default gateway. Clients that accept the rogue offer route all their traffic through the attacker, who acts as a transparent proxy — forwarding traffic to maintain connectivity while capturing or modifying it at will. This is a complete man-in-the-middle with no indication to end users that anything is wrong.

Trusted vs. Untrusted Ports

DHCP snooping classifies every port as either trusted or untrusted. By default, all ports are untrusted.

  • Untrusted ports are ports connected to end hosts — workstations, printers, IP phones. Untrusted ports are allowed to send DHCP client messages (DISCOVER, REQUEST, INFORM, RELEASE). They are not allowed to send DHCP server messages (OFFER, ACK, NAK). If a DHCP OFFER or ACK arrives on an untrusted port, DHCP snooping drops it. This is what stops the rogue DHCP server.

  • Trusted ports are ports connected to legitimate DHCP servers or to uplinks toward a DHCP server (routers, other switches in the path). DHCP server messages are permitted on trusted ports.

                    DISTRIBUTION SWITCH
                    +------------------+
                    |  DHCP Server     |
                    |  10.0.0.1        |
                    +--------+---------+
                             |
                    Gi0/0 (TRUSTED)
                             |
                    +--------+---------+
                    |   ACCESS SWITCH  |
                    |  (snooping ON)   |
                    +--+--+--+--+--+---+
                       |  |  |  |  |
                 Gi0/1 |  |  |  |  | Gi0/5
                (UNTRUSTED)         (UNTRUSTED)
                  |                    |
            +-----+----+         +-----+----+
            | Legit PC |         | Rogue    |
            | Client   |         | DHCP     |
            +----------+         | Server   |
                                 +----------+

  Gi0/5: OFFER/ACK from rogue server --> DROPPED by snooping
  Gi0/0: OFFER/ACK from real server  --> FORWARDED (trusted)

The DHCP Snooping Binding Table

When DHCP snooping witnesses a successful DHCP exchange on an untrusted port — specifically when it sees a DHCPACK from the server — it creates an entry in the DHCP snooping binding table. Each entry records:

  • Client MAC address
  • Leased IP address
  • VLAN number
  • Switch interface
  • Lease duration

This binding table is critical because it is the data source that Dynamic ARP Inspection and IP Source Guard use for their validations. Think of it as the ground truth of who is legitimately using which IP address on which port. DHCP snooping is not just useful on its own; it is infrastructure for the features that follow it in this post.

A critical operational note: the DHCP snooping binding table lives in RAM. If the switch reloads — power loss, scheduled reload, IOS upgrade — the binding table is lost. Devices that already have leases will not re-trigger DHCPDISCOVER immediately (they try to renew at the T1 timer, typically 50% of lease time). During that window, DAI and IP Source Guard will have no entries for these hosts and may block their traffic. To persist the binding table across reloads, configure the switch to write it to NVRAM or a TFTP server:

ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 300

IOS Configuration

! Enable DHCP snooping globally
ip dhcp snooping

! Enable on specific VLANs (must be explicit)
ip dhcp snooping vlan 10
ip dhcp snooping vlan 20
ip dhcp snooping vlan 30

! Trust the uplink to the distribution switch (or to the DHCP server directly)
interface GigabitEthernet0/0
 ip dhcp snooping trust

! Rate limit DHCP traffic on untrusted ports to protect against DHCP starvation
interface range GigabitEthernet0/1 - 24
 ip dhcp snooping limit rate 15

! Persist the binding table across reloads
ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 300

The rate limit of 15 DHCP packets per second per port is a common baseline. Legitimate hosts rarely need more than a few DHCP transactions per minute. An attacker running DHCP starvation will be sending hundreds per second — rate limiting prevents the attack from exhausting the server pool and triggers a syslog warning.

Option 82 (Relay Agent Information)

Option 82, also called the DHCP relay agent information option, is a field that DHCP relay agents insert into forwarded DHCP packets to convey information about the client’s network location — typically the switch identifier and port number. This is useful for DHCP servers that need to assign addresses based on location.

The problem for CCNA candidates: when DHCP snooping is enabled on a switch that is not acting as a relay agent (the clients and the server are in the same broadcast domain or the relay is upstream), IOS by default inserts Option 82 into snooped packets. This is technically incorrect behavior for a non-relay-agent switch and some DHCP servers reject these packets, causing DHCP to fail completely. If DHCP stops working after enabling snooping and you can confirm snooping is correctly configured with trusted uplinks, this is almost always the culprit:

no ip dhcp snooping information option

This disables Option 82 insertion by the snooping switch. Check your environment — some enterprise DHCP servers expect Option 82 for policy enforcement, in which case you want it on.

Verification

show ip dhcp snooping

Shows the global snooping status, which VLANs it is active on, and whether Option 82 insertion is enabled.

show ip dhcp snooping binding

Displays the complete binding table: MAC address, IP address, lease time remaining, binding type (DHCP learned vs. static), VLAN, and interface.

show ip dhcp snooping statistics

Shows counters for forwarded and dropped packets on each interface. If you are seeing unexpected drops, this tells you exactly how many and on which port.

The Most Common Gotcha

If DHCP snooping is enabled globally and on the correct VLANs, but the uplink interface is not configured as trusted, all DHCP OFFER and ACK packets from the legitimate server will be dropped. Clients will send DISCOVER requests that go nowhere. This presents as “DHCP not working” and it is one of the most common implementation mistakes. Always verify:

show ip dhcp snooping | include Trusted

or check the interface configuration directly to confirm the uplink is trusted.

Dynamic ARP Inspection (DAI)

Dynamic ARP Inspection validates ARP packets on a VLAN to prevent ARP cache poisoning attacks. It uses the DHCP snooping binding table as its reference data to determine whether an ARP packet contains a valid IP-to-MAC binding.

How ARP Poisoning Works (and Why It Is So Effective)

ARP operates at Layer 2 and has no concept of authentication or trust. When a host wants to communicate with another IP address on the same subnet, it broadcasts an ARP request: “Who has IP 10.0.0.1? Tell 10.0.0.50.” The device with that IP responds with an ARP reply containing its MAC address. The requesting host caches this mapping and uses it for subsequent frames.

The attack exploits two behaviors. First, hosts accept unsolicited (gratuitous) ARP replies — they do not need to have sent a request to update their cache. Second, hosts will overwrite existing cache entries with newer ARP replies. An attacker simply needs to continuously send gratuitous ARP replies claiming to be the gateway:

  BEFORE DAI (attack succeeds):

  Attacker sends gratuitous ARP:
  "10.0.0.1 is at AA:BB:CC:DD:EE:FF (attacker MAC)"

  +----------+         +----------+         +----------+
  | Victim A |         | ATTACKER |         |  Router  |
  | .50      |         |    .99   |         |  .1      |
  +----+-----+         +----+-----+         +----+-----+
       |                    |                    |
       +--------------------+--------------------+
                 L2 Broadcast Domain

  Victim A ARP cache: 10.0.0.1 -> AA:BB:CC:DD:EE:FF (POISONED)
  All traffic from Victim A to 10.0.0.1 goes to Attacker first.
  Attacker forwards to Router, intercepts/modifies at will.

  -------------------------------------------------------

  WITH DAI (attack blocked):

  Attacker sends gratuitous ARP:
  "10.0.0.1 is at AA:BB:CC:DD:EE:FF"

  Switch checks DHCP snooping binding table:
  10.0.0.1 bound to MAC 00:11:22:33:44:55 on Gi0/24 (trusted uplink)
  AA:BB:CC:DD:EE:FF does not match --> ARP packet DROPPED

  Victim A never sees the fake ARP reply. Cache remains valid.

How DAI Uses the DHCP Snooping Binding Table

When an ARP packet arrives on an untrusted DAI port, the switch extracts the sender IP and sender MAC from the ARP packet and checks the DHCP snooping binding table for a matching entry. If an entry exists and the MAC matches the interface it arrived on, the ARP is forwarded. If there is no entry, or the MAC does not match, or the IP does not match the binding for that MAC, the ARP is dropped and a syslog message is generated.

This is why DHCP snooping must be enabled before DAI. DAI without a populated binding table will drop ARP packets from every host because there are no entries to validate against. Enable snooping, let clients get DHCP leases and populate the binding table, then enable DAI.

Trusted DAI ports (uplinks to routers and distribution switches) bypass validation entirely — their ARP packets are forwarded unconditionally. The same trust topology as DHCP snooping: all host-facing ports are untrusted, uplinks are trusted.

ARP ACLs for Static IP Hosts

Devices with statically configured IP addresses do not go through DHCP, so they never appear in the DHCP snooping binding table. DAI will drop their ARP packets. The solution is an ARP ACL that provides the static mapping:

arp access-list STATIC-HOSTS
 permit ip host 10.0.0.10 mac host 0050.7966.0001
 permit ip host 10.0.0.11 mac host 0050.7966.0002

ip arp inspection filter STATIC-HOSTS vlan 10

The ARP ACL maps specific IP addresses to specific MAC addresses. When DAI checks an ARP packet and finds no DHCP snooping binding, it then checks the ARP ACL. If a match is found and the MAC matches, the ARP is permitted.

IOS Configuration

! DAI requires DHCP snooping to be enabled first
ip dhcp snooping
ip dhcp snooping vlan 10

! Enable DAI on the VLAN
ip arp inspection vlan 10

! Trust the uplink (same port that is trusted for DHCP snooping)
interface GigabitEthernet0/0
 ip arp inspection trust

! Optional: ARP rate limiting on untrusted ports (default is 100 pps burst 1 sec)
! Reduces to something more conservative for access ports
interface range GigabitEthernet0/1 - 24
 ip arp inspection limit rate 100

DAI enables per-VLAN rate limiting by default. If an untrusted port sends more ARP packets than the configured rate limit (default 100 packets per second per burst interval), DAI err-disables the port. This prevents ARP flooding attacks but can also err-disable a legitimate port if a device sends a burst of ARPs — some applications and operating systems do this during startup. You may need to tune the rate limits up for ports connected to servers or applications known to send ARP bursts.

! To recover a DAI-err-disabled port:
interface GigabitEthernet0/5
 shutdown
 no shutdown

! Or configure automatic recovery:
errdisable recovery cause arp-inspection
errdisable recovery interval 300

Verification

show ip arp inspection

Global summary: VLANs with DAI active, packet forwarded/dropped/dropped-by-ACL counts.

show ip arp inspection vlan 10

Per-VLAN detail including the trust status of interfaces and forwarding/drop statistics per interface.

show ip arp inspection statistics

Detailed counters including ARP probes forwarded/dropped, gratuitous ARP forwarded/dropped, and the reasons for drops.

IP Source Guard

IP Source Guard (IPSG) is the most granular of the three snooping-dependent features. Where DHCP snooping controls DHCP traffic and DAI validates ARP mappings, IP Source Guard filters all IP traffic based on the DHCP snooping binding table, creating implicit per-port ACLs that allow only traffic from the IP address (and optionally MAC address) that was legitimately assigned to that port.

The Attack IP Source Guard Prevents

IP address spoofing at the access layer. An attacker connected to switch port Gi0/5 might have been assigned 10.0.0.50 by DHCP. Without IPSG, that attacker can configure their interface to use any arbitrary source IP — say, 10.0.0.1 (the gateway) or 10.0.0.99 (a server) — and send traffic with that spoofed source address. This allows IP-based ACL bypass, log poisoning, and various reflection/amplification attacks where the attacker wants responses directed elsewhere.

IP Source Guard prevents this by allowing only traffic with source IP 10.0.0.50 to egress Gi0/5. Any packet with a different source IP is dropped before it can traverse the switch fabric.

How It Works

When IPSG is enabled on a port, the switch dynamically creates a VACL (VLAN ACL) or port ACL that permits only traffic matching the DHCP snooping binding table entry for that port. The permit entry is implicitly maintained as the DHCP lease is renewed; when the lease expires, the permit is removed and all IP traffic from that port is dropped until a new binding is created.

Two modes are available:

! IP-only filtering: only validates source IP address
interface GigabitEthernet0/1
 ip verify source

! IP + MAC filtering: validates both source IP and source MAC (more thorough)
interface GigabitEthernet0/1
 ip verify source port-security

The port-security keyword adds MAC address validation on top of IP validation. To use this mode, port security must also be enabled on the interface. This is the most thorough option but also the most operationally complex to manage.

For devices with static IP addresses that are not in the DHCP snooping binding table, you must create static binding entries:

ip source binding 0050.7966.0010 vlan 10 10.0.0.10 interface GigabitEthernet0/3

This tells IPSG that MAC 0050.7966.0010 on VLAN 10 is legitimately using 10.0.0.10 on Gi0/3 — without relying on DHCP snooping to have populated this entry.

Verification

show ip verify source

Shows each interface with IPSG enabled, the filter type (IP or IP/MAC), and the IP and MAC addresses being permitted.

show ip source binding

Shows all bindings — both dynamically learned from DHCP snooping and statically configured — that IPSG is using.

When to Deploy IP Source Guard

IPSG is the right tool for highly regulated or sensitive environments: PCI-DSS cardholder data networks, management networks for critical infrastructure, or any segment where IP spoofing represents a significant threat. It adds CPU and TCAM overhead because the switch must maintain per-port ACL entries dynamically. On a large access switch with 48 ports all using IPSG, this TCAM pressure is worth evaluating against your hardware’s capacity. For most enterprise access layers, DHCP snooping and DAI provide substantial protection at lower overhead. IPSG is the additional layer you add when the risk warrants it.

802.1X Port-Based Authentication

Everything discussed so far authenticates devices by their MAC addresses or IP addresses — properties that are trivially spoofable. Port security can be defeated by MAC cloning in under a minute. DAI and DHCP snooping protect against specific protocol attacks but do not actually verify the identity of the device on the port. 802.1X is the answer to the question: “Who is actually plugging into this port, and are they authorized to be on this network?”

The Three Components

802.1X port-based network access control involves three distinct roles:

Supplicant: The end device requesting access — a workstation, laptop, IP phone, or printer. The supplicant runs 802.1X client software and responds to authentication challenges. Modern operating systems (Windows, macOS, Linux) have built-in 802.1X supplicants. The supplicant communicates with the authenticator using EAPOL (EAP over LAN), a special Ethernet frame type with its own EtherType (0x888E).

Authenticator: The network switch (or wireless access point) that enforces access control. The switch is in the middle: it passes EAP messages from the supplicant to the authentication server, but it does not make authentication decisions itself. The authenticator enforces the result: put the port in authorized state or leave it in unauthorized state.

Authentication Server: Typically a RADIUS server (FreeRADIUS, Cisco ISE, Microsoft NPS, Aruba ClearPass). The RADIUS server holds the user/device credential database and makes the actual pass/fail decision. It communicates with the authenticator using RADIUS over UDP.

  +---------------+    EAPOL (L2)    +---------------+
  |   Supplicant  | <--------------> | Authenticator |
  |  (workstation)|                  |    (switch)   |
  +---------------+                  +-------+-------+
                                             |
                                   RADIUS (UDP 1812/1813)
                                             |
                                     +-------+-------+
                                     |   Auth Server |
                                     |   (RADIUS)    |
                                     +---------------+

  Port states:
  UNAUTHORIZED: Only EAPOL frames pass. No IP traffic allowed.
  AUTHENTICATING: EAP exchange in progress.
  AUTHORIZED: Full access granted. Normal traffic flows.

EAP and Common EAP Types

EAP (Extensible Authentication Protocol) is a framework that supports multiple authentication methods. The switch does not need to understand the EAP method being used — it just passes EAP messages between the supplicant and the RADIUS server (this is called EAP pass-through). Common EAP types:

EAP-TLS: Mutual certificate-based authentication. Both the client and the server present X.509 certificates. This is the most secure method and eliminates password-based attacks entirely, but requires a PKI infrastructure to issue and manage client certificates. Common in enterprises with Active Directory Certificate Services.

PEAP (Protected EAP): Wraps an inner authentication method (usually MSCHAPv2 for username/password) inside a TLS tunnel. Only the server needs a certificate. Less infrastructure overhead than EAP-TLS. The most commonly deployed method in enterprise environments without full PKI.

EAP-FAST: Cisco proprietary method that uses Protected Access Credentials (PACs) instead of certificates. Rarely used in new deployments.

For the CCNA, you need to understand that EAP-TLS is certificate-based and considered the gold standard, and PEAP uses a password inside a TLS tunnel. You do not need to know the inner workings of the cryptographic handshakes.

IOS Configuration

! Enable AAA subsystem (required for 802.1X)
aaa new-model

! Define the authentication method for 802.1X: use RADIUS
aaa authentication dot1x default group radius

! Define RADIUS server
radius server ISE
 address ipv4 10.0.0.200 auth-port 1812 acct-port 1813
 key Sup3rS3cr3tRADIUS

! Enable 802.1X globally
dot1x system-auth-control

! Configure the interface
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10
 authentication port-control auto
 dot1x pae authenticator
 spanning-tree portfast

The authentication port-control auto command is the key line. With auto, the port starts in unauthorized state and transitions to authorized only after successful 802.1X authentication. Other port-control options:

  • force-authorized: Port is always authorized regardless of authentication. Equivalent to disabling 802.1X. Default state.
  • force-unauthorized: Port is always unauthorized. Nothing passes. Useful for temporarily blocking a port.
  • auto: Normal 802.1X operation.

Authentication Host Modes

By default, 802.1X operates in single-host mode: one device authenticates, and once that device is authenticated, no other device on the port can communicate (any additional MAC addresses are dropped). This works for a PC connected directly to a switch port.

The complication arises with IP phones. A typical cubicle deployment has a Cisco IP phone with a built-in switch: the PC connects to the phone, which connects to the wall jack. The phone and PC are two different devices, and 802.1X needs to handle both.

Multi-auth mode (authentication host-mode multi-auth) allows each device on a port to authenticate independently. The phone authenticates (potentially to a voice VLAN via CDP/LLDP), and the PC authenticates (to the data VLAN). This is the recommended configuration for ports with IP phones in an 802.1X deployment.

Multi-domain authentication (MDA) specifically differentiates between voice domain (phone) and data domain (PC), enforcing that only one device can be in each domain simultaneously.

Practical Considerations at CCNA Level

The CCNA exam expects you to understand the three-component model (supplicant, authenticator, authentication server), know the difference between EAP-TLS and PEAP at a conceptual level, and be able to configure the basic IOS commands shown above. Deep RADIUS server configuration, certificate management, and troubleshooting 802.1X authentication failures are more in the realm of CCNP Security and implementation-level work. Focus on understanding what problem 802.1X solves (device/user identity verification) and why it is superior to MAC-based port security (MAC is spoofable; credentials or certificates are not).

Management Plane Hardening

All of the features covered so far protect the data plane — the traffic traversing the network. The management plane is the traffic destined for the switch itself: SSH sessions, SNMP queries, Syslog messages, NTP synchronization. A switch that is fully locked down in the data plane but accessible via Telnet with weak credentials can still be completely compromised.

Telnet is Dead. Use SSH.

Telnet transmits everything in cleartext, including credentials. Anyone with a packet capture between the administrator and the switch sees every command typed during the session. There is no acceptable security reason to use Telnet in 2026. Disable it unconditionally.

Enabling SSH requires an RSA key pair. IOS will not allow SSH without it:

! Set hostname and domain name (required for RSA key generation)
hostname ACCESS-SW-01
ip domain-name lunarops.internal

! Generate RSA keypair (2048 bits minimum; 4096 is better for high-security environments)
crypto key generate rsa modulus 2048

! Force SSH version 2 (v1 has known vulnerabilities)
ip ssh version 2

! Optional: reduce authentication retries and timeout
ip ssh authentication-retries 3
ip ssh time-out 60

Once the key is generated, configure the VTY lines:

line vty 0 4
 transport input ssh
 login local
 exec-timeout 10 0
 logging synchronous

transport input ssh blocks Telnet entirely — only SSH connections are accepted. login local uses the local username database (configured with username commands) rather than the line password. exec-timeout 10 0 terminates idle sessions after 10 minutes — an administrator who walks away from a terminal leaves no unlocked session for the next person.

Local User Authentication

! Create an admin account with privilege level 15 (full access)
username admin privilege 15 algorithm-type scrypt secret <strong-password-here>

! Create a read-only account with privilege level 1
username monitor privilege 1 algorithm-type scrypt secret <password-here>

The algorithm-type scrypt argument stores the password as a Type 9 hash (scrypt-based), which is computationally expensive to brute-force. This is available in IOS-XE 16.x and later. On older IOS, secret without the algorithm-type argument uses Type 5 (MD5), which is much weaker but still preferable to Type 7.

Privilege Levels

Cisco IOS has 16 privilege levels, numbered 0 through 15:

Level Default Access Common Use
0 Absolute minimum: disable, enable, exit, help, logout Rarely used directly
1 User EXEC — show commands, ping, traceroute Read-only monitoring staff
2-14 Custom — assign specific commands Role-based access: NOC, helpdesk
15 Privileged EXEC — full access Network administrators

Custom privilege levels let you grant specific capabilities without giving full admin access. For example, to let a helpdesk account bounce a specific interface:

privilege exec level 5 clear interface
privilege exec level 5 show interfaces
username helpdesk privilege 5 secret <password>

Helpdesk users who SSH in will be at privilege level 5 and can run only the commands explicitly assigned to that level.

Password Encryption and the Type 7 Problem

service password-encryption is a global command that applies weak reversible encryption (Cisco’s proprietary Type 7, based on a Vigenere cipher) to passwords stored in the configuration. This prevents casual shoulder-surfing of a printed config, but it is not cryptographically meaningful. Type 7 passwords can be decoded in seconds with freely available online tools. Do not mistake it for security:

service password-encryption

The correct approach is to avoid Type 7 passwords entirely and use secret instead of password everywhere:

! Wrong: uses Type 7 (reversible)
enable password cisco123

! Correct: uses MD5 (Type 5) or scrypt (Type 9)
enable secret algorithm-type scrypt <strong-password>

The enable secret command always takes precedence over enable password if both are configured. Never configure enable password in a production environment. If you see both in a configuration, enable secret wins, but the existence of enable password is a red flag.

A summary of IOS password types:

Type Algorithm Strength Command
0 Plaintext None password <text> without encryption
7 Vigenere (reversible) Obfuscation only service password-encryption applied
5 MD5 Moderate (fast hash, brutable) secret <text> on older IOS
8 PBKDF2-SHA256 Strong algorithm-type sha256 secret
9 scrypt Very strong algorithm-type scrypt secret

Always use Type 9 if your IOS version supports it. Type 5 is acceptable on platforms where Type 9 is unavailable. Type 7 should be treated as plaintext for security purposes.

Console and AUX Hardening

The console port provides physical access to the switch CLI. Unlike VTY lines, it does not go over the network, so encryption is less relevant — but it still needs authentication and timeout:

line console 0
 login local
 exec-timeout 5 0
 logging synchronous

The AUX port on older IOS routers is historically used for out-of-band management via modem. Most modern switches do not have AUX ports, but if your device does and you are not using it:

line aux 0
 transport input none
 no exec
 exec-timeout 0 1

This disables the AUX port entirely — no exec process, no input accepted, session times out after one second.

AAA and Centralized Authentication

For environments with more than a handful of switches, managing local usernames on every device becomes operationally untenable. AAA (Authentication, Authorization, Accounting) with a centralized server solves this:

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

tacacs server ISE-TACACS
 address ipv4 10.0.0.201
 key TacacsKey123

! Fallback to local accounts if TACACS is unreachable
username admin privilege 15 algorithm-type scrypt secret <local-fallback-password>

RADIUS vs. TACACS+: Both are AAA protocols but with important differences:

Characteristic RADIUS TACACS+
Transport UDP (1812/1813) TCP (49)
Encryption Password field only Full packet body
Architecture Combines auth + authz Separates auth, authz, acct
Command authorization Not natively supported Supported per-command
Vendor IETF standard Cisco proprietary
Common use Network access (802.1X, VPN) Device management (SSH to switch)

For managing network devices, TACACS+ is generally preferred because it supports per-command authorization (log every command issued, require approval for certain commands) and encrypts the entire packet body rather than just the password. RADIUS is the standard for user network access control (802.1X, VPN, wireless).

Logging and Monitoring

Without logging, you have no audit trail. Configure at minimum:

! Buffer logs in RAM (survives until reload)
logging buffered 64000 informational

! Send logs to a remote syslog server
logging host 10.0.0.100
logging trap informational

! Add timestamps to log messages
service timestamps log datetime msec localtime show-timezone

! Correlate log messages with their source
logging source-interface Loopback0

The logging source-interface command is important in multi-interface environments. Without it, the source IP of syslog packets changes depending on which interface is used to reach the syslog server. Using a loopback interface gives a consistent, stable source address.

SNMP Security

SNMP v1 and v2c use community strings — essentially plaintext passwords transmitted in cleartext. Anyone who captures an SNMP query to your switches can read the community string and potentially use it to query or configure your entire network. Avoid SNMPv1/v2c on management interfaces in sensitive environments:

! If you must use v2c, restrict it to a specific host and use an ACL
access-list 10 permit 10.0.0.100
snmp-server community R3adOnly123 RO 10

! SNMPv3 with authentication and encryption (preferred)
snmp-server group MGMT-GROUP v3 priv
snmp-server user SNMP-ADMIN MGMT-GROUP v3 auth sha AuthPassw0rd priv aes 128 PrivPassw0rd

SNMPv3 with auth priv mode authenticates the packet (SHA or MD5, use SHA) and encrypts it (AES or DES, use AES). This is the only SNMP version appropriate for production network management.

The banner message of the day (MOTD) is not just cosmetic. In many jurisdictions, a warning banner is legally required to establish that unauthorized access is not permitted — without one, prosecution for unauthorized access may be complicated by an argument that there was no notice:

banner motd ^
**************************************************************************
AUTHORIZED ACCESS ONLY

This system is the property of LunarOps and is for authorized use only.
Unauthorized access is strictly prohibited and may be subject to criminal
and civil penalties. All activities on this system are monitored and
logged. By continuing, you consent to this monitoring.
**************************************************************************
^

Keep the banner factual and avoid advertising specific software versions or network topology — that information is useful to attackers. Do not include a login prompt in the MOTD (e.g., do not say “Login below”) as some organizations use that to argue there was an implicit invitation.

Putting It All Together: A Secure Access Layer Design

The features covered in this post are not meant to be deployed in isolation. They form a layered defense that addresses different attack vectors, and the full benefit is realized only when they work together.

Reference Topology

Consider a typical access layer: a distribution switch connected to multiple access switches, each serving 24-48 end users. The distribution switch has an uplink to a routed core, and the DHCP server lives somewhere above the distribution layer.

                    +------------------------+
                    |   Distribution Switch  |
                    |   (or Router-on-stick) |
                    +----------+-------------+
                               |
                          Gi0/0 UPLINK
                          (TRUSTED: DHCP/DAI)
                               |
                    +----------+-------------+
                    |    ACCESS SWITCH       |
                    |  hostname ACCESS-01    |
                    +--+--+--+--+--+--+--+--+
                       |  |  |  |  |  |  |
                    Gi0/1 thru Gi0/24 (UNTRUSTED)
                    Host-facing ports, VLAN 10

                    Each access port:
                    - 802.1X auto OR port-security sticky
                    - DHCP snooping untrusted
                    - DAI untrusted
                    - BPDU Guard enabled
                    - PortFast enabled
                    - CDP disabled

Complete Access Switch Configuration Block

! ============================================================
! GLOBAL SECURITY SETTINGS
! ============================================================
hostname ACCESS-01
ip domain-name lunarops.internal

! Management credentials
crypto key generate rsa modulus 2048
ip ssh version 2
ip ssh authentication-retries 3
ip ssh time-out 60
username admin privilege 15 algorithm-type scrypt secret Str0ngPassw0rd!
username monitor privilege 1 algorithm-type scrypt secret M0nit0rPass!

service password-encryption
enable secret algorithm-type scrypt En4bleSecret!

! AAA
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

tacacs server TACACS-PRIMARY
 address ipv4 10.0.0.201
 key TacacsKey!

! Logging
service timestamps log datetime msec localtime show-timezone
logging buffered 64000 informational
logging host 10.0.0.100
logging trap informational
logging source-interface Vlan99

! SNMP (v3 only)
snmp-server group MGMT-GROUP v3 priv
snmp-server user SNMP-ADMIN MGMT-GROUP v3 auth sha AuthPassw0rd priv aes 128 PrivPassw0rd

! VTY lines - SSH only
line vty 0 4
 transport input ssh
 login authentication default
 exec-timeout 10 0
 logging synchronous

line console 0
 login local
 exec-timeout 5 0
 logging synchronous

! Banner
banner motd ^
AUTHORIZED ACCESS ONLY - LunarOps Property - Unauthorized access prohibited.
^

! ============================================================
! DHCP SNOOPING
! ============================================================
ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option
ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 300

! ============================================================
! DYNAMIC ARP INSPECTION
! ============================================================
ip arp inspection vlan 10

! ============================================================
! UPLINK TO DISTRIBUTION (TRUSTED)
! ============================================================
interface GigabitEthernet0/0
 description UPLINK-TO-DIST-SW
 switchport mode trunk
 switchport trunk allowed vlan 10,99
 switchport nonegotiate
 ip dhcp snooping trust
 ip arp inspection trust
 no cdp enable
 spanning-tree guard root
 no shutdown

! ============================================================
! MANAGEMENT VLAN INTERFACE
! ============================================================
interface Vlan99
 description MANAGEMENT
 ip address 10.99.0.10 255.255.255.0
 no shutdown

ip default-gateway 10.99.0.1

! ============================================================
! ACCESS PORTS - HOST FACING (TEMPLATE)
! ============================================================
interface range GigabitEthernet0/1 - 24
 description Access-User-Port
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 ! Port security (use OR 802.1X, not both on same port in basic config)
 switchport port-security
 switchport port-security maximum 2
 switchport port-security mac-address sticky
 switchport port-security violation restrict
 ! DHCP snooping rate limit
 ip dhcp snooping limit rate 15
 ! DAI rate limit
 ip arp inspection limit rate 100
 ! IP Source Guard (enable selectively based on risk/overhead tradeoff)
 ip verify source
 ! STP protection
 spanning-tree portfast
 spanning-tree bpduguard enable
 ! Disable CDP on user-facing ports
 no cdp enable
 no shutdown

! ============================================================
! ERRDISABLE RECOVERY
! ============================================================
errdisable recovery cause psecure-violation
errdisable recovery cause arp-inspection
errdisable recovery cause dhcp-rate-limit
errdisable recovery interval 300

The Security Trinity

Three questions define whether a device on your network is legitimate:

  1. Who is connecting? — Answered by 802.1X. The device presents credentials or a certificate; the RADIUS server says yes or no. Port security is the lighter alternative for environments without an 802.1X infrastructure.

  2. What IP address did they legitimately receive? — Answered by DHCP snooping. The binding table records the MAC-to-IP mapping established through a legitimate DHCP exchange. DAI and IP Source Guard depend on this record.

  3. Is their ARP traffic consistent with their identity? — Answered by DAI. Any ARP packet claiming an IP-to-MAC mapping is checked against the binding table. Mismatches are dropped.

These three together close the major Layer 2 attack vectors: MAC flooding (port security limits MAC count per port), DHCP starvation and rogue servers (DHCP snooping), ARP poisoning (DAI), and IP spoofing (IP Source Guard).

Troubleshooting Reference

Symptom Likely Cause Fix
Host cannot get DHCP address DHCP snooping enabled, uplink not trusted ip dhcp snooping trust on uplink interface
Host cannot get DHCP address (2) Option 82 being inserted, server rejecting no ip dhcp snooping information option
Host has DHCP address but no connectivity DAI dropping ARP — binding table empty Verify show ip dhcp snooping binding; check snooping is trusted on uplink; may need to wait for DHCP renew
Static IP host cannot reach anything DAI dropping ARP — no binding table entry Create ARP ACL with arp access-list and apply with ip arp inspection filter
Static IP host still cannot reach anything after ARP ACL IPSG blocking IP traffic Add static binding ip source binding for the host
Port went err-disabled Port security, DAI rate limit, or BPDU guard violation show interfaces Gi0/X status, identify cause, remove offending device, shutdown/no shutdown
Cannot SSH to switch No RSA key, SSH not version 2, VTY transport input not set crypto key generate rsa modulus 2048, ip ssh version 2, line vty 0 4 / transport input ssh
SSH accepts connection but rejects password login local not configured, or username does not exist Verify line vty 0 4 / login local and `show running-config
DHCP snooping binding table empty after reload Database not configured for persistence ip dhcp snooping database flash:dhcp-snooping.db
ARP inspection dropping too many packets Rate limit too low for device sending ARP bursts Increase ip arp inspection limit rate on that interface; check show ip arp inspection statistics
enable secret and enable password both present Historical misconfiguration Remove enable password, keep only enable secret

Closing Thoughts

Layer 2 security is unglamorous infrastructure work. It does not have the visibility of a firewall or an IDS, and nobody writes blog posts celebrating the ARP poison attack that DAI quietly dropped at 2pm on a Tuesday. But the absence of these features is visible: in a breach investigation, in a “why is my traffic going through that weird host” ticket, in a penetration test report that starts with “we obtained DHCP credentials from a conference room port.”

The features in this post represent a reasonable baseline for any wired access layer. Port security or 802.1X for access control. DHCP snooping for server integrity. DAI to close the ARP attack surface. SSH-only management with strong credentials and centralized AAA. These are not optional hardening measures — they are the minimum expected configuration of a professionally managed network.

For the CCNA exam, understand what each feature does, what attack it prevents, and the basic configuration syntax. Know that DAI depends on DHCP snooping, that sticky MAC addresses require a write memory to persist, that transport input ssh is the correct VTY configuration, and that enable secret beats enable password. Understand the trusted/untrusted port model that DHCP snooping and DAI share.

For production, pair this post with your specific platform’s documentation. IOS-XE behavior on Catalyst 9000-series switches is the current reference for most enterprise deployments, and some command syntax and feature availability varies between older IOS versions and modern IOS-XE. The concepts are stable; the exact options evolve.

Build these habits at the access layer and you will have a significantly harder network to compromise — not because you have closed every possible attack vector, but because you have forced an attacker to escalate from “plug in a laptop” to “find a real vulnerability.” That escalation requirement is the goal.

Comments