Networking Scenario-Based Questions and Solutions

1) DNS TTL and IP Address Change

A company changes IP address of its web server from [Link] to [Link]. The domain '[Link]' has a DNS TTL of 3600 seconds.

Answer:
TTL = 3600 seconds = 1 hour. It may take up to 1 hour for all cached DNS resolvers worldwide to see the updated IP address. Some users will see the
change immediately if their cache expired earlier.
To minimize impact:
1. Lower TTL to 300 seconds (5 minutes) a day before migration.
2. Keep both old and new servers live during transition.
3. Verify DNS propagation with tools like 'dig' or 'nslookup'.
4. Use CDN or load balancing to serve both IPs temporarily.

2) HTTP/1.1 Page Load Delay Calculation

A user requests a webpage consisting of a base HTML file and 5 embedded images. RTT(local DNS)=10 ms, RTT(root/TLD/auth DNS)=40 ms, RTT(web
server)=200 ms.
Answer:
Step 1 – DNS Resolution:
1 RTT (user→local DNS) + 3×40ms (root, TLD, auth) = 130 ms.
Step 2 – TCP Connection: 1 RTT (200 ms)
Step 3 – Base HTML Fetch: 1 RTT (200 ms)
Step 4 – Image Fetch:
• With pipelining: 1 RTT = 200 ms
• Without pipelining: 5 RTT = 1000 ms

Total Time:
• With pipelining: 130 + 200 + 200 + 200 = 730 ms
• Without pipelining: 130 + 200 + 200 + 1000 = 1530 ms

3) ISP Subnetting Example

Given: Block [Link]/16 (65,536 addresses). Groups:
a) 64 customers × 256 each = 16,384
b) 128 customers × 128 each = 16,384
c) 128 customers × 64 each = 8,192

Total allocated = 40,960 → Remaining = 24,576 addresses.

Sub-blocks:
• a) [Link]/18 → 64×/24
• b) [Link]/18 → 128×/25
• c) [Link]/19 → 128×/26
Remaining range: [Link]–[Link].

4) Subnet Design for [Link]/22

Subnet 1 (≥300): [Link]/23 → 512 addresses (510 usable)
Subnet 2 (≥200): [Link]/24 → 256 addresses (254 usable)
Subnet 3 (≥120): [Link]/25 → 128 addresses (126 usable)
Subnet 4 (≥100): [Link]/25 → 128 addresses (126 usable)

5) IPv4 Datagram Description

IPv4 Header Fields:
Version | IHL | Type of Service | Total Length | Identification | Flags | Fragment Offset | TTL | Protocol | Header Checksum | Source IP | Destination IP.
a) TTL: decremented per hop, prevents infinite loops.
b) Header Checksum: 1’s complement of header fields, recomputed at each hop.
c) Fragment Offset: shows byte offset of fragment (in 8-byte units).
d) Upper-layer Protocol: indicates next-layer (TCP=6, UDP=17). Removed in IPv6, replaced by 'Next Header' field.

6) UDP Checksum
Significance: Detects header/data corruption.
Includes pseudo-header (source/dest IP, protocol, length) + UDP header + data.
Calculated using one's complement addition; 0xFFFF transmitted if sum is zero.

7) OpenFlow Switch Behavior

At switch s2:
• From h3 → to {h1,h2,h5,h6}: OUTPUT anti-clockwise port.
• From h4 → to {h1,h2,h5,h6}: OUTPUT clockwise port.
Flow entries sample:
match: in_port=<h3_port>, nw_dst in {h1,h2,h5,h6} → OUTPUT=<anticlockwise>
match: in_port=<h4_port>, nw_dst in {h1,h2,h5,h6} → OUTPUT=<clockwise>
8) IP Fragmentation Calculation
Given datagram = 4000 bytes (payload 3980). MTU = 1500+XX bytes.
Max payload per fragment = (MTU - 20), rounded to multiple of 8.
Number of fragments = ceil(3980 / payload_per_fragment).
Offsets are in 8-byte units, MF=1 for all except last.
Example (XX=24): MTU=1524 → payload=1504, fragments:
Frag1: size=1524, offset=0, MF=1
Frag2: size=1524, offset=188, MF=1
Frag3: size=992, offset=376, MF=0.

Scenario-Based Networking Questions (TCP, ARP, DHCP)

TCP (Transmission Control Protocol)

Scenario 1: Application Delay Due to TCP Handshake and Congestion Window
New TCP connections start with a small congestion window (cwnd). When a user connects to a web server, the 3-way handshake (SYN → SYN-ACK →
ACK) must complete before data transfer. If the round-trip time (RTT) is high, the initial window (usually 10 segments) can cause noticeable delay. Once
acknowledgments return, cwnd expands exponentially (slow start). In high-latency or lossy networks, this phase causes short initial slowness.

Scenario 2: SYN-ACK Dropped by Firewall

If a firewall mistakenly drops SYN-ACK packets, TCP handshake never completes. The client repeatedly retransmits SYN requests, timing out eventually.
Root cause: firewall stateful inspection rules do not recognize the connection direction. Fix: ensure the firewall allows return SYN-ACK packets and
maintains state tables correctly.

Scenario 3: Repeated TCP Resets (RST)

When a TCP RST flag is received, it forces immediate connection termination. RSTs can occur if a port is closed, if sequence numbers are desynchronized,
or if middleboxes (NAT/firewalls) expire state early. Applications see 'connection reset by peer' errors. Mitigation: ensure consistent NAT mappings and
avoid aggressive idle-timeout values.

Scenario 4: SYN Flood Attack

Attackers send large volumes of SYN packets but never respond with ACKs, causing the server to maintain half-open states in its backlog queue. This
exhausts memory and connection slots. Defense: enable SYN cookies (encode initial sequence numbers cryptographically) and rate-limit SYNs per source
IP.

Scenario 5: Fluctuating Download Speeds

TCP throughput varies due to flow and congestion control. Flow control uses the receiver’s window size; congestion control (AIMD, Reno, Cubic) adjusts
cwnd based on packet loss or delay. If the network experiences temporary loss, cwnd shrinks, reducing speed. Solution: use modern algorithms
(Cubic/BBR) and stable RTT paths.
ARP (Address Resolution Protocol)
Scenario 1: ARP Spoofing and Wrong MAC Entries
Two hosts on the same LAN cannot communicate because their ARP caches were poisoned. An attacker sends fake ARP replies claiming the gateway’s IP.
Packets are redirected through the attacker, who can sniff or modify data. Fix: enable Dynamic ARP Inspection (DAI), use static ARP entries for gateways.

Scenario 2: Detecting ARP Poisoning via Switch Logs

A managed switch reports MAC address flapping between ports. This occurs when an attacker sends forged ARP packets with multiple MAC-IP bindings.
DAI or port security can limit MAC addresses per port, detecting and blocking spoofing attempts.

Scenario 3: Gratuitous ARP Misuse

An attacker broadcasts Gratuitous ARP replies announcing ownership of a legitimate IP. Devices update caches with attacker’s MAC, diverting traffic.
Mitigation: restrict unsolicited ARP replies and monitor ARP tables for sudden changes.

Scenario 4: ARP Cache Poisoning in Public Wi-Fi

In open networks, attackers poison ARP caches so that all traffic passes through them as the ‘default gateway’. They can intercept HTTPS sessions using
SSL stripping. Defenses: use WPA2 encryption, static ARP for key hosts, and VPN tunnels to protect traffic.

DHCP (Dynamic Host Configuration Protocol)

Scenario 1: Rogue DHCP Server
A user sets up a personal router on the office LAN. Its DHCP server responds faster than the legitimate one, assigning incorrect IP, gateway, and DNS.
Clients lose internet access or get redirected. Mitigation: enable DHCP snooping on switches to only allow DHCP responses from trusted ports.

Scenario 2: DHCP Starvation Attack

An attacker floods Discover requests with fake MAC addresses, exhausting the DHCP pool. Legitimate clients cannot get IPs. Solution: use DHCP snooping
and rate-limiting to restrict request frequency per port.

Scenario 3: Remote Office Without Local DHCP

DHCP broadcasts don’t cross routers. A relay agent (configured via 'ip helper-address') forwards requests as unicast to the central DHCP server.
Responses return the same path, ensuring remote clients are assigned valid IPs.

Scenario 4: Frequent IP Changes

A laptop renews leases frequently due to short lease times (T1=50%, T2=87.5% of total). If the server is unreachable during renewal, the client falls back
to APIPA or loses connectivity. Fix: extend lease durations or ensure reliable DHCP reachability.

Scenario 5: Preventing Static IP Assignment

Users manually configure static IPs, causing conflicts. DHCP snooping with IP Source Guard validates bindings of IP-MAC-port pairs. Packets from
unregistered combinations are dropped, enforcing dynamic address integrity.