The "Networking" Interview - a few Pointers

You’re sitting in a tiny room at Googamazbook. The interviewer comes in, says hi (if you’re lucky), introduces themselves (they act like they’re doing you a favor) and starts with what seems like an easy question:

What happens when you run telnet www.brainware.ro 80? Please go through all the layers.

Warmed up by the systems interview pointers, you start with /etc/hosts and /etc/resolv.conf: name resolution first, then the actual connection to the HTTP port. If your knowledge stops there, keep reading. If it doesn’t, keep reading anyway, in case something was missed.

Name resolution works by sending a UDP packet to each resolver listed in /etc/resolv.conf. The UDP header is small and contains:

• Source port and destination port;
• Packet length (header + payload);
• Checksum.

The checksum is computed over a so-called UDP pseudoheader (which includes data from the protocol above it, such as the source and destination IP addresses) plus the payload. This is a tricky protocol detail.

The IP address needed for the next stage is taken from the first response received (the exact response format is out of scope for an interview).

Everybody knows the SYN / SYN-ACK / ACK sequence. But what is actually exchanged when the connection is initiated?

• Sequence numbers;
• MSS (maximum segment size: if a TCP payload larger than the MSS arrives in a single packet, the other side drops it);
• Receive window size (how much data the other side is able to receive).

From here, questions can escalate quickly, for example:

• How does TCP detect that packets were lost in transit? It doesn’t directly; a retransmission timer is used. The other side may also send packets from time to time with the ACK field set to the last sequence number received.
• What is silly window syndrome? The receiver keeps advertising tiny window sizes while the sender tries to push out as much data as it can. It is usually mitigated by both the sender (delaying data) and the receiver.
• What is TCP Cork? It delays data for up to a timer value (around 200 milliseconds) so that larger payloads can be sent when appropriate and possible.
• What are SYN cookies? A defense against a SYN flood. The initial sequence number is a specially crafted value that encodes the MSS and a connection signature.
• What is a congestion window? The amount of data one side may send without waiting for an ACK; it is dynamically resized up and down. In practice it is represented as a “window” over a circular buffer.
• Why are there many TIME_WAIT connections in netstat that can’t be closed or removed? This comes from the inner workings of TCP: connections can’t be guaranteed to close cleanly before a timeout. During those few minutes, any stray ACK packets belonging to the connection can still be received and handled properly.

The discussion will soon move down to layer 3 (IP).

As soon as you mention MSS, the interviewer will probably ask how it differs from MTU. They are distinct concepts: one applies to the TCP payload, the other to the total IP packet size. Exceeding one causes packets to be dropped; exceeding the other causes fragmentation. MSS is communicated, while MTU is discovered.

An important topic is MTU discovery. On both IPv4 and IPv6, this is done by sending maximum-size packets and listening for “fragmentation needed” ICMP replies. With IPv4, the “do not fragment” flag must be set for this to work. The ICMP responses (if any) carry the MTU accepted by that node on the route.

Some points worth mentioning about MTU:

• The standard Ethernet value is 1500 bytes;
• Every transmission protocol (e.g. WLAN, PPPoE, FDDI, Token ring) has its own maximum value;
• IPv6 forbids fragmentation by intermediate nodes (only the source may fragment data as needed).

Mentioning “Ethernet” leads the discussion to layer 2.

This layer is simpler to describe: the payload (most likely an IP datagram, but possibly ARP) is encapsulated in a frame with a header and a footer. The header usually holds the source and destination MAC addresses, an optional VLAN field, and a field indicating either the length or the payload type. The footer holds the checksum.

The conversation may then turn to ARP, which is simply an IP-to-MAC resolution protocol. It works by broadcasting messages like “who has ip_address?” and answering with unicast messages like “ip_address is at mac_address”. Every node keeps a cache of the associations it knows about; entries expire within minutes, so ARP messages are sent regularly. Such a simple protocol is open to attacks, but that’s getting a bit far afield.

Very few candidates get asked about the next layer, the physical link.

Layer 1: it can’t get any lower than this. With an Ethernet connection, the 1524 bytes (maximum MTU plus the Ethernet header) are placed between a header (the preamble) and a footer (the frame check sequence). These are handled by the firmware of the Ethernet device.

Is that all? Not necessarily. There may still be time for variations.

You still have 10 minutes left, and the interviewer wants to end on a high note:

How does DHCP work?

You can’t help thinking of Dora the Explorer, and that’s actually a good thing: it means you read the docs! There are 4 steps before the client gets an IP address, two initiated by the client and two by the server:

• Discover;
• Offer;
• Request;
• Acknowledge.

Communication uses UDP on port 67 (server) and 68 (client). The client has no IP address yet, so 0.0.0.0 is used as the source address. The first packet is a broadcast, which means any device on the local network can receive it and possibly return an offer. The remaining 3 packets are unicast (sent to a specific MAC address).

Follow-up:

Why 4 packets? Wouldn’t the first 2 be enough?

Two would be enough if the protocol guaranteed that only a single DHCP server exists on the network. That isn’t the case, so the client must choose one of the offers to proceed with.

As the next interviewer knocks on the door, the current one still has one last question:

How does traceroute work?

It’s simple: it sends packets with increasing TTL values and records the responses. All the usual protocols (ICMP, TCP, UDP) are supported. The traceroute program also offers handy features such as MTU discovery and gateway testing. There is also a simpler tool worth checking out: tracepath.

Even at this point the interview may not be over, but these pointers should help you make a good impression, or at least there’s hope. Thanks for reading!