Networking Interview Questions

An IP address is a 32-bit dynamic address of a node in the network. An IPv4 address has 4 octets of 8-bit each with each number with a value up to 255.

IPv4 classes are differentiated based on the number of hosts it supports on the network. There are five types of IPv4 classes and are based on the first octet of IP addresses which are classified as Class A, B, C, D, or E.

Also, check out Scaler topics' Free Computer Networks course with certification to learn the fundamentals of computer networking. 

Private Address: For each class, there are specific IPs that are reserved specifically for private use only. This IP address cannot be used for devices on the Internet as they are non-routable.

Special Address: IP Range from 127.0.0.1 to 127.255.255.255 are network testing addresses also known as loopback addresses are the special IP address.

The different types of network topology are given below:

Bus Topology:

• All the nodes are connected using the central link known as the bus.
• It is useful to connect a smaller number of devices.
• If the main cable gets damaged, it will damage the whole network.

Star Topology:

• All the nodes are connected to one single node known as the central node.
• It is more robust.
• If the central node fails the complete network is damaged.
• Easy to troubleshoot.
• Mainly used in home and office networks.

Ring Topology:

• Each node is connected to exactly two nodes forming a ring structure
• If one of the nodes are damaged, it will damage the whole network
• It is used very rarely as it is expensive and hard to install and manage

Mesh Topology:

• Each node is connected to one or many nodes.
• It is robust as failure in one link only disconnects that node.
• It is rarely used and installation and management are difficult.

Tree Topology:

• A combination of star and bus topology also know as an extended bus topology.
• All the smaller star networks are connected to a single bus.
• If the main bus fails, the whole network is damaged.

Hybrid:

• It is a combination of different topologies to form a new topology.
• It helps to ignore the drawback of a particular topology and helps to pick the strengths from other.

Network topology is a physical layout of the network, connecting the different nodes using the links. It depicts the connectivity between the computers, devices, cables, etc.

Node: Any communicating device in a network is called a Node. Node is the point of intersection in a network. It can send/receive data and information within a network. Examples of the node can be computers, laptops, printers, servers, modems, etc.

Link: A link or edge refers to the connectivity between two nodes in the network. It includes the type of connectivity (wired or wireless) between the nodes and protocols used for one node to be able to communicate with the other.

Few types of VPN are:

• Access VPN: Access VPN is used to provide connectivity to remote mobile users and telecommuters. It serves as an alternative to dial-up connections or ISDN (Integrated Services Digital Network) connections. It is a low-cost solution and provides a wide range of connectivity.
• Site-to-Site VPN: A Site-to-Site or Router-to-Router VPN is commonly used in large companies having branches in different locations to connect the network of one office to another in different locations. There are 2 sub-categories as mentioned below:
• Intranet VPN: Intranet VPN is useful for connecting remote offices in different geographical locations using shared infrastructure (internet connectivity and servers) with the same accessibility policies as a private WAN (wide area network).
• Extranet VPN: Extranet VPN uses shared infrastructure over an intranet, suppliers, customers, partners, and other entities and connects them using dedicated connections.

Below are few advantages of using VPN:

• VPN is used to connect offices in different geographical locations remotely and is cheaper when compared to WAN connections.
• VPN is used for secure transactions and confidential data transfer between multiple offices located in different geographical locations.
• VPN keeps an organization’s information secured against any potential threats or intrusions by using virtualization.
• VPN encrypts the internet traffic and disguises the online identity.

VPN or the Virtual Private Network is a private WAN (Wide Area Network) built on the internet. It allows the creation of a secured tunnel (protected network) between different networks using the internet (public network). By using the VPN, a client can connect to the organization’s network remotely. The below diagram shows an organizational WAN network over Australia created using VPN:

LANs are widely used to connect computers/laptops and consumer electronics which enables them to share resources (e.g., printers, fax machines) and exchange information. When LANs are used by companies or organizations, they are called enterprise networks. There are two different types of LAN networks i.e. wireless LAN (no wires involved achieved using Wi-Fi) and wired LAN (achieved using LAN cable). Wireless LANs are very popular these days for places where installing wire is difficult. The below diagrams explain both wireless and wired LAN.

Below are few types of networks:

Network types can be classified and divided based on the area of distribution of the network. The below diagram would help to understand the same:

SMTP is the Simple Mail Transfer Protocol. SMTP sets the rule for communication between servers. This set of rules helps the software to transmit emails over the internet. It supports both End-to-End and Store-and-Forward methods. It is in always-listening mode on port 25.

HTTP is the HyperText Transfer Protocol which defines the set of rules and standards on how the information can be transmitted on the World Wide Web (WWW).  It helps the web browsers and web servers for communication. It is a ‘stateless protocol’ where each command is independent with respect to the previous command. HTTP is an application layer protocol built upon the TCP. It uses port 80 by default.

HTTPS is the HyperText Transfer Protocol Secure or Secure HTTP. It is an advanced and secured version of HTTP. On top of HTTP, SSL/TLS protocol is used to provide security. It enables secure transactions by encrypting the communication and also helps identify network servers securely. It uses port 443 by default.

It is a compressed version of the OSI model with only 4 layers. It was developed by the US Department of Defence (DoD) in the 1980s. The name of this model is based on 2 standard protocols used i.e. TCP (Transmission Control Protocol) and IP (Internet Protocol).

Here the 7 layers of the OSI reference model:

Open System Interconnections (OSI) is a network architecture model based on the ISO standards. It is called the OSI model as it deals with connecting the systems that are open for communication with other systems.

The OSI model has seven layers. The principles used to arrive at the seven layers can be summarized  briefly as below:

• Create a new layer if a different abstraction is needed.
• Each layer should have a well-defined function.
• The function of each layer is chosen based on internationally standardized protocols.

DNS is the Domain Name System. It is considered as the devices/services directory of the Internet. It is a decentralized and hierarchical naming system for devices/services connected to the Internet. It translates the domain names to their corresponding IPs. For e.g. interviewbit.com to 172.217.166.36. It uses port 53 by default.

The router is a networking device used for connecting two or more network segments. It directs the traffic in the network. It transfers information and data like web pages, emails, images, videos, etc. from source to destination in the form of packets. It operates at the network layer. The gateways are also used to route and regulate the network traffic but, they can also send data between two dissimilar networks while a router can only send data to similar networks.

tcpdump is a command-line packet capture tool used to inspect network traffic at the packet level. It is commonly used for debugging connectivity issues, protocol behavior, and unexpected network traffic.

Capture traffic for a specific host: tcpdump host 192.168.1.10

Capture traffic for a specific port: tcpdump port 443

Capture traffic for both host and port: tcpdump host example.com and port 443

tcpdump captures packets in real time and displays header-level details. It is often used alongside tools like Wireshark for deeper packet analysis.

12. What are common TCP flags (SYN, ACK, FIN, RST) and how do they appear in packet captures?

TCP flags control the state of a TCP connection and are visible in packet captures such as tcpdump.

• SYN: Used to initiate a connection
• ACK: Acknowledges received data
• FIN: Gracefully closes a connection
• RST: Immediately resets a connection due to an error or refusal

How they appear in packet captures:

• A normal connection starts with SYN -> SYN-ACK -> ACK
   
• Connection termination uses FIN/ACK exchanges
   
• RST packets indicate connection refusal, crashes, or policy blocks

In tcpdump, flags appear in shorthand, for example: 

S (SYN), S. (SYN-ACK), . (ACK), F (FIN), R (RST)

Several logs and system paths are useful when diagnosing Linux networking issues.

Common places to check include:

• System logs (/var/log/syslog or /var/log/messages) for general network errors
• NetworkManager logs for interface and connection issues

Kernel logs using: dmesg

to identify driver, interface, or hardware-related problems

These logs help correlate network failures with configuration changes, driver issues, or system events.

The routing table defines how network traffic is forwarded from the system to different networks. It determines which gateway or interface is used to reach a destination.

View the routing table: ip route

Add a temporary static route: ip route add 10.0.0.0/24 via 192.168.1.1

This route remains active until reboot or network restart.

Temporary static routes are often added for testing connectivity or debugging routing issues before making permanent configuration change

Established connections and socket states can be checked using the ss command, which provides detailed and real-time socket information.

Check summary of socket states: ss -s

This shows counts of:

• Established connections
   
• Listening sockets
   
• Time-wait, closed, and other TCP states

Check detailed active connections:

ss -ant

• -a -> all sockets
• -n -> numeric output
• -t -> TCP sockets

This is commonly used to inspect active connections, ports in use, and connection states during troubleshooting.

MTU (Maximum Transmission Unit) defines the largest packet size that can be transmitted over a network interface without fragmentation. The standard Ethernet MTU is 1500 bytes.

MTU-related issues typically cause:

• Slow connections
• Hanging requests
• Connections that work for small packets but fail for larger ones

Common checks include:

• Verifying MTU size on interfaces
• Testing packet fragmentation using ping with the “do not fragment” option
• Checking for mismatched MTU values across the network path

MTU problems often appear in VPNs, tunnels, or cloud networks where packet overhead reduces the effective MTU.

These are Linux networking techniques used for connectivity, redundancy, and network segmentation, but they solve different problems.

• Bridging connects multiple network interfaces at Layer 2, making them behave like a single network. It is commonly used to connect virtual machines or containers to the host network.
• Bonding combines multiple network interfaces into one logical interface to provide high availability or increased bandwidth. It is used for redundancy (failover) or load balancing.
• VLANs (Virtual LANs) logically split a physical network into multiple isolated networks using VLAN IDs. This allows traffic separation without additional physical interfaces.

In short:

• Bridging connects networks
   
• Bonding combines interfaces
   
• VLANs segment traffic

A Linux network namespace provides isolation for networking resources such as interfaces, IP addresses, routing tables, and firewall rules. Each namespace has its own independent network stack.

Network namespaces are useful because they allow multiple isolated network environments to exist on the same system.

Common use cases include:

• Containers (Docker, Kubernetes)
• Network isolation for testing
• Running multiple services with separate network configurations

In containerized environments, each container typically runs inside its own network namespace, ensuring that its networking setup does not interfere with others.

Firewall rules on Linux can be listed using either iptables or nftables, depending on which framework is in use.

Using iptables: iptables -S

This shows:

• All rules in a readable, rule-by-rule format
• Default policies (ACCEPT, DROP)
• Rule order, which is important because rules are evaluated sequentially

Using nftables: nft list ruleset

This displays:

• Tables, chains, and rules in a unified view
• Rules for IPv4, IPv6, and other families together

When interpreting firewall rules, key things to check are:

• Default policy of chains
• Rule order (first match wins)
• Which ports, protocols, or IP ranges are allowed or blocked

iptables and nftables are Linux firewall frameworks used to filter and control network traffic.

• iptables is the older, legacy firewall system. It uses multiple tables and chains and can become complex and inefficient for large rule sets.
• nftables is the modern replacement that unifies IPv4, IPv6, ARP, and bridge filtering under a single framework with simpler syntax and better performance.

Key differences:

• nftables has a cleaner, more consistent rule syntax
• nftables performs better with large rule sets
• iptables is still widely used and supported but is gradually being replaced

On modern Linux systems, nftables is preferred, while iptables knowledge remains important for legacy environments.

traceroute and mtr are both used to analyze the network path between a source and a destination.

• traceroute shows the path packets take hop by hop, displaying each router along the route. It provides a static snapshot of the path at a point in time.
• mtr combines the functionality of traceroute and ping. It continuously sends probes and shows live statistics such as latency and packet loss for each hop.

When to use which:

• Use traceroute for a quick, one-time path check
• Use mtr when diagnosing intermittent latency or packet loss, as it provides ongoing measurements

If a domain resolves correctly but the service cannot be reached, DNS is working and the issue is usually related to ports, service availability, or network access controls.

Common checks include:

• Verifying the service is listening on the expected port using tools like ss or netstat
• Testing port reachability with utilities such as nc or curl
• Checking firewall rules on the host and along the network path
• Confirming NAT or port-forwarding rules if the service is accessed externally
• Ensuring the service is bound to the correct address (for example, 0.0.0.0 instead of 127.0.0.1)
• Verifying whether a proxy configuration is required or interfering with the connection

Since name resolution succeeds, troubleshooting should focus on transport-level connectivity and service configuration, rather than DNS.

If a system can ping an IP address but not a domain name, the issue usually lies with DNS resolution, not basic network connectivity.

Common checks include:

• Verifying DNS resolution using tools like dig or nslookup
• Checking that valid DNS servers are configured in /etc/resolv.conf
• Ensuring /etc/hosts does not contain incorrect overrides
• Confirming DNS traffic is not blocked by firewall rules

Since IP connectivity is working, routing is typically correct, and the focus should remain on the DNS resolver path.

/etc/resolv.conf is a configuration file that specifies the DNS servers used by the system for hostname resolution. It typically contains one or more nameserver entries along with optional search domains.

On modern Linux systems, /etc/resolv.conf is often auto-generated and should not be edited directly. It can be managed or overwritten by services such as:

• systemd-resolved
• NetworkManager
• DHCP clients

In many cases, /etc/resolv.conf is a symbolic link to another file maintained by these services. As a result, manual changes may be lost after a network restart.

/etc/hosts is a local file used for static hostname-to-IP mapping. It allows a Linux system to resolve hostnames without querying a DNS server.

Each entry maps an IP address to one or more hostnames,

for example:

127.0.0.1   localhost

192.168.1.10   app.internal.local

How it interacts with DNS

The order in which /etc/hosts and DNS are consulted is controlled by /etc/nsswitch.conf. A common configuration looks like this: hosts: files dns

This means:

1. The system checks /etc/hosts first
2. If no match is found, it queries DNS

Because of this order, entries in /etc/hosts can override DNS results.

When /etc/hosts is commonly used

• Testing services locally before DNS changes
• Overriding DNS temporarily for debugging
• Defining internal hostnames in small setups

So, If a domain resolves differently in dig and getent hosts, it often indicates an entry in /etc/hosts or a resolver order issue. Checking /etc/hosts is a standard first step in DNS troubleshooting.

DNS resolution on Linux can be tested using tools like dig, nslookup, and getent hosts. These commands help verify whether a domain name is resolving correctly and where the resolution might be failing.

Using dig (preferred for detailed DNS checks): dig example.com

This shows:

• Resolved IP addresses
• DNS server used
• Query time and response status

To check a specific DNS server: dig @8.8.8.8 example.com

Using nslookup: nslookup example.com

This provides basic DNS resolution details and is useful for quick checks, though it is considered less powerful than dig.

Using getent hosts:getent hosts example.com

This command checks name resolution using the system’s configured resolver, including:

• /etc/hosts
• DNS
• Other name service sources (as defined in /etc/nsswitch.conf)

During Interview:

• Use dig to debug DNS issues in detail
• Use getent hosts to confirm what the system itself resolves
• Differences between dig and getent results often indicate resolver or /etc/hosts issues

netstat and ss are both used to inspect network connections, listening ports, and socket statistics. The key difference is that ss is the modern replacement for netstat.

netstat is part of the legacy net-tools package, which is deprecated on many Linux distributions. ss is part of the iproute2 suite and is actively maintained.

Key differences:

• ss is faster because it reads socket information directly from the kernel
• netstat relies on older interfaces and can be slower on busy systems
• ss provides more detailed socket and TCP state information
• netstat may not be installed by default on modern Linux systems

Example commands:

ss -lntp        # modern way to view listening TCP ports with process info

netstat -lntp   # legacy equivalent

In interviews, it’s best to use ss as the primary tool, while mentioning netstat to show awareness of legacy commands that are still referenced in older systems.

To identify which process is using a specific port on Linux, tools like ss, lsof, and fuser are commonly used. These commands help map ports to processes, which is essential when a service fails to start or a port is already in use.

Using ss (which is preferred on modern systems):

ss -lntp

• -l = listening sockets
• -n = numeric addresses (no DNS lookup)
• -t = TCP ports
• -p = process information

This shows the port, protocol, and the process (PID and name) listening on it.

To check a specific port: ss -lntp | grep :80

Using lsof: lsof -i :80

This lists the process using port 80 along with the PID and command. It works for both TCP and UDP and is widely available.

Using fuser: fuser 80/tcp

This shows the PID of the process using the port. It is useful for quick checks and can also terminate the process if needed.

Remember during the interview: ss is the modern replacement for netstat and is faster and more informative. Mentioning lsof as an alternative shows familiarity with multiple debugging tools.

Linux provides the ip command to inspect IP addresses, network interfaces, and routing information. These are usually the first commands run during network troubleshooting.

Check IP addresses assigned to interfaces:

ip a

# or

ip addr show

This shows:

• Interface names (eth0, ens33, wlan0, etc.)
• Assigned IPv4 and IPv6 addresses
• Interface state (UP/DOWN)

Check network interfaces and their state:

ip link

This command helps verify whether an interface is:

• UP or DOWN
• Administratively enabled
• Experiencing errors or drops

Check the routing table:

ip r

# or

ip route show

This displays:

• Default gateway
• Network routes
• Which interface traffic is routed through

ifconfig is an older, legacy tool used to configure and display network interfaces, while ip is a modern utility from the iproute2 suite that replaces ifconfig, route, and arp.

The ip command is preferred today because it provides better functionality, supports newer networking features, and is actively maintained.

Common commands:

ip addr        # show IP addresses

ip link        # show interface state

ip route       # show routing table

Legacy equivalent: ifconfig

Key differences:

• ip supports advanced features like network namespaces, policy routing, and traffic control
• ifconfig is deprecated on many modern distributions and may not be installed by default
• ip offers a consistent and extensible syntax for managing networking

In interviews, it is best to use ip commands first, while briefly acknowledging ifconfig, since many interviewers still reference it.

MAC address is the Media Access Control address. It is a 48-bit or 64-bit unique identifier of devices in the network. It is also called the physical address embedded with Network Interface Card (NIC) used at the Data Link Layer. NIC is a hardware component in the networking device using which a device can connect to the network.

Below are the steps that are being followed:

• Check the browser cache first if the content is fresh and present in cache display the same.
• If not, the browser checks if the IP of the URL is present in the cache (browser and OS) if not then request the OS to do a DNS lookup using UDP to get the corresponding IP address of the URL from the DNS server to establish a new TCP connection.
• A new TCP connection is set between the browser and the server using three-way handshaking.
• An HTTP request is sent to the server using the TCP connection.
• The web servers running on the Servers handle the incoming HTTP request and send the HTTP response.
• The browser process the HTTP response sent by the server and may close the TCP connection or reuse the same for future requests.
• If the response data is cacheable then browsers cache the same.
• Browser decodes the response and renders the content.

Conclusion

In today’s world, it is very hard to stay away from the Internet and that is what makes networking one of the most important interview topics. As of 2021 if we check the facts, there is a total of 1.3 million kilometers of submarine optical fiber cables set globally to connect the world to the Internet. These cables are more than enough to revolve around the earth more than 100 times.

Resources

Learn Coding

How To Become Network Engineer

Network Engineer Salary

Difference Between Hub and Switch

• Unicasting: If the message is sent to a single node from the source then it is known as unicasting. This is commonly used in networks to establish a new connection.
• Anycasting: If the message is sent to any of the nodes from the source then it is known as anycasting. It is mainly used to get the content from any of the servers in the Content Delivery System.
• Multicasting: If the message is sent to a subset of nodes from the source then it is known as multicasting. Used to send the same data to multiple receivers. 
• Broadcasting: If the message is sent to all the nodes in a network from a source then it is known as broadcasting. DHCP and ARP in the local network use broadcasting.

The firewall is a network security system that is used to monitor the incoming and outgoing traffic and blocks the same based on the firewall security policies. It acts as a wall between the internet (public network) and the networking devices (a private network). It is either a hardware device, software program, or a combination of both. It adds a layer of security to the network.

A subnet is a network inside a network achieved by the process called subnetting which helps divide a network into subnets. It is used for getting a higher routing efficiency and enhances the security of the network. It reduces the time to extract the host address from the routing table.

The difference between MAC address and IP address are as follows:

FTP is a File Transfer Protocol. It is an application layer protocol used to transfer files and data reliably and efficiently between hosts. It can also be used to download files from remote servers to your computer. It uses port 27 by default.

ARP is Address Resolution Protocol. It is a network-level protocol used to convert the logical address i.e. IP address to the device's physical address i.e. MAC address. It can also be used to get the MAC address of devices when they are trying to communicate over the local network.

DHCP is the Dynamic Host Configuration Protocol.

It is an application layer protocol used to auto-configure devices on IP networks enabling them to use the TCP and UDP-based protocols. The DHCP servers auto-assign the IPs and other network configurations to the devices individually which enables them to communicate over the IP network. It helps to get the subnet mask, IP address and helps to resolve the DNS. It uses port 67 by default.

ICMP is the Internet Control Message Protocol. It is a network layer protocol used for error handling. It is mainly used by network devices like routers for diagnosing the network connection issues and crucial for error reporting and testing if the data is reaching the preferred destination in time. It uses port 7 by default.

UDP is the User Datagram Protocol and is based on Datagrams. Mainly, it is used for multicasting and broadcasting. Its functionality is almost the same as TCP/IP Protocol except for the three ways of handshaking and error checking. It uses a simple transmission without any hand-shaking which makes it less reliable.

TCP or TCP/IP is the Transmission Control Protocol/Internet Protocol. It is a set of rules that decides how a computer connects to the Internet and how to transmit the data over the network. It creates a virtual network when more than one computer is connected to the network and uses the three ways handshake model to establish the connection which makes it more reliable.

If an IP address is reachable but the domain name is not, basic network connectivity is working and the issue is usually related to DNS resolution.

Key checks:

Test DNS resolution using:

dig example.com

nslookup example.com

getent hosts example.com

Verify DNS servers configured in:

cat /etc/resolv.conf

Check for incorrect hostname overrides in:

cat /etc/hosts

Confirm DNS server reachability:

dig @8.8.8.8 example.com

Ensure DNS traffic (port 53) is not blocked by firewall rules

Handling Troubleshooting (DNS issue):

• IP ping works - routing and interface are fine
• Domain lookup fails - DNS resolver path issue
• dig works but applications fail - resolver configuration (/etc/nsswitch.conf)
• No DNS server reachable - firewall or network policy blocking DNS

This scenario is commonly used to test whether a candidate can separate DNS issues from general network connectivity problems.

If clients successfully obtain IP addresses but cannot access the internet, DHCP is working, and the issue is typically downstream.

For troubleshooting, common checks include:

• Verifying DHCP options such as default gateway and DNS servers
• Checking routing and NAT configuration on the gateway
• Confirming DNS resolution is functioning
• Inspecting firewall rules blocking outbound traffic
• Checking for captive portal or restricted network policies

This scenario helps interviewers assess whether a candidate can distinguish address assignment issues from routing, NAT, or policy problems.

When containers cannot communicate with each other, the issue is usually related to the container networking layer, not the application itself.

Common checks include:

• Verifying the CNI plugin or bridge configuration
• Inspecting iptables or nftables rules created for container networking
• Checking the container’s network namespace
• Validating service discovery and DNS inside the cluster
• Ensuring node-level routing between container subnets is correct

Interviewers use this scenario to assess whether the candidate understands how container networking is implemented on Linux, instead of treating it as a black box

Latency that appears only during peak hours usually points to capacity or congestion-related issues, not configuration problems.

Common areas to check include:

• Network congestion and bandwidth saturation during high traffic periods
• Queue drops or bufferbloat, where excessive buffering increases latency
• Interface or gateway statistics for errors and drops
• ISP or peering congestion, especially for external traffic
• QoS policies that may deprioritize certain traffic under load

This scenario tests whether the candidate can associate time-based performance degradation with traffic patterns and capacity limits.

If a TCP connection is established but the TLS handshake fails, network connectivity is intact and the problem lies at the TLS or application layer.

Common causes include:

• Certificate issues, such as invalid or expired certificates
• SNI mismatch, where the server expects a different hostname
• TLS version or cipher mismatch between client and server
• Middlebox inspection (firewall or proxy interfering with TLS)
• System time skew, causing certificate validation to fail

This scenario is used to check whether a candidate can distinguish transport-level success from encryption or application-level failures.

If a host can reach the internet but not a particular subnet, general connectivity is working and the issue is usually routing or policy-related.

Common causes checked during troubleshooting include:

A missing route to the specific subnet: ip route

• Overlapping CIDRs causing traffic to be routed incorrectly
• Policy-based routing rules affecting only certain destinations
• ACLs or firewall rules blocking traffic to that subnet
• An incorrect default gateway or next-hop configuration

This scenario tests whether the candidate can identify selective routing failures rather than global network issues.

If IPv6 is enabled and only some users experience failures, the issue is often related to incomplete or inconsistent IPv6 support.

For troubleshooting, common checks include:

• Verifying AAAA DNS records resolve correctly
• Ensuring firewall rules allow IPv6 traffic
• Confirming the application is listening in dual-stack mode (IPv4 and IPv6)
• Checking for path MTU issues, which are more common with IPv6
• Validating IPv6 routing configuration on the host and network

This scenario tests whether the candidate understands that enabling IPv6 requires end-to-end readiness.

A routing loop occurs when packets circulate between routers without reaching the destination.

Common symptoms and checks include:

TTL exceeded errors, indicating packets are looping until TTL runs out

Running: traceroute destination_ip

and observing repeating hops in the output

Verifying the routing table for incorrect or overlapping routes: ip route

Checking for dynamic routing misconfigurations (incorrect metrics, missing routes, or redistribution issues)

This scenario is used to test whether a candidate can recognize path-level routing problems rather than host or service issues.

When an application works in one region but fails in another, the issue is usually related to regional configuration differences, not application logic.

For troubleshooting, common checks include:

• Comparing DNS records, especially geo-based routing or region-specific endpoints
• Verifying routing and peering differences between regions
• Checking firewall rules, security groups, or NACLs applied per region
• Inspecting load balancer configuration and health checks in the failing region
• Confirming backend instances in the affected region are healthy and reachable

This scenario tests whether a candidate can systematically compare environments instead of assuming a global failure.

Both errors indicate connection failure, but they point to different problem areas.

Connection refused means the request reached the destination host, but no service is listening on the target port, or the port is explicitly rejected.

• Common causes: service down, wrong port, service bound to localhost only
• Typical checks: ss -lntp

Connection timed out means the request never received a response, usually due to the network path blocking or dropping packets.

• Common causes: firewall rules, routing issues, security groups, network ACLs
• Typical checks: firewall rules, routing table, path connectivity

Interviewers expect candidates to clearly separate service-level failures from network-path failures.

When servers in different VLANs cannot communicate with each other, the issue typically lies in inter-VLAN connectivity or configuration, rather than basic host networking.

For troubleshooting, common checks include:

• Verifying inter-VLAN routing is configured on a router or Layer 3 switch
• Checking ACLs or firewall rules between VLANs
• Confirming trunk ports are correctly tagged with the required VLANs
• Ensuring each server has the correct subnet mask
• Verifying the default gateway points to the VLAN’s router interface
• Checking switch port VLAN assignment (access vs trunk mode)

This scenario tests whether the candidate understands how traffic moves between VLANs, not just within one.

When traffic breaks after a firewall change, the issue is often caused by rule order, default policies, or overly restrictive rules.

For troubleshooting and safe rollback, typical checks include:

• Reviewing the rule order, since firewall rules are evaluated sequentially
• Checking default policies (ACCEPT vs DROP)
• Inspecting rule hit counters or logs to see which rule is blocking traffic
• Temporarily reverting to the previous known-good rule set
• Applying changes in a staged manner and allowing only the minimal required paths first

Interviewers use this scenario to assess whether a candidate can handle production incidents carefully without causing further impact.

If a service works from inside the network but not from outside, the issue is usually related to exposure or access controls, not the service itself.

For troubleshooting, common checks include:

• Verifying NAT or port-forwarding rules are configured correctly
• Checking public firewall rules and cloud security groups/NACLs

Ensuring the service is listening on the correct port: ss -lntp

• Confirming the service is bound to 0.0.0.0 (all interfaces) and not 127.0.0.1
• Validating that the external IP or load balancer forwards traffic to the correct backend

This scenario tests whether the candidate understands the difference between internal reachability and external exposure.

If SSH connections are responsive but HTTP downloads are slow, basic connectivity is working and the issue is usually related to packet size, congestion, or traffic handling.

Common causes checked during troubleshooting include:

• MTU or MSS mismatches are causing packet fragmentation or drops
• Asymmetric routing, where return traffic follows a different path
• Network congestion is affecting bulk data transfers
• TCP window size or high RTT impacting throughput
• Proxy or firewall traffic shaping applied to HTTP/HTTPS traffic

This scenario tests whether the candidate understands that different protocols behave differently under the same network conditions.

Intermittent packet loss is usually diagnosed by checking where along the network path the loss starts.

For troubleshooting, common steps include:

Run a hop-by-hop path test: mtr remote_server_ip

• Look for packet loss or high latency at specific hops
• Distinguish between last-mile issues (close to the source or destination) and middle-mile issues (ISP or transit networks)
• Be cautious with ICMP loss, as some routers rate-limit ICMP responses

Check for TCP retransmissions on the affected connection: ss -ti

This approach helps identify whether packet loss is local, network-path related, or destination-specific.

If slowness is limited to a single application, general network connectivity is usually fine, and the issue is often application-specific or protocol-specific.

For troubleshooting, common checks include:

• Identifying which ports and protocols the application uses
• Comparing DNS resolution behavior for the application
• Checking for MTU-related issues that affect larger packets
• Verifying proxy settings used by the application
• Looking for TCP retransmissions or high latency on the application’s connections
• Checking server-side health or rate limits
• Reviewing QoS or traffic shaping rules that may prioritize or limit traffic

Interviewers use this scenario to assess whether a candidate can isolate application-layer issues from overall network performance.

When only one host in a subnet has connectivity issues, the problem is usually local to that machine, not the network itself.

For troubleshooting, the following checks are typically done:

Verify the network interface is up: ip link

Check IP address and subnet mask: ip a

Confirm the default gateway: ip route

Inspect the ARP table for incomplete entries or conflicts: ip neigh

• Check for duplicate IP addresses on the network
• Verify VLAN configuration if the network uses VLANs
• Rule out physical issues such as cable, Wi-Fi signal, or adapter problems
• Ensure local firewall rules are not blocking outbound traffic

This scenario tests whether the candidate can differentiate host-level issues from subnet-level problems.

If DNS resolution works but an HTTPS request times out, the issue is usually beyond name resolution and related to port connectivity, firewall rules, or service availability.

Key checks:

Test port reachability: nc -vz domain 443

Verify the service is listening on the server: ss -lntp | grep :443

• Check host and network firewall or security group rules allowing port 443
• Confirm routing to the destination network is correct
• Check whether a proxy is required or misconfigured for outbound HTTPS traffic

For troubleshooting:

• DNS works - name resolution is fine
• Port test fails - firewall, security group, or routing issue
• Port open, but no response - service not listening or bound incorrectly
• Works internally but not externally - NAT, firewall, or proxy configuration

Interviewers use this scenario to assess whether a candidate can move from DNS checks to transport-level debugging in a logical way.