Modern Networking & Tools

1. What is the core philosophy behind Software-Defined Networking (SDN)?

SDN decouples the control plane from the data plane.

• Control plane — the intelligence that decides where traffic goes (routing logic, policies).
• Data plane — the hardware (switches, routers) that actually forwards the packets.

Traditional switch:  control + data logic together in each box
SDN:                 [SDN Controller (central brains)]   ← control plane
                          │ (OpenFlow/config API)
                    [switch] [switch] [switch]           ← dumb data plane

The result:

• One central SDN controller programs all switches via a standard API (e.g., OpenFlow).
• Network behavior becomes software-defined — reconfigurable centrally in seconds, no per-device CLI.
• Switches become simple forwarding hardware; the controller holds the intelligence.

Great for dynamic networks (clouds, data centers) where policy changes constantly.

2. In network performance diagnostics, how do Latency and Jitter differ?

• Latency — the total time delay for a packet to travel from source to destination. One number per trip.
• Jitter — the variance in that delay across multiple packets.

Latency:   packet A = 20ms, packet B = 25ms, packet C = 21ms
Jitter:    the fluctuation (20 → 25 → 21) is the jitter

Why jitter matters: real-time applications (VoIP, video calls, online gaming) care more about consistent delay than low delay. If packets arrive at wildly different times, audio cuts out and video stutters — even if average latency is fine. Buffers help absorb jitter, but too much breaks the stream.

Latency = how slow. Jitter = how uneven.

3. How does a Software-Defined WAN (SD-WAN) improve on traditional wide-area networking architectures?

SD-WAN abstracts WAN control into software and steers traffic dynamically over a mix of cheap links based on real-time performance.

Traditional WAN:  branch ────MPLS (expensive, rigid)──── HQ
SD-WAN:           branch ── broadband / LTE / MPLS ── HQ
                        ↑ software picks the best path live

What changes:

• Old way: everything forced over expensive dedicated MPLS circuits; changes require per-device config.
• SD-WAN: an overlay controller monitors each link’s latency, loss, jitter and routes each flow over the best available path — often consumer broadband and cellular alongside MPLS. A VoIP call can stay on MPLS while bulk backups go over cheap broadband, automatically.

Result: lower cost, higher resilience, centralized control.

4. What is the core objective of the Intent-Based Networking (IBN) model?

IBN lets engineers state high-level business intent and the network automates the configuration, then continuously verifies it complies.

"All guests get web-only access"   ← intent (business language)
        │  automation engine
        ▼
concrete device configs → deployed → monitored → auto-fixed if drifted

Contrast: traditional config is manual, line-by-line CLI on each device. IBN translates the what (“guests are web-only”) into the how (ACLs, VLANs, segmentation) automatically — and keeps checking that the live network still matches the intent, self-correcting drift.

Network management goes from “configure devices” to “declare outcomes.”

5. Which specific information is provided by running the standard ‘ipconfig’ (Windows) or ‘ip address’ (Linux) command utilities?

These commands display the host’s local interface configuration:

• IP address assigned to each active interface
• Subnet mask
• Default gateway
• Interface names and MAC addresses

$ ipconfig /all
Ethernet adapter Ethernet0:
   IPv4 Address. . . . . : 192.168.1.50
   Subnet Mask . . . . . : 255.255.255.0
   Default Gateway . . . : 192.168.1.1

What it does NOT show: the full route path to a website (that’s tracert), listening TCP sessions (netstat), or cipher suites. It answers the local question: “what address did my NIC get, and where does my traffic exit?“

6. What diagnostic insight does the ‘netstat’ command line utility provide to a network administrator?

netstat (network statistics) shows active socket connections and network-level state:

$ netstat -an
Proto  Local Address       Foreign Address      State
TCP    0.0.0.0:22          0.0.0.0:0            LISTENING
TCP    192.168.1.50:5432   10.0.0.7:51800       ESTABLISHED
TCP    192.168.1.50:5432   10.0.0.8:51812       ESTABLISHED

What it reveals:

• Active TCP/UDP sessions — local and remote IP:port
• Listening ports (what’s open, e.g., is SSH/DB exposed?)
• Connection states (ESTABLISHED, LISTENING, TIME_WAIT)
• Interface statistics and routing tables

It’s the go-to for “what’s connected to my machine and what am I listening on?“

7. If a workstation user can access internal network file shares but cannot load public internet websites, which configuration item should be checked first?

The Default Gateway address.

Think it through:

• Internal shares work → the NIC, IP address, and Layer 2 connectivity are fine.
• Traffic to the internet must leave the local subnet — and that exit is the default gateway.

Internal share: 192.168.1.50 → 192.168.1.20  (same subnet, no gateway needed) ✓
Internet:       192.168.1.50 → 8.8.8.8       (different subnet → needs gateway)

If the gateway is wrong, missing, or down, everything internal still works but nothing leaves the LAN. Check: ipconfig → is the Default Gateway correct and reachable? (A bad gateway could also be pointing to a dead router.)

8. What does an IP address assignment of ‘169.254.10.45’ on a workstation operating system indicate?

The device failed to reach a DHCP server and self-assigned an APIPA address.

DHCP Discover → no Offer → timeout → APIPA self-assign 169.254.x.x

APIPA (Automatic Private IP Addressing): when DHCP fails, the OS grabs a random address from 169.254.0.0/16 so the machine can still talk to other APIPA devices on the same segment — local communication works, but there’s no default gateway, so no internet access.

Troubleshooting cue: a 169.254.x.x address almost always means DHCP is down or unreachable — check the cable/port, DHCP server, and switch. It’s the network’s “I couldn’t get a real address” fallback.

9. When designing a multi-branch enterprise network architecture, how is traffic from remote offices securely routed to a central Data Center over the public internet?

Via encrypted site-to-site IPSec VPN tunnels or an SD-WAN overlay fabric.

Branch A ──IPSec/SD-WAN tunnel──┐
Branch B ──IPSec/SD-WAN tunnel──┼── Data Center
Branch C ──IPSec/SD-WAN tunnel──┘
            (all over the public internet)

Why tunnels:

• The public internet is untrusted — raw traffic would be readable in transit.
• An IPSec site-to-site tunnel encrypts everything between branch gateway and DC gateway (tunnel mode), creating a private path through public infrastructure.
• SD-WAN overlays the same idea with software steering across mixed links, adding flexibility and redundancy.

Either way, the branch and DC appear to be on one private network, with all inter-site traffic encrypted.

10. In high-availability infrastructure environments, how do companies protect critical storage data against individual drive failures?

By implementing RAID — Redundant Array of Independent Disks.

RAID combines multiple physical drives into one logical unit with redundancy, so a single drive failing doesn’t lose data:

RAID level	How it protects
RAID 1	Mirror — exact copy on two drives
RAID 5	Striping + distributed parity (survives 1 drive)
RAID 6	Striping + double parity (survives 2 drives)
RAID 10	Mirror + stripe (performance + redundancy)

RAID 5:  [D1][D2][D3][P]   parity rebuilt from remaining disks
         one disk dies → data recomputed from the others

The system keeps running during a disk failure, and the array is rebuilt once a replacement drive is installed — no downtime, no data loss.

11. What is the primary benefit of utilizing Git as a version control tool within modern Infrastructure as Code (IaC) network engineering pipelines?

Git makes config-as-code auditable: a single source of truth with history, peer review, and rollback.

router-config.txt (v1) → v2 → v3
   │                     │     └─ "introduced the outage"
   │                     └─ reviewed in PR before merge
   └─ git revert → back to known-good state in seconds

The benefits:

• Track history — every change, who made it, when, and why (commit messages).
• Peer review — configs go through pull requests before hitting production.
• Roll back — a bad deployment is git revert to the last known-good state.
• Consistency — the repo is the truth; no more “who changed the router and didn’t tell anyone.”

Without it, network config is folklore; with it, you can answer “what changed right before the outage?” precisely.

12. Which Python module tool is typically used to execute regular expressions to parse string patterns (like extracting failed logins from a syslog file)?

The built-in re module.

import re

line = "Jan 5 12:01:00 sshd[123]: Failed password for invalid user admin"
match = re.search(r"Failed password for (\w+)", line)
if match:
    print(match.group(1))   # admin

Why re: it provides regex matching — search, match, findall, sub — perfect for pulling structured data (IPs, usernames, timestamps) out of free-form log lines.

The others:

• paramiko — SSH connections
• scapy — packet crafting
• socket — raw network sockets

For “find patterns in text,” it’s re.

13. What is the function of the Paramiko library when writing Python network automation scripts?

Paramiko is a pure-Python SSHv2 implementation — it lets scripts connect to network devices over SSH and run commands.

import paramiko

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect("192.168.1.1", username="admin", password="secret")
stdin, stdout, stderr = ssh.exec_command("show running-config")
print(stdout.read().decode())

Why it matters for automation: network engineers need to log into routers/switches over encrypted SSH and issue commands programmatically. Paramiko provides the client side of that — so scripts can pull configs, push changes, and capture output without a human at the CLI. (Ansible and NAPALM build on this same idea.)

14. What makes the Python Scapy library a valuable tool for network diagnostic and security operations?

Scapy lets you forge, capture, decode, and inject raw packets — down to individual header bits.

from scapy.all import *

pkt = IP(src="192.168.1.99", dst="10.0.0.5") / TCP(sport=1234, dport=80)
send(pkt)          # inject a custom packet
pkts = sniff(count=10)   # capture traffic

Use cases:

• Security auditing — craft probes to test firewalls and IDS.
• Protocol exploration — build packets from scratch to see how devices react.
• Fuzzing — send malformed packets to find vulnerabilities.
• Path tracing / analysis — decode and inspect captured traffic.

Because you control every field at the bit level, Scapy is a favorite for security researchers and network engineers who need to test behaviors that no GUI tool can produce.

15. What is the difference between HTTP/1.1, HTTP/2, and HTTP/3?

The three generations of HTTP:

• HTTP/1.1 — one request per TCP connection at a time (head-of-line blocking): each object (CSS, JS, image) needs its own request/response round-trip. Pipelining was attempted but barely used. Lots of parallel connections (6+) per site just to get tolerable speed.
• HTTP/2 — fixes HOL blocking with multiplexing: many streams of requests/responses run concurrently over one TCP connection. Adds header compression (HPACK) and server push (server sends resources before asked). Binary framing instead of plain text. Same TCP underneath, so a dropped packet still blocks all streams (TCP-level HOL blocking remains).
• HTTP/3 — swaps TCP for QUIC, which runs over UDP. This removes TCP HOL blocking entirely: each stream is independent, so one lost packet stalls only that stream, not the whole connection. Also has 0-RTT handshakes (connection + TLS setup in one round trip), built-in encryption, and better connection migration (survives switching Wi-Fi → cellular).

HTTP/1.1:  one object per round-trip  (slow)
HTTP/2:    many objects over one TCP  (better)
HTTP/3:    many streams over QUIC/UDP (fastest, no HOL blocking)

The one-liner: HTTP/1.1 serializes, HTTP/2 multiplexes over TCP, HTTP/3 multiplexes over UDP/QUIC and drops the head-of-line blocking.

16. What is the difference between L4 and L7 load balancing?

A load balancer distributes incoming traffic across backend servers. The split is by how deep it looks into the traffic:

• L4 (transport-level) load balancing — makes decisions on the IP + port only. It doesn’t read the HTTP content; it forwards whole TCP/UDP flows to a backend. Extremely fast, minimal overhead, works for any protocol (not just HTTP). But it can’t route based on URL, cookies, or headers — and it hides client IPs unless configured with proxy protocol.

Client ──→ L4 LB (sees IP:port) ──→ Server A / Server B

• L7 (application-level) load balancing — inspects the application payload (HTTP URL, headers, cookies, hostname). It can route /api/* to one pool and /images/* to another, do SSL termination, content caching, and path/cookie-based sticky sessions. More features, more per-request cost.

Client ──→ L7 LB (sees GET /api/users) ──→ API servers
                                  └──→ image CDN

	L4	L7
Decides on	IP + port	URL, headers, cookies
Speed	Very fast	Slower (parses content)
Scope	Any protocol	HTTP-focused
Examples	HAProxy L4, AWS NLB	HAProxy L7, NGINX, AWS ALB

Interview takeaway: L4 is a fast, protocol-agnostic traffic forwarder; L7 is a smart HTTP router that understands the request. Modern stacks often put an L4 LB in front and L7 inside.