8 hours ago8 hr Half the networks we inherit have VLANs that someone started and never finished. Usually I find out because the office manager calls to say the desk phones are dead again, or because I'm standing in a closet with a console cable after a trunk change cut me off. So this is how we plan VLANs now, what trunks and access ports actually do, and the config we use on Cisco IOS and on HP/Aruba ProCurve-style switches. Have these ready first A managed switch you can reach by console or SSH. Bring the console cable anyway, because you will lock yourself out at least once. The list of networks you need, like data, voice, guest, cameras, printers and management. A gateway on the router or firewall (SVI or subinterface) for each VLAN. Somewhere to write it all down, whether that's a spreadsheet, NetBox or your wiki. Write the table before you touch a switch Every VLAN gets an ID, a name, a subnet and a purpose. We keep the same scheme at every site we manage, so whoever walks into a building next already knows VLAN 20 is voice. Often that person is me, six months later. A simple plan looks like this. VLAN Name Subnet Gateway Purpose 10 DATA 10.10.10.0/24 10.10.10.1 Staff PCs 20 VOICE 10.10.20.0/24 10.10.20.1 Desk phones 30 GUEST 10.10.30.0/24 10.10.30.1 Guest Wi-Fi (internet only) 99 MGMT 10.10.99.0/24 10.10.99.1 Switch/AP/UPS management 999 BLACKHOLE (none) (none) Unused native VLAN on trunks Two rules I don't bend on. Management gets its own VLAN, never VLAN 1 and never the data VLAN. And VLAN 1 carries nothing. Using an unused VLAN as the native VLAN on trunks closes off VLAN-hopping tricks and keeps untagged junk from landing somewhere useful. Access ports, trunks and the native VLAN An access port belongs to one VLAN and sends frames untagged. That's what a PC or printer plugs into. A trunk carries many VLANs, with each frame tagged using 802.1Q. You use trunks switch to switch, switch to firewall, and usually switch to AP. The native VLAN is the one VLAN on a trunk that goes out untagged. Both ends have to agree on it. If they don't, traffic leaks between VLANs, and on Cisco you'll see native VLAN mismatch messages from CDP. An access port can also carry a tagged voice VLAN, so the phone and the PC plugged into the back of it share one cable. The phone learns which VLAN to use through LLDP-MED, CDP or DHCP options. Cisco calls these "access" and "trunk." HP/Aruba ProCurve doesn't use those words. Each port is untagged in one VLAN and tagged in any others. An HP port untagged in VLAN 10 and tagged in VLAN 20 is the same idea as a Cisco access port with a voice VLAN. The Cisco IOS side vlan 10 name DATA vlan 20 name VOICE vlan 99 name MGMT vlan 999 name BLACKHOLE ! interface range GigabitEthernet1/0/1 - 46 switchport mode access switchport access vlan 10 switchport voice vlan 20 spanning-tree portfast ! interface GigabitEthernet1/0/48 description UPLINK-TO-CORE switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 10,20,99 ! interface Vlan99 ip address 10.10.99.11 255.255.255.0 no shutdown ! ip default-gateway 10.10.99.1 On some older or multilayer platforms, switchport mode trunk won't be accepted until you add switchport trunk encapsulation dot1q first. Prune your trunks with allowed vlan instead of letting every VLAN go everywhere. This next part is where I see people trip most. When you add a VLAN to an existing trunk later, use switchport trunk allowed vlan add 30. Leave off the word add and you replace the whole list, which drops everything else on that trunk, including the management session you're typing into. Same thing on HP/Aruba vlan 10 name "DATA" untagged 1-46 tagged 48 exit vlan 20 name "VOICE" tagged 1-46,48 voice exit vlan 99 name "MGMT" tagged 48 ip address 10.10.99.12 255.255.255.0 exit ip default-gateway 10.10.99.1 Making a port untagged in VLAN 10 pulls it out of VLAN 1 automatically. The voice flag marks VLAN 20 so LLDP-MED advertises it to phones. On the uplink (port 48), the native VLAN is just whichever VLAN the port is untagged in. If the port is tagged-only for everything, there's no native VLAN at all. I prefer that when the other end allows it. Move management last Build the new management SVI and make sure you can reach it over the trunk before you remove the old management IP. On Cisco, run reload in 10 before anything risky. If you cut yourself off, the switch rolls back on its own and you're not driving out to the site. Once you're safely back in, cancel it with reload cancel. Then save with write memory, which works on both platforms. After that, write it down. Record the VLAN table, which ports are trunks and what's on the other end, the native VLAN on each trunk, and each switch's management IP. Port descriptions on uplinks cost nothing, and the next tech who inherits the site will save hours because of them. Checking your work ! Cisco show vlan brief show interfaces trunk show interfaces GigabitEthernet1/0/5 switchport show cdp neighbors detail ! HP/Aruba show vlans show vlans ports 48 detail show lldp info remote-device Each trunk should list the VLANs you expect as allowed and forwarding. Plug in a test PC and make sure it gets a DHCP address in the right subnet, then do the same with a phone and check that it pulls an address from the voice scope. The time the phones went dead We put a new switch in at an outlying building for one of our municipal clients. PCs were fine, but every desk phone sat at "network unavailable." The access ports had the voice VLAN set correctly, and the phones were even learning the VLAN ID over LLDP-MED. The problem was upstream. The voice VLAN had never been created on the new switch's uplink path, so the uplink wasn't carrying it tagged, and the phones were tagging their traffic into a VLAN that went nowhere. We fixed it by creating the VLAN, tagging it on the uplink, and confirming the upstream switch was tagging it toward us too. Now when phones fail and PCs work, I check the trunk allowed list on every hop between the phone and the call server before I look at anything else. Other things that have bitten us A native VLAN mismatch between two vendors quietly bridges two VLANs together. Make both ends match, or tag everything. Forgetting add on Cisco and overwriting the allowed list. For remote work, set reload in first. The VLAN exists but clients get no DHCP. Usually the firewall or router has no interface or DHCP relay for the new VLAN yet. APs on trunks. If the AP's management is on the native VLAN and you change the native VLAN, the AP drops off the controller. When something on one VLAN breaks and everything else works, I walk the trunks hop by hop. It's tedious, but it finds the problem faster than guessing.
Create an account or sign in to comment