Networking Interview Questions

The OSI model has seven layers, and each one has one job in getting data from an application on one machine to an application on another.

1. Physical: sends raw bits over a cable or radio signal.
2. Data Link: frames the data and addresses it on the local segment (Ethernet, MAC addresses).
3. Network: routes packets between networks (IP).
4. Transport: delivers data end to end between applications (TCP, UDP).
5. Session: manages a conversation between two endpoints.
6. Presentation: handles formatting and encoding, such as encryption and compression.
7. Application: the protocol the software actually speaks (HTTP, DNS).

It is a mental model, not a literal description of every real stack. TCP/IP squeezes several of these layers together in practice.

Interviewers ask this because it gives you shared vocabulary. Saying "that is a Layer 2 problem" narrows the search much faster than "the network is broken".

Reference: Cloudflare - What is the OSI model?

A hub is a simple repeater. It copies every incoming signal out of every other port, with no intelligence. It works at Layer 1, and all its ports share one collision domain.

A switch works at Layer 2. It learns which MAC address sits behind which port, then forwards each frame only to the port that needs it. That is why switches replaced hubs.

A router works at Layer 3. It forwards packets between different networks using IP addresses. It is what connects your home network to the internet.

The short version an interviewer wants: hub is a dumb repeater, switch is smart inside one network, router connects separate networks.

A common follow-up: a switch does not stop broadcasts, because they stay inside one broadcast domain. A router does stop them, which is one reason networks are split into subnets.

The three-way handshake sets up a reliable TCP connection before any application data is sent.

1. SYN: the client sends a SYN packet with its starting sequence number.
2. SYN-ACK: the server replies, acknowledging the client's number and sending its own.
3. ACK: the client acknowledges the server's number.

After that, both sides know the connection is open and agree on sequence numbers, so lost or out-of-order segments can be detected and resent.

Handshake behaviour explains real symptoms. A SYN flood attack sends many SYNs and never finishes the handshake, filling the server's table of half-open connections. A connection that hangs in SYN_SENT usually means a firewall is silently dropping packets, as opposed to a closed port, which answers quickly with a reset.

Reference: RFC 9293 - Transmission Control Protocol

A subnet mask marks which bits of an IP address identify the network and which identify the host on that network.

/24 is CIDR (Classless Inter-Domain Routing) notation. It means the first 24 bits are the network part, which is the same as the mask 255.255.255.0. That leaves 8 bits for hosts: 256 addresses, of which 254 are usable after removing the network and broadcast addresses.

This is what lets you decide, from an IP and a prefix alone, whether another device is on your network or must be reached through a gateway. It is the most common everyday networking calculation.

NAT (Network Address Translation) rewrites the source IP address of outbound packets so many devices on a private network can share one public IP address. On the way back, it rewrites the destination so replies reach the right internal device. The router keeps a table that maps each internal connection to a port on the shared public IP.

It exists mainly because IPv4 addresses ran out. There are not enough public addresses for every device, so a home or office hides dozens of devices behind one.

A side effect is that outsiders cannot easily start a connection to an internal device. But NAT was never designed as a security feature, and you should not rely on it as one. A firewall does that job.

Reference: RFC 3022 - Traditional IP Network Address Translator

A public IP address is globally unique and routable on the internet. No two devices can use the same public address at the same time.

A private IP address comes from reserved ranges that only mean something inside a local network. Routers on the public internet do not forward traffic to or from them.

That is why NAT exists. Millions of homes and offices can all reuse 192.168.1.x because those addresses are never exposed directly to the internet. A common mistake is joining two networks, such as two offices over a VPN, that use the same private range. Their addresses then overlap and routing breaks.

Reference: RFC 1918 - Address Allocation for Private Internets

An A record points a name at an IPv4 address. An AAAA record does the same for IPv6.

A CNAME record points a name at another name instead of an IP address. It is used for aliases, such as pointing www.example.com at example.com.

An MX record says which mail servers accept email for a domain, with a priority number so there can be backups.

A useful gotcha: a name that has a CNAME cannot have any other record type at the same name, such as MX or TXT. A CNAME means "this name is only an alias, look everywhere else at the target", so mixing them is ambiguous and invalid. For the same reason you normally cannot put a CNAME at the root of a domain (the zone apex), which is why some DNS providers offer special "alias" or "flattened CNAME" records.

ARP (Address Resolution Protocol) finds the MAC address that belongs to an IP address on the local network.

IP works at Layer 3, but a frame on an Ethernet segment is actually delivered using MAC addresses at Layer 2. ARP bridges the two. A device knows the IP address it wants to reach, but needs the physical address to send the frame to.

It works like this: the device broadcasts "who has 192.168.1.5?" to the whole segment. The owner replies directly with its MAC address. The asker stores the answer in its ARP cache for a while, so it does not repeat the broadcast for every packet.

If the destination is on another network, the device does not ARP for the remote host. It ARPs for the default gateway's MAC address and sends the frame there. You can see the cache with arp -a.

Reference: RFC 826 - Address Resolution Protocol

The default gateway is the router a device sends traffic to when the destination is not on its own local network. It is the "door out" of the local segment. Most devices get it automatically from DHCP.

If it is wrong or missing, the device can still talk to other devices on its own subnet, but anything outside the subnet, including the internet, is unreachable. The device has no idea where to forward non-local traffic.

That gives you a classic diagnosis: "I can reach my coworker's PC but nothing else works" points straight at the gateway setting, the gateway itself, or the subnet mask. A wrong mask is a sneaky cause because it makes the device wrongly think remote hosts are local, so it never sends that traffic to the gateway.

Latency is how long one piece of data takes to travel from source to destination, usually measured in milliseconds as round-trip time. Bandwidth is how much data can be sent per unit of time. It is the width of the pipe, not the speed of one drop through it.

They are independent. A satellite link can have high bandwidth but poor latency, because each packet makes a long physical trip. A short, uncongested local link can have low bandwidth but excellent latency.

Real-time uses such as video calls and competitive gaming care much more about latency (and jitter) than raw bandwidth. That is why "just buy a faster plan" does not always fix a laggy call.

A helpful picture: bandwidth is how many lanes the road has, latency is how long the road is.

ping checks basic reachability and round-trip time using ICMP echo requests. It answers "can I reach this host at all?".

traceroute (tracert on Windows) shows the path packets take, hop by hop. It sends packets with rising TTL values and records which router replies at each step. Use it to find where along a path something fails or slows down.

nslookup and dig query DNS directly. They show which record a name resolves to and which server answered. Use them when the symptom could be DNS and not routing.

A sensible troubleshooting order: ping to confirm reachability, dig to rule out DNS, traceroute to locate the failing hop.

One caution: some routers do not answer ICMP, so a * in traceroute does not always mean a break.

A DoS (Denial of Service) attack tries to make a service unavailable by overwhelming it, usually from one source. A DDoS (Distributed Denial of Service) attack does the same from many sources at once, often a large botnet of infected devices. That makes it much stronger and harder to stop, because you cannot just block one IP address.

There are three common types:

• Volumetric: flooding the target with more traffic than its link can carry.
• Protocol: abusing how a protocol handles state, such as a SYN flood that fills the half-open connection table.
• Application-layer: sending requests that look legitimate but are expensive, such as repeated searches, to exhaust backend resources instead of bandwidth.

Defence is usually layered: a CDN or scrubbing service to absorb volume, rate limiting, and sensible firewall and server settings.

Port forwarding tells a router to send incoming traffic on a certain external port to a certain internal device and port. It is a deliberate hole through NAT for a service that must be reachable from outside. Without it, NAT drops unsolicited inbound connections, because no internal device owns them.

Legitimate uses include a self-hosted game server, a home security camera's web interface, or a personal media server that you want to reach from elsewhere.

The trade-off: every forwarded port is an exception to NAT's incidental "nothing gets in uninvited" behaviour. Keep the rules as narrow as possible, with a specific port and a specific device, and keep the exposed software updated.

Safer alternatives exist. A VPN into your home network avoids opening ports to the whole internet, and some services offer secure tunnels that need no forwarding at all.

A MAC address is a 48-bit hardware address assigned to a network interface when it is made. It is used for Layer 2 addressing on a local segment. The first half normally identifies the manufacturer (the OUI) and the second half is unique to that device. Unlike an IP address, it does not change based on which network you plug into.

Sharing one can be legitimate in a few cases:

• Virtual machines and containers often use virtual MAC addresses that do not match real hardware.
• Some people deliberately change ("spoof") a MAC address for privacy or to work around a network policy tied to a specific address. Many phones now randomize it per Wi-Fi network by default.
• High-availability gateway pairs using HSRP or VRRP share a virtual MAC, so failover is seamless for devices on the segment.

Outside these deliberate cases, two devices with the same MAC on one segment is a misconfiguration. It causes confusing connectivity problems, because the switch cannot tell which port really owns that address.

Unicast is one-to-one: one sender to one specific receiver. It covers most everyday traffic, such as loading a web page.

Broadcast is one-to-all: one sender to every device in the local broadcast domain, whether they want it or not. DHCP discovery and ARP requests use broadcasts.

Multicast is one-to-many, but only to devices that have joined a multicast group. Interested receivers subscribe, and everyone else is left alone.

Multicast is the one candidates struggle to give a real example for. It is used for IPTV distribution, stock price feeds, some video conferencing, and routing protocols such as OSPF, which uses multicast to talk to neighbouring routers. It lets the same stream reach many receivers without being copied into many separate unicast streams or blasted to everyone as a broadcast.

IPv6 has no broadcast at all. It uses multicast for the same jobs.

A port number is a 16-bit number that identifies a specific service or conversation on a device. The IP address finds the machine, and the port finds the application on it. TCP and UDP each have ports 0 to 65535.

Ports are grouped by range. 0 to 1023 are well-known ports for standard services. 1024 to 49151 are registered ports. 49152 to 65535 are dynamic (ephemeral) ports that clients pick automatically for the source side of a connection.

A connection is identified by four values together: source IP, source port, destination IP and destination port. That is how one server on port 443 can handle thousands of clients at once.

Reference: IANA service name and port registry

A LAN (Local Area Network) covers a small area such as a home, office or building. It is usually owned by one organization and is fast and cheap to run, using Ethernet and Wi-Fi.

A WAN (Wide Area Network) connects networks over large distances, such as offices in different cities, using links from service providers. The internet is the largest WAN. WAN links are slower per cost and add latency.

A MAN (Metropolitan Area Network) sits between them. It covers a city or campus area, for example linking several buildings of a university.

The practical difference is who owns the links. On a LAN you own the cables and switches. On a WAN you usually rent connectivity from a provider, so you depend on their reliability and agreements (SLAs). This is also why a WAN link is where you more often apply QoS, VPNs and careful capacity planning.

HTTP status codes are grouped by their first digit:

The family tells you who to look at first. A 4xx says the request was wrong or not allowed. A 5xx says the server (or something behind it) failed.

Common mix-ups: 401 means "not authenticated" (who are you?), while 403 means "authenticated but not allowed". And 502 and 504 usually come from a proxy or load balancer: 502 means the backend gave an invalid response, 504 means the backend took too long.

Reference: MDN - HTTP response status codes

A routing table is the list a router (or any host) uses to decide where to send each packet next. Each entry says, in effect, "to reach this destination network, send packets out this interface, to this next hop".

Typical columns: destination network and prefix, next-hop address, outgoing interface, and a metric (a cost used to compare routes). Entries come from three sources: directly connected networks, static routes an admin added, and routes learned from dynamic routing protocols.

A special entry is the default route, 0.0.0.0/0, which matches anything with no more specific route. That is the "everything else goes to the ISP" rule.

You can see a host's table with ip route on Linux or route print on Windows. When troubleshooting "I can reach some networks but not others", the routing table is one of the first places to look, because a missing or wrong entry is a very common cause.

Both are radio bands used by Wi-Fi, with different trade-offs.

2.4 GHz reaches farther and passes through walls better, but it is slower and more crowded. It has only three non-overlapping channels in many regions (1, 6 and 11), and shares the band with microwaves, Bluetooth and many neighbours' networks.

5 GHz is faster and has many more channels, so it is usually less congested. Its drawback is shorter range and weaker wall penetration.

Newer Wi-Fi 6E and Wi-Fi 7 devices can also use the 6 GHz band, which is even less crowded but has shorter range still.

A practical rule: use 5 GHz (or 6 GHz) for speed when you are near the access point, and keep 2.4 GHz for far-away rooms and simple devices such as smart plugs that only support it. Most modern access points offer both at once, and many clients choose automatically.

SSH (Secure Shell) gives you a remote command line on another machine, over an encrypted connection, usually on TCP port 22. Telnet does the same job but sends everything, including usernames and passwords, in plain text.

Anyone on the path between you and the server can read a Telnet session with a simple packet capture. With SSH, the traffic is encrypted, and the server proves its identity with a host key, so you can detect an impostor.

SSH also does more than remote shells. It can transfer files (SCP and SFTP) and create tunnels for other traffic (port forwarding).

For logins, key-based authentication is stronger than passwords. You keep a private key and put the public key on the server, so there is no password to guess. A good practice is to disable password login and root login on servers exposed to the internet.

The loopback address is a special address that always points back to the device itself. Traffic sent to 127.0.0.1 never leaves the machine and never touches a physical network card. The name localhost normally resolves to it. The whole 127.0.0.0/8 block is reserved for this, and IPv6 uses ::1.

It is used to test and run local services. A developer runs a web server and visits http://localhost:8080, and processes on one machine can talk to each other over TCP without any real network.

It is also a quick check that the TCP/IP stack on your machine works. If ping 127.0.0.1 fails, the problem is the local network software, not the cable or the wider network.

A common gotcha: a service bound only to 127.0.0.1 accepts local connections only. If other machines must reach it, it needs to listen on a real interface address or on 0.0.0.0, which means "all interfaces". Many "it works on my machine but not from outside" problems come from exactly this.

In DNS, TTL (Time to Live) is the number of seconds a resolver may keep a record in its cache before it must ask again. It is set per record by the domain owner. This is different from the IP packet TTL, which counts router hops.

A longer TTL (say 24 hours) means fewer lookups, faster answers for users and less load on your DNS servers. A shorter TTL (say 60 seconds) means changes spread quickly, but resolvers ask more often.

That trade-off is why TTL matters when you change a record. If an A record has a 24-hour TTL and you change the IP address, some users may keep being sent to the old address for up to a day, because their resolvers cached the old answer.

The standard trick before a planned change is to lower the TTL ahead of time, wait at least as long as the old TTL, make the change, and raise the TTL again later.

A topology is the layout of how devices are connected.

• Bus: all devices share one cable. Cheap, but one break takes down the network. Obsolete for LANs.
• Ring: each device connects to two neighbours in a loop. It is mostly historic in LANs, though rings are still used in some metro and industrial networks.
• Star: every device connects to one central switch. This is the standard for modern Ethernet LANs. It is easy to manage and one broken cable only affects one device, but the central switch is a single point of failure.
• Mesh: devices have multiple links to each other. A full mesh has a link between every pair, which is very resilient but expensive. A partial mesh is common between routers and in data center and wireless mesh designs.

Real networks combine them. A typical office is a star at each floor, with those stars linked in a partial mesh or a tree to a core, with redundant links for reliability.

The interview point: name the trade-off. More links mean more resilience and more cost and complexity.

ICMP (Internet Control Message Protocol) is a Layer 3 helper protocol that carries error and diagnostic messages between devices. It does not carry application data.

Common uses:

• Echo request and reply: this is ping.
• Destination Unreachable: a router or host tells the sender a packet could not be delivered.
• Time Exceeded: sent when a packet's TTL reaches zero. traceroute uses it to discover each hop.
• Fragmentation Needed: part of Path MTU Discovery.

It is not a transport protocol like TCP or UDP and has no ports.

Security teams sometimes block ICMP entirely, which is a mistake. Blocking everything breaks Path MTU Discovery and makes troubleshooting much harder. A better approach is to allow the needed message types, and rate limit the rest.

Remember that a failed ping does not always mean a host is down. Many hosts and firewalls simply do not answer echo requests.

TCP/IP is the model the real internet runs on. OSI is a more detailed reference model used for teaching and troubleshooting.

TCP/IP has four layers: Link, Internet, Transport and Application. It merges OSI's Physical and Data Link layers into one Link layer, and merges Session, Presentation and Application into one Application layer.

You can see the difference in how people talk. Nobody deploys a "session layer", but everybody deploys IP, TCP and HTTP, which are TCP/IP concepts.

Interviewers use this question to check that you see OSI as a framework and not as an exact description of running software. Someone who insists real traffic passes through a separate "session layer" process has memorized the diagram without understanding what it represents.

Reference: RFC 1122 - Requirements for Internet Hosts

TCP is connection-oriented. It does a handshake, guarantees delivery with acknowledgments and retransmission, and keeps data in order. The cost is extra overhead and latency.

UDP is connectionless. It sends datagrams with no handshake, no delivery guarantee and no ordering. It is faster and lighter, and leaves any reliability to the application.

Choose UDP when a late packet is worse than a lost one. Live video calls, VoIP and online games use it, because resending an audio frame half a second late is useless. You would rather skip it and stay in real time. DNS also uses UDP by default for small one-round-trip queries, and falls back to TCP for large responses.

The common wrong answer is "UDP is just a worse TCP". It is a different trade-off, and choosing the wrong one for the workload is the real mistake. Modern protocols like QUIC (used by HTTP/3) build their own reliability on top of UDP.

Reference: RFC 768 - User Datagram Protocol

A /26 leaves 6 bits for hosts (32 - 26 = 6), so there are 2^6 = 64 addresses in total. Subtract 2 for the network address and the broadcast address, which leaves 62 usable hosts.

• Network address: 192.168.10.0
• Usable range: 192.168.10.1 to 192.168.10.62
• Broadcast address: 192.168.10.63

A quick method: the block size is 256 - 192 = 64, so subnets start at .0, .64, .128 and .192. The broadcast address is the last address before the next block starts.

Interviewers ask this live because it is easy to fake on paper and hard to fake on the spot. The trap is forgetting the two reserved addresses. Answering "64" shows you know the formula but not why two addresses cannot be given to hosts.

DNS translates human-readable domain names into IP addresses.

A recursive resolver is the service your device actually asks, such as your ISP's DNS or a public one like 1.1.1.1 or 8.8.8.8. It does all the work of finding the answer for you and caches the result.

An authoritative nameserver is the source of truth for a specific domain. It holds the real DNS records for, say, example.com, and only answers for zones it is responsible for.

When the resolver has no cached answer, it walks the hierarchy: it asks a root server who handles .com, asks the .com server who handles example.com, then asks that authoritative server for the record.

This matters when troubleshooting. If a site is unreachable, you need to know whether it is a caching problem at the resolver or wrong records at the authoritative server, because the fixes are completely different.

Reference: Cloudflare - What is DNS?

DHCP (Dynamic Host Configuration Protocol) automatically gives devices an IP address and network settings (subnet mask, gateway, DNS servers) when they join a network, so nobody configures addresses by hand.

The exchange is remembered as DORA:

• Discover: the client broadcasts a request for any DHCP server.
• Offer: a server proposes an IP address and lease details.
• Request: the client broadcasts that it accepts that specific offer.
• Acknowledge: the server confirms the lease and the client starts using the address.

Interviewers like this because it tests whether you know why it uses broadcasts. The client has no IP address yet, and there may be several DHCP servers making offers. The Request is broadcast so the servers that were not chosen know to withdraw their offers.

On bigger networks, a DHCP relay (IP helper) forwards these broadcasts across routers to a central server, since broadcasts do not cross subnet boundaries.

Reference: RFC 2131 - Dynamic Host Configuration Protocol

A 169.254.x.x address is APIPA (Automatic Private IP Addressing), also called a link-local address. The device failed to get an address from DHCP and gave itself a fallback address. It only works for talking to other devices on the same local segment, and has no route to the internet.

The root cause is almost always that the DHCP server cannot be reached. Possible reasons:

• The DHCP server is down, or its address pool is full.
• The cable or Wi-Fi link is faulty at a lower layer.
• A VLAN or switch port misconfiguration blocks DHCP broadcasts.
• On a larger network, the DHCP relay (IP helper) is not forwarding requests.

So chase the DHCP path. The trap is treating this as a DNS or website problem when the device never finished its basic IP configuration.

A VLAN (Virtual LAN) splits a physical switch, or a set of switches, into several separate logical networks. Each one is its own broadcast domain. Frames are tagged (802.1Q) so the switches know which VLAN they belong to.

Devices in different VLANs cannot talk to each other at Layer 2, even on the same switch. They need a router or a Layer 3 switch to route between VLANs.

Why use them instead of more hardware:

• Cost and flexibility. You can group finance PCs, guest Wi-Fi and VoIP phones on shared hardware, and move a device to another network with a config change instead of new cabling.
• Smaller broadcast domains. Broadcast traffic, and broadcast storms, cannot spread beyond one VLAN.
• Security. You can apply different rules to each VLAN without changing the physical layout.

A common mistake is thinking a VLAN is a security boundary on its own. It separates traffic, but the real policy is enforced where inter-VLAN traffic is routed, usually by a firewall or ACLs.

Reference: IEEE 802.1Q

ARP spoofing (or ARP poisoning) is when an attacker sends forged ARP replies saying their own MAC address belongs to someone else's IP address, usually the gateway's. Other devices then send traffic meant for the gateway to the attacker. ARP has no authentication, so any device on the same broadcast domain can lie.

It is dangerous because it enables a man-in-the-middle attack. The attacker can read, log or change traffic before passing it on, or simply drop it for a denial of service.

Defences include:

• Dynamic ARP Inspection on managed switches, which checks ARP replies against known IP-to-MAC bindings.
• Static ARP entries for critical devices such as the gateway.
• Segmentation, so one poisoned broadcast domain affects fewer devices.
• End-to-end encryption such as HTTPS, which keeps intercepted data unreadable.

STP prevents Layer 2 loops in a switched network that has redundant links. Redundancy is good for reliability, but a loop at Layer 2 causes a broadcast storm. Ethernet frames have no TTL like IP packets do, so frames circle forever and are copied at every hop, quickly saturating the network.

STP solves this in three steps:

1. The switches elect a root bridge.
2. Each switch works out its best path to the root.
3. Any port that would create a loop is put into a blocking state. It does not forward traffic but keeps listening.

If an active link fails, STP recalculates and moves a blocked port to forwarding to restore connectivity.

The trade-off to mention is convergence time. Classic STP can take 30 to 50 seconds to react to a change, which is why faster variants such as Rapid STP (802.1w) are used in practice.

Reference: IEEE 802.1D

A forward proxy sits in front of clients and makes requests on their behalf. The server at the other end sees the proxy, not the client. It is used for content filtering, caching, or giving clients on a private network one controlled exit to the internet.

A reverse proxy sits in front of servers and receives requests on their behalf. The client sees the proxy, not the real backend. It is used for load balancing, TLS termination, caching and hiding internal infrastructure.

The whole distinction is who is being represented. A forward proxy represents the client, a reverse proxy represents the server.

Nginx and HAProxy are common reverse proxies. Squid is a common forward proxy. A good extra point: a CDN or a cloud load balancer is, in effect, a reverse proxy run by someone else.

Reference: Cloudflare - What is a reverse proxy?

A firewall controls which traffic may pass, using rules that match things like source and destination IP, port and protocol.

A stateless firewall checks each packet on its own, with no memory of earlier packets. You must write rules for both directions of a conversation, because it cannot tell that an inbound packet is a reply to something you sent out.

A stateful firewall tracks active connections. It automatically allows return traffic that belongs to a connection it already approved, with no separate rule needed. That is both easier and safer. An attacker cannot just craft a packet with the right port numbers to slip through, because it has to belong to a tracked connection.

Almost all modern firewalls, including the one in a typical home router, are stateful. A modern next-generation firewall also inspects application content, but the stateful idea is the foundation.

A VPN (Virtual Private Network) creates an encrypted tunnel between your device and a VPN server. Anyone watching the network in between, such as coffee shop Wi-Fi or your ISP, sees only encrypted data. The VPN server decrypts it and sends it on to the real destination, so it appears to come from the VPN server's location.

The privacy benefit is about that middle hop. It hides your traffic contents and real IP address from the local network and ISP, and hides which sites you visit from them.

What it does not do is make you anonymous. The VPN provider can see what your ISP would normally see, so you are shifting trust, not removing it. "A VPN makes you anonymous online" is a common overstatement worth correcting.

Common protocols are IPsec, OpenVPN and WireGuard. Companies also use VPNs for the other main purpose: giving remote staff secure access to internal resources.

IPv4 uses 32-bit addresses, about 4.3 billion in total, a number the internet has already outgrown. IPv6 uses 128-bit addresses, which is effectively unlimited. It also simplifies header processing, supports automatic address configuration, and removes the need for NAT, because every device can have its own globally unique address.

Adoption has been slow for a few reasons:

• IPv4 and IPv6 are not directly interoperable. A pure IPv6 host cannot talk to a pure IPv4 host without translation.
• Moving needs dual-stack (running both) or translation mechanisms.
• NAT let IPv4 last far longer than anyone expected, so there was never one moment forcing a hard cutover.

Most networks today run dual-stack, not a clean IPv6-only setup. An IPv6 address looks like 2001:db8::1, and the usual home allocation is a /64 per network.

Reference: RFC 8200 - IPv6 Specification

QoS is a set of techniques for giving some traffic priority over other traffic when a link is congested, instead of treating every packet equally on a first-come, first-served basis.

It works by classifying traffic (by port, protocol or a DSCP tag) and then applying queuing and scheduling rules that give priority traffic more bandwidth, lower latency, or both.

You need it when a link does not have enough headroom for everything at once and some traffic is more sensitive than the rest. The textbook case is prioritizing VoIP or video calls over a large file backup, so a call does not stutter when a backup starts.

On a link that is rarely full, QoS has nothing to do. The common wrong answer is treating it as a way to speed up a network. It decides who goes first when the network is already busy. It also only helps where you control the path, since marks are often ignored or cleared across the public internet.

A static route is entered by an administrator and never changes unless someone edits it. The router has no idea whether that path is still working.

A dynamic routing protocol such as OSPF, EIGRP or BGP lets routers discover the topology, share reachability with neighbours and recalculate paths automatically when something changes.

Static routing is a deliberate choice in small or simple setups, such as a branch office with one internet connection, where there is only one path anyway. It is predictable and has no protocol overhead. It is also common for a default route ("everything else goes this way") alongside dynamic routing for internal networks.

The trap is assuming dynamic is always better. It adds complexity and risk. A misconfigured or compromised router can inject bad routes. When the topology never changes, that extra risk is not worth it.

BGP (Border Gateway Protocol) exchanges reachability information between autonomous systems (ASes). These are the large networks run by ISPs, cloud providers and big organizations. Other routing protocols work inside one network, and BGP works between networks.

It is what lets a packet cross a dozen independently run networks to reach a server on the other side of the world. No central authority computes every path. Each AS announces which address ranges (prefixes) it can reach, and picks routes based on policies it controls, which are largely business relationships and not just shortest distance.

That is also why BGP mistakes can cause visible, sometimes global outages. If a network accidentally announces routes it should not, traffic can be pulled into the wrong place or dropped. Protections such as RPKI route validation are being adopted to reduce this.

Reference: Cloudflare - What is BGP?

A broadcast domain is the set of devices that all receive a broadcast frame sent by any one of them. Switches forward broadcasts everywhere within the same Layer 2 network or VLAN. Routers stop them from crossing into another network.

A collision domain is the set of devices whose transmissions can collide on a shared medium. This was a big problem with hubs, where every device shared one collision domain. A switch gives each port its own collision domain, since each link is point-to-point and full duplex.

So switches mostly removed collisions, but every device still shares a broadcast domain unless you split it with VLANs or a router. That is why broadcast domain size is still a live design question on modern networks. Large flat networks suffer from lots of broadcast noise and wider blast radius.

Symmetric encryption uses one shared key to both encrypt and decrypt. It is fast, but both sides must already hold the same secret, which raises the question of how to share it safely.

Asymmetric encryption uses a key pair: a public key anyone can use, and a private key only the owner holds. It solves the key-sharing problem but is much slower.

TLS, which secures HTTPS, uses both. The handshake uses asymmetric techniques to agree on a shared secret without sending it in the clear, and then the bulk of the data is protected with fast symmetric encryption for the rest of the session. Asymmetric keys are also used to prove identity through certificates and signatures.

Knowing this hybrid approach is usually what separates a surface answer from one that shows you understand how HTTPS works end to end.

Reference: Cloudflare - What happens in a TLS handshake?

A load balancer spreads incoming traffic across several backend servers, so no single server is overwhelmed and the service keeps working if one backend fails.

A Layer 4 load balancer decides using IP address and port only. It does not look inside the data, it just forwards TCP or UDP connections. That makes it fast and protocol-agnostic.

A Layer 7 load balancer works at the application layer and can read the request itself: HTTP headers, cookies and URL paths. That allows smarter decisions, such as sending /api/* to one pool and /static/* to another, or keeping a user on one server with a session cookie.

The trade-off is cost. Layer 7 has to terminate and inspect the connection, often decrypting TLS, which uses more processing than Layer 4's simple forwarding. Choose based on whether you really need content-aware routing or just raw distribution.

Most load balancers also run health checks and stop sending traffic to a backend that fails them.

MTU (Maximum Transmission Unit) is the largest packet size a link can carry without splitting it. 1500 bytes is the usual value for Ethernet.

If a packet is bigger than a link's MTU, one of two things happens:

• If fragmentation is allowed (IPv4), the router splits the packet into fragments that are reassembled at the destination.
• If the packet has the "Don't Fragment" flag, the router drops it and should send back an ICMP "Fragmentation Needed" message, so the sender retries with a smaller size. This is Path MTU Discovery. IPv6 routers never fragment, so IPv6 depends on it completely.

The classic real-world failure is a firewall blocking that ICMP message for "security". The sender never learns it must shrink its packets. Connections then hang or time out for large payloads, while small packets like a basic ping work fine. It is hard to diagnose because everything looks reachable until you send something big enough. VPN and tunnel overhead are common triggers because they reduce the usable MTU.

Reference: RFC 1191 - Path MTU Discovery

A CDN (Content Delivery Network) is a set of servers placed in many locations that cache copies of content close to users, so every request does not travel back to one origin server. Users are sent to a nearby edge server, often through DNS or Anycast.

The latency gain comes partly from physics. A shorter distance means a shorter round trip. And if the content is already cached at the edge, it also skips the work the origin would do to build a fresh response.

CDNs do more than speed things up:

• They reduce load on the origin server.
• They add resilience. If the origin is briefly down, cached content can still be served.
• They help absorb traffic spikes and some DDoS attacks.

The usual catch is cache control. Dynamic or personalized content cannot be cached the same way, and stale content after an update is solved with cache expiry settings or explicit purges.

Reference: Cloudflare - What is a CDN?

A Layer 2 switch forwards frames by MAC address within one broadcast domain or VLAN. It knows nothing about IP addresses or routing.

A Layer 3 switch does all that, and also has routing built in. It can forward traffic between VLANs or subnets at wire speed, without a separate router.

This matters because inter-VLAN routing is very common in offices and data centers, for example a finance VLAN reaching a shared printer VLAN. Doing it in switch hardware is much faster than sending every packet out to a router and back.

The trade-off is cost and configuration effort. Layer 3 switches are pricier and need more setup, so a small network with a single flat VLAN often does not need one.

A typical design has Layer 2 switches at the edge and Layer 3 switching at the distribution or core, where routing happens.

A man-in-the-middle (MITM) attack is when an attacker secretly sits between two communicating parties and can read or change the traffic without either side knowing. A classic example is a rogue Wi-Fi access point that intercepts everything from anyone who connects.

TLS protects against this mainly through certificate-based authentication. When you connect to a site over HTTPS, the server presents a certificate signed by a trusted Certificate Authority. That proves the server is who it claims to be, and not an interceptor pretending.

Together with the encryption TLS provides after the handshake, an attacker in the middle can see that a connection exists, but cannot read its contents or impersonate the real server without a valid certificate for that domain.

This is why browsers show hard warnings for invalid or self-signed certificates. That warning is the one signal standing between the user and a possible MITM. Training users to click past it removes the protection.

Reference: Cloudflare - What is a man-in-the-middle attack?

A routing loop happens when two or more routers each think the other is the right next hop for a destination, so a packet bounces between them and never arrives. It is usually caused by a misconfiguration, or by timing problems while the network settles after a change.

TTL keeps this from being permanent. Every IP packet has a TTL field that starts at some value and drops by 1 at each router. When it reaches zero, the router discards the packet and sends back an ICMP "Time Exceeded" message. A looping packet is therefore dropped after a bounded number of hops, instead of circling forever.

TTL does not prevent the loop itself. That is the job of loop-avoidance features inside routing protocols, such as split horizon. TTL just limits the damage to short-lived packet loss and wasted bandwidth. In IPv6 the same field is called the hop limit.

traceroute uses the same mechanism on purpose, sending packets with small TTL values to reveal each router along the path.

Reference: RFC 791 - Internet Protocol

Jitter is the variation in latency between consecutive packets. It is not how slow the network is on average, but how inconsistent it is from one packet to the next. A link can have acceptable average latency and still have bad jitter if some packets arrive quickly and others arrive late, with no pattern.

It matters for real-time audio and video because they need packets to arrive at a steady rhythm to rebuild a smooth stream. The receiver uses a small jitter buffer to smooth out minor timing variation before playback.

If jitter is larger than the buffer can absorb, you get audio that cuts out or crackles, and video that stutters, even when a simple average latency or bandwidth test looks healthy. That is why "my ping average is fine but my calls sound choppy" is a real and common complaint.

Average latency and jitter are different numbers, and real-time applications depend on the second one staying low. A bigger jitter buffer reduces choppiness but adds delay, which is the trade-off.

Both limit how fast a sender transmits, but they protect different things.

Flow control protects the receiver. The receiver tells the sender how much data it can accept right now, using the receive window in each acknowledgment. If the receiver's buffer fills up, it advertises a smaller window, and the sender slows down or pauses.

Congestion control protects the network in between. The sender keeps its own congestion window and grows it carefully. It starts small and doubles each round trip (slow start), then grows more slowly (congestion avoidance). When it sees loss or delay signals, it shrinks the window. Algorithms such as CUBIC and BBR differ in how they do this.

The amount a sender may have in flight is limited by the smaller of the two windows.

The trap is mixing them up. A slow transfer to a fast, healthy receiver over a lossy link is a congestion-control story. A fast network where the receiver application reads data slowly is a flow-control story.

Reference: RFC 5681 - TCP Congestion Control

A TCP connection closes with a four-step exchange, because each direction is closed separately:

1. One side sends a FIN, meaning "I am done sending".
2. The other side replies with an ACK.
3. When it is also done, it sends its own FIN.
4. The first side replies with a final ACK.

The side that closes first then enters TIME_WAIT and stays there for a short time (often about 60 seconds on Linux, defined as twice the maximum segment lifetime). It exists for two reasons: to resend the final ACK if it was lost, and to make sure old delayed packets from this connection die out before the same address and port pair is reused.

A server that handles huge numbers of short connections can accumulate many TIME_WAIT sockets. That is normal and usually harmless. It only becomes a problem if a client runs out of source ports to the same destination.

The fixes are to reuse connections (keep-alive, connection pooling) rather than trying to shorten TIME_WAIT blindly.

Reference: RFC 9293 - TCP connection termination

TCP numbers every byte it sends (sequence numbers), and the receiver acknowledges what it has received in order. That gives the sender two ways to notice loss.

• Timeout. If the sender does not get an acknowledgment within a retransmission timeout (RTO), it resends the data. The RTO is calculated from measured round-trip times, and is doubled after each failed attempt.
• Duplicate ACKs (fast retransmit). If one segment is lost but later ones arrive, the receiver keeps acknowledging the last in-order byte. When the sender sees three duplicate ACKs, it assumes that segment was lost and resends it right away, without waiting for the timer.

Selective acknowledgments (SACK) let the receiver say exactly which pieces it already has, so the sender resends only the missing ones.

Loss also tells TCP that the network is congested, so it reduces its sending rate. That is why even small packet loss can hurt throughput a lot, and why "just 1 percent packet loss" can make a transfer feel very slow.

In a capture, retransmissions and duplicate ACKs are the first things to look for when a connection feels slow.

Reference: RFC 6298 - Computing TCP's Retransmission Timer

Both are routing protocols, but they work at different levels.

OSPF is an interior gateway protocol (IGP) used inside one organization's network. It is link-state: every router learns the full map of the network (grouped into areas) and runs the shortest path algorithm to work out the best routes. It converges quickly and chooses routes by a cost, usually based on link bandwidth.

BGP is an exterior gateway protocol used between autonomous systems, such as between your company and ISPs, or between ISPs. It is path-vector: routes carry the list of networks (AS path) they crossed. BGP chooses routes by policy, not just distance, so business rules can decide which path wins.

In short, OSPF finds the best path inside a network, and BGP decides how networks connect to each other.

Many organizations use both. OSPF runs internally, and BGP connects to the ISP or the cloud. Large data centers also use BGP internally because it scales and has fine control.

Reference: RFC 2328 - OSPF Version 2

A router applies three checks in order.

1. Longest prefix match. The most specific matching route wins, always. If you have 10.0.0.0/8 and 10.1.2.0/24 and the destination is 10.1.2.5, the /24 is used, even if the /8 looks "better" in every other way.
2. Administrative distance. If routes with the same prefix come from different sources, the source that is more trusted wins. On Cisco devices, typical values are: connected 0, static 1, eBGP 20, OSPF 110, RIP 120. A lower number wins.
3. Metric. Within the same routing protocol, the lowest metric (such as OSPF cost) wins. If there is a tie, the router may load-balance across the equal paths.

The first rule is the one candidates forget, and it is the most important. It also explains many odd behaviours, such as a more specific route from a misconfigured router pulling traffic away, which is how some BGP hijacks work.

When troubleshooting, show ip route <address> or ip route get <address> tells you which route was actually chosen.

Link aggregation bundles several physical links between two devices into one logical link, so you get more total bandwidth and redundancy. LACP (Link Aggregation Control Protocol, from IEEE 802.1AX) negotiates the bundle automatically and detects when a member link fails, so traffic continues on the remaining links.

The common misconception is that bundling four 1 Gbps links gives one 4 Gbps pipe. It does not. Traffic is spread across the links by a hash, usually of addresses and ports, and each individual flow stays on one link. So one large file transfer between two hosts is still limited to the speed of one member link. The benefit shows up with many different flows.

Another point: because it uses a hash, uneven traffic can load one link more than the others.

It also gives resilience. If one cable or port fails, the bundle keeps working at reduced capacity, with no spanning tree recalculation. Some switch vendors support multi-chassis versions (MLAG, vPC) so the links can go to two different switches.

Port security limits which devices may use a switch port, based on MAC addresses. You can set a maximum number of MAC addresses per port, define which ones are allowed (manually or by "sticky" learning), and choose what happens on a violation: drop the traffic, drop and log, or shut the port down.

It helps against:

• Someone plugging an unauthorized device into a wall socket in a meeting room or lobby.
• MAC flooding. An attacker sends thousands of frames with fake source MACs to fill the switch's address table, so the switch starts flooding traffic out of all ports like a hub, which lets the attacker sniff it.
• Rogue switches or hubs connected to a port that is meant for one device.

It is not a strong identity control, because MAC addresses can be spoofed. For real access control, use 802.1X, which authenticates the user or device.

Related switch protections work together with it: DHCP snooping (blocks rogue DHCP servers), Dynamic ARP Inspection, and BPDU guard on edge ports so nobody can interfere with spanning tree.

A default gateway is a single point of failure. If that router dies, every device in the subnet loses access to everything outside it, even if there is a second router available. Devices cannot be told to switch gateways quickly, because the gateway address is configured on each of them.

First-hop redundancy protocols solve this. Two or more routers share a virtual IP address (and a virtual MAC). Devices use the virtual IP as their gateway. One router is the active (VRRP calls it master) and answers traffic. The others stand by, and take over the virtual IP within seconds if the active router stops sending its hello messages.

HSRP is Cisco's protocol, VRRP is the open standard (RFC 5798), and GLBP is a Cisco variant that also shares load.

The devices do not notice anything except a brief pause, because their configured gateway address never changed.

A useful detail: priorities and preemption decide who becomes active. A typical mistake is having the standby router with a better uplink, so after a failover the traffic takes a poor path.

Reference: RFC 5798 - VRRP Version 3

PoE sends electrical power over the same twisted-pair Ethernet cable that carries data. That lets you power devices such as IP phones, wireless access points, IP cameras and some sensors, without a separate power outlet near them.

The switch (or a PoE injector) is the power source. Standards define the power level:

What to check before deploying:

• Total power budget. A switch might have 24 PoE ports but only enough power supply for some of them at full load. Adding up the devices matters.
• Cable length and quality. The 100 metre limit still applies, and poor cable loses power on the way.
• Device class. Make sure the device's needs match the standard on the port.
• Backup power. If a UPS supports the switch, it also keeps the phones and access points alive in an outage.

A common symptom of an exhausted budget is that some devices simply do not power on.

Wi-Fi standards come from IEEE 802.11 and are now given simple names:

Newer standards mainly improve speed and how well the network copes with many devices at once.

On security, WPA2 uses a pre-shared key handshake. If an attacker captures that handshake, they can try passwords offline at high speed, so weak passwords fall quickly. WPA3 replaces it with SAE (Simultaneous Authentication of Equals), which resists offline guessing and gives forward secrecy, so a later password leak does not expose past traffic. WPA3 also improves open networks with encryption (Enhanced Open).

Both have personal (shared password) and enterprise (802.1X with RADIUS) modes. For businesses, enterprise mode is the right choice, as covered in the 802.1X question.

Both filter traffic in a VPC, but at different levels and in different ways.

Stateful means return traffic for an allowed connection is automatically allowed. A security group that allows inbound port 443 does not need an outbound rule for the replies. A network ACL is stateless, so you must allow the return traffic yourself, including the ephemeral port range.

In practice, security groups do most of the work. They can reference other security groups (for example "allow the app tier to reach the database tier"), which is much cleaner than IP lists. Network ACLs are used as a coarse extra layer, or to block specific addresses, since security groups cannot deny.

A common debugging trap is a connection that works one way but not back, caused by a NACL missing the ephemeral port rule.

Reference: AWS - Infrastructure security in Amazon VPC

The difference is routing, not the name. A public subnet has a route to an internet gateway, and its instances can have public IP addresses, so they can be reached from the internet if security rules allow it. A private subnet has no such route. Its instances have only private addresses and cannot be reached directly from outside.

Private instances still often need to go out, for example to download updates. They do this through a NAT gateway placed in a public subnet. The private subnet's route table sends internet-bound traffic to the NAT gateway, which translates the source address to its own public address. Replies come back through it. Inbound connections from the internet are still not possible.

A standard layout is: load balancers in public subnets, application servers and databases in private subnets, spread across several availability zones.

Cost and resilience points worth mentioning: NAT gateways are zonal and charged by hour and by data, so teams use one per zone for resilience. And private access to cloud services (such as object storage) can use VPC endpoints, which avoid the NAT gateway and keep traffic on the provider's network.

Both watch network traffic (or host activity) for signs of attack, using signatures of known threats and sometimes behaviour analysis.

An IDS (Intrusion Detection System) is passive. It sits off to the side, usually receiving a copy of traffic from a mirror port, and raises alerts. It cannot stop anything itself.

An IPS (Intrusion Prevention System) sits inline, in the path of the traffic, so it can block malicious packets, reset connections or drop sessions as it sees them.

The trade-offs follow from that:

• An IPS can stop attacks in real time, but because it is in the path, a bad rule can block legitimate traffic, and if it fails it can disrupt the network.
• An IDS cannot cause an outage, but someone has to act on the alerts.

False positives are the main operational problem for both. Teams often run a new rule set in detection mode first, tune it, and only then enable blocking.

Many modern firewalls include IPS features, so the two ideas are often delivered together in one device.

A DMZ (demilitarized zone) is a separate network segment that holds services which must be reachable from the internet, such as web servers, mail gateways or reverse proxies. It sits between the internet and the internal network, with a firewall controlling traffic in each direction.

The idea is to limit damage. Public-facing servers are the most likely to be attacked and compromised. If they were on the internal network, an attacker who broke in would have direct access to everything. In a DMZ, the firewall rules strictly limit what the DMZ can reach inside. For example, the web server may only talk to one database port on one internal host, and nothing else.

Typical rules: internet to DMZ is allowed only on needed ports, DMZ to internal is tightly limited, and internal to DMZ is allowed for management. Direct internet to internal access is denied.

In cloud environments, the same idea appears as separate subnets and security groups, instead of a physical DMZ.

The traditional model trusts the inside of the network. If you are in the office or on the VPN, you are treated as trusted, and a firewall guards the edge. The weakness is that once an attacker gets inside, for example through a phished laptop, they can move around freely.

Zero trust assumes the network is hostile everywhere and says "never trust, always verify". Every request is checked on its own, whatever network it comes from.

Core ideas:

• Strong identity. Verify the user, usually with multi-factor authentication.
• Device posture. Check the device is managed, patched and healthy.
• Least privilege. Give access to a specific app or resource only, not to a whole network.
• Micro-segmentation. Split the network into small zones so a compromise stays contained.
• Continuous checks and logging, not a one-time login.

In practice it is often delivered through identity-aware proxies and ZTNA (zero trust network access) products, in place of a broad VPN.

It is a strategy and not a single product. A balanced answer notes it takes time to adopt, and most organizations move toward it step by step.

SNMP (Simple Network Management Protocol) lets a monitoring system collect information from network devices and sometimes change their settings. A manager polls agents on devices (UDP 161) for values such as interface traffic, CPU load and errors, which are identified by OIDs defined in MIBs. Devices can also send unsolicited traps (UDP 162) when something happens, such as a link going down.

The security problem is in the older versions. SNMPv1 and v2c use a "community string" that works like a password, and it is sent in plain text. Anyone who sees it can read device data, and if a write community is configured, change configuration.

SNMPv3 adds proper authentication and optional encryption, with per-user access control. That is why it is the recommended version.

Good practice: use v3, restrict which IPs may query devices, never leave default community strings such as "public", and set read-only access unless write is really needed.

Many teams now also use streaming telemetry and APIs for modern devices, but SNMP is still the common baseline for monitoring almost any network gear.

NTP (Network Time Protocol, UDP 123) keeps device clocks synchronized to a reliable time source. It seems minor, but a lot depends on it:

• Logs and troubleshooting. To trace an incident across firewalls, servers and switches, timestamps must line up. If clocks differ by minutes, the story is impossible to piece together.
• Authentication. Kerberos rejects requests if clocks differ by more than about five minutes by default. Time-based one-time passwords also depend on correct time.
• Certificates. TLS checks that a certificate is within its validity dates. A device with the wrong clock may reject a valid certificate, or accept an expired one.
• Scheduled jobs and distributed systems, which can behave badly with clock drift.

NTP uses a hierarchy of "strata". Stratum 0 devices are reference clocks such as GPS, and each level of servers below syncs from the one above. Organizations usually run a few internal NTP servers that sync with trusted external sources, and point everything else at them.

A classic symptom: "everyone gets certificate errors on one device". Check its clock first.

Reference: RFC 5905 - Network Time Protocol Version 4

They solve different problems, and it is a common mistake to mix them up.

DNSSEC protects the authenticity of DNS answers. The domain owner signs records with cryptographic keys, and a validating resolver checks the signatures. This catches forged or tampered answers, such as cache poisoning. It does not encrypt anything. Anyone can still see which names you look up.

DoT and DoH protect the privacy of the query on the way from your device to the resolver, by encrypting it. DoT uses its own port (853). DoH sends DNS inside normal HTTPS on port 443, so it is harder to tell apart from web traffic. They stop your ISP or someone on the same Wi-Fi from reading or changing your lookups.

Neither hides your queries from the resolver itself, so you are choosing whom to trust. And DoH/DoT do not prove that an answer is correct, only that it was not altered in transit between you and the resolver.

The best answer notes they complement each other: DNSSEC for integrity of the data, DoT or DoH for confidentiality of the connection.

Reference: RFC 8484 - DNS Queries over HTTPS

When a site presents its certificate, the browser runs several checks:

1. Chain of trust. The certificate must be signed by a certificate authority (CA), possibly through one or more intermediate CAs, that leads up to a root CA the browser or operating system already trusts.
2. Hostname match. The name you typed must appear in the certificate's Subject Alternative Name list.
3. Validity dates. The certificate must not be expired, or not yet valid.
4. Not revoked. The browser may check revocation status (through OCSP or revocation lists, or built-in lists).
5. Valid signature and allowed use. The certificate's key usage must fit TLS server use.

If any check fails, the browser shows a warning.

A very common real-world error is a missing intermediate certificate. The site's certificate is fine, but the server does not send the intermediate, so some clients cannot build the chain and fail, while others (which cached the intermediate) work. Servers should send the full chain apart from the root.

Another common cause is a wrong system clock on the client, which makes a valid certificate look expired.

Reference: Cloudflare - What is an SSL certificate chain?

VLSM (Variable Length Subnet Masking) means using different subnet sizes inside the same address block, instead of splitting it into equal pieces. Each subnet is given only as many addresses as it needs, so little space is wasted.

Example: you have 10.0.0.0/24 (256 addresses) and need a network of 100 hosts, one of 50, one of 20, and two point-to-point links.

The method:

1. Sort the needs from largest to smallest.
2. Give each the smallest block that fits (including network and broadcast addresses), starting with the largest.
3. Place blocks one after another, aligned to their size.

Allocating the largest first keeps blocks aligned and avoids gaps you cannot use.

Good practice in real designs: leave room to grow, keep a clear plan so subnets can be summarized into larger blocks for routing, and use /31 for point-to-point links where supported to save addresses.

A packet capture shows what is really on the wire, which settles arguments about what is actually sent and received. Typical tools are tcpdump on a server and Wireshark for analysis.

Capture filters decide what gets recorded in the first place. They are efficient, so use them on busy links, but anything you exclude is lost. They use BPF syntax.

Display filters (Wireshark) hide packets that were already captured, so you can change them freely without losing data.

Some useful Wireshark display filters: tcp.analysis.retransmission for resent packets, dns for name lookups, tcp.flags.syn==1 && tcp.flags.ack==0 for new connection attempts.

What to look for: a SYN with no reply (blocked or dropped), a reset (RST) in response (port closed or refused), many retransmissions or duplicate ACKs (loss), long gaps between a request and a response (slow server), and DNS queries that never get answered.

Two cautions: captures may contain sensitive data, so handle them carefully, and capture on the right side, because a capture on the client and a capture on the server together show where a packet disappeared.

IPv6 addresses are 128 bits, written in hexadecimal groups, and :: can replace one run of zeros. The main types:

ARP is replaced by the Neighbor Discovery Protocol (NDP), which uses ICMPv6 and multicast messages to find the link-layer address of neighbours and to find routers.

Address configuration is flexible. With SLAAC (stateless address autoconfiguration), a device builds its own address from the network prefix announced by a router (in a Router Advertisement) plus an interface identifier. DHCPv6 can still be used to hand out addresses or other settings, such as DNS servers, when stricter control is wanted.

A standard LAN gets a /64. A good practical point: because NDP uses ICMPv6, blocking all ICMPv6 breaks IPv6 completely, which is a common firewall mistake.

Reference: RFC 4861 - Neighbor Discovery for IPv6

A traditional MPLS WAN is a private network run by a carrier. Your sites connect to the carrier's network, and traffic is forwarded by labels, with agreed service levels (SLAs) for latency and loss. It is reliable and predictable, but expensive, slow to order for new sites, and usually sends internet-bound traffic from branches back through a central data center.

SD-WAN (software-defined WAN) builds an overlay across whatever links are available: broadband, LTE or 5G, and optionally MPLS. A central controller sets policy, and edge devices measure each link's quality and choose a path for each application. For example, voice may use the best low-jitter link while bulk backups use the cheapest one. It encrypts traffic across the links and can send cloud and SaaS traffic directly out of the branch.

Benefits: lower cost, faster branch deployment, central management and better use of multiple links. Caveats: you depend on the quality of public internet links, which do not carry guarantees, and you still need good security at each branch.

Many companies run a hybrid, keeping MPLS for critical sites and adding SD-WAN over broadband.

Ethernet links can run full duplex (both ends send and receive at the same time) or half duplex (one direction at a time, with collisions). Both ends of a link must agree. A duplex mismatch happens when one end is full duplex and the other half duplex.

It usually happens when one side is hard-coded (for example 100 Mbps full duplex) and the other is left on auto-negotiation. The auto side cannot detect the duplex setting of a fixed side, so it falls back to half duplex.

The symptom is confusing because the link is up and the pings work. But performance is poor, especially with heavy traffic. The half-duplex side sees collisions and late collisions, and the full-duplex side sees CRC and frame errors. Throughput drops and TCP transfers are slow, while light traffic looks fine.

To diagnose, check interface counters on both sides (show interface) for late collisions, CRC errors and runts, and check the negotiated speed and duplex.

The fix is to make both ends match. The modern recommendation is to leave both on auto-negotiation. Hard-code both ends only when needed, such as with very old equipment.

In a hub-and-spoke design, every branch connects to one central site, and branch-to-branch traffic passes through the hub. It is simple to manage, with few tunnels (one per branch), and the hub is a natural place for inspection. The costs are extra latency for branch-to-branch traffic and the hub being a single point of failure and a bandwidth bottleneck.

In a full mesh, every site has a tunnel to every other site. Traffic takes the direct path, and there is no single hub to fail. But the number of tunnels grows fast (n times n-1, divided by 2), so it is harder to configure and run. Dynamic approaches such as DMVPN or SD-WAN build tunnels between spokes only when needed.

Overlapping address ranges break either design. If two sites both use 192.168.1.0/24, a router cannot tell which one a packet is for. Common workarounds are renumbering one site, which is the proper fix, or using NAT between the sites, which makes everything harder to run.

The lesson is to plan address space centrally from the start, and avoid default ranges like 192.168.1.0/24 and 10.0.0.0/24 that people tend to reuse everywhere, especially if you may later connect to partners or acquisitions.

This question connects almost everything you know about networking into one story, which is why it is so popular.

1. DNS resolution. The browser checks its cache, then the OS cache, then asks a configured DNS resolver. If nothing is cached, the resolver walks from the root servers to the TLD servers to the domain's authoritative server.
2. TCP connection. The browser opens a TCP connection to the IP address on port 443 (or 80) with the three-way handshake.
3. TLS handshake. For HTTPS, client and server exchange certificates, agree on a cipher suite and derive session keys before any HTTP data is sent.
4. HTTP request and response. The browser sends the request (method, headers, path). The server returns a status code, headers and a body.
5. Rendering. The browser parses the HTML, finds more resources (CSS, JavaScript, images), requests them, often over the same connection, and renders the page.

You do not need to recite every RFC detail. A strong answer shows how DNS, TCP, TLS and HTTP stack on top of each other, and that a slow page can be caused at any one of these steps. Mentioning that ARP and the default gateway are used to leave the local network earns extra credit.

Reference: MDN - How does the Internet work?

The trap is stopping at "the network is fine because ping works". ICMP echo only proves basic Layer 3 reachability and round-trip time. It says almost nothing about the real HTTP path.

Check, roughly from cheapest to most involved:

• DNS resolution time. A slow resolver delays everything before the connection starts. Time it with dig or nslookup.
• TCP and TLS handshake time to the actual service port. Routers and firewalls may treat ICMP differently from real application traffic.
• Application latency. The backend itself may be slow to build the response, with no network fault at all.
• Packet loss and retransmissions on the real data path. Ping's tiny traffic may not show them, but a page load with many parallel connections will.
• MTU and fragmentation. Large HTTP responses may hit a path with a smaller MTU than ping ever used, causing fragmentation or silent drops.

A tool like curl -w with timing variables splits a request into DNS, connect, TLS, first-byte and total time, which tells you which stage is slow.

State the lesson explicitly: ping tests one narrow thing, and a slow application can have perfect ping while being broken for reasons further up the stack.

NAT gives you a security side effect, not a security feature. That distinction is what a strong answer must draw out.

Because NAT hides private addresses behind one public address, an outsider cannot directly reach an internal device that has not started a connection. There is no route to a private IP from the public internet, so unsolicited inbound traffic has nowhere to land.

But that is accidental, not designed access control, and it breaks down easily:

• Port forwarding deliberately opens a path to an internal device.
• UPnP lets applications open ports automatically, often without the user noticing.
• Outbound connections from a compromised device are not stopped at all. The infected machine starts the session to the attacker, and NAT happily allows it.
• IPv6 typically has no NAT, so every device can have a public address.

The right tool for controlling what traffic is allowed is a firewall with an explicit default-deny policy. NAT making direct inbound access harder is a bonus, not a substitute.

Because wired works, the problem is in the wireless layer, not the wider network. That is useful information, so do not jump straight to "reboot the access point".

Work through the likely causes:

• Channel interference and congestion. Check whether nearby access points (yours or neighbours') use overlapping channels. The 2.4 GHz band has few non-overlapping channels and suffers from microwaves and Bluetooth.
• Physical changes. New equipment, furniture or more people on that floor can reflect or absorb signal.
• Access point load. One AP serving far more clients than it is rated for degrades instead of failing outright.
• Placement and roaming. Drops can happen when a client sits in a weak spot between two APs and roams badly.
• DHCP scope exhaustion. If the wireless VLAN's address pool is too small, clients lose connectivity waiting for a lease, even though the radio link is fine.
• Firmware bugs. Check vendor notes for the AP model. Floor-specific intermittent drops are often a known issue on a hardware batch.

A site survey tool or the controller's client logs will show signal strength, retries and roaming events, which is far better than guessing.

The reasoning to show is elimination in a sensible order, from the most common causes to the rarer ones.

Anycast announces the same IP address from several physical locations at once. The network's normal routing (BGP path selection) then sends each user to whichever announcing location is closest from the network's point of view. No DNS trick or central traffic-steering system is needed.

The difference from a load balancer is architectural. A load balancer is a specific device or service in front of known backends, making per-request decisions. Anycast has no single component making that decision. It relies on internet routing to converge each client on the nearest instance.

That is why it is popular for public DNS resolvers and DDoS mitigation. An attack on one location's address mostly affects only the clients already routed there, and the load is spread across many sites by the network itself.

The trade-off: routing can shift mid-connection, so Anycast suits short, stateless exchanges (DNS) best, and long-lived TCP services need extra design care.

Reference: Cloudflare - What is Anycast?

Split-horizon DNS means the same domain name gives different answers depending on who asks. Internal users get one answer and external users get another. It is built by running two separate zones (or views) for the same domain: an internal one served only to internal clients, and an external one served to everyone else.

Common reasons:

• Pointing internal users straight at a private IP for a service, avoiding a trip out to the internet and back, and getting lower latency.
• Hiding internal hostnames and topology from the public internet, as a defence-in-depth measure.

The trap is that it is easy to get wrong in ways that are hard to debug. "It works for me" and "it is broken for you" can both be true at once, depending only on which network each person is on. Teams that do not know split-horizon is in place waste hours on confusing bug reports.

Keep the two zones in sync for records that should match, and document the setup clearly.

HTTP/1.1 handles one request at a time per connection. Browsers work around this by opening several parallel TCP connections to a host, but that adds overhead. Its main pain point is head-of-line blocking: a slow request holds up the ones queued behind it.

HTTP/2 added multiplexing. Many requests and responses are interleaved over one TCP connection, removing the need for many parallel connections. But it did not fully fix head-of-line blocking, because it still sits on one TCP connection. If one TCP packet is lost, TCP's in-order delivery makes every stream on that connection wait for the retransmission, even unrelated ones.

HTTP/3 drops TCP and runs over QUIC, a transport built on UDP. QUIC tracks each stream on its own, so a lost packet only blocks the stream it belonged to. It also builds TLS 1.3 into connection setup, which cuts the round trips needed before data flows, and it handles network changes (such as switching from Wi-Fi to mobile) more gracefully.

The story an interviewer wants: each version fixed a specific, real bottleneck the previous one still had. It is not just "newer is faster".

Reference: Cloudflare - What is HTTP/3?

The prompt tells you the server is healthy, so this question pulls you away from server metrics and into the network path.

Look at:

• Bandwidth saturation on the link at either end. Free capacity on the server says nothing about the path to the user.
• Packet loss and retransmissions. They can quietly cut TCP throughput, because TCP backs off sharply when it sees loss.
• Latency and distance. If users are far away with no CDN or edge nearby, every round trip (DNS, TCP, TLS, each request) pays that penalty again.
• DNS resolution time, especially with a slow third-party DNS provider.
• MTU and fragmentation problems, which can stall larger responses while small test traffic looks fine.
• Connection reuse. If every request opens a new TCP and TLS connection instead of reusing one with keep-alive, the overhead adds up under load.
• Middleboxes. Proxies, firewalls and load balancers doing deep inspection or TLS termination add latency of their own.

Work outward from the server, which is confirmed healthy, along the actual path to the user. Tools such as curl -w, mtr and a packet capture show where the time goes.

The point to show is systematic elimination, not guessing at one likely culprit.

802.1X is a port-based network access control standard. A device or user must authenticate, usually against a central RADIUS server, before getting any network access. It is the mechanism behind "enterprise" Wi-Fi (WPA2 or WPA3-Enterprise), where each user signs in with their own credentials or certificate, instead of everyone using one pre-shared key.

A shared password has fundamental weaknesses:

• Everyone uses the same key, so you cannot tell which person or device a connection belongs to.
• You cannot revoke one person's access without changing the password for everyone.
• You cannot give different people different levels of access.

802.1X gives each user or device its own identity. You can log exactly who connected and when, revoke a single compromised credential without disturbing anyone else, and, with dynamic VLAN assignment, put different users on different segments automatically based on who they are.

The trade-off is infrastructure. You need a RADIUS server and a way to issue credentials or certificates, which is why many smaller networks still use a shared key despite the weaknesses.

Reference: IEEE 802.1X

Default deny blocks all traffic except what a rule explicitly permits. Default allow permits all traffic except what is explicitly blocked.

For a new internal segment, default deny is almost always the right choice. Here is the reasoning an interviewer wants to hear:

• With default allow, every new service, port or lateral-movement path an attacker tries is open until someone notices and closes it. You are always catching up on things you have not thought of.
• With default deny, nothing works until someone decides it should. Unexpected traffic, such as a compromised host calling a command-and-control server or probing other segments, has no path unless it happens to match a rule someone wrote.

The real cost is upfront effort. Every legitimate service needs an explicit rule, and a rushed rollout can break things that were quietly relying on being allowed. That cost is exactly why default allow still appears in practice, despite being the weaker posture.

A practical way to roll out default deny safely is to start in logging mode, watch what traffic actually flows, write rules from that, and only then enforce.

Use a structured method instead of guessing. A common one is to work up the layers from the bottom, while narrowing the scope as quickly as you can.

1. Scope the problem. Is it everyone or some people? Everything or only the internet? Did something change recently (a change window, a power event, an ISP notice)? This alone often points to the cause.
2. Layer 1 and 2. Are the switches and the router powered on and the link lights lit? Is a core uplink down? A failed core switch or cable would take down a whole area. Check interface status and logs.
3. Layer 3, local. Does a client have a proper IP address (not 169.254.x.x) and a default gateway? Can it ping the gateway? If not, the problem is local (VLAN, DHCP, switch). If yes, continue.
4. Layer 3, beyond. Can the gateway reach the ISP's next hop? Can you ping a public IP such as 1.1.1.1? If that works but names do not, it is DNS. If it fails, check the WAN link, the ISP status and routing.
5. DNS. Test with dig against the internal resolver and a public one to see which is failing.
6. Upper layers and security. Check firewall rules, recent policy changes, NAT table exhaustion or a certificate or proxy problem.

Throughout, change one thing at a time, write down what you did, and communicate status to the users. Once restored, find the root cause and record it so it does not repeat.

The interviewer is listening for a method, not for a lucky guess.

Intermittent loss is hard because it may not be happening when you look. Start by proving it with data instead of anecdotes.

1. Measure it. Run continuous tests, such as mtr (which combines ping and traceroute) or long-running pings, from affected clients to a few targets: the local gateway, an internal server and a public address. Note times.
2. Localize it by segment. Compare results. Loss to the gateway means the local segment (cable, Wi-Fi, switch port). Loss only past the gateway means the router, the WAN or the ISP. Loss that begins at one hop and continues on all later hops points to that hop. Note: loss shown only at one hop, with none after it, is often just that router rate-limiting its own ICMP replies and not real loss.
3. Check interface counters on every device along the path: errors, CRC, drops, discards, and utilization over time. Rising counters name the culprit.
4. Look for the usual causes. Bad or damaged cable, a failing optic or port, duplex mismatch, congestion and full buffers, Wi-Fi interference, an overloaded firewall or CPU, and a flapping link.
5. Correlate with time. If it happens at the same time each day, think of backups, scheduled jobs or peak usage. If it follows a pattern with a device, suspect that device.
6. Capture traffic at both ends to see retransmissions and to prove where packets disappear.

Fix by replacing the suspect component or adding capacity, and then confirm with the same tests that the loss is gone.

The challenge is that DNS answers are cached, so different users see the change at different times. You plan around that.

1. Lower the TTL in advance. At least one full old-TTL period before the cutover, reduce the record's TTL (for example from 24 hours to 60 seconds). Now caches will expire quickly when you switch.
2. Prepare the new environment and test it directly (by IP, or with a hosts file entry or curl --resolve) before changing anything in DNS.
3. Run both in parallel. Keep the old service running and able to handle requests. Data written to the old and new systems must be kept in sync, or the cutover must be designed for it (read-only mode, replication, a short freeze).
4. Change the record. Because the TTL is low, most resolvers move within minutes. Watch traffic on both sides to see it shift.
5. Wait and verify. Some resolvers and apps ignore TTLs and cache longer. Keep the old service alive until traffic to it drops to nothing, usually a day or more.
6. Raise the TTL again and decommission the old one.

Other tools: for stronger control, put a load balancer or reverse proxy in front, so you can shift traffic gradually (weighted routing) and roll back instantly.

The key idea to state: DNS is a cache-based system, so downtime is avoided by preparing the caches (low TTL) and by keeping the old service alive during the overlap.

Separate "is DNS the problem?" from "which part of DNS?".

1. Reproduce it. Use dig example.com (or nslookup) from an affected machine and note the query time and status. NXDOMAIN means the name does not exist, SERVFAIL means the resolver could not get an answer, and a timeout means the resolver was not reached or did not answer.
2. Find out which resolver the client uses. Check DHCP or the device settings. A client pointed at a dead or distant resolver is a very common cause.
3. Compare resolvers. Run the same query directly against the internal resolver and a public one with dig @1.1.1.1 example.com. If the public one works and the internal one does not, the problem is your resolver (overloaded, misconfigured forwarders, broken cache). If both fail, the problem is probably the authoritative side.
4. Check the authoritative servers. dig NS example.com and query each directly with dig @ns1... example.com. Different answers between servers suggest a sync problem. Check for an expired DNSSEC signature, which causes SERVFAIL on validating resolvers only.
5. Check the network path. Is UDP and TCP port 53 reachable? Large responses may need TCP, and a firewall that blocks it causes failures only for big answers.
6. Check for caching and split-horizon issues. Stale cached answers and different internal and external views often explain "it works for me".
7. Look at load and logs on the resolver, for query rates and errors.

Slow lookups only for some names point to a bad upstream or a slow authoritative server for those domains. Also remember the ndots and search-domain behaviour, which adds extra queries on some systems.

The cause is the bandwidth-delay product (BDP): bandwidth multiplied by round-trip time. It is the amount of data that must be "in flight" to keep the link full.

TCP can only have as much unacknowledged data in flight as the smaller of its congestion window and the receiver's window. If the window is smaller than the BDP, the sender sends a full window and then waits for acknowledgments, leaving the link idle. Throughput is roughly window size divided by round-trip time.

Example: a 1 Gbps link with 100 ms RTT has a BDP of about 12.5 MB. With a 64 KB window, the maximum rate is about 64 KB per 0.1 s, which is roughly 5 Mbps. The link is almost empty, and no extra bandwidth helps.

Fixes:

• Make sure TCP window scaling is enabled, which allows windows larger than 64 KB (RFC 7323), and that buffers are large enough. Modern operating systems auto-tune, but old or restricted systems may not, and some firewalls strip the option.
• Check for packet loss, which shrinks the congestion window. On long links even small loss hurts badly.
• Use parallel streams, as many transfer tools do, to fill the pipe.
• Use a congestion control algorithm suited to the path, such as BBR, or a WAN optimization or UDP-based transfer tool for very long paths.

The key insight is that bandwidth and latency together limit a single stream.

Reference: RFC 7323 - TCP Extensions for High Performance

Asymmetric routing is when traffic takes one path in one direction and a different path coming back. It is common and legitimate in networks with several uplinks or redundant paths, and it works fine for plain routers, which forward each packet on its own.

The problem appears when a stateful device sits on the paths. A stateful firewall records the connection when it sees the first packet (the SYN) and only permits replies that match an entry in its state table. If the return packets go through a different firewall, that second device has never seen the SYN and has no state, so it drops the replies as invalid. The result is connections that fail or hang, even though every link is up.

You may see it as a handshake that never completes, or a connection that works for some users and not others, depending on which path each takes. A packet capture on both firewalls shows the SYN on one and the SYN-ACK on the other.

Fixes:

• Make routing symmetric, for example by controlling BGP preferences, route metrics or policy routing so both directions use the same firewall.
• Share state between firewalls using a high-availability pair.
• Use NAT carefully so return traffic is forced back through the same device.
• In some cases, relax strict state checking on a specific flow, though this reduces protection.

This is a favourite scenario because it tests whether you understand both routing and state.

BGP picks among multiple routes to the same prefix using an ordered list of attributes. A common simplified order is:

1. Highest local preference (a policy value set inside your AS, the strongest lever you have).
2. Shortest AS path.
3. Lowest origin type.
4. Lowest MED (a hint from a neighbour about which entry point to prefer).
5. Prefer external (eBGP) over internal (iBGP) routes.
6. Lowest IGP cost to the next hop, then tie-breakers such as router ID.

Before all that, remember that a more specific prefix always wins (longest prefix match), which is the key to hijacks.

A hijack is when a network announces prefixes it does not own, or more specific parts of someone else's prefix, drawing traffic to itself. A route leak is when a network re-announces routes in a way that breaks agreed relationships, for example passing routes from one provider to another, which can pull large volumes of traffic through a network that cannot handle it.

Defences:

• Prefix filters and max-prefix limits on every neighbour, so you only accept what they should announce.
• RPKI route origin validation (ROAs). Owners publish which AS may originate a prefix, and routers reject invalid announcements.
• Monitoring for unexpected announcements of your prefixes.
• Standards such as MANRS that set good operator practice.

BGP was built on trust, so protection depends on operators filtering carefully.

Reference: RFC 4271 - A Border Gateway Protocol 4 (BGP-4)

Start with requirements, then design in layers. A good answer is structured and shows trade-offs.

Requirements. Number and type of users and devices, applications (voice, video, cloud, on-premises), growth over several years, availability expectations, compliance needs, and budget.

Addressing. Pick a private range that will not overlap with other sites (avoid common defaults), and plan subnets with room to grow, using VLSM and keeping blocks summarizable.

Segmentation. Use separate VLANs and subnets for staff, voice, guests, servers or printers, IoT and management. Route between them through a Layer 3 switch or firewall with rules, so guests and IoT cannot reach internal systems.

Switching and wiring. Access switches per floor (with PoE for phones and access points), uplinks to a core or distribution layer, redundant uplinks with LACP or spanning tree design, and enough ports and spare capacity.

Wireless. Plan with a site survey, not by guessing. Use enterprise access points, WPA3 or WPA2/WPA3-Enterprise with 802.1X, and a separate guest SSID.

Internet and WAN. Two ISPs for resilience, a pair of firewalls in high availability, and a VPN or SD-WAN to other sites and the cloud.

Services. DHCP, DNS, NTP, and monitoring (SNMP or telemetry, logging, alerting).

Security. Default-deny firewall policy, 802.1X or port security, DHCP snooping, patching, backups of configs.

Operations. Documentation, naming standards, change management and a tested failure plan.

Finish by saying how you would validate: a pilot, a test of failover, and capacity checks.

This pattern strongly suggests a Layer 2 loop causing a broadcast storm. Ethernet frames have no TTL, so a loop makes broadcasts circulate and multiply endlessly until switch CPUs and links are saturated. Everything slows or stops, and all the activity lights flash.

Common triggers: someone plugged a cable between two ports of the same switch or two wall sockets (a loop through a small desk switch), a spanning tree misconfiguration or a failed STP, or a rogue switch.

Confirm. Look at switch interface counters for very high broadcast and multicast rates, high CPU, and MAC addresses flapping between ports in the logs ("MAC move" messages). A capture shows the same frames repeated.

Contain. Find the loop quickly. Use the counters to find the ports with huge traffic, and trace back toward the source. Disconnect the suspect link or shut down the port. Recent changes help, such as "someone moved a desk this morning".

Prevent. Make sure spanning tree is enabled and well designed. Use:

• BPDU guard on access ports, so a port that receives spanning tree messages from a switch is shut down.
• Storm control, which limits broadcast and multicast traffic per port.
• Loop guard and root guard, where appropriate.
• Small segments, so one loop affects fewer users, and clear documentation and cabling discipline.

The key statement: the speed of failure is the clue, and the fix is to find and break the loop, then add protections so it cannot recur.

A SYN flood exploits the TCP handshake. The attacker sends a large number of SYN packets, often with forged source addresses. The server replies with SYN-ACK and reserves memory for each half-open connection while it waits for a final ACK that never comes, because the spoofed address does not respond. The queue of half-open connections fills up, and legitimate clients can no longer connect.

Defences work at several levels:

• SYN cookies. The server encodes the connection details into the sequence number of its SYN-ACK and stores nothing until a valid ACK returns. This removes the memory exhaustion, and is built into most operating systems (for example Linux enables it under load).
• Tuning. Increase the backlog size and shorten the SYN-ACK retry time.
• Rate limiting SYN packets per source at the firewall or load balancer.
• Upstream protection. A load balancer, CDN or DDoS scrubbing service that terminates TCP connections for you and only passes on completed ones. Cloud providers offer this.
• Anti-spoofing filters at the network edge (BCP 38 ingress filtering) so forged source addresses cannot enter.

A key point is that a large SYN flood can also fill the network link itself, which no server-side setting can fix. For that, you need capacity or an upstream service.

In an interview, link it back to the handshake: the attack works because the server commits resources before the client has proved it is real.

Reference: RFC 4987 - TCP SYN Flooding Attacks and Common Mitigations

Use layers, so a failure or attack in one does not expose everything. A typical design:

• Multiple availability zones, with subnets in each, so the loss of a zone does not cause an outage.
• Public subnets hold only what must face the internet: a load balancer (or a WAF in front of it) and NAT gateways.
• Private application subnets hold the web or app servers. They receive traffic only from the load balancer and reach the internet only outbound through the NAT gateway.
• Private data subnets hold databases. They accept connections only from the app tier, and have no route to the internet.
• Security groups by tier. The load balancer allows 443 from the internet. The app group allows traffic only from the load balancer group. The database group allows traffic only from the app group on the database port. Using group references instead of IP addresses keeps it tidy.
• Network ACLs as a coarse extra layer, if needed.
• Admin access through a bastion host, or better a managed session service with no open SSH port, with logging and MFA.
• Private connectivity to cloud services with VPC endpoints.
• Encryption with TLS at the edge and between tiers where needed, and encryption of data at rest.
• Visibility. Flow logs, load balancer logs, and alerts, and a WAF with rate limiting.

State the principle: least privilege at every layer, no direct internet path to data, and everything logged.

Mention trade-offs honestly, such as the cost of NAT gateways and multiple zones against resilience.

There are two main options.

Site-to-site VPN uses encrypted IPsec tunnels over the public internet. It is quick to set up (hours), cheap, and encrypted by default. The downsides are variable latency and throughput because it rides the internet, no guaranteed performance, and tunnel throughput limits (often a bit over 1 Gbps per tunnel).

Dedicated connection (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) is a private physical link through a provider or colocation site. It gives consistent latency, higher bandwidth, and often lower data transfer costs for heavy traffic. The downsides are cost, lead time (weeks or months), and the fact that it is not encrypted by default, so sensitive traffic may still need an IPsec VPN or encryption on top.

A common design uses the dedicated link as primary and a VPN as backup, with BGP advertising routes on both and a preference for the dedicated path.

Things to plan carefully:

• Non-overlapping address ranges between on-premises and every VPC.
• Routing: BGP for dynamic failover versus static routes, and route limits.
• Transit design: connecting many VPCs usually uses a transit gateway or hub, because VPC peering is not transitive.
• DNS across both sides, with conditional forwarding.
• Bandwidth, redundancy and tested failover.

A good answer recommends based on needs: a VPN to start or for light traffic, and a dedicated link for steady, heavy or latency-sensitive workloads.

First separate network failure from TLS failure. If the TCP connection itself does not open, that is a firewall, routing or listening-port problem. If TCP opens but the handshake fails, then it is TLS.

A great tool is openssl s_client, which shows what the server sends:

Check these in the output:

• SNI. The -servername flag matters. A server hosting many sites uses the requested name to pick a certificate. A missing or wrong name returns a default certificate, which causes a name mismatch.
• Certificate chain. Does the server send its certificate and the intermediates? Look for "unable to verify the first certificate". A missing intermediate is one of the most common faults.
• Name and dates. Does the certificate cover the hostname, and is it within its validity period?
• Protocol and cipher. If client and server have no TLS version or cipher in common (for example an old client that only supports TLS 1.0, against a server requiring TLS 1.2 or 1.3), the handshake fails with an alert.
• Client certificate. If the server requires mutual TLS and the client does not send a valid certificate, the server closes the connection.
• Clock. A wrong system time on either side can make valid certificates look expired.
• Middleboxes. A proxy or firewall that intercepts TLS may present its own certificate, which the client may not trust.

A packet capture shows the alert message in the handshake, which usually names the failure (such as handshake_failure or bad_certificate). Then fix the specific cause.

"Tunnel up" only means the control side (key exchange) worked. Data can still fail for several reasons. Check in this order.

1. Routing. Does each side have a route to the other's network pointing into the tunnel (or a policy that matches it)? A missing route sends traffic out to the internet instead, or drops it. Check return routes too, on the far side and on the hosts or their gateway.
2. Traffic selectors or encryption domains. In policy-based VPNs, both ends must define matching local and remote networks (proxy IDs). A mismatch gives a tunnel that comes up for some subnets but not the ones you are testing.
3. Overlapping address ranges. If both sites use the same subnet, routing cannot work without NAT.
4. Firewall rules and NAT. Rules must allow the traffic in both directions. Make sure traffic for the tunnel is not being NATed to the internet address by an outbound NAT rule (a "NAT exemption" is needed).
5. MTU and MSS. Tunnel headers reduce the usable packet size. Small packets (ping) pass, but large ones (TLS, file transfers) hang. Lower the tunnel MTU or clamp the TCP MSS to fix it.
6. Asymmetric paths. Return traffic that avoids the tunnel gets dropped by a stateful firewall.
7. Security groups and host firewalls on the destination machines.

Tools: check that encrypted and decrypted packet counters on the tunnel increase, test with ping from each side, and run traceroute and a capture on the tunnel interface to see where packets stop.

The pattern worth stating: tunnel up does not equal traffic flowing, and the usual culprits are routes, selectors, NAT and MTU.

The status codes are clues. A 502 Bad Gateway means the load balancer got an invalid response, or the connection to the backend failed or was reset. A 504 Gateway Timeout means the backend did not answer in time.

Start with the load balancer's metrics and logs, which usually say which backend and which error each request hit.

Common causes and checks:

• Backend health. Are some backends failing health checks, being restarted, or overloaded (CPU, memory, thread or connection limits)? Intermittent errors often point to one bad backend, so compare errors per target.
• Timeout mismatches. If the load balancer's idle timeout is longer than the backend's keep-alive timeout, the backend closes a connection that the load balancer thinks is still open, and the next request on it fails with a 502. The standard rule is to set the backend keep-alive timeout longer than the load balancer's idle timeout.
• Slow requests. A request that takes longer than the load balancer's timeout becomes a 504. Check application latency and slow queries or dependencies.
• Deployments and scaling. Backends being removed during a rolling deploy without proper connection draining cause bursts of 502s. Check the timing against deploys and autoscaling events.
• Health check settings. A check that is too strict marks healthy backends as down, or too loose keeps sending traffic to broken ones.
• Network and security rules between the load balancer and backends, and connection or port exhaustion on either side.
• Backend crashes or out-of-memory restarts in the application logs.

Correlate timestamps across the load balancer logs, application logs and metrics, then fix the specific cause: capacity, timeouts, draining, or application errors.

Reference: MDN - 502 Bad Gateway