This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
A frame, a packet, and a name are three different problems
Networking is a stack of envelopes. The application writes a message. TCP or UDP carries it between ports. IP carries it between addresses. Ethernet carries it between interfaces on a link. A failure has a layer. The troubleshooting guide is that idea applied to an incident. This guide is the idea itself, so the later guides have somewhere to point.
A switch forwards Ethernet frames inside a VLAN. It does not need to understand the IP address to do that, though many switches also route. A router forwards IP packets between prefixes. It does not care which application, except when a firewall policy does. DNS turns a name into an address before any of that happens. If the name is wrong, the packet is right and still useless.
Addresses are assigned within prefixes. The subnetting guide is the arithmetic. A host needs an address, a mask or a prefix length, and a gateway inside its own prefix. The gateway is the router that will forward everything else. A host that uses a gateway outside its prefix has a configuration error, not a mysterious routing bug.
Nothing in this stack requires you to memorise every header field. It requires you to say which envelope failed. Link, VLAN, address, gateway, route, name, port, application. The tools on this desk each live at one of those layers. Use the one that matches the envelope you have not opened yet.
One web request, told in order
You type a name. The host asks a resolver. The resolver returns an address, or it does not. If it does not, you stop. There is no packet to the server yet, except the DNS query itself. Fix the name or the resolver. The DNS guide is that envelope.
The host looks at the address and its own prefix. If the address is inside the prefix, it tries to reach it on the link, using neighbour discovery or ARP to find a MAC address. If the address is outside, it does that for the gateway instead. A wrong mask makes the host treat a remote address as local, or a local address as remote. Both fail in ways that look like a dead server.
The frame crosses the switch inside the VLAN. If the access VLAN is wrong, the frame is in the wrong broadcast domain and the gateway never sees it. The switching guide is that envelope. Trunks and spanning tree live there, not in the IP header.
The gateway routes toward the destination using the longest prefix it has. The routing guide is that envelope. A default route is a prefix of last resort. A more specific route wins. If the gateway has no route, it should say so, and the host will notice only as silence or an unreachable message, depending on the filters in between.
A firewall on the path may allow the TCP port or not. ICMP working and TCP failing means the firewall or the server treated them differently. That is not a contradiction. They are different envelopes. The packet guide tells you how to see which one you have, on a network you are allowed to observe.
The server answers, and the answer must find its way back. The return route is a second design. State that only one direction was tested is how a change gets closed early. Test the reply. Then the application speaks. A certificate error is the application envelope. Do not re-subnet the VLAN because a certificate expired.
Names you will meet in every other guide
A prefix is a network and a length. A mask is the same fact in dotted decimal for IPv4. A gateway is a router address inside the prefix. A VLAN is a layer-2 group. A trunk carries several VLANs. A route is a prefix plus a next hop. A resolver answers names. An authoritative server publishes them. These words are not interchangeable, and tickets get long when they are used as if they were.
Private addresses and documentation addresses are not the public Internet. 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are for examples. Use the examples in notes. Use your own addresses in production. The lookup guide explains what a public database can say about a public address, which is less than people hope.
A port is a number on a host, not a physical jack, except when someone says port and means the jack. In a ticket, say TCP 443 or switch port 12. The ambiguity is expensive. A protocol is the rule the port is speaking. Allowing a port is not the same as understanding the protocol, and it is enough for a firewall rule if the ticket only asked for the port.
Broadcast and multicast are not unicast. A broadcast in a VLAN is heard by that VLAN. Making a VLAN enormous makes the broadcast enormous. That is the layer-2 reason the subnetting guide keeps prefixes moderate and the switching guide keeps VLANs purposeful. You do not fix a broadcast storm with a DNS change.
How to use the rest of this desk
When you learn a new device, map it onto this stack before you memorise the commands. Where does it put an address? Where does it put a route? How does it show the VLAN? The vendor guides on this desk are that mapping for specific platforms. They assume you know which envelope you meant to change.
When you are stuck, say the envelope out loud. If you cannot, you are not stuck in a deep way. You are stuck because the symptom has not been pinned to a layer. Go back to the troubleshooting guide and get the five facts: host, address, gateway, name, and port.
The calculators and simulators are there to make the arithmetic and the longest match visible. They are not the network. A correct calculator result that was never typed into the right device has not changed production. The ticket is the bridge.
- Name the layer you are changing before you change it.
- Keep address, VLAN, route, and name in separate lines of the ticket.
- Test the return path.
- Use documentation prefixes only in labs and notes.
- Say TCP port or switch port, not port alone.
- Stop at the first envelope that failed.
Mistakes that come from mixing the layers
Changing DNS because a cable is unplugged.
Changing a VLAN because a certificate expired.
A gateway that is not inside the host's prefix.
Calling every problem a firewall problem.
Using a documentation prefix in production because the lab worked.
A VLAN so large that broadcast is the traffic.
A ticket that says port without a number or a jack.
A test that never checked the reply.
Fundamental checks on any new design
Confirm this before you call the change done: Every host prefix has a gateway inside that prefix. Every VLAN has a purpose and a size you can justify. Names resolve to the addresses you meant, in the view the user is in. The return path is drawn. TCP ports in the policy match the application. Documentation prefixes are labelled as examples. The layer of the next change is written in the ticket. A calculator result has a destination device, not only a screenshot. Broadcast domains are no larger than the VLAN plan. Someone can explain the design with the words prefix, VLAN, route, and name used correctly. The troubleshooting five facts are the start of any incident. Vendor commands are treated as a dialect of this stack, not as a replacement for it. A certificate error was not patched with a static route. The desk's tools were used at the layer they actually implement. A wrong mask was considered before a routing protocol was blamed. Return traffic was tested with a reply, not only with a sent ping. The word port in the ticket is either a TCP number or a switch jack. Private addressing and documentation addressing were not mixed up in the plan. The first failed envelope stopped the investigation. A broadcast storm was not assigned to the DNS owner. And the gateway address was checked to sit inside the host prefix. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.