Short answer: On a typical wired IPv4 network, a PC needs a working Ethernet link and an authorized, forwarding switch port; it then obtains or reuses its IP configuration. With a fresh DHCP lease, the familiar exchange is Discover, Offer, Request and Acknowledge.[1]
To send ordinary IPv4 traffic, the host selects a local destination or next-hop router and resolves the required Ethernet address with ARP if necessary.[2][3] DNS is used when an application needs a name resolved, not as an unconditional final step of every boot.[4]
What assumptions should you state first?
This walkthrough assumes a wired PC on an access VLAN, IPv4 DHCP, a reachable DHCP server or relay, and no cached lease or neighbor entry for the initial example. It is a conceptual packet walkthrough, not a capture from a production network or an executed lab.
A useful interview answer starts with those assumptions. Static addressing, an existing DHCP lease, network admission control, IPv6, or a VPN can change what appears in a capture. Do not present one packet order as a universal boot sequence.
1. Ethernet link, VLAN membership and switch forwarding
First, the NIC and switch must establish a usable physical link. Then check whether the port belongs to the intended VLAN and can forward user traffic. A link LED alone does not prove either condition.
For a conventional learning Ethernet switch, the forwarding table associates a source MAC address with the ingress port and VLAN as frames arrive. The switch does not need the PC to obtain an IP address before learning its MAC. Broadcast traffic is flooded within the relevant VLAN, subject to forwarding state and policy; learned unicast destinations can be forwarded to a specific port.
Keep three separate questions in your answer:
- Physical: Is the link up without significant errors?
- Layer 2: Is the correct access VLAN active along the required path, with forwarding permitted?
- Admission: If 802.1X or another access-control mechanism is configured, has the endpoint been authorized?
STP edge/PortFast behavior is relevant to host-facing ports, but do not suggest disabling spanning tree to make a PC boot faster. Use the related STP guide below for port-state details.
2. Fresh IPv4 configuration: DHCP DORA
For a client starting without a usable lease, DHCP begins with a broadcast Discover; the client selects an Offer, broadcasts a Request identifying the selected server, and receives an Acknowledge confirming the allocation.[1]
| Message | Purpose | What to inspect |
|---|---|---|
| DHCPDISCOVER | Find available DHCP servers | Client identity, transaction ID, ingress VLAN |
| DHCPOFFER | Propose an address and configuration | Offered address, server identifier, options |
| DHCPREQUEST | Request the selected offer | Requested address and selected server |
| DHCPACK | Confirm the lease and parameters | Lease, mask and supplied configuration |
The table describes the fresh-allocation exchange in RFC 2131, not every possible DHCP state.[1] The initial client exchange uses UDP client port 68 and server port 67, and a client without an address uses source IPv4 address 0.0.0.0.[1] Server responses can be broadcast or unicast according to the client state, flags and relay situation; “all four DORA packets are broadcasts” is not a safe answer.[1]
A DHCP server need not be in the PC's VLAN: a relay can carry requests between the client segment and the server.[1] In troubleshooting, verify the relay and the server's scope selection instead of assuming a remote server should receive an ordinary Layer-2 broadcast directly.
After an ACK, the client should check that the allocated address is not already in use; RFC 2131 describes an ARP-based check and DHCPDECLINE when a conflict is detected.[1] A DHCPACK is therefore important evidence, but it is not proof that every subsequent network service works.
Does every reboot produce Discover, Offer, Request, ACK?
No. A client remembering a previously allocated address can start by requesting confirmation of that address, rather than beginning with a new Discover/Offer exchange.[1] Renewal and rebinding are also different states with different delivery behavior.[1] Start capturing before boot or reconnect, and interpret the DHCP state rather than searching only for the word Discover.
3. Route first, then ARP for the correct next hop
For a directly connected IPv4 destination, the host can deliver on the local network; a remote destination requires a gateway.[3] On Ethernet, ARP supplies the IPv4-to-MAC mapping needed to address the next-hop frame.[2] An existing valid neighbor entry can avoid a new ARP request; do not demand a fresh ARP exchange before every packet.[2][3]
Consider this fictional, isolated example:
PC: 192.0.2.10/24
Default gateway: 192.0.2.1
Local service: 192.0.2.20
Remote service: 198.51.100.20
Assume no more-specific routes and empty neighbor cache.
Local service:
ARP target = 192.0.2.20
Ethernet destination = local service MAC
IPv4 destination = 192.0.2.20
Remote service:
ARP target = 192.0.2.1
Ethernet destination = gateway MAC
IPv4 destination = 198.51.100.20
The example applies the local/remote decision and Ethernet address-resolution process.[2][3] The PC does not normally ARP for the remote server's MAC address across a router. It addresses the local next-hop frame to the gateway while keeping the remote service as the IP destination.[2][3]
For a real multihomed host, inspect the actual route decision, including VPN and more-specific routes, rather than assuming every remote destination follows the default route.
4. DNS and application traffic: dependencies, not a rigid order
DNS resolution can return an answer from cached information or require queries to a server.[4] Consequently, opening a service by name does not guarantee a visible DNS query on every attempt.[4] A cached answer or a numeric destination changes what you should expect in the trace.
If the DNS resolver is remote and the gateway's MAC is unknown, the host needs next-hop resolution to deliver its DNS request.[2][3] If the resolver is local, it needs the resolver's local MAC instead.[2][3] This is why “DHCP, then DNS, then ARP” is an unreliable memorized sequence.
Once the application has a usable destination, troubleshoot the transport and service separately. For a TCP service, use the linked handshake guide rather than treating successful DHCP as proof of a working connection. Other applications may use UDP; boot traffic is not synonymous with web browsing.
Troubleshooting checklist: find the first missing dependency
Use this as a recommended investigation order, not as evidence that a particular device has failed.
| Observation | Next checks |
|---|---|
| No link | NIC state, cable, switch port, negotiation and errors |
| Link up but no usable network access | Access VLAN, forwarding state, authentication and port policy |
| Repeated Discover with no Offer at the PC | Trace toward relay/server; check scope, relay configuration and DHCP filtering |
| Offer received, no completed lease | Match transaction/client identity; inspect Request, ACK/NAK and server logs |
| Lease present, ARP for gateway unanswered | Confirm mask, selected route, gateway address, VLAN path and ARP/security drops |
| Gateway reachable, remote service unavailable | Check onward routing, return path, ACL/firewall policy and the service |
| Name lookup fails | Check configured resolver, route to it, query/response and resolver behavior |
Read-only verification examples
These commands are illustrative; adapt interface names and syntax to the operating system or switch release. They were not executed against a network appliance for this article.
# Windows
ipconfig /all
route print
arp -a
nslookup example.com
# Linux
ip -br link
ip -br addr
ip route
ip route get 198.51.100.20
ip neigh
# Cisco IOS / IOS XE examples
show interfaces status
show interfaces switchport
show vlan brief
show spanning-tree interface GigabitEthernet1/0/10 detail
show mac address-table interface GigabitEthernet1/0/10
Suggested Wireshark display filter for classic DHCPv4, ARP and ordinary port-53 DNS traffic:
arp || udp.port == 67 || udp.port == 68 || udp.port == 53 || tcp.port == 53
This is a deliberately scoped filter, not a complete boot capture: it omits admission-control traffic, IPv6, encrypted DNS and most application traffic. Capture only on networks you are authorized to inspect, and protect packet files because they can contain identifying information.
Common interview pitfalls
- Confusing the MAC table with the ARP cache: the switch's forwarding entry is a MAC-to-port/VLAN association; the host's ARP entry maps an IPv4 neighbor to a MAC address.[2]
- Assuming DHCP happens on every boot in exactly four packets: existing leases and DHCP states matter.[1]
- ARPing for an off-subnet application's MAC: resolve the selected local gateway instead.[2][3]
- Treating DNS as mandatory before any communication: cached resolution can avoid new queries, and the example can use a numeric IP.[4]
- Equating a successful lease with Internet access: test routing, name resolution and the application as separate checkpoints.
- Applying this ARP/DHCPv4 sequence to IPv6: IPv6 uses different address-configuration and neighbor-discovery mechanisms; clarify the protocol family first.
A concise interview answer
“Assuming wired Ethernet and IPv4 DHCP, I first check link, VLAN membership, forwarding and any admission control. The switch learns source MAC addresses from arriving frames. A fresh DHCP client obtains configuration through Discover, Offer, Request and ACK, although a retained lease changes the exchange.[1] For application traffic, the host selects a route and resolves either the local destination or gateway MAC with ARP if needed.[2][3] DNS is used when name resolution is needed and can be satisfied from cache.[4] If something fails, I identify the earliest missing dependency rather than calling every startup problem a DHCP issue.”
Related reading
- Access Port vs Trunk Port vs Native VLAN Explained
- STP vs RSTP Port States and Roles Explained
- DHCP Snooping vs DAI vs IP Source Guard
- TCP 3-Way Handshake and Firewall Troubleshooting
Summary
Explain boot-time connectivity as a chain of dependencies: link and access, address configuration, route and neighbor resolution, then the service being used. State the assumptions before describing a packet order.
Preparing for a network engineering interview? Practice the answer with one local and one remote destination, then explain how you would locate a missing DHCP Offer without guessing.
Post a Comment