Question 1

How would you segment this network without buying new hardware or changing IP subnets?

Accepted Answer

I would implement VLANs on the existing L2 switch to create three broadcast domains: VLAN 10 for Sales, VLAN 20 for Warehouse, and VLAN 30 for Management. Since the current setup is a single /24, I would subnet it into /26s or use the same /24 with inter-VLAN routing on a router-on-a-stick configuration. The key is isolating the warehouse broadcast traffic so it never reaches the Sales VLAN where the VoIP phones live. I would also verify that the switch supports 802.1Q trunking to the router.

Question 2

What are the first three things you check, and in what order?

Accepted Answer

First, I check the trunk link between the switch and the router — `show interfaces trunk` — to confirm the router-facing port is trunking and all three VLANs are allowed. Second, I verify the router subinterfaces with `show ip interface brief` and confirm each subinterface has the correct encapsulation dot1Q VLAN tag and IP address serving as the default gateway for that VLAN. Third, I check the switchport mode on the PC-facing ports with `show vlan brief` and `show interfaces switchport` to ensure the access ports are assigned to the correct VLANs. Nine times out of ten, it is either a missing `switchport mode access` command or a native VLAN mismatch on the trunk.

Question 3

What OSPF feature prevents this, and how would you configure it?

Accepted Answer

This is a classic case where OSPF needs an IP event dampening or, more commonly, an OSPF stub link advertisement without a stable LAN interface. The correct production fix is to use the OSPF `ip ospf cost` or, better, to enable OSPF Conditional Advertisement or simply ensure the LAN interface is up before OSPF forms adjacencies. However, the simplest and most widely implemented fix is to use the `passive-interface` command on the LAN-facing interfaces so OSPF does not form adjacencies there, while redistributing the connected route only when the interface is actually up. In real networks, many engineers also use IP SLA tracking with EEM scripts to withdraw routes when next-hop fails.

Question 4

What type of NAT are they likely using, and what is the fix?

Accepted Answer

They are almost certainly using static NAT or a PAT overload pool that is too small. With 200 hosts behind a single public IP using PAT (Port Address Translation), the available source ports per protocol are limited to roughly 64,000. During peak hours, ephemeral ports get exhausted, causing new connections to fail. The fix is to expand the PAT pool to multiple public IPs using an ACL-based NAT pool, or to implement dynamic NAT with a larger pool of public addresses. On Cisco IOS, this means changing from `overload` on a single IP to a `ip nat pool` with 4–8 public IPs and applying `overload` across the pool. I would also check `show ip nat translations` to confirm port exhaustion.

Question 5

Explain why the web traffic broke, and rewrite the ACL correctly.

Accepted Answer

The administrator likely wrote a standard or extended ACL that denied TCP port 23 but forgot that extended ACLs are processed top-to-bottom and end with an implicit `deny ip any any`. If they placed `deny tcp any any eq 23` without a subsequent `permit ip any any`, all traffic including HTTP/HTTPS return traffic was dropped. Additionally, if they applied it inbound on the server interface, return traffic from the web server back to clients was blocked because the source is the server and the destination is the client. The correct approach is to apply the ACL outbound on the interface facing the untrusted network, or inbound on the interface where the Telnet traffic enters. The ACL should be: `permit tcp any any established` first (for return traffic), then `deny tcp any any eq 23`, then `permit ip any any`.

Question 6

What are the two most likely physical and logical causes, and how do you verify each?

Accepted Answer

Physically, the most likely cause is a fiber mismatch — either single-mode vs. multimode fiber, or a Tx/Rx cross-connect (straight-through instead of crossover). I verify this with `show interfaces transceiver` and by checking the SFP wavelength and fiber type. Logically, even with the link up, the trunk may have a native VLAN mismatch. If Switch A sends untagged traffic on VLAN 1 and Switch B expects native VLAN 99, the trunk comes up but control traffic like CDP/VTP and untagged user traffic is dropped. I verify with `show interfaces trunk` on both sides and look for the native VLAN mismatch error message. A third possibility is DTP mismatch if one side is `dynamic auto` and the other is `access`, but since the link shows up/up as a trunk, native VLAN is the primary suspect.

Question 7

What STP flavor should you use, and what specific feature eliminates the 30–50 second freeze?

Accepted Answer

The network is likely running legacy 802.1D STP, which has a forward delay of 15 seconds and requires listening + learning states before forwarding — roughly 30–50 seconds per topology change. I would migrate to Rapid PVST+ (Per-VLAN Rapid Spanning Tree) or MSTP if there are many VLANs. The specific feature that eliminates the freeze is the **Proposal/Agreement mechanism** in RSTP, which allows ports to transition to forwarding immediately on point-to-point links without waiting for forward delay timers. I would also enable `spanning-tree portfast` on all access ports connecting to end devices so direct link flaps do not trigger unnecessary TCNs (Topology Change Notifications). For the video call issue specifically, enabling QoS alongside RSTP ensures that even during convergence, voice/video traffic is prioritized.

Question 8

What are three reasons the DHCP discover packets still never reach the server?

Accepted Answer

First, the `ip helper-address` is configured on the wrong interface — it must be on the ingress interface where the DHCP Discover arrives (the LAN facing the clients), not the WAN interface. Second, the router ACL is blocking UDP ports 67 and 68. Many security-hardened routers have implicit ACLs that drop BOOTP/DHCP relay traffic. Third, the DHCP server itself has a subnet declaration mismatch or the server is not authoritative for the remote subnet. I would verify with `debug ip dhcp server events` and `debug ip udp` on the router, plus `show ip interface` to confirm the helper-address placement. A fourth common cause is a firewall between the branch and HQ dropping the forwarded broadcast as it becomes a unicast packet toward the DHCP server.

Question 9

What happened, and how do you fix it while still maintaining port security?

Accepted Answer

Port security was likely configured with `switchport port-security maximum 1` and `switchport port-security violation shutdown`. When the first executive unplugged and a second executive plugged in, the MAC address changed, triggering a security violation and err-disabling the port. To fix it while maintaining security, I would either increase the maximum MAC addresses to a reasonable number (e.g., 5 for a conference room) using `switchport port-security maximum 5`, or configure `violation restrict` instead of `shutdown` so the port stays up but unauthorized MACs are dropped and logged. For executive conference rooms, the best practice is `violation restrict` plus SNMP traps to the NOC so security events are monitored without causing an outage. I would also consider `sticky` MAC learning so approved devices are remembered across reboots.

Question 10

What is the most likely missing piece, and how does IPv6 neighbor discovery differ from IPv4 ARP in this context?

Accepted Answer

The router interface likely does not have a global unicast address configured, or the PCs do not have a default gateway configured with the router's link-local address. In IPv6, Neighbor Discovery Protocol (NDP) replaces ARP, using ICMPv6 Type 135/136 (Neighbor Solicitation/Advertisement) to resolve Layer 3 to Layer 2 addresses. However, NDP operates on link-local scope for on-segment communication. For off-segment traffic, the PC needs a default gateway, and in IPv6 that gateway is typically the router's link-local address (fe80::) advertised via Router Advertisements (RA). If RA is disabled (`ipv6 nd ra suppress`) or the router has no global address on the interface, the PCs will not auto-configure a gateway. The fix is to ensure the router interface has both a link-local and global unicast address, and that RAs are not suppressed. I would verify with `show ipv6 interface` and `debug ipv6 nd`.

Question 11

What Wi-Fi standard or feature reduces this handoff delay, and what wired network feature should be verified alongside it?

Accepted Answer

The issue is Layer 2 roaming delay. The solution is **802.11r (Fast BSS Transition)** which allows the client to pre-authenticate with the next AP before roaming, reducing handoff time from seconds to milliseconds. However, 802.11r alone is not enough — the wired infrastructure must also support **802.11k (Neighbor Reports)** and **802.11v (BSS Transition Management)** for the AP to guide the client to the best next AP. On the wired side, I must verify that all APs are on the same VLAN or that the controller supports Layer 3 roaming with GRE tunneling. Most importantly, the switchports connecting the APs must be trunk ports carrying the voice VLAN so the phone maintains its VLAN membership across APs. If the voice VLAN is missing on one AP's trunk, the phone gets a data VLAN IP and drops the call.

Question 12

What HSRP timer misconfiguration causes this, and what is the correct timer relationship?

Accepted Answer

The issue is a timer mismatch where the hold time expired before the standby router could take over, or more commonly, the active router has a very long hold time and the standby does not detect the failure quickly. In HSRP, the default hello time is 3 seconds and the default hold time is 10 seconds. If the active router's hold time was accidentally set lower than the standby's hello time, or if the timers were mismatched across routers, the standby may not declare itself active promptly. The correct relationship is: **hold time = 3 × hello time** (minimum). For faster convergence in production, I use `standby 1 timers 1 3` (1-second hello, 3-second hold). I would also verify preemption is enabled so the original active router reclaims its role after reboot: `standby 1 preempt`. Without preemption, the standby stays active indefinitely, which causes asymmetric routing and confusion during future troubleshooting.

Question 13

What attack is this, and what Layer 4 and Layer 7 mitigations would you deploy on a Cisco ASA or router?

Accepted Answer

This is a **SYN flood attack**, a classic Denial of Service (DoS) attack. At Layer 4, I would enable TCP Intercept on a Cisco router, which proxies the TCP three-way handshake and only forwards completed connections to the server. The command is `ip tcp intercept list ACL_NAME` with `ip tcp intercept mode intercept`. On an ASA firewall, I would enable **TCP Normalization** and **Threat Detection** to rate-limit SYNs per source IP. At Layer 7, I would deploy a Web Application Firewall (WAF) rule to drop connections without valid HTTP headers, and implement connection limits on the server itself (e.g., `ip inspect` with maximum embryonic connections). For long-term resilience, I would also work with the ISP to implement upstream DDoS scrubbing and ensure the server has SYN cookies enabled at the OS level.

Question 14

What changes are needed on the router for the new /29, and how do you minimize downtime during the cutover?

Accepted Answer

First, I would configure the new WAN interface with an IP from the /29 and set the ISP's gateway as the next hop. Since we now have multiple public IPs, I would migrate from static one-to-one NAT to a **NAT pool** or use individual static NAT entries for specific internal services. For example, `ip nat inside source static 192.168.1.10 203.0.113.2` for the web server, and `ip nat inside source static 192.168.1.11 203.0.113.3` for the mail server. To minimize downtime, I would pre-stage the new interface configuration in a notepad, then during the maintenance window, apply it using `configure replace` or paste the config quickly. I would also keep the old /30 interface administratively down but configured as a fallback. Before going live, I verify NAT translations with `show ip nat translations` and test reachability with extended pings sourced from the new interface. Finally, I update the ISP-facing ACLs to permit traffic to the new /29 range.

Question 15

What are the three most common causes of high CPU on a Layer 3 switch, and how do you isolate each?

Accepted Answer

First, **broadcast storms or Layer 2 loops** can cause the switch to process-switch thousands of frames, spiking CPU. I check with `show processes cpu` and `show interfaces counters` to identify the interface with excessive input rate, then use `show spanning-tree` to verify no loops or TCN floods. Second, **IP routing process overload** from suboptimal routing or excessive route recalculations. I verify with `show processes cpu | include IP Input` and `show ip route summary`. If there are thousands of host routes from a flapping WAN link, I would use route summarization or adjust routing protocol timers. Third, **control plane policing (CoPP) misconfiguration** or excessive ARP traffic. In networks with large /23 or /22 subnets, ARP requests can overwhelm the CPU. I check `show arp statistics` and consider enabling `ip arp inspection` or reducing the ARP cache timeout. In all cases, I would enable `debug platform packet all` cautiously and check for traffic destined to the switch itself (control plane) versus transit traffic that should be hardware-switched.