Switching, VLANs, and Layer 2 Segmentation Questions

Summary / priority: Start L2 (host→switch trunk/ VLAN), then SVI status, then inter-VLAN routing (routes/VRF), then ACLs.

1) Verify host & VLAN membership (L2)

• On host: confirm IP/gw and ARP

ipconfig /all  # or `ip addr` on Linux
arp -a
ping <SVI-IP>

• On switch: confirm interface in VLAN 100 and not shut

show interface status | include <access-port>
show running-config interface <int>
show mac address-table vlan 100

Likely root cause: host mis-VLAN or port shutdown.

2) Check trunk between access switch and routed switch/router (L2)

show interface <trunk-int> trunk
show running-config interface <trunk-int>
show vlan brief

Likely root cause: trunk misconfiguration (native/tagged VLANs, allowed VLANs).

3) Verify SVI state and VLAN existence (L3 on switch)

show ip interface brief | include Vlan100|Vlan200
show running-config interface Vlan100
show vlan id 100

Likely root cause: SVI admin down, VLAN missing.

4) Test inter-VLAN routing and routing table / VRF (L3)

show ip route vrf all | include 10.100.0.0  # adjust subnets
show ip route
show vrf
show ip cef  # or show ip route detail

Likely root cause: missing route or VRF mismatch (SVIs in different VRFs).

5) Check ACLs applied to SVIs

show access-lists
show running-config interface Vlan100
show running-config interface Vlan200
show ip access-lists | include Vlan100

Likely root cause: ACL blocking inter-VLAN traffic on source or destination SVI.

6) Verify forwarding/ARP across VLANs (end-to-end tests)

show ip arp | include <host-in-VLAN200>
traceroute <host-in-VLAN200>
ping <VLAN200-IP> source <VLAN100-IP>   # from switch if supported

7) If routed via external router/firewall

show route on upstream device
show access-lists on upstream device
show nat translations

Likely root cause: missing return route or firewall ACL/NAT.

Notes: Run tests in order (L2 → SVI → routing → ACLs). Capture outputs, correlate ARP/mac tables to ensure frames traverse.

High-level summary

• DHCP snooping builds a binding table of (MAC, IP, VLAN, interface, lease) by permitting DHCP responses only from trusted ports.
• Dynamic ARP Inspection (DAI) validates ARP packets against that DHCP snooping binding table to prevent ARP spoofing/poisoning.
  Together they stop DHCP spoofers from issuing bogus leases and stop hosts from sending ARP replies that claim IPs/MACs they don’t own.

How they work together (steps)

1. Enable DHCP snooping globally and on VLANs — switch learns bindings from legitimate DHCP server traffic on trusted ports.
2. Mark uplink/trunk to DHCP server as trusted so DHCP OFFERs/ACKs pass.
3. Enable DAI on VLANs — switch drops ARP packets that don’t match the snooping DB; trusted ports (e.g., trunk to router) are exempt.

Example Cisco IOS commands

• Enable DHCP snooping for VLANs 10 and 20:

ip dhcp snooping
ip dhcp snooping vlan 10,20

• Mark trunk uplink ports trusted (example Gi0/1 and Gi0/2):

interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip dhcp snooping trust

interface GigabitEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 ip dhcp snooping trust

• Enable DAI to use the DHCP snooping binding DB for VLANs 10 and 20:

ip arp inspection vlan 10,20

Operational notes / best practices

• Configure rate-limiting on untrusted access ports (ip arp inspection limit rate) to mitigate floods.
• If using DHCP relay or multiple switches, consider configuring a central DHCP snooping database: ip dhcp snooping database + transfer.
• Verify with: show ip dhcp snooping binding and show ip arp inspection and monitor logs for dropped packets.

VLAN plan (small office — 50 users)

• VLAN 10 — Staff (Users)
  • Purpose: Desktop/laptops, printers
  • Subnet: 10.10.10.0/24
• VLAN 20 — Guests/Wi‑Fi
  • Purpose: Internet-only access, client devices
  • Subnet: 10.10.20.0/24
• VLAN 30 — Servers/Infrastructure
  • Purpose: App servers, file server, AD/DNS
  • Subnet: 10.10.30.0/24
• VLAN 40 — Management
  • Purpose: Network devices, IPMI, jump hosts
  • Subnet: 10.10.40.0/29 (small, limited hosts)

Security & operational rationale

• Separate broadcast domains to reduce noise and contain lateral movement.
• Guest VLAN isolated to Internet only, preventing access to internal resources.
• Management VLAN tightly limited (/29) and reachable only from admin jump host.
• Servers on their own VLAN to apply server‑specific policies and monitoring.

Immediate ACLs / Firewall recommendations

• Default deny between VLANs; allow explicit flows:
  • Staff → Servers: allow TCP 80/443, 445, 88/389 as needed
  • Servers → Staff: ephemeral responses only (stateful)
  • Guest → Internet: allow 80/443, DNS; deny 10.0.0.0/8
  • Management → All: allow SSH/HTTPS to devices; deny from others
• Block SMB/RDP from Guest/Staff → Server unless required.
• Enable stateful firewall on inter‑VLAN router and log denied attempts.
• Implement DHCP snooping, ARP inspection, and port security on access switches.

This plan is simple, scalable for growth (add VLANs/subnets), and enforces least privilege while keeping operations straightforward.

Situation & goal
I’d stabilize MAC learning in a dynamic VM/container environment by combining timer tuning, security features, sticky MACs, distributed switching, and orchestration so MAC-table churn is reduced without sacrificing mobility or security.

1) Aging timer tuning

• Reduce flapping by increasing MAC aging on access/leaf switches (e.g., from 300s → 900–1800s) so transient moves don’t flush entries.
• Trade-offs: longer timers delay stale eviction (blackholing when VM truly moved) and consume CAM table space — must monitor table utilization.

2) DHCP Snooping + Dynamic ARP Inspection (DAI)

• Enable DHCP snooping to build trusted bindings (IP-MAC-VLAN-Port). Turn on DAI to block spoofed ARP packets.
• Trade-offs: requires DHCP everywhere or reliable relay; binding table must be kept current during migrations — stale bindings can block legitimate traffic; CPU/feature cost on edge devices.

3) Sticky MACs (selective)

• Use sticky MACs on ports where VMs are pinned (bare-metal, long-lived VMs) but avoid for highly mobile workloads.
• Trade-offs: Improves security/consistency for static endpoints but prevents live migration unless orchestration updates config; operational complexity increases.

4) Distributed Virtual Switch (DVS) features

• Leverage DVS (vDS/NSX/VDS) and host-level learning so host switch tracks vNIC moves and updates hypervisor uplinks via control plane (vCenter/NSX controllers).
• Trade-offs: Requires virtualization vendor features and licensing; reduces reliance on physical CAM learning but adds dependency on controller high availability.

5) Orchestration integration

• Integrate the orchestrator (vCenter, Kubernetes CNI, OpenStack) to push network updates: update DHCP snooping bindings, program port-security or DVS metadata, and proactively clear/refresh MAC entries on target leaf switches during migrations.
• Trade-offs: Needs API work, RBAC, careful sequencing to avoid transient blackholes.

Overall approach

• Start with monitoring: measure MAC churn and CAM usage.
• Combine moderate aging increase + DHCP snooping/DAI + host-side DVS awareness.
• Apply sticky MACs only where appropriate and automate orchestration hooks to update network state during migrations.
• Continuously test migrations and tune to balance stability, security, and mobility.

High-level summary
A CAM/MAC table overflow (MAC flooding) attack floods a switch with frames that have many different (usually spoofed) source MAC addresses. The switch’s CAM table fills; when it can’t learn destination MACs, it treats unknown-unicast frames as unknown and floods them out all ports in the VLAN — producing unknown‑unicast flooding and exposing traffic to other hosts.

How it works (mechanism)

• Attacker generates a high rate of frames with unique source MACs.
• CAM table entries exceed capacity or eviction rate spikes; legitimate entries get aged out.
• For destinations not in table, switch floods packets to all ports (L2 broadcast-like behavior), enabling sniffing or man‑in‑the‑middle.

Detection

• Monitor CAM usage: show mac address-table count (Cisco) and SNMP OIDs (dot1dTpFdbTable).
• Watch for syslog: “mac address table full” or frequent MAC move/age warnings.
• Observe spikes in unknown-unicast traffic, high CPU on switches, large multicast/broadcast counters.
• Use sFlow/NetFlow/packet capture or SPAN to see many frames with varying source MACs.
• Check port statistics for many MACs per port: show port-security address; show mac address-table dynamic interface GiX/X.

Mitigation techniques

• Port‑security
  • Configure maximum MACs per port, violation action (shutdown/restrict/reset), and sticky MACs for trusted endpoints.
  • Example: switchport port-security maximum 2; switchport port-security violation restrict; switchport port-security mac-address sticky.
• DHCP Snooping
  • Enable per-VLAN DHCP snooping to build trusted DHCP bindings (IP-MAC-PORT-VLAN), preventing rogue DHCP servers and providing binding table for other protections.
  • Example: ip dhcp snooping vlan 10; ip dhcp snooping trust on uplink.
• Dynamic ARP Inspection (DAI)
  • Use DAI to validate ARP packets against DHCP snooping binding table, blocking ARP spoofing that can accompany MAC attacks.
  • Example: ip arp inspection vlan 10.
• Static MACs / MAC pinning
  • Configure static MAC entries for critical servers and trunk ports to ensure those entries are not aged out.
  • Use static entries sparingly for key infrastructure (gateways, firewall interfaces).
• Network design hardening
  • Use private VLANs, layer‑3 access (use routed access ports) to reduce L2 exposure.
  • Segment sensitive hosts into separate VLANs and reduce broadcast domains.
  • Enable BPDU guard, root guard, storm-control, and control-plane policing (CoPP) to protect switch resources.
• Monitoring & automation
  • Alert on rapid growth of MACs per port, frequent MAC flaps, or CAM usage thresholds via NMS.
  • Periodic audits, firmware updates, and testing of port-security policies.

Trade-offs / operational notes

• Port-security sticky/static MACs can increase management overhead in dynamic environments (DHCP, laptops).
• DHCP snooping + DAI require correct trust configuration (uplinks trusted; edge ports untrusted) or may block legitimate traffic.
• Static MACs protect but don’t scale; combine with monitoring and segmentation for layered defense.

This layered approach (port security, DHCP snooping, DAI, selective static MACs, and good L2/L3 design + monitoring) is recommended to detect, limit and recover from MAC flooding attacks while minimizing operational disruption.