The “Networking” interview – a few pointers

You’re in a tiny room at Googamazbook and the interviewer comes in, says hi (if you’re lucky), presents themselves (they’re really into doing you a favor) and then starts asking questions. The easy one comes first:

What happens when you run telnet 80 ? Please go on through all the layers.

Warmed up from the systems interview, you start talking about /etc/hosts and /etc/resolv.conf: name resolution and then the actual connection to the http port. If your knowledge stops here, please do go on reading this text. Or just do go on, maybe I forgot something.

1. Name Resolution

The name resolution protocol is performed by sending an UDP packet to each resolver found in /etc/resolv.conf. The UDP packet has a small header containing:

  • Source port / destionation port;

  • Packet Length (Payload + Header);

  • Checksum.

The checksum is calculated on a so-called UDP pseudoheader (it also contains some data from the protocol above, e.g. the source and destination IP addresses) plus the payload. That’s a tricky protocol detail.

The IP address for the next stage is extracted from the first response received (the actual format is out of the scope for such interview).

2. TCP Connection

Everybody knows about SYN / SYN ACK / ACK sequence. But what exactly does get exchanged upon connection initiation?

  • Sequence numbers;

  • MSS (maximum segment size – TCP payloads larger than MSS, in a single packet, cause packets to be dropped by the other side);

  • Receive window size (how much data can the other side receive).

From here on, things can escalate very quickly, e.g.:

  • How does the TCP protocol figure out that packets are lost in transit? It doesn’t, a retry timer is used. The other side may send from time to time packets with ACK field set to the last sequence number received.

  • What is a silly window syndrome? Constantly advertising small window sizes while the sender attempts to send in as much data as possible. Usually dealt with by both the sender (delaying data) and the receiver.

  • What is TCP Cork? Delaying data up to some timer value (200 miliseconds) in order to send larger payloads, when appropriate and possible.

  • What are Syncookies? A technique for defending against SYN flood. Basically it’s about choosing an initial sequence number that is a specially crafted value that encodes the MSS and a connection signature;

  • What is a Congestion Window? How much data one side can send out without waiting for ACK; this buffer is dynamically sized up and down. The actual representation is actually a “window” in a circular buffer;

  • Why there are many TIME_WAIT connections visible with netstat that cannot be closed (or removed)? It’s about the inner workings of the TCP protocol, connections cannot be guaranteed to be closed before a timeout. During those few minutes any “stray” ACK packets belonging to that connection can be received and cleanly dealt with.

The discussion will soon migrate over to layer 3 (IP).

3. IP Connection

Probably as soon as hearing about MSS, the interviewer will ask about how it is different from MTU. These are different protocol concepts, one applies to the TCP payload, the other to the total IP packet size. Exceeding one will cause packets to be dropped, exceeding the other will cause packet fragmentation. MSS is communicated, MTU is discovered.

An important topic that will be asked is indeed the MTU discovery; this is being done on both IPv4 and IPv6 by sending maximum size packets and then listening for “fragmentation needed” ICMP replies. Of course, the “do not fragment” flag must be set with IPv4 in order for this to work. The ICMP responses (if any) contain the MTU accepted by that node on the route.

Some details to be mentioned about MTU:

  • The Ethernet protocol standard is 1500 bytes;

  • Every transmission protocol (e.g. WLAN, PPPoE, FDDI, Token ring) has its own maximum allowed value;

  • IPv6 disallows fragmentation by intermediate nodes (the source can fragment data as needed).

The “Ethernet” word will bring the discussion to layer 2.

4. Data Connection

This layer is simpler to express: the payload (most likely an IP datagram, but could be ARP) is encapsulated into a frame with a header and a footer. The header usually contains the source/destination MAC addresses, one optional field (the VLAN) and a field indicating either the length or the payload type. The footer contains the checksum.

At this point the discussion may go to ARP, which is just an IP – MAC resolution layer. This protocol is about sending out messages such as “who has ip_address?” (broadcast) and “ip_address is at mac_address” (unicast). Every node in the network maintains a cache with the associations it is aware of; the entries expire within minutes so ARP packages are sent frequently, on a regular basis. Such simple protocol is open to attacks – but we’re getting a bit too far.

Very few candidates get to be asked about what happens on the next layer, the physical link.

5. Physical Link

Layer 1: it can’t get any worse than this. Actually, with an Ethernet connection, the 1524 bytes (maximal protocol allowed MTU + Ethernet header) come between a header (preamble) and a footer (frame check sequence). These are obviously handled by the firmware on the Ethernet device.

That’s it? No. There may still be time for variations.

6. More questions

So, you still have 10 minutes left and the interviewer wants to end it on a high note. The question comes:

How does DHCP work?

You can’t help but think about Dora the Explorer:

Dora and Boots

This is actually a good thing: you read the docs! How is that even possible? There are 4 steps before the client gets the IP address assigned; 2 initiated by the client, 2 by the server:

  • Discover;

  • Offer;

  • Request;

  • Acknowledge.

The communication is done through UDP to port 67 (server) and 68 (client). No IP address is assumed by the client; is used as the source IP address. The first packet is sent as broadcast, this also means that any device connected to the local network is able to receive it and possibly return an offer. The subsequent 3 packets are unicast (sent to a specific MAC address).

Follow up:

Why 4 packets? Wouldn’t the first 2 of them suffice?

Yes, 2 would be enough if there were a protocol guarantee that a single DHCP server may be available on the network. Unfortunately this isn’t the case; the client must choose one offer to follow on through.

The next interviewer knocks on the door, but the current one still has something for you:

How does traceroute work?

This is simple: it’s about sending packages with increasing TTL and recording the responses. All “usual” protocols (ICMP, TCP, UDP) are supported. The traceroute program also has nice features such as MTU discovery and gateway testing. There is also a simpler tool one may want to check out, tracepath.

Even at this point you may not be done with the interview, but it’s likely these pointers helped make a good impression. Or at least this is what I hope. Anyway, thank you for your read!

Leave a Reply

Your email address will not be published. Required fields are marked *