Exam Objective 2.2: Configure Layer 2 switch port attributes for edge-host connectivity (VLAN, PoE, port channel, and LACP).
2.2.a Desktop, printer, and IOT appliances
2.2.b Wireless access points (standalone and controller based)
2.2.c Voice over IP phone
2.2.d Virtualized hosts
2.2.e Network appliances
Objective 2.1 covered how switches connect to each other. This objective covers the other side of the network — how switches connect to the actual end devices that make up the edge of the network. Different device types have very different requirements: a desktop just needs a single VLAN, a VoIP phone needs both a voice and data VLAN on the same port plus power, a wireless AP might need a trunk instead of an access port, and a virtualized host might need multiple VLANs presented to multiple virtual machines through one physical uplink. This objective tests whether you can match the right switchport configuration to the right device type.
An access port belongs to exactly one VLAN (with one important voice VLAN exception covered below) and is the standard configuration for any end device that has no awareness of VLAN tagging at all — the device sends and receives plain untagged Ethernet frames, and the switch handles all VLAN tagging/untagging internally.
Basic configuration:
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
switchport nonegotiate
switchport nonegotiate — disables DTP (Dynamic Trunking Protocol) negotiation on the port, a security best practice on any edge-facing port, since DTP negotiation is unnecessary for a port that should always remain an access port and disabling it removes a potential VLAN-hopping attack vector.
These represent the simplest edge-host case — a single device needing a single VLAN, no special power requirements beyond standard low-voltage device power (typically supplied externally, not via PoE), and no trunking.
Standard configuration:
interface GigabitEthernet0/2
switchport mode access
switchport access vlan 20
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree portfast — bypasses the normal STP listening/learning delay on an access port, allowing the port to move directly to the forwarding state as soon as link comes up, rather than waiting through STP's default 30-second progression. This is appropriate only on ports connected to a single end host that will never itself introduce a Layer 2 loop.
spanning-tree bpduguard enable — protects a PortFast-enabled port by immediately error-disabling it if a BPDU (Bridge Protocol Data Unit) is ever received on that port, since a legitimate end host should never be sending BPDUs. This guards against someone accidentally (or maliciously) plugging a switch or hub into what should be a simple end-host port, which could otherwise introduce a Layer 2 loop.
IoT appliance considerations: IoT devices (badge readers, environmental sensors, smart building equipment, security cameras that aren't part of a dedicated VoIP-style deployment) are typically treated identically to a standard desktop from a switchport-configuration perspective — a single access VLAN, PortFast, and BPDU Guard — though many organizations place IoT devices into a dedicated, more restrictively firewalled VLAN separate from user desktops for security segmentation purposes.
Printers — configured the same as a desktop, single access VLAN; printers are also common candidates for static IP assignment or DHCP reservations, and occasionally for PoE if the specific printer model supports and requires it, though most printers use standard AC power.
A VoIP phone deployment is one of the most commonly tested access-port scenarios because it requires two VLANs on a single physical port — a distinct pattern from every other basic edge-host case.
The topology: A Cisco IP phone typically has a built-in 2-port switch — one port connects up to the wall/wiring closet switch, and the second port allows a PC to be daisy-chained through the phone, sharing the single cable run to the wall. The switchport must therefore support two separate VLANs simultaneously on the same physical link: a voice VLAN for the phone's own VoIP traffic, and the (regular) access VLAN for the PC plugged into the back of the phone.
Configuration:
interface GigabitEthernet0/3
switchport mode access
switchport access vlan 20
switchport voice vlan 100
spanning-tree portfast
spanning-tree bpduguard enable
switchport voice vlan [number] — designates a separate voice VLAN on an otherwise standard access port. The switch tags voice traffic from the phone with an 802.1Q tag for the voice VLAN, while the PC's data traffic (passed through the phone) remains untagged and uses the regular access VLAN — meaning this port behaves almost like a limited trunk (carrying two VLANs) even though it's still configured in access mode.
Why voice and data are separated onto different VLANs:
QoS (Quality of Service) — voice traffic is extremely sensitive to latency, jitter, and packet loss, and needs to be identified and prioritized separately from ordinary data traffic; a separate VLAN makes this classification straightforward
Security/segmentation — keeping voice traffic on its own VLAN limits exposure if the data VLAN is compromised, and vice versa
Simplified addressing — the phone and PC can be managed and addressed as clearly distinct populations of devices
Power over Ethernet (PoE) for VoIP phones: IP phones nearly always require PoE, since running separate electrical outlets to every desk phone location is impractical. PoE is covered in more detail in section 6 below.
Exam Alert: Know the switchport voice vlan command by name and understand that it coexists with switchport access vlan on the same interface — this is the single most distinctive configuration pattern tested under this objective, since every other device type uses only a single VLAN.
The correct switchport configuration for an access point depends heavily on whether it's a standalone (autonomous) AP or a controller-based (lightweight) AP, and on how many wireless SSIDs/VLANs it needs to support.
Standalone (autonomous) AP, single SSID/VLAN:
Behaves like any other simple edge host if it's only ever going to broadcast one SSID mapped to one VLAN
Configured as a standard access port, similar to the desktop configuration above
interface GigabitEthernet0/4
switchport mode access
switchport access vlan 30
spanning-tree portfast
spanning-tree bpduguard enable
Standalone AP, multiple SSIDs mapped to multiple VLANs:
Requires a trunk port instead, since the AP itself needs to tag traffic from each SSID into its corresponding VLAN before sending it to the switch
The AP handles the 802.1Q tagging for each SSID internally, exactly the way a switch would for a trunk connection to another switch
interface GigabitEthernet0/5
switchport mode trunk
switchport trunk native vlan 30
switchport trunk allowed vlan 30,40,50
Controller-based (lightweight) AP: In a controller-based (WLC-managed) deployment, the AP itself typically only needs a single access VLAN for its own management traffic back to the Wireless LAN Controller (WLC), since client traffic from multiple SSIDs is commonly tunneled back to the WLC using CAPWAP (Control And Provisioning of Wireless Access Points) rather than being locally tagged and switched at the AP itself.
interface GigabitEthernet0/6
switchport mode access
switchport access vlan 30
spanning-tree portfast
Exam Alert: Know the distinguishing factor: a standalone AP broadcasting multiple SSIDs onto multiple VLANs needs a trunk port, while a controller-based (lightweight) AP typically only needs a simple access port, since CAPWAP tunneling to the WLC handles carrying multiple SSIDs' traffic instead of relying on local 802.1Q trunking at the switchport.
PoE for access points: Nearly all modern enterprise APs are powered via PoE rather than a local power adapter, since APs are frequently mounted in ceilings or other locations where running dedicated electrical wiring is impractical.
A virtualized host (a physical server running a hypervisor with multiple VMs) frequently needs to present multiple VLANs to the switch through a single (or bundled) physical uplink, since different VMs on that host may need to belong to different VLANs — for example, a web-tier VM on one VLAN and a database-tier VM on a separate, more restricted VLAN, both running on the same physical server.
Why virtualized hosts typically need a trunk port: Since the hypervisor's internal virtual switch (vSwitch, covered in objective 1.2) handles distributing traffic to the correct VM based on VLAN tag, the physical uplink from the server to the physical switch needs to carry multiple tagged VLANs — making a trunk port the standard configuration rather than a simple access port.
interface GigabitEthernet0/7
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport nonegotiate
Link aggregation on virtualized hosts: Physical servers hosting many VMs often generate enough aggregate traffic, and have enough redundancy requirements, to justify bundling multiple physical NICs into an EtherChannel (LACP) rather than relying on a single physical uplink — combining the trunk configuration above with the port-channel/LACP configuration from objective 2.1.
interface range GigabitEthernet0/7 - 8
channel-group 3 mode active
interface Port-channel3
switchport mode trunk
switchport trunk allowed vlan 10,20,30
Exam Alert: The key pattern to recognize: a virtualized host commonly requires a trunk (to carry multiple VLANs for multiple VMs) and is a strong candidate for EtherChannel/LACP (for bandwidth and NIC-level redundancy) — a combination not typically needed for a simple single-purpose desktop or printer.
"Network appliances" in this context refers to purpose-built physical devices such as firewalls, load balancers, IDS/IPS sensors, and WAN optimization appliances connecting into the switched network — distinct from a general-purpose server. Their switchport requirements vary more than any other category on this list, depending entirely on the specific appliance's role.
Single-interface appliance on one VLAN: Behaves like a simple access port, identical to a desktop, if the appliance only needs Layer 2 connectivity to a single VLAN/subnet.
Appliance requiring multiple VLANs (e.g., a firewall with sub-interfaces for several security zones over one physical link): Requires a trunk port, since the appliance itself will tag traffic per VLAN/zone on its own single physical interface, similar in concept to router-on-a-stick.
interface GigabitEthernet0/8
switchport mode trunk
switchport trunk allowed vlan 10,50,60
High-availability appliance pairs: Some network appliances are deployed in active/standby or active/active HA pairs and may require specific switchport configuration to support a heartbeat/sync link between the two appliance units, in addition to their normal data-carrying interfaces — this heartbeat link is often configured simply as a dedicated access port on its own VLAN.
Exam Alert: There's no single fixed pattern for "network appliances" the way there is for VoIP phones (voice VLAN) — the correct configuration always depends on how many VLANs/zones the specific appliance needs, so read the scenario carefully rather than assuming a fixed answer for this device category.
PoE delivers electrical power to a connected device over the same Ethernet cable used for data, eliminating the need for a separate power adapter/outlet at the device location. This is directly relevant to VoIP phones, wireless access points, and some IoT/network appliance devices.
PoE standards:
802.3af (PoE) — up to approximately 15.4 watts supplied at the switch port (about 12.95 watts guaranteed delivered at the device after cable loss)
802.3at (PoE+) — up to approximately 30 watts supplied at the switch port (about 25.5 watts delivered at the device), sufficient for most modern APs and higher-power devices
802.3bt (PoE++/UPOE) — up to roughly 60–100 watts depending on the specific type/class, intended for very high-power devices such as advanced APs, PTZ cameras, or even certain laptops/monitors
Relevant verification and configuration commands:
show power inline — displays PoE status per interface, including whether a device is detected, how much power is currently being consumed, and the administrative/operational power state
power inline auto — the default setting on most PoE-capable ports, allowing the switch to automatically detect and power a connected PoE device as needed
power inline never — explicitly disables PoE on a port, useful for a port that should never supply power (for example, a port connecting to another switch, where accidentally applying PoE could be problematic)
Common PoE problems:
Insufficient power budget — the switch's total PoE power budget (a fixed wattage shared across all PoE ports on the switch) can be exceeded if too many high-power devices are connected, preventing additional devices from powering up even though the ports themselves are otherwise correctly configured
Device requires a higher PoE standard than the switch port supports — for example, plugging a PoE++ device into a port that only supports standard 802.3af, resulting in the device either not powering on at all or operating in a reduced-power/reduced-functionality mode
Non-PoE-rated cable or a cable run exceeding standard distance limits, degrading power delivery even if data still passes
Exam Alert: Know the general power tiers by name (802.3af/PoE, 802.3at/PoE+, 802.3bt/PoE++/UPOE) and recognize that exceeding a switch's total PoE power budget is a distinct failure mode from an individual port's power capability being insufficient for a specific device.
Determine whether the device needs a single VLAN (access port) or multiple VLANs (trunk port) — desktops, printers, and most IoT devices need access; VoIP phones need access plus a voice VLAN; virtualized hosts and multi-SSID standalone APs typically need trunk; controller-based APs typically need access.
For access ports connecting a single end host, apply spanning-tree portfast and spanning-tree bpduguard enable to speed up convergence and protect against accidental loops.
For VoIP phones, configure both switchport access vlan (for the daisy-chained PC) and switchport voice vlan (for the phone itself) on the same interface.
For trunk ports (multi-SSID APs, virtualized hosts, multi-zone appliances), explicitly restrict switchport trunk allowed vlan to only the VLANs actually needed, and disable DTP negotiation with switchport nonegotiate.
If the device requires PoE (VoIP phone, most APs, some appliances/cameras), confirm the switch port and switch-wide power budget can support the device's power class, and verify with show power inline if a device fails to power up.
If the device benefits from bandwidth/redundancy (typically virtualized hosts, sometimes network appliances), consider bundling multiple physical uplinks into an LACP EtherChannel per objective 2.1's configuration pattern.
Q1. Which command is used to configure a separate voice VLAN on an access port that also carries regular data traffic from a PC connected through an IP phone?
A. switchport trunk native vlan
B. switchport voice vlan
C. switchport access vlan
D. switchport mode dynamic desirable
Answer: B. switchport voice vlan designates a distinct voice VLAN on an otherwise standard access port, allowing the switch to tag the IP phone's voice traffic separately from the untagged data traffic passed through from a PC plugged into the phone's second port, all on the same physical interface.
Q2. A standalone (autonomous) access point needs to broadcast three separate SSIDs, each mapped to a different VLAN. What switchport configuration is required on the switch port connecting to this AP?
A. A simple access port with switchport access vlan set to the first SSID's VLAN
B. A trunk port allowing all three VLANs, since the AP will tag each SSID's traffic itself
C. Three separate physical switchports, one per SSID
D. A voice VLAN configuration identical to a VoIP phone
Answer: B. When a standalone AP handles multiple SSIDs each mapped to a different VLAN, it tags traffic from each SSID with the appropriate 802.1Q tag itself, similar to how a switch trunk operates. The switchport connecting to this AP must therefore be configured as a trunk allowing all the relevant VLANs, rather than a simple single-VLAN access port.
Q3. Why does a controller-based (lightweight) access point typically only require a simple access port rather than a trunk, even when it broadcasts multiple SSIDs?
A. Lightweight APs cannot support more than one SSID
B. Client traffic from multiple SSIDs is commonly tunneled to the Wireless LAN Controller via CAPWAP, rather than being locally tagged at the AP
C. Lightweight APs do not require IP connectivity
D. Trunk ports are never supported on Cisco switches
Answer: B. In a controller-based deployment, the AP typically forwards client traffic from all its SSIDs to the WLC using a CAPWAP tunnel, rather than locally applying 802.1Q tags per SSID the way a standalone AP does. Because of this, the AP itself usually only needs a single access VLAN for its own management connectivity to the switch.
Q4. What is the primary reason a physical server running a hypervisor with multiple VMs typically requires a trunk port on its uplink to the switch, rather than an access port?
A. Hypervisor traffic cannot use PoE
B. Different VMs on the server may belong to different VLANs, and the vSwitch needs the physical uplink to carry multiple tagged VLANs
C. Virtualized hosts always require a voice VLAN
D. Trunk ports are required for spanning-tree bpduguard to function
Answer: B. Since a hypervisor's internal virtual switch can distribute traffic to different VMs based on VLAN, and those VMs may belong to different VLANs, the physical NIC/uplink connecting the server to the switch needs to carry multiple tagged VLANs simultaneously — which requires a trunk port rather than a single-VLAN access port.
Q5. A newly installed wireless access point is not powering on, even though the switch port shows as up/up and correctly configured for data connectivity. What should be checked first?
A. Whether spanning-tree bpduguard is enabled
B. Whether the switch port and the switch's overall PoE power budget can supply sufficient power for the AP's power class
C. Whether the voice VLAN is configured correctly
D. Whether LACP mode is set to active
Answer: B. Since the port is up/up for data, the connectivity/VLAN configuration is not the problem. A device that isn't powering on over PoE points to a power-related issue — either the port's individual power capability is insufficient for the AP's power class, or the switch's total shared PoE power budget has been exceeded by other connected devices, which can be checked with show power inline.
Q6. Which of the following commands, when applied to an access port connecting a single desktop PC, helps protect against an accidental Layer 2 loop if someone plugs a switch or hub into that port instead?
A. switchport voice vlan
B. spanning-tree bpduguard enable
C. switchport trunk allowed vlan
D. power inline never
Answer: B. spanning-tree bpduguard enable, used alongside spanning-tree portfast on an end-host access port, immediately error-disables the port if a BPDU is ever received on it. Since a legitimate single end host should never send BPDUs, this protects against someone unexpectedly introducing a switch, hub, or other loop-capable device into what should be a simple single-host port.