“Connected” proves a checkpoint—not usable Internet service
An Ethernet status icon or link LED usually means the NIC and switch interface established a physical Ethernet link. That is valuable evidence, but it says nothing by itself about the switch port's VLAN, the client's DHCP lease, subnet mask, default gateway, ARP resolution, upstream routing, NAT, DNS, proxy behavior, or the application being tested. The fastest method preserves the successful link checkpoint and searches for the first network dependency that fails.
Use Link → VLAN → IP Configuration → Gateway/ARP → Remote Numeric IP → DNS → Exact Service → Targeted Change → Same-Path Verification. Do not restart at the cable after every failure when the evidence already proves later checkpoints.
A negotiated Ethernet link establishes a physical relationship, not a Layer 3 identity
When Ethernet link is stable, the endpoint and switch have enough physical signaling to establish carrier and negotiate their link behavior. The port can still belong to the wrong VLAN, have an access-control restriction, or deliver a network where DHCP, routing, or Internet service is unavailable. Conversely, a marginal physical path can sometimes stay linked while producing errors, so link state should be paired with interface counters when symptoms suggest loss or instability.
Link can establish
Physical carrier and interface relationship at that moment.
Link cannot establish
Correct VLAN, IP configuration, gateway, DNS, NAT, or Internet service.
Link plus clean load test
Provides stronger evidence against a physical-path explanation for the reproduced failure.
One endpoint, one jack, one switch, or the entire wired network imply different shared dependencies
| Failure scope | Shared dependency to investigate | Useful control |
|---|---|---|
| One device only | Client IP state, NIC, local security, static settings, proxy/VPN | Known-good device on same jack |
| Any device on one jack/port | Port VLAN, port policy, patching, physical/interface state | Same device on known-good jack |
| Many ports in one VLAN | DHCP scope/relay, SVI/gateway, VLAN path, policy | Another healthy VLAN on same switch |
| Whole switch | Uplink/trunk, switch gateway path, shared policy | Nearby switch using same upstream services |
| All wired clients | Gateway/edge, routing, NAT, firewall, WAN, shared DNS | Local internal services and edge state |
Swipe horizontally to see the full table.
A port can be physically up while delivering the wrong broadcast domain
An access port assigned to an unintended VLAN may give the client no lease, a lease from the wrong subnet, or restricted guest connectivity. The link light cannot reveal VLAN membership. Compare the suspect port's configured VLAN and learned behavior with a known-good port intended for the same users.
VLAN evidence is strongest when it connects configuration to client state. If a laptop receives 10.60.20.x on the suspect jack but 10.20.30.x on a known-good employee jack, that address difference is a clue that the logical placement changed with the port.
For deeper Layer 2 placement analysis, use VLAN Explained and VLAN Mismatch Symptoms.
Read the entire lease, not just whether an address exists
A usable DHCP result normally supplies more than an IP address: prefix/subnet information, a default gateway where required, DNS resolver information, and lease state. Compare those values with the intended network. An address from an unexpected subnet may indicate wrong VLAN placement or wrong DHCP scope rather than a failed cable.
A 169.254.x.x IPv4 link-local address is a particularly useful clue: the interface did not obtain normal IPv4 configuration through the expected DHCP process. It does not tell you why. The cause can be client-side, VLAN placement, DHCP server/scope, relay, filtering, or path behavior.
Continue with DHCP Explained or DHCP Scope Exhaustion when lease evidence points there.
A valid-looking static address can be wrong in four independent ways
Static configuration can provide an address that looks normal while the subnet mask, gateway, or DNS server is stale. A laptop moved from one network to another may retain settings from its previous location. Compare every field against a working peer and the intended subnet rather than assuming “10.x.x.x looks internal, so IP is fine.”
Wrong address
Client may be in another subnet or collide with another host.
Wrong mask
Changes the client's local-versus-remote decision.
Wrong gateway
Local subnet can work while remote destinations fail.
Wrong DNS
Numeric connectivity can work while names fail.
The client decides whether to ARP locally or send the packet to its gateway
Before an IPv4 host sends to a destination, it compares that destination with its own address/prefix. If it considers the destination local, it attempts local neighbor resolution. If it considers the destination remote, it sends toward an appropriate router, commonly the default gateway. A wrong subnet mask can therefore create a failure even when the IP address and gateway text look plausible.
This is why “gateway configured” is not enough. The gateway should be reachable according to the client's local subnet logic, and the client must be able to resolve the gateway's Layer 2 address on the local segment.
Gateway failure keeps the unresolved boundary close to the local LAN
If the client has the intended IP configuration but cannot resolve or reach its gateway, do not jump immediately to public DNS or the ISP. Inspect the local VLAN, ARP/neighbor state, switch path, gateway interface, access controls, and duplicate/misconfiguration possibilities.
Illustrative checkpoint Client: 10.20.30.44/24 Gateway: 10.20.30.1 DNS: 10.20.10.53 Observed: - Ethernet link: UP - Address/prefix: expected - ARP for 10.20.30.1: unresolved - Remote numeric test: fails First unresolved dependency: local path to the gateway.
Do not interpret an empty ARP entry without context. Generate the relevant traffic, then inspect whether neighbor resolution succeeds.
After the gateway works, a remote numeric test separates routed service from name resolution
If the first router is reachable, test an appropriate remote numeric destination. Success demonstrates that at least one routed IP path works without requiring DNS. Failure keeps the investigation in routing, edge firewall, NAT, WAN, or remote-path territory.
A single remote host can itself be unavailable or block the test protocol, so use a sensible control and interpret the exact traffic used. The point is not to memorize one public IP; it is to remove hostname resolution from the experiment.
When the gateway works but upstream access does not, use Gateway Works but No Internet for the next branch.
Private-to-public traffic may require translation even when internal routing is correct
A private IPv4 client can reach internal routed networks successfully yet fail Internet access because the edge device does not create the expected NAT translation, uses the wrong egress interface, or lacks matching policy. NAT is therefore an edge dependency, not a property of the Ethernet cable or access switch.
Strong NAT evidence comes from the exact flow and time window: source private address, chosen egress, translation/state entry, and return behavior. “NAT exists on the router” is weaker than evidence showing whether the failing client flow matched it.
If remote numeric traffic works but hostnames fail, preserve the routed-path success
Successful numeric communication proves the tested path did not require DNS. If a hostname fails next, inspect configured resolver addresses, resolver reachability, query response, and returned records. Do not replace the Ethernet cable merely because a browser reports “site cannot be reached.”
| Observation | What it suggests | Next evidence |
|---|---|---|
| Remote numeric works; DNS query times out | Resolver path/service problem | Configured resolver, route/port to resolver, peer query |
| DNS returns NXDOMAIN | Resolver answered name does not exist in its context | Exact spelling/FQDN, intended resolver/zone |
| DNS returns address; exact service fails | Name resolution completed | Route/transport/application to returned address |
Internet access is not equivalent to “can ping a public host”
ICMP echo can be filtered while HTTPS works, and a host can answer ICMP while the web service you need is unavailable. Define the actual requirement. If the complaint is “web browsing fails,” eventually test DNS plus TCP/TLS/HTTP behavior rather than treating ping as the final verdict.
The same evidence discipline applies in reverse: ping success does not prove DNS, TCP/443, TLS, proxy, or application health.
After IP and DNS checkpoints pass, test the flow the user actually needs
A client may have correct Ethernet link, VLAN, DHCP, gateway, Internet routing, and DNS while a proxy, endpoint firewall, VPN route, browser policy, or remote service prevents one application. At that point “Ethernet connected but no Internet” is too broad. Rewrite the symptom as the exact failed transaction.
Examples include “DNS resolves but TCP/443 to the returned address times out,” “HTTPS establishes but the proxy returns an error,” or “browser fails while a command-line HTTPS test succeeds.” Precision changes the next evidence.
Use a two-way swap to see whether the failure follows the endpoint or the physical/logical port
Test the affected device on a known-good jack, then test a known-good device on the suspect jack when practical. If the symptom follows the device, client configuration/security becomes more plausible. If it follows the jack across devices, port VLAN, port policy, patching, switch interface, or upstream path deserves attention.
| Device | Jack | Result | Interpretation |
|---|---|---|---|
| Affected laptop | Jack A | No Internet | Initial symptom |
| Affected laptop | Jack B known-good | Works | Device can work elsewhere |
| Known-good laptop | Jack A | No Internet | Failure follows Jack A path/context |
If local traffic works but every client on one switch loses Internet, investigate the shared uplink/gateway path
Suppose clients can reach each other or local resources in their VLAN but cannot reach remote networks. That pattern proves more than “the switch has power.” It suggests access switching may still function while the shared routed/uplink dependency is impaired. Compare uplink state, trunk/VLAN carriage, gateway reachability, and a peer switch using the same upstream network.
A switching loop or congestion can also create broad impairment, so correlate interface counters, MAC behavior, and topology evidence rather than assuming every switch-wide outage is a dead uplink.
Capture state before renewing, rebooting, or moving the cable
Intermittent failures often disappear when DHCP is renewed, the cable is reseated, the device moves ports, or the adapter resets. Before changing state, record IP configuration, ARP/neighbor entries, route table, DNS resolver, link speed, interface errors, switch port/VLAN, and timestamps. Those artifacts can distinguish a physical flap from an expiring lease, duplicate IP, gateway loss, or policy transition.
Each successful checkpoint narrows what can still explain the failure
| Successful evidence | What becomes known-good for that test | Still unresolved |
|---|---|---|
| Stable Ethernet link | Physical link established | VLAN through application |
| Expected DHCP/IP state | Client received/has intended Layer 3 configuration | Gateway and beyond |
| Gateway reachable | Local first-hop path works for tested traffic | Upstream routing/NAT/DNS/service |
| Remote numeric IP works | Some routed IP connectivity works without DNS | DNS and exact service |
| DNS returns intended address | Name resolution succeeded | Transport/application to returned address |
| Original HTTPS transaction succeeds | Required user path works | Verify stability/policy controls |
Swipe horizontally to see the full table.
The Ethernet link is fine, but the port belongs to the guest VLAN
A desktop shows stable gigabit Ethernet but receives an address from 10.70.50.0/24 instead of the employee 10.20.30.0/24 network. Another employee workstation on a known-good jack receives the expected subnet. Switch configuration shows the suspect access port assigned to the guest VLAN, where Internet access is restricted by policy.
Correcting the port to its approved VLAN changes the DHCP lease to the expected network and restores the required service. The decisive evidence is logical placement, not the link LED.
A 169.254 address points to failed configuration acquisition, not directly to the ISP
One VLAN's new clients self-assign link-local IPv4 addresses. Existing clients with unexpired leases still work. The switch ports are in the intended VLAN. DHCP scope data shows no remaining leases available. After the approved scope correction, a new client receives the expected address, gateway, and DNS values and reaches the Internet.
The failure occurs before normal gateway/Internet testing. The link-local address is evidence of missing normal configuration, while the multi-client scope points toward the shared DHCP service.
The gateway works and remote IP works, but DNS is pointed at a retired resolver
A client has the intended DHCP address and can reach its gateway and a remote numeric destination. Hostname lookups time out. Its configured DNS server differs from a working peer and points to an old resolver address. Correcting the managed resolver setting restores name resolution and browser access.
Because numeric routing already succeeded, replacing the cable or changing the default route would ignore strong known-good evidence.
Local routing works, but the edge has no matching NAT state for one subnet
Clients in VLAN 20 reach internal routed networks and the edge gateway, but public numeric traffic fails. Another VLAN using the same WAN works. Edge evidence shows the failing subnet is absent from the intended translation policy. After the approved NAT policy is corrected, public traffic succeeds while internal routing remains unchanged.
This case shows why “gateway reachable” is not equivalent to “Internet reachable”: translation and edge policy are later dependencies.
Everything through DNS works, but only the browser fails because of proxy state
The endpoint has correct link, VLAN, IP, gateway, remote numeric connectivity, and DNS. A direct diagnostic HTTPS request succeeds, while the managed browser attempts to use an unavailable proxy. A working peer has a newer PAC configuration. Correcting the approved proxy configuration restores the browser.
The final symptom is application/path-specific. Calling it an Ethernet failure after those checkpoints would throw away the most useful evidence.
Change one observation and the leading hypothesis should change
Link begins flapping
Physical/interface evidence rises in priority; inspect errors, cable/port, and link events.
Gateway becomes unreachable
Stop prioritizing public DNS. The first unresolved boundary is local first-hop connectivity.
Remote IP succeeds
Preserve routed success and move toward DNS/exact-service evidence.
Only one website fails
Broad “no Internet” becomes inaccurate; investigate the dependencies unique to that destination/service.
Run the shortest test that answers the next unresolved question
- Record scope, exact symptom, time, interface, and whether link is stable.
- Compare a working endpoint/jack before changing configuration.
- Confirm intended switch-port/VLAN placement.
- Read IP address, prefix/mask, gateway, DNS, and lease state.
- Confirm the client's local-versus-remote subnet decision.
- Resolve/reach the default gateway on the local LAN.
- Test an appropriate remote numeric destination.
- If numeric routing works, test DNS and inspect its actual response.
- Test the original transport/application requirement.
- Make the smallest justified change and repeat the same path.
Verification should prove both recovery and that the diagnosis did not weaken the network
| Repair area | Positive verification | Control |
|---|---|---|
| Port/VLAN | Correct VLAN and intended lease; original service works | Other ports/VLANs remain correctly segmented |
| DHCP | Fresh client receives complete intended lease | Existing clients/scopes remain healthy |
| Gateway/routing | First hop and intended remote path succeed | Unrelated routes remain correct |
| NAT/firewall | Approved Internet flow succeeds | Prohibited traffic remains denied |
| DNS | Resolver returns intended answer and application opens | Other required names resolve correctly |
| Physical repair | Stable expected link under load | Error counters do not reproduce abnormal growth |
Build the answer from known-good checkpoints and the first failed dependency
Observation: “The Ethernet link is stable, the client has the expected DHCP lease, and the gateway responds.” Boundary: “Physical link, logical addressing, and the tested local first-hop path are known-good.” Next evidence: “A remote numeric test fails, so inspect the route/NAT/firewall/WAN path before DNS.” Mechanism: “If the edge shows no translation for this private subnet while another subnet translates normally, the missing NAT match explains why local routing works but public traffic fails.” Verification: “Repeat the original Internet application and confirm approved translation while prohibited policy remains intact.”
24 Ethernet-connected-but-no-Internet flashcards
Practice link evidence, VLAN placement, DHCP, subnet logic, ARP, gateway boundaries, remote routing, NAT, DNS, scope, controlled comparisons, and verification.