Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Module 8: Advanced Networking Introduction

This module provides an overview of advanced networking topics. Each topic here has its own dedicated deep-dive module later in the course.

​
8.1 SDN (Software-Defined Networking)

SDN separates the Control Plane (decision making — “where should this packet go?”) from the Data Plane (forwarding — actually moving the packet). In traditional networking, every router and switch has its own brain — it makes forwarding decisions independently. SDN centralizes the brain into a controller, and the switches become simple forwarding devices that execute the controller’s instructions. Think of it as the difference between every car driver deciding their own route (traditional) vs a central traffic management system directing all cars (SDN). Another way to think about it: traditional networking is like a restaurant where every waiter decides their own path through the dining room. SDN is like having a floor manager who tells each waiter exactly where to go. The floor manager (controller) has a bird’s-eye view and can optimize traffic flow in ways no individual waiter could.
  • Centralized Controller: A software application that has a global view of the network and programs forwarding rules into switches. This makes network management programmable, automatable, and far more flexible than configuring each device individually via CLI.
  • OpenFlow: The original protocol for communication between the controller and switches. The controller sends flow rules (“if destination is 10.0.1.0/24, forward to port 3”) and the switch executes them.
Why it matters: Cloud networking (AWS VPC, Azure VNet, GCP VPC) is essentially SDN. When you create a VPC, define subnets, or configure route tables in the AWS console, you are programming a software-defined network. There are no physical routers being configured — it is all software. Understanding SDN is understanding how cloud networking works under the hood.
Practical scenario: Imagine you need to redirect all traffic from subnet A to subnet B through a new firewall appliance. In traditional networking, you would log into every router, update routes, and hope you did not make a typo. With SDN, you update one rule in the controller, and every switch gets the new forwarding instructions simultaneously. Changes that took hours now take seconds, and rollbacks are just as fast.

​
8.2 Cloud Networking (AWS VPC)

In the cloud, networking is virtualized. You do not buy routers and switches — you define networks in software. This makes networking faster to set up, but it also means every engineer (not just network engineers) needs to understand networking fundamentals.
  • VPC (Virtual Private Cloud): Your own isolated network environment within AWS. Think of it as renting a floor in a giant office tower. You control the floor layout (subnets), who can enter (security groups), and how mail is delivered (route tables). Other tenants (other AWS customers) share the same building but cannot see or access your floor.
  • Subnets: Divisions within your VPC. Public subnets have a route to an Internet Gateway (resources can have public IPs and be reached from the internet). Private subnets route through a NAT Gateway (resources can reach the internet for updates, but the internet cannot reach them directly). This is the most fundamental security pattern in cloud architecture.
  • Security Groups: Virtual firewalls attached to individual instances (stateful — return traffic is automatically allowed). These are your most frequently used security control in AWS.
  • Route Tables: Determine where traffic goes. Each subnet has a route table that says things like “traffic to 10.0.0.0/16 stays local, everything else goes to the NAT Gateway.” Understanding route tables is essential for debugging “why can’t my instance reach the internet?”
Deep Dive Available: See Module 10 (NAT), Module 11 (Routing), and Module 17 (Firewalls) for comprehensive coverage.

​
8.3 IPv6

IPv4 ran out of addresses. Literally — IANA allocated the last IPv4 blocks in 2011, and regional registries have been running on fumes since. IPv6 solves this with an address space so large it defies comprehension.
  • 128-bit addresses: Written in hexadecimal (e.g., 2001:0db8:85a3:0000:0000:8a2e:0370:7334). While IPv4 provides ~4.3 billion addresses, IPv6 provides 340 undecillion — enough to assign trillions of addresses to every grain of sand on Earth.
  • No NAT needed: With enough addresses for every device, the original end-to-end internet model works again. Every device can have a globally unique public IP. This simplifies peer-to-peer communication, VoIP, and IoT deployments.
  • Simplified Header: IPv6 removed optional fields and checksums from the header, making router processing more efficient. Fragmentation is handled by the endpoints, not routers.
  • Auto-configuration: SLAAC (Stateless Address Autoconfiguration) allows devices to generate their own IPv6 address without a DHCP server, using the network prefix from the router and their own MAC address.
The reality of IPv6 adoption: As of 2025, roughly 40-45% of internet traffic is over IPv6 (Google’s stats show this). Major cloud providers, mobile carriers, and large enterprises support it. But many corporate networks and smaller ISPs remain IPv4-only with NAT. You should understand IPv6, but you will still work with IPv4 and NAT for years to come. Plan for dual-stack (supporting both) in any new deployment.
Troubleshooting dual-stack: If a service works over IPv4 but fails over IPv6 (or vice versa), check that your DNS has both A (IPv4) and AAAA (IPv6) records, that your firewall rules cover both protocols (a common oversight — teams lock down IPv4 but leave IPv6 wide open), and that your load balancer or reverse proxy is listening on both. Use curl -4 example.com and curl -6 example.com to test each protocol independently.

​
8.4 Course Continues: Deep Dive Modules

The remaining modules provide in-depth coverage of critical networking topics:

Module 9: IP Addressing Mastery

CIDR notation, subnetting, private vs public IPs

Module 10: NAT Deep Dive

PAT, NAT Gateway, how private networks reach internet

Module 11: Routing Mastery

BGP, OSPF, route tables, cloud routing

Module 12: DNS Deep Dive

Zones, records, TTL, propagation, troubleshooting

Module 13: Load Balancing

L4/L7, algorithms, reverse proxies, SSL termination

Module 14: Troubleshooting

Essential tools and debugging techniques

Module 15: VPNs & Tunneling

IPsec, OpenVPN, WireGuard, SSH tunnels

Module 16: Network Scenarios

Real-world end-to-end network flows

Module 17: Firewalls

Security Groups, NACLs, iptables, Zero Trust

Module 18: Container Networking

Docker, Kubernetes, CNI, Service Mesh

​
Next Module

Module 9: IP Addressing Mastery

Deep dive into CIDR, subnetting, and private vs public IP addressing.

​
Interview Deep-Dive

Strong Answer:
  • SDN separates the control plane (decision-making about where traffic goes) from the data plane (actually forwarding packets). In traditional networking, each router and switch makes independent forwarding decisions. SDN centralizes decision-making into a software controller, and network devices become simple forwarding engines.
  • Cloud engineers need to understand SDN because every major cloud platform — AWS VPC, Azure VNet, GCP VPC — is fundamentally SDN. When you create a VPC, define subnets, configure route tables, or set up security groups, you are programming a software-defined network. There are no physical routers being configured.
  • This means concepts like route tables, security groups, and NACLs are SDN abstractions. When you add a route sending 10.0.0.0/16 to a NAT Gateway, you are programming a flow rule into the SDN controller, which programs the hypervisor on every host in your VPC. Understanding this explains why VPC route table changes take effect almost instantly versus traditional routing where convergence takes seconds to minutes.
  • The practical implication is that networking in the cloud is programmable via APIs. This enables infrastructure-as-code (Terraform), automated topology changes during deployments, and programmatic security policy enforcement.
Follow-up: What is the difference between the control plane and the data plane, and what happens if the controller goes down?The control plane builds and maintains the routing table — it runs routing protocols, processes topology changes, and computes optimal paths. The data plane does the actual packet forwarding based on those decisions. Separating them allows centralized intelligence with distributed performance. If the controller goes down, the data plane continues forwarding based on the last set of rules it received — existing flows keep working, but new flows or topology changes cannot be handled. This is why production SDN deployments always run controller clusters. In cloud environments, the SDN controller is the cloud platform itself, running with extreme redundancy.
Strong Answer:
  • Adoption has been slow for three reasons. First, NAT extended IPv4’s life far beyond expectations by letting millions of devices share a single public IP. Second, the transition cost is enormous — every router, firewall, load balancer, monitoring tool, and application must support IPv6. Third, there is no direct interoperability between IPv6-only and IPv4-only hosts without translation mechanisms like NAT64/DNS64.
  • As of 2025, roughly 40-45% of internet traffic is IPv6, driven by mobile carriers and large cloud providers. Google, Facebook, and most CDNs fully support it. But many corporate networks and smaller ISPs remain IPv4-only.
  • For new systems, I design for dual-stack. All major cloud providers support dual-stack VPCs. On the internet-facing edge, enable IPv6 on load balancers and CDN. Internally, most organizations still use IPv4 with RFC 1918 addresses because the tooling is mature. The exception is IoT or mobile-first services where IPv6 is already dominant.
  • Avoid hardcoded IPv4 assumptions: do not store IPs in 32-bit integers, do not use regex that only matches dotted-decimal format. Make data models flexible for both address families.
Follow-up: What practical differences would an engineer notice when working with IPv6 versus IPv4?The biggest differences are: address format (128-bit hex in colons versus 32-bit dotted decimal), no NAT by default (every device gets a globally unique address), auto-configuration via SLAAC (devices generate their own addresses without DHCP), and no broadcast (IPv6 uses multicast instead). In packet captures you see NDP (Neighbor Discovery Protocol) instead of ARP. In firewall rules, you need separate IPv4 and IPv6 rule sets — a common security gap is locking down IPv4 rules but leaving IPv6 wide open. In DNS, AAAA records replace A records. URLs with literal IPv6 addresses require brackets: http://[2001:db8::1]:8080/.
Strong Answer:
  • Two primary options: AWS Site-to-Site VPN and AWS Direct Connect. VPN creates encrypted IPsec tunnels over the public internet. Direct Connect is a dedicated private fiber connection from your data center to an AWS facility.
  • VPN is cheaper (around $36/month) and faster to set up (hours). The downside is variable latency, bandwidth limited by your internet connection, and internet congestion. AWS provides two redundant IPsec tunnels per connection.
  • Direct Connect provides consistent, low-latency connectivity with dedicated bandwidth (1 Gbps or 10 Gbps). It bypasses the public internet. The downsides are cost (thousands per month), lead time (weeks to provision), and requiring connectivity to an AWS Direct Connect location.
  • My recommendation: start with VPN for development and testing, Direct Connect for production latency-sensitive workloads. Run both simultaneously — Direct Connect primary, VPN failover. For CIDR planning, ensure on-premises ranges do not overlap with VPC ranges.
Follow-up: What happens if the Direct Connect link fails?If VPN is configured as backup, BGP handles failover automatically. Both Direct Connect and VPN advertise routes via BGP. Direct Connect routes are preferred (lower local preference or shorter AS path). When Direct Connect goes down, those routes are withdrawn and VPN routes become the best path. Failover time depends on BGP timers — default hold time is 90 seconds, but BFD (Bidirectional Forwarding Detection) can reduce it to 10-30 seconds. The caveat is VPN bandwidth is typically much lower — if you were pushing 5 Gbps over Direct Connect, VPN might only handle 1.25 Gbps. Plan for this degraded mode or provision multiple VPN connections for aggregate bandwidth.