Switch Port Is Up but the Device Has No Network: VLAN, MAC Table, and Port Checks

A switch port showing connected or up confirms a physical link. It does not prove that the attached device is in the correct virtual LAN (VLAN), can reach Dynamic Host Configuration Protocol (DHCP), or has a working path to its default gateway.

This guide starts at the switch port and follows the traffic path outward. The Cisco IOS and IOS XE commands are read-only examples. Interface names and available commands vary by switch model and software release.

Start with the symptom and scope

Before changing the port, identify what is failing:

• Does one device fail, or do several devices on the same VLAN fail?
• Did the problem begin after a desk move, phone replacement, switch change, or VLAN change?
• Does a known-good device work on the same cable and port?
• Does the affected device work on another known-good port?
• Does the device have no IP address, a 169.254.x.x address, or a valid address with no remote connectivity?

These comparisons separate a device problem from a port, VLAN, or shared-service problem. Record the original port and configuration before testing another port, and follow the local change process before moving a device into a different VLAN or changing switch configuration.

1. Separate link state from network connectivity

A working link means the switch and network interface card negotiated at the physical layer. Frames can still be placed into the wrong VLAN, blocked by a security feature, or sent toward a VLAN with no working DHCP or Layer 3 path.

On a Cisco-style switch, begin with:

show interfaces status
show interfaces gigabitethernet1/0/10

The first command summarizes port status, VLAN, duplex, and speed. The detailed interface command can show whether the interface and line protocol are up, whether errors are increasing, and whether traffic counters change.

Interpret the result rather than stopping at connected:

• Not connected: Check the cable, wall jack, patching, dock, adapter, network card, and power state.
• Administratively down: Confirm why the port is shut down before requesting a change.
• Error-disabled: Find the reason before attempting recovery.
• Connected with increasing input or output errors: Investigate the cable, transceiver, negotiation, or interface hardware.
• Connected with normal counters: Continue to VLAN and MAC-address checks.

A link light is therefore the first checkpoint, not proof of end-to-end connectivity.

2. Confirm the access VLAN assignment

An endpoint port normally operates as an access port in one data VLAN. If the port is assigned to the wrong VLAN, the device may still show link while receiving no address or an address from an unexpected subnet.

Check the port’s switchport details and the VLAN database:

show interfaces gigabitethernet1/0/10 switchport
show vlan brief
show running-config interface gigabitethernet1/0/10

Verify:

• The operational mode is appropriate for an endpoint port.
• The access VLAN matches the approved network design.
• The VLAN exists and is active on the switch.
• The running configuration does not contain an unexpected trunk, access VLAN, voice VLAN, or authentication setting.

A phone-and-PC connection may legitimately use both a voice VLAN and a data access VLAN. Do not remove the voice VLAN just because two VLAN references appear in the configuration.

If the access VLAN is correct locally but the problem affects multiple devices, the next checks may include whether that VLAN is carried over the required uplinks. That is a different issue from the access-port assignment and may require a network administrator.

For a basic explanation of access and trunk ports, see VLAN Basics for Homelab Beginners.

3. Confirm the port is forwarding

A port can have physical link without forwarding data traffic. Where spanning tree is relevant, use a brief read-only check:

show spanning-tree interface gigabitethernet1/0/10 detail

Confirm that the interface is in a forwarding state for the expected VLAN. A blocking or discarding state explains why link is up but frames are not passing; investigate the topology and escalate rather than changing spanning-tree settings as a quick fix. If the port is forwarding, continue to MAC learning.

4. Check whether the switch learns the device MAC address

A switch learns a source Media Access Control (MAC) address when it receives frames from a device. Check the affected interface after generating normal endpoint traffic, such as renewing its DHCP lease or attempting to reach its gateway:

show mac address-table interface gigabitethernet1/0/10

Some platforms also support a VLAN-specific or address-specific lookup:

show mac address-table vlan 20
show mac address-table address aaaa.bbbb.cccc

Possible findings change the next step:

• Expected MAC learned on the expected port and VLAN: Layer 2 traffic is reaching the switch. Continue toward DHCP and the gateway.
• No dynamic MAC learned: Confirm the correct port, make the endpoint send traffic, and recheck the cable, dock, network adapter, and security state.
• Expected MAC learned on another port: Verify patching and whether the device moved. A MAC address moving repeatedly can indicate a loop, duplicate path, or incorrect identification.
• Unexpected MAC addresses on the port: Check for an IP phone, dock, small unmanaged switch, or unauthorized device according to policy.

Dynamic MAC entries age out after inactivity, so an empty table is not final proof of failure. Generate permitted traffic and check again. Also confirm the endpoint MAC from the active adapter rather than relying only on an old inventory record.

5. Check port security and error-disabled state

Port security can restrict how many MAC addresses are allowed or which addresses may use a port. A device move, replacement computer, dock, phone, or unauthorized downstream switch can trigger a violation depending on the configured mode.

Use read-only checks first:

show port-security interface gigabitethernet1/0/10
show interfaces status err-disabled
show logging

Look for:

• Whether port security is enabled.
• The maximum and currently learned secure MAC addresses.
• The violation counter and violation mode.
• Sticky or statically configured secure addresses.
• An error-disabled reason and related log messages.

Avoid clearing secure addresses or cycling the port before identifying the cause. That can hide the evidence or allow the same condition to disable the port again. Confirm the attached equipment, document the violation, and follow the recovery procedure or escalate.

Port security is only one possible reason for an error-disabled port. Cisco switches can also disable ports for conditions such as link flapping or other protection features, depending on the configuration and platform.

6. Follow the DHCP path

If Layer 2 checks look correct, inspect the endpoint’s IP configuration. On Windows:

ipconfig /all

Check the active adapter’s IPv4 address, subnet mask, default gateway, DHCP status, DHCP server, and DNS servers.

A 169.254.x.x Automatic Private IP Addressing (APIPA) address usually means the client did not receive normal DHCP settings. It does not identify which part of the path failed. Use the scope to narrow it:

• One device fails on a working port and VLAN: Check the endpoint adapter, driver, cable, dock, local firewall or service state, and port security.
• Every device on one access port fails: Focus on that port, patching, and its security or authentication state.
• Several devices in one VLAN fail: Check the VLAN path, DHCP scope, relay, gateway interface, and any DHCP security policy.
• DHCP fails across multiple VLANs: Investigate a shared DHCP server, relay path, routing dependency, or broader infrastructure outage.

DHCP begins with client broadcasts. If the DHCP server is on another subnet, DHCP relay is normally configured on the first-hop Layer 3 interface for the client subnet, such as a router interface or switched virtual interface (SVI). On Cisco IOS or IOS XE, this is commonly an ip helper-address. Routers do not forward local broadcasts between subnets by default, so the relay receives the client broadcast and forwards the request toward the DHCP server.

A random static address is not a safe permanent workaround: it can create an address conflict and hide the DHCP failure. If the support procedure permits a temporary static test, use a confirmed unused address and remove it afterward.

For endpoint-side DHCP symptoms, see What Is APIPA? 169.254 IP Address Explained for Beginners.

7. Test the gateway and Layer 3 boundary

A device can have a valid IP address but still be unable to reach its gateway. Confirm that its address, subnet mask, and gateway belong to the intended VLAN and subnet. Then test the gateway where policy permits:

ping <default-gateway>

If the gateway does not reply, compare with a known-good device in the same VLAN. A failed ping is a clue, not conclusive proof, because some devices or firewalls do not answer Internet Control Message Protocol (ICMP) echo requests.

A switch or router administrator can also check the Layer 3 interface:

show ip interface brief
show ip route
show arp

Depending on the platform, show arp may appear as show ip arp. These checks help answer whether the VLAN interface is up, the expected connected route exists, and the gateway is learning the endpoint’s IP-to-MAC mapping.

Use the pattern of results:

• No valid IP settings: Stay with DHCP reachability.
• Valid IP, but the wrong subnet or gateway: Check the access VLAN, static settings, and DHCP scope options.
• Correct settings, but no gateway reachability for one device: Recheck the endpoint, MAC learning, port policy, and duplicate-IP possibility.
• Correct settings, but no device in the VLAN reaches the gateway: Escalate the SVI, trunk, routing, or upstream switch path.
• Gateway works, but remote IP addresses fail: Investigate routing, firewall policy, or upstream connectivity.
• Remote IP works, but names fail: Move to Domain Name System (DNS) checks rather than changing the switch port.

The layer-by-layer Windows troubleshooting guide continues with endpoint, routing, and DNS tests after the local switch path is established.

A compact decision flow

1. Confirm the affected scope and recent changes.
2. Verify physical link, administrative state, errors, speed, and duplex.
3. Confirm access mode, the assigned VLAN, and that the VLAN is active.
4. Confirm that the port is forwarding, including its spanning-tree state where relevant.
5. Generate normal traffic and check MAC learning on the port.
6. Check port security, error-disabled reasons, and logs where relevant.
7. Inspect the client’s IP, mask, gateway, and DHCP information.
8. If DHCP fails across a subnet boundary, check the relay on the client’s first-hop Layer 3 interface and verify the VLAN path.
9. Test the gateway and compare with a known-good client in the same VLAN.
10. Escalate when the evidence points beyond the endpoint or your access level.

When to escalate

Escalate instead of changing configuration when:

• The port is error-disabled or shows a security violation.
• The correct VLAN is missing from an uplink or trunk.
• Multiple users in the same VLAN cannot obtain DHCP settings.
• The DHCP relay, scope, server, SVI, gateway, route, or firewall needs investigation.
• MAC addresses appear on unexpected ports or move repeatedly.
• Interface errors continue to increase after a known-good cable or endpoint test.
• The required commands or configuration are outside your permissions.

Provide the switch name, interface, time of the test, affected scope, link and error state, access VLAN, learned MAC address, port-security state, client IP details, gateway test, known-good comparison, and recent changes. This gives the next support tier a clear starting point without claiming a cause that has not been proven.

Sources

Technical claims and command usage in this general guide were checked against Cisco documentation:

• Checking Port Status and Connectivity, Cisco IOS XE
• Interface and Hardware Commands: show interfaces ... switchport, Cisco IOS XE
• Troubleshoot STP Issues on Catalyst Switches
• Recover Errdisable Port State on Cisco IOS Platforms
• Troubleshoot DHCP in Enterprise Networks

The commands and result patterns above are instructional examples. They are not presented as output from Jensen’s work or lab.