VLAN Leak, DHCP Instability, and Server ACL in an Enterprise Campus
A BSNL enterprise customer has a campus with three VLANs: VLAN 10 for users on 192.168.10.0/24, VLAN 20 for servers on 192.168.20.0/24, and VLAN 30 for management on 192.168.30.0/24. Inter-VLAN routing is done on a router-on-a-stick with 802.1Q subinterfaces. A DHCP server on VLAN 20 serves all three VLANs; the router has ip helper-address configured on each user and management subinterface. After a new access switch was added, VLAN 10 users intermittently receive 192.168.20.x addresses or APIPA, while wired users on the original switch work. VLAN 20 can ping VLAN 10 but cannot reach VLAN 30. The new switch trunk is configured with switchport trunk allowed vlan 10,20 and native VLAN 1; the distribution switch trunk uses native VLAN 99. The JTO must restore stable addressing and then tighten server access so VLAN 10 can reach only TCP 443 on the server subnet, while VLAN 30 retains full management access.
1. Identify the likely causes of the intermittent DHCP behaviour and the VLAN 20-to-VLAN 30 failure. List the verification commands and the configuration changes you would make.
Read the worked answer
Two separate trunk problems are visible. First, the new trunk allows only VLAN 10 and 20, so VLAN 30 is not carried; that explains why VLAN 20 cannot reach VLAN 30. Second, the native VLAN mismatch (1 on the new switch, 99 on the distribution switch) causes untagged traffic and control-plane inconsistencies, and can contribute to intermittent forwarding and address leaks.
The 192.168.20.x addresses on VLAN 10 suggest a Layer 2 leak or a rogue/incorrect DHCP path, not just a trunk failure. Check whether an access port on the new switch is wrongly assigned to VLAN 20, whether a rogue DHCP server exists, and whether the VLAN 10 helper address points to the correct DHCP server address.
Verification: show interfaces trunk on both ends, show vlan brief, show interfaces switchport, show ip interface brief, show running-config interface, and show ip dhcp snooping binding if available. Capture DHCP traffic on VLAN 10 if needed.
Fixes: set the native VLAN consistently to 99 on both trunk ends; allow VLANs 10,20,30 on the trunk; correct any access-port VLAN assignment; confirm the VLAN 10 and VLAN 30 helper addresses; enable DHCP snooping with the uplink and legitimate server port trusted. Then test DHCP renewal from a VLAN 10 client.
2. Write an access control list and interface placement that permits VLAN 10 to reach only TCP 443 on the server subnet, blocks other VLAN 10-to-server traffic, and preserves full VLAN 30 management access. Explain why the ACL is placed where it is.
Read the worked answer
Apply an extended ACL inbound on the VLAN 10 router subinterface so traffic is filtered before it is routed to the server subnet.
access-list 110 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443 access-list 110 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 access-list 110 permit ip any any
interface GigabitEthernet0/0.10 ip access-group 110 in
This permits only TCP 443 from VLAN 10 to VLAN 20 and denies all other VLAN 10-to-server traffic, while allowing VLAN 10 to reach other networks such as the Internet. The implicit deny at the end is avoided by the explicit permit ip any any.
For VLAN 30, do not apply this ACL to the VLAN 30 subinterface, or add a separate permit for VLAN 30 before any deny. Verify with a VLAN 10 client that HTTPS works and SSH/ICMP to the server subnet fails, and with a VLAN 30 client that management access still works. Because the ACL is inbound on VLAN 10, return traffic from the server is not blocked by this ACL. If the server subnet also needs protection from other sources, use a stateful firewall or a separate ACL on the VLAN 20 inbound direction.