Switch Port Up, No Network? Check These 5 Things

A green link light is easy to overtrust. On a Cisco switch, connected means the cable and network adapter negotiated a link. It does not prove the device is in the right VLAN or has a working IP path.

Fast path: Port → VLAN → MAC → DHCP → Gateway

Stop at the first failed check. That is where the useful troubleshooting starts.

Replace gigabitethernet1/0/10 below with the affected port. These checks are read-only.

1. Read the port in one line

show interfaces status

Find the port and read across the row.

• connected: move to the VLAN check.
• notconnect: test the cable, wall jack, dock, adapter, and device power.
• disabled or err-disabled: find the cause before anyone resets the port.

If possible, plug a known-good device into the same cable and port. If it also fails, stop blaming the original laptop.

2. Check the VLAN, not the link light

A virtual LAN (VLAN) puts the port into a particular logical network. The link can be up while the device sits in the wrong one.

show interfaces gigabitethernet1/0/10 switchport
show vlan brief

For a normal PC port, confirm that it operates as an access port and that its access VLAN is the intended, active VLAN. A phone with a PC behind it may legitimately show separate voice and data VLANs.

Wrong or inactive VLAN? Stop here. Fix or escalate that assignment before testing DNS.

3. See whether the switch hears the device

The MAC address table shows which hardware addresses the switch has learned on each port.

show mac address-table interface gigabitethernet1/0/10

Generate traffic from the device, then check:

• The expected MAC appears: the switch is receiving its frames. Move to DHCP.
• No MAC appears: recheck the port, cable, dock, adapter, and any port-security policy.
• The MAC appears on another port: verify the patching and whether the device moved.

MAC entries age out, so an empty table only matters after the device has tried to send traffic.

4. Read the IP settings

On the Windows device:

ipconfig /all

Look at the active Ethernet adapter. Check its IPv4 address, subnet mask, default gateway, and whether DHCP is enabled.

An address starting with 169.254 usually means Windows did not receive settings from Dynamic Host Configuration Protocol (DHCP). One failed device points back toward that device or port. Several failed devices in the same VLAN point toward a shared VLAN, DHCP, relay, or gateway problem.

5. Test the way out

The default gateway is the device’s route to other networks. If the client has a valid address for the intended VLAN, test that gateway:

ping <default-gateway>

A reply makes the local port, VLAN, and gateway path less likely suspects. No reply means compare with a working device in the same VLAN. Some gateways block ping, so treat the result as a clue, not a verdict.

Match the result to the next move

What you find	Go here next
Port is not connected	Cable, jack, dock, adapter, or power
Port is up, VLAN is wrong	Access-port assignment
VLAN is right, no MAC is learned	Endpoint path or port security
MAC is learned, client has 169.254.x.x	DHCP service, relay, or VLAN path
Client has valid settings, gateway fails	Client, gateway, or Layer 3 path
Gateway works, names fail	DNS troubleshooting

Only then go deeper

The five checks above solve the navigation problem: they show where to look next. Bring in advanced checks only when the evidence points there.

• Port is error-disabled or a replacement device was connected: inspect port-security status and the recorded violation before clearing anything.
• The correct VLAN fails for several devices: check the uplink, VLAN interface, DHCP scope, and DHCP relay. On Cisco networks, the relay is often an ip helper-address on the VLAN’s Layer 3 interface.
• Link exists but frames still do not forward: have the topology and Spanning Tree state reviewed. Do not change Spanning Tree as a quick fix.

When escalating, include the switch and port, affected VLAN, learned MAC, client IP settings, gateway result, number of affected devices, and anything that recently changed. That is enough to show exactly where the fast path stopped.

For the next layer after a successful gateway test, use the Windows connected-but-no-internet guide. For more on 169.254, see the APIPA note.

Sources

• Cisco IOS XE interface monitoring commands
• Cisco IOS XE show interfaces switchport reference
• Microsoft ipconfig reference