Hands-On Lab: Power over Ethernet (PoE) Basics

This hands-on lab covers verifying PoE capability on a switch port, checking how much power is being drawn by a connected device such as an IP phone or access point, and configuring power priority to protect critical devices during a power budget shortage.

Power over EthernetPoE VerificationPower Priority Configuration

~3 min read · Updated Sep 12, 2026

Lab Objective

Verify PoE status and power consumption on a switch port connected to a powered device, and configure power priority so a critical device is protected if the switch's total power budget is exceeded.

Lab Purpose

PoE eliminates the need for separate electrical wiring to devices like IP phones, wireless access points, and security cameras, but every switch has a finite total power budget shared across all its ports. Engineers must know how to verify actual power draw and how to prioritize critical devices when that budget is tight.

Lab Topology

Switch1 ---- Gi1/0/1 ---- IP Phone
Switch1 ---- Gi1/0/2 ---- Wireless Access Point

Both devices are PoE-powered by Switch1

Task 1: Verify PoE Is Enabled on the Switch Ports

Confirm PoE is active (the default) on both Gi1/0/1 and Gi1/0/2.

Task 2: Check Power Consumption Per Port

Display how much power each connected device is actually drawing.

Task 3: Check Total Switch Power Budget

Display the switch's total available and currently used power budget.

Task 4: Configure Power Priority

Configure the IP phone's port with a higher power priority than the access point's port, so the phone remains powered first if the total budget becomes insufficient.

Task 5: Simulate a Power Shortage Response

Explain what happens if a newly connected high-power device would exceed the switch's remaining budget, given the priority configured above.

Solution and Verification

Switch1# show power inline gigabitethernet1/0/1

Interface  Admin  Oper       Power(Watts)  Device
Gi1/0/1    auto   on         6.3           IP Phone

Switch1# show power inline gigabitethernet1/0/2

Interface  Admin  Oper       Power(Watts)  Device
Gi1/0/2    auto   on         12.9          AIR-AP

Switch1# show power inline

Available:370.0(w)  Used:19.2(w)  Remaining:350.8(w)

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# power inline priority high

Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# power inline priority low

Switch1# show power inline gigabitethernet1/0/1 | include Priority

Priority: high

-- With this priority set, if the switch's total
-- power budget were ever exceeded by a newly
-- connected device, the switch would deny power
-- to the LOWER-priority access point port first,
-- before ever removing power from the HIGH-priority
-- IP phone port -- protecting voice service
-- specifically during a power-constrained situation

Key Takeaway

show power inline is the essential command for confirming both individual port draw and the switch's overall remaining budget — and configuring power priority ensures that if the budget is ever exceeded, the switch makes a deliberate choice about which devices lose power rather than an arbitrary one, protecting genuinely critical devices like IP phones over less critical ones.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue