CompTIA Network+ Switching: VLANs, 802.1Q Trunks, Spanning Tree, and MTU

What objective 2.2 asks you to configure on CompTIA Network+ N10-009

Objective 2.2 is one of the "given a scenario" objectives in Network Implementation (20% of CompTIA Network+ N10-009), so expect to choose or apply a switch setting, not just define it. Its items fall into four groups:

• VLANs: the VLAN database and the switch virtual interface (SVI).
• Interface settings: native VLAN, voice VLAN, 802.1Q tagging, link aggregation, speed, and duplex.
• Spanning tree.
• MTU and jumbo frames.

Spanning tree comes back in objective 5.3 as a troubleshooting topic (loops, root bridge selection, port roles and states), so the theory here supports that domain too. This page works every item on one original office. Commands are shown only as labeled vendor examples, because Network+ is vendor-neutral.

The office: two switches, three VLANs

A fictional dental practice has two switches. SW1 serves the front desk and treatment rooms. SW2 sits in the back office, connects to the router, and also routes between VLANs.

Both switches need VLANs 10, 20, 30, and 999 in their VLAN database. A VLAN that exists on only one switch cannot carry traffic across the trunk.

Access ports and the voice VLAN on a phone port

Most of SW1's ports are access ports: each carries exactly one VLAN, and the device on it never sees a VLAN tag. The guest kiosk ports are access ports in VLAN 30.

The treatment rooms are different. Each desk has an IP phone plugged into the wall port, and the PC plugs into the phone's built-in switch port. A voice VLAN handles this with one access port:

• The port's access (data) VLAN is 10, for the PC.
• The port's voice VLAN is 20, for the phone.
• The phone sends its traffic tagged for VLAN 20. The PC's traffic passes through the phone untagged and lands in VLAN 10.

Cisco's Catalyst 9600 voice VLAN guide (IOS XE 17.15) describes the same model. It says voice VLANs are configured only on access ports, not trunk ports, and that the switch can use CDP to tell the phone which VLAN to use for voice. On that platform, the voice VLAN is set with the switchport voice vlan interface command. Other vendors use different commands, and LLDP-MED can carry the same voice VLAN information for non-Cisco phones.

The free mixed set of 20 Network+ questions includes a desk-phone scenario like this one, with a company rule that user ports stay access ports. After the phone-port example, configure the desk-phone switch port in the free set's voice VLAN item → and see why a trunk and a single shared VLAN both fail the rule.

The 802.1Q trunk between SW1 and SW2

A trunk carries several VLANs over one link by adding an 802.1Q tag that names each frame's VLAN. Cisco's trunk configuration guide for Catalyst 9300 switches adds the details the exam likes:

• Frames in the trunk's native VLAN are sent untagged, and untagged frames that arrive are placed in the native VLAN.
• The native VLAN is VLAN 1 by default, and it should be the same on both ends. Cisco warns that a mismatch might cause spanning tree loops.
• All VLANs are allowed on a trunk by default, and trunks carry VLAN IDs 1 to 4094.

For the office trunk, the plan is:

1. Set the native VLAN to 999, an unused VLAN, on both SW1 and SW2.
2. Allow only VLANs 10, 20, 30, and 999 on the trunk.
3. Bundle two physical links into one logical link with link aggregation, so multiple flows can share their combined capacity and spanning tree sees one logical link. A single flow is normally assigned to one member and does not automatically get both links' bandwidth.

An explicit, unused native VLAN and a trimmed allowed list are basic trunk hygiene. They also close the gap that VLAN hopping attacks rely on, which the network attacks guide covers. Both ends of an aggregated link must agree on its settings, including speed, duplex, and VLANs, or the bundle will not form correctly.

SVIs as gateways. SW2 has one SVI per user VLAN, at 10.40.10.1, 10.40.20.1, and 10.40.30.1. Each SVI is a virtual Layer 3 interface for its VLAN, and hosts in that VLAN use it as their default gateway. A router with subinterfaces on a trunk can do the same job, as the routing guide shows.

Finding a device through the MAC address table

A switch learns the source MAC address of each frame and records the port and VLAN it arrived on. Suppose a printer with MAC address 00-00-5e-00-53-2c needs to be found. On SW2, the MAC address table shows that address learned on the aggregated link to SW1. That means the printer is not on SW2 at all: it sits somewhere behind SW1, so you read SW1's table next and find the access port.

The N10-009 objectives write the command as show mac-address-table. Spellings differ by platform: Cisco's Catalyst 9300 command reference (IOS XE 17.4) writes it as show mac address-table, with a space, and lists VLAN, MAC address, type, and port for each entry.

One troubleshooting item in the free set gives you a MAC address from a DHCP log and asks which device command finds the port. Once following a MAC across the trunk makes sense, match the switch command to the MAC address question →.

Spanning tree: why loops form and how the root is chosen

Now the practice adds SW3 on the second floor and cables it to both SW1 and SW2 for redundancy. The three links form a triangle, and that is a loop.

Why a loop is a problem. An Ethernet frame carries destination, source, and type fields (RFC 894 describes this framing) but no hop limit like IP's TTL. A broadcast sent into a loop is copied out of every port and circulates with nothing to stop it, and switches keep relearning the same MAC addresses on different ports. Spanning tree prevents this by putting redundant ports into a blocking state and reactivating them if an active path fails.

Electing the root bridge. Each switch has a bridge ID made of a priority and its MAC address. The lowest bridge ID wins: lowest priority first, then lowest MAC address as the tie-breaker. Cisco's Catalyst 9300 STP guide gives the default priority as 32768. The MAC addresses below come from the range RFC 7042 reserves for documentation.

SW2 becomes the root, because 24576 is lower than 32768, even though SW3 has the lowest MAC address. If all three kept the default 32768, SW3 would win on MAC address. Cisco's guide also notes that each VLAN has its own bridge ID, with the VLAN ID added in as an extended system ID, so on that platform SW2's VLAN 10 bridge priority shows as 24576 + 10 = 24586.

Port roles, assuming every link has the same speed:

• SW1 and SW3 each make their direct link to SW2 their root port, the best path to the root.
• On the SW1 to SW3 link, both switches are one hop from the root at equal cost, so the lower sender bridge ID wins the designated port. SW3's ID (32768, ...53-03) is lower than SW1's (32768, ...53-0a), so SW3's end is designated.
• SW1's end of that link becomes an alternate port and blocks. The loop is broken, and the link stays ready if SW1 loses its path to SW2.

Classic 802.1D STP uses blocking, listening, learning, forwarding, and disabled states. Rapid STP uses discarding, learning, and forwarding states, and names an alternate port role. Keep the protocol's states separate from its port roles.

MTU, jumbo frames, speed, and duplex: settings both ends must share

MTU. RFC 894 sets the maximum data field of a standard Ethernet frame at 1500 octets. Jumbo frames carry more than that and are enabled per device, often for storage traffic. Every device on the path has to accept the larger size. A port that receives a frame bigger than it accepts can drop it, which is one reason the giants counter appears in objective 5.2. Change MTU on both ends of a link and on every switch in between, or not at all.

Speed and duplex. Cisco's NIC compatibility note says a duplex mismatch causes very slow performance, intermittent connectivity, and loss of connection, and it lists rising FCS, CRC, alignment, runt, and late-collision counters as signs. It calls autonegotiation on both ends a valid practice, and it warns that hard-coding full duplex on only one side produces a mismatch. So either let both ends negotiate, or set both ends to the same speed and duplex. Reading those counters is covered in the cable and interface troubleshooting guide, and the layer each setting belongs to is mapped in the OSI model guide.