7a:T486,# Create a network namespace (simulating a container) sudo ip netns add container_ns # Create a veth pair # veth-host: will stay in the host namespace # veth-container: will be moved into the container namespace sudo ip link add veth-host type veth peer name veth-container # Move one end into the container namespace sudo ip link set veth-container netns container_ns # Verify: veth-container is now GONE from host namespace ip link show | grep veth # Only shows: veth-host # But it exists in the container namespace sudo ip netns exec container_ns ip link show # Shows: lo, veth-container # Configure IP addresses # Host side sudo ip addr add 172.17.0.1/24 dev veth-host sudo ip link set veth-host up # Container side sudo ip netns exec container_ns ip addr add 172.17.0.2/24 dev veth-container sudo ip netns exec container_ns ip link set veth-container up sudo ip netns exec container_ns ip link set lo up # Test connectivity! sudo ip netns exec container_ns ping -c 2 172.17.0.1 # SUCCESS: Container can reach host via veth pair ping -c 2 172.17.0.2 # SUCCESS: Host can reach container # The veth pair creates a Layer 2 tunnel between namespaces7b:T425,flowchart TB subgraph HOST["Host Machine"] subgraph HOSTNS["Host Network Namespace"] eth0["eth0 (Physical NIC) 192.168.1.100"] docker0["docker0 (Linux Bridge) 172.17.0.1/16"] veth1["veth1"] veth2["veth2"] veth3["veth3"] iptables["iptables NAT (masquerade)"] end subgraph C1["Container 1 Namespace"] eth0_c1["eth0 (172.17.0.2)"] end subgraph C2["Container 2 Namespace"] eth0_c2["eth0 (172.17.0.3)"] end subgraph C3["Container 3 Namespace"] eth0_c3["eth0 (172.17.0.4)"] end end eth0 <--> iptables iptables <--> docker0 docker0 --- veth1 & veth2 & veth3 veth1 <-->|"veth pair"| eth0_c1 veth2 <-->|"veth pair"| eth0_c2 veth3 <-->|"veth pair"| eth0_c3 style HOST fill:#0d1117,stroke:#30363d style HOSTNS fill:#161b22,stroke:#00d9ff style C1 fill:#1a1a2e,stroke:#ff6b6b style C2 fill:#1a1a2e,stroke:#4ade80 style C3 fill:#1a1a2e,stroke:#fbbf247c:T492,# When you run: docker run -p 8080:80 nginx # Docker creates rules equivalent to: # 1. DNAT rule in nat table PREROUTING chain # Packets arriving at host:8080 get destination rewritten to container:80 sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 \ -j DNAT --to-destination 172.17.0.2:80 # 2. Also needed: DNAT for localhost access # (PREROUTING doesn't catch traffic from the host itself) sudo iptables -t nat -A OUTPUT -p tcp --dport 8080 \ -j DNAT --to-destination 172.17.0.2:80 # 3. Masquerade rule for container replies (already set up for general access) # Ensures return traffic has correct source IP sudo iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE # View Docker's actual NAT rules sudo iptables -t nat -L -n -v | grep docker # DOCKER chain contains the port mapping rules sudo iptables -t nat -L DOCKER -n -v # Example output: # Chain DOCKER (2 references) # pkts bytes target prot opt in out source destination # 0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0 # 5 260 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:8072:{"json":{"id":"seed_92ab088a2b012c2262e1f3ef601b01fc","slug":"containerized-networking","category":"Computer Networks","topic":"Containerized Networking","title":"Containerized Networking","description":"Master the intricate networking mechanisms that power modern container orchestration. From Linux namespaces and virtual Ethernet pairs to Kubernetes networking models and service mesh architectures, this module provides the deep understanding needed to design, deploy, and troubleshoot container networking in production environments.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_94402b589b176763c1b1bba1ba97ac8a","title":"Container Networking Fundamentals","order":0,"content":[{"id":"opening-hook","title":"The Containerization Paradigm Shift","content":[{"data":{"content":"In 2013, Docker introduced a paradigm that would fundamentally transform how we build, deploy, and operate software. Containers—lightweight, portable, and isolated execution environments—enabled developers to package applications with their dependencies and run them consistently across any infrastructure. But beneath this deceptively simple abstraction lies a sophisticated networking layer that makes it all possible.\n\n**Container networking is where operating systems, network protocols, and distributed systems converge.** Understanding it deeply is essential for anyone operating modern infrastructure, from single-host Docker deployments to globe-spanning Kubernetes clusters serving billions of requests."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the fundamental building blocks of container networking: Linux namespaces for isolation, virtual Ethernet pairs for connectivity, bridge networks for host-local communication, and the challenges that arise when containers need to communicate across hosts. You'll see how containers are not virtual machines—and why that distinction creates unique networking requirements.","variant":"info"},"type":"callout"}]},{"id":"containers-vs-vms","title":"Containers vs Virtual Machines: A Networking Perspective","content":[{"data":{"content":"Before diving into container networking specifics, we must understand what makes containers fundamentally different from virtual machines—and why this difference creates unique networking challenges and opportunities.\n\n**Virtual Machines (VMs)** emulate complete hardware environments. Each VM runs its own operating system kernel, has its own network stack implementation, and appears to the hypervisor as an independent machine with dedicated virtual network interface cards (vNICs). VM networking leverages decades of established paradigms: assign IP addresses, configure virtual switches, apply firewall rules—the same concepts used for physical servers.\n\n**Containers** share the host operating system's kernel. They don't emulate hardware; instead, they use kernel features to create isolated process environments. This fundamental architectural difference means container networking cannot simply replicate VM networking patterns. Containers require new abstractions."},"type":"text"},{"data":{"rows":[["Kernel","Own kernel per VM","Shared host kernel","Containers use kernel networking features directly"],["Network Stack","Full stack per VM","Virtualized via namespaces","Containers share kernel's TCP/IP implementation"],["Startup Time","Minutes","Milliseconds","Network setup must be instantaneous"],["Density","10-20 per host","100-1000+ per host","IP address exhaustion becomes critical concern"],["Isolation","Hardware-level (hypervisor)","Process-level (kernel)","Security boundaries require careful network isolation"],["Network Identity","Persistent MAC/IP","Ephemeral by default","Traditional networking assumptions break"]],"caption":"Architectural Comparison: VM vs Container Networking","headers":["Aspect","Virtual Machine","Container","Networking Implication"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Ephemerality Problem","content":"Containers are designed to be ephemeral—created and destroyed in milliseconds. Traditional networking assumes relatively static endpoints with persistent addresses. This mismatch creates profound challenges: how do you route traffic to something that might not exist a second from now? How do you maintain connections when containers are recycled? These questions drive the evolution of container networking solutions.","variant":"warning"},"type":"callout"},{"data":{"content":"**The density challenge:**\n\nA single physical host might run 500+ containers simultaneously, each requiring network connectivity. Traditional approaches of assigning one IP per workload would exhaust address space rapidly. Container networking solutions must address:\n\n- **Address space efficiency**: How do hundreds of containers share limited IP addresses?\n- **Port management**: How do multiple containers expose services without port conflicts?\n- **Routing scalability**: How does traffic find the right container among thousands?\n- **Performance overhead**: How do we minimize the cost of network virtualization at scale?\n\nThese requirements drove the development of container-specific networking primitives and patterns we'll explore throughout this module."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"linux-namespaces","title":"Linux Namespaces: The Isolation Foundation","content":[{"data":{"content":"Container isolation is built upon **Linux namespaces**—a kernel feature that partitions system resources so that one set of processes sees a different view than another. Namespaces create the illusion that a container has its own isolated environment, even though it shares the kernel with all other containers on the host.\n\nLinux provides several namespace types, each isolating a different aspect of the system. For container networking, the **network namespace** is paramount, but understanding the full picture reveals how containers achieve comprehensive isolation."},"type":"text"},{"data":{"rows":[["Network (net)","Network stack, interfaces, routing","Each container has own network identity","**Critical** - Core of container networking"],["Mount (mnt)","Filesystem mount points","Containers see own filesystem view","Low - But affects /etc/hosts, /etc/resolv.conf"],["PID","Process IDs","Container processes numbered from 1","Low - Network processes appear isolated"],["UTS","Hostname and domain","Container has own hostname","Medium - Affects network identity/DNS"],["IPC","Inter-process communication","Shared memory isolated per container","Low - But may affect local communication patterns"],["User","User and group IDs","Container can have root without host root","Medium - Affects network capability permissions"],["Cgroup","Cgroup root directory","Resource limits isolated","Low - But cgroups limit network bandwidth"]],"caption":"Linux Namespace Types and Their Roles in Container Isolation","headers":["Namespace","Isolates","Container Impact","Networking Relevance"]},"type":"table"},{"data":{"content":"**Deep Dive: The Network Namespace**\n\nThe network namespace is the cornerstone of container networking. Each network namespace contains:\n\n1. **Network interfaces**: Each namespace has its own set of network interfaces, including the loopback (lo) interface. A container's eth0 is completely separate from another container's eth0.\n\n2. **IP addresses**: IP addresses are bound to interfaces within a namespace. The same IP can exist in different namespaces simultaneously without conflict.\n\n3. **Routing tables**: Each namespace maintains its own routing table, determining how packets are forwarded.\n\n4. **Firewall rules (iptables/nftables)**: Packet filtering rules are namespace-specific, enabling per-container firewalling.\n\n5. **Socket bindings**: Ports are namespace-scoped. Two containers can both bind to port 80 without conflict.\n\n6. **Network-related sysctls**: Kernel tuning parameters like TCP settings can be namespace-specific."},"type":"text"},{"data":{"code":"# View current network namespace (default is 'init' namespace)\nip netns list\n\n# Create a new network namespace\nsudo ip netns add my_container_ns\n\n# Execute commands inside the namespace\nsudo ip netns exec my_container_ns ip addr show\n# Output: Only shows loopback (lo), in DOWN state\n\n# Notice: the namespace is completely isolated - no eth0, no connectivity\n\n# Compare to host namespace\nip addr show\n# Output: Shows all host interfaces (eth0, lo, docker0, etc.)\n\n# Each namespace has independent routing\nsudo ip netns exec my_container_ns ip route show\n# Output: Empty - no routes configured\n\n# And independent iptables rules\nsudo ip netns exec my_container_ns iptables -L\n# Output: Empty chains - no rules\n\n# Clean up\nsudo ip netns delete my_container_ns","fileName":"namespace-exploration.sh","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Namespace Implementation Detail","content":"Network namespaces are implemented in the kernel via the CLONE_NEWNET flag to the clone() or unshare() system calls. When Docker creates a container, it calls unshare(CLONE_NEWNET) to create a new network namespace. The container's processes then run within this namespace, completely isolated from the host's network stack by default.","variant":"tip"},"type":"callout"},{"data":{"content":"**The isolation-connectivity paradox:**\n\nHere lies the central challenge: a freshly created network namespace is completely isolated. It can't communicate with the host, other containers, or the outside world. The namespace has achieved perfect isolation—but also perfect uselessness.\n\nContainer networking must solve this paradox: **how do we provide connectivity while maintaining isolation?** The answer lies in virtual network devices that can bridge namespaces while preserving security boundaries."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"virtual-ethernet-pairs","title":"Virtual Ethernet Pairs: Connecting Namespaces","content":[{"data":{"content":"**Virtual Ethernet pairs (veth)** are the primary mechanism for connecting network namespaces. A veth pair consists of two virtual network interfaces that act as a tunnel: packets sent through one end emerge from the other, regardless of which namespace each end resides in.\n\nThink of a veth pair as a virtual Ethernet cable with two ends. You can place each end in a different namespace, creating a dedicated communication channel between them. This is how containers connect to the host network and, through it, to the outside world."},"type":"text"},{"data":{"height":"320px","mermaidSyntax":"flowchart LR\n subgraph HOST[\"Host Network Namespace\"]\n veth_host[\"veth-host\n(172.17.0.1)\"]\n bridge[\"docker0 bridge\n(172.17.0.1)\"]\n eth0[\"eth0 (Physical)\n(192.168.1.100)\"]\n end\n subgraph CONTAINER[\"Container Network Namespace\"]\n eth0_container[\"eth0\n(172.17.0.2)\"]\n lo_container[\"lo\n(127.0.0.1)\"]\n end\n eth0_container <-->|\"veth pair\nvirtual cable\"| veth_host\n veth_host --> bridge\n bridge --> eth0\n style HOST fill:#1a1a2e,stroke:#00d9ff\n style CONTAINER fill:#1a1a2e,stroke:#ff6b6b"},"type":"mermaid-excalidraw"},{"data":{"code":"$7a","fileName":"veth-pair-creation.sh","showLineNumbers":true},"type":"code"},{"data":{"content":"**How veth pairs work internally:**\n\n1. **Kernel datastructure linking**: When you create a veth pair, the kernel creates two `net_device` structures that point to each other. Each has a `peer` pointer to its partner.\n\n2. **Packet transmission**: When the network stack calls `dev_queue_xmit()` on one veth interface, instead of going to hardware, the driver's `xmit` function directly calls `netif_rx()` on the peer interface in the other namespace.\n\n3. **No copying overhead**: The packet's `sk_buff` structure (Linux kernel's representation of a network packet) is passed directly between namespaces. There's minimal copying—just pointer manipulation.\n\n4. **Bidirectional by nature**: veth pairs are inherently bidirectional—they act as a pipe, not a one-way valve."},"type":"text"},{"data":{"icon":"Info","title":"Performance Characteristics","content":"Veth pairs add minimal latency (typically <5 microseconds) compared to physical interfaces. However, every packet traverses both interfaces and the bridge (if used), which means CPU overhead scales with packet count rather than byte count. High packet-per-second (PPS) workloads are more affected than high-throughput, large-packet workloads.","variant":"note"},"type":"callout"},{"data":{"items":["**Always created in pairs** — You cannot create a single veth interface; they come as connected pairs.","**One end can be moved to any namespace** — This is how containers get their network interface.","**Deleting one end deletes both** — The pair is atomic; you can't have a dangling veth.","**Layer 2 device** — Operates at Ethernet frame level, has MAC addresses, can be bridged.","**Supports VLANs and QoS** — Can apply tc (traffic control) rules, VLAN tags, etc.","**Checksum offload works** — The kernel maintains consistency, no extra CPU overhead."],"title":{"icon":"CheckCircle","text":"Veth Pair Key Properties","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"bridge-networking","title":"Linux Bridge Networking","content":[{"data":{"content":"With veth pairs, we can connect individual containers to the host namespace. But what about connecting containers to each other? And what about connecting them to the outside world?\n\nThe **Linux bridge** (software-defined switch) solves this. A bridge acts as a Layer 2 (Ethernet) switch: it learns MAC addresses, forwards frames between connected interfaces, and maintains a forwarding table exactly like a physical switch.\n\nDocker's default `docker0` bridge is the canonical example. Every container (in bridge mode) gets a veth pair: one end attached to docker0, the other placed inside the container as its eth0."},"type":"text"},{"data":{"height":"420px","mermaidSyntax":"$7b"},"type":"mermaid-excalidraw"},{"data":{"content":"**Bridge operation details:**\n\n1. **MAC learning**: When a frame arrives on a bridge port, the bridge records which MAC address lives behind which port. This is the forwarding database (FDB).\n\n2. **Frame forwarding**: When a frame arrives, the bridge looks up the destination MAC in the FDB. If found, it forwards only to that port. If unknown, it floods to all ports (except the source).\n\n3. **Local addresses**: The bridge itself has a MAC and IP address (172.17.0.1 for docker0). Frames destined for this address are delivered to the host's network stack.\n\n4. **External connectivity**: For containers to reach the internet, packets must be NAT'd (masqueraded) by iptables. The source IP (container's private address) is replaced with the host's public IP."},"type":"text"},{"data":{"code":"# Create a bridge (similar to what Docker creates)\nsudo ip link add docker0 type bridge\nsudo ip addr add 172.17.0.1/16 dev docker0\nsudo ip link set docker0 up\n\n# Enable IP forwarding (required for routing between containers and outside)\nsudo sysctl -w net.ipv4.ip_forward=1\n\n# Add iptables rules for container internet access (NAT/masquerade)\nsudo iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE\n\n# Allow forwarding for container traffic \nsudo iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT\nsudo iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT\n\n# Now containers connected to docker0 can reach the internet!\n\n# View bridge status\nbridge link show docker0\nbrctl show docker0 # legacy command\n\n# View MAC forwarding database\nbridge fdb show br docker0","fileName":"bridge-setup.sh","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Bridge Scalability Limitations","content":"Linux bridges work well for tens to hundreds of containers on a single host. However, bridge broadcast domains don't scale well—MAC flooding and broadcast storms become problematic at large scale. Additionally, bridges are host-local; containers on different hosts cannot communicate via bridges alone. This limitation drives the need for overlay networks and more sophisticated solutions covered later in this module.","variant":"warning"},"type":"callout"},{"data":{"type":"ordered","items":["**Container 1 sends packet to Container 2's IP** — The packet has src=172.17.0.2, dst=172.17.0.3","**Container 1 checks routing table** — Destination is on the same subnet, so send directly (no gateway needed)","**ARP resolution** — Container 1 sends ARP 'who has 172.17.0.3?' broadcast","**Bridge forwards ARP** — The broadcast floods to all container-attached veths","**Container 2 responds** — 'I have 172.17.0.3, my MAC is xx:xx:xx:xx:xx:xx'","**Frame transmission** — Container 1 sends Ethernet frame to Container 2's MAC","**Bridge learns and forwards** — Updates FDB, forwards frame only to Container 2's veth port","**Delivery via veth pair** — Frame traverses veth pair into Container 2's namespace"],"title":{"icon":"Target","text":"Container-to-Container Communication via Bridge","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"port-mapping-nat","title":"Port Mapping and Network Address Translation","content":[{"data":{"content":"Containers on a bridge network have private IP addresses (like 172.17.0.x) that are not routable from the outside world. For external clients to reach containerized services, we need **port mapping** (also called port publishing or port forwarding).\n\nWhen you run `docker run -p 8080:80 nginx`, you're instructing Docker to:\n1. Listen on host port 8080\n2. Forward incoming connections to container port 80\n3. Translate return traffic back to the original client\n\nThis is implemented using Linux **iptables NAT rules**, specifically DNAT (Destination NAT) for incoming traffic."},"type":"text"},{"data":{"code":"$7c","fileName":"port-mapping-iptables.sh","showLineNumbers":true},"type":"code"},{"data":{"content":"**The NAT packet flow:**\n\n**Inbound request (client → container):**\n1. Client sends packet to `HOST_IP:8080`\n2. Packet arrives at host's network interface\n3. PREROUTING chain evaluates DNAT rule\n4. Destination rewritten: `172.17.0.2:80`\n5. Routing decision: forward to docker0 bridge\n6. Bridge forwards to container's veth\n7. Container receives request on port 80\n\n**Outbound response (container → client):**\n1. Container sends response to original client IP\n2. Packet leaves container via veth\n3. Bridge forwards to host's network stack\n4. POSTROUTING chain evaluates masquerade rule\n5. Source IP rewritten from `172.17.0.2` to `HOST_IP`\n6. Connection tracking ensures correct translation\n7. Response sent to client with host's IP as source"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Connection Tracking (conntrack)","content":"Linux's connection tracking subsystem (conntrack) maintains state for every connection, enabling stateful NAT. It remembers the original destination of DNAT'd packets so return traffic can be correctly translated. View connection tracking entries with: sudo conntrack -L","variant":"tip"},"type":"callout"},{"data":{"left":[{"data":{"items":["**Works with private IP addresses** — Containers don't need public IPs","**Port flexibility** — Map any host port to any container port","**Multiple services per IP** — Different containers on different ports","**Simple firewall integration** — Control at host level"],"title":{"icon":"CheckCircle","text":"Port Mapping Advantages","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Port conflicts** — Two containers can't map to the same host port","**NAT overhead** — CPU cost for translation at high PPS","**Breaks some protocols** — Protocols embedding IPs (SIP, FTP active mode)","**Debugging complexity** — Tracing through NAT adds cognitive load"],"title":{"icon":"XCircle","text":"Port Mapping Limitations","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"}],"titleType":"number","titleNumber":5},{"id":"network-models","title":"Container Network Models","content":[{"data":{"content":"Container runtimes like Docker support multiple network modes, each with different isolation, performance, and connectivity characteristics. Understanding these modes is essential for choosing the right networking approach for your use case."},"type":"text"},{"data":{"rows":[["**bridge** (default)","High","Good","Most applications; inter-container communication with external access","`docker run --network bridge ...`"],["**host**","None","Best","Performance-critical apps; when port flexibility isn't needed","`docker run --network host ...`"],["**none**","Complete","N/A","Security-sensitive workloads requiring no network access","`docker run --network none ...`"],["**container:id**","Shared with specified container","Good","Sidecar patterns; tightly coupled containers","`docker run --network container:nginx ...`"],["**macvlan**","L2 isolation","Excellent","When containers need real network identities","`docker run --network my_macvlan ...`"],["**ipvlan**","L3 isolation","Excellent","L3-aware environments; avoids MAC issues","`docker run --network my_ipvlan ...`"]],"caption":"Docker Network Modes Comparison","headers":["Mode","Isolation","Performance","Use Case","Command Example"]},"type":"table"},{"data":{"tabs":[{"id":"host-mode","label":"Host Mode","content":[{"data":{"content":"In **host mode**, the container shares the host's network namespace entirely. There's no network isolation—the container sees all host interfaces, uses the host's IP address, and binds directly to host ports.\n\n**When to use:**\n- Performance-critical applications where veth/bridge overhead matters\n- Applications that need to see all network traffic (monitoring tools)\n- When you need to bind to privileged ports (<1024) without special configuration\n- Legacy applications that assume a traditional network environment"},"type":"text"},{"data":{"code":"# Run nginx in host mode - no network isolation\ndocker run -d --network host nginx\n\n# nginx now binds directly to host's port 80\n# (no -p flag needed)\ncurl localhost:80\n# Served by nginx\n\n# Inside the container, you see host's interfaces\ndocker exec ip addr\n# Shows eth0, docker0, etc. (same as host)\n\n# Performance benefit: no veth crossing, no bridge, no NAT\n# But: complete loss of network isolation","fileName":"host-mode.sh","showLineNumbers":true},"type":"code"}],"titleIcon":"Zap"},{"id":"macvlan-mode","label":"Macvlan Mode","content":[{"data":{"content":"**Macvlan** assigns a unique MAC address to each container, making them appear as distinct physical devices on the network. Containers can have routable IPs on the same subnet as the host, enabling direct L2 communication with other network devices.\n\n**When to use:**\n- Migrating applications that expect a 'real' network interface\n- When containers need to be directly accessible without NAT\n- Integration with network infrastructure that expects distinct MAC addresses\n- When you need maximum network performance with isolation"},"type":"text"},{"data":{"code":"# Create a macvlan network on eth0\ndocker network create -d macvlan \\\n --subnet=192.168.1.0/24 \\\n --gateway=192.168.1.1 \\\n -o parent=eth0 \\\n my_macvlan\n\n# Run container with a specific IP\ndocker run -d --network my_macvlan \\\n --ip 192.168.1.200 \\\n nginx\n\n# Container is directly reachable at 192.168.1.200\n# from anywhere on the 192.168.1.0/24 network\n\n# Note: Host cannot directly communicate with macvlan containers\n# (unless you create a macvlan interface on the host too)","fileName":"macvlan-setup.sh","showLineNumbers":true},"type":"code"}],"titleIcon":"Target"},{"id":"none-mode","label":"None Mode","content":[{"data":{"content":"The **none** mode gives the container an isolated network namespace with only a loopback interface. No external connectivity is possible unless you manually configure it.\n\n**When to use:**\n- Security-sensitive batch jobs that don't need network access\n- Preventing data exfiltration from untrusted code\n- Unit testing in isolation\n- As a base for custom network configuration"},"type":"text"},{"data":{"code":"# Run container with no networking\ndocker run -d --network none myapp\n\n# Inside the container\ndocker exec ip addr\n# Shows only:\n# 1: lo: ...\n# inet 127.0.0.1/8 scope host lo\n\n# No external connectivity whatsoever\ndocker exec ping google.com\n# ping: bad address 'google.com'\n\n# Useful for air-gapped processing of sensitive data","fileName":"none-mode.sh","showLineNumbers":true},"type":"code"}],"titleIcon":"AlertCircle"}]},"type":"tabs"}],"titleType":"number","titleNumber":6},{"id":"summary-path-forward","title":"Summary: Container Networking Fundamentals","content":[{"data":{"content":"We've covered the foundational building blocks that make container networking possible. These primitives—namespaces, veth pairs, bridges, and NAT—form the substrate upon which all container networking solutions are built."},"type":"text"},{"data":{"type":"ordered","items":["**Containers are not VMs** — They share the host kernel and use kernel features (namespaces) for isolation, creating unique networking requirements.","**Network namespaces provide isolation** — Each container has its own network stack: interfaces, routing, firewall rules, and port bindings.","**Veth pairs connect namespaces** — These virtual Ethernet tunnels allow packets to flow between the isolated container world and the host.","**Linux bridges act as virtual switches** — They enable container-to-container communication and form the foundation of default Docker networking.","**NAT enables external connectivity** — iptables DNAT/SNAT rules allow containers with private IPs to communicate with the outside world.","**Multiple network modes exist** — Bridge, host, macvlan, ipvlan, and none modes offer different isolation/performance tradeoffs."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nIn the next page, we'll take a deep dive into **Docker Networking** specifically—exploring Docker's network drivers, custom bridge networks, DNS-based service discovery, and the nuances of container networking in Docker Compose and Swarm environments."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental Linux primitives that power container networking. These concepts—namespaces, veth pairs, bridges, and NAT—appear in every container networking solution, from simple Docker deployments to complex Kubernetes clusters. Master these, and the advanced topics will follow naturally.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_da961f9972945636ce405561922f404a","title":"Docker Networking Deep Dive","order":1,"content":null,"isLocked":true},{"id":"seed_90118f0d368fd7312fab683e06b2e35f","title":"Kubernetes Networking","order":2,"content":null,"isLocked":true},{"id":"seed_493e71e2174ea0c67ad508d94642538b","title":"Service Mesh Architecture","order":3,"content":null,"isLocked":true},{"id":"seed_99c166d0c13419707120c633dca5eb31","title":"CNI Plugins Deep Dive","order":4,"content":null,"isLocked":true}]}}