The virtual network lab: namespaces, bridges and OvS

1. Why build a virtual network at all

The virtual network infrastructure of chapter 2 was described from the outside; here it is built from the inside, by hand, on a single Linux machine. The motivation stated in the lab is the same one that justified emulation in general: computer networks are complex — several devices, several interfaces, several protocols running, and physical interconnections that originate complex topologies — and you cannot experiment on a live one.

The physical picture the lab starts from is worth keeping in mind, because the whole exercise is to reproduce it on one host:

• A physical network is a TCP/IP protocol stack, bound to a Network Interface Card, plugged by a cable into a Layer 2 switch (bridge).
• A virtual network runs many separate TCP/IP stacks on the same physical machine, each attached to a virtual network interface, all wired to a software Layer 2 switch, which finally reaches the one physical NIC.

The mapping from physical roles to Linux constructs is the plan for the whole chapter:

Why namespaces first? Because network namespaces are the foundation of network isolation in Linux: they isolate network devices, isolate the IPv4 and IPv6 stacks, isolate routing tables and firewall rules, and isolate sockets and port spaces. They are the basic building block behind many virtual networking systems — including the Docker bridge driver from chapter 2 and the Kathará containers of chapter 11.

2. The building blocks: namespaces, veth, bridges, switches

The lab uses the modern ip suite throughout. The commands below are the complete vocabulary you need to build any topology in this chapter; the annotated view groups them by the object they act on.

Managing namespaces

ip netns add NAMESPACE       # create a namespace
ip netns del NAMESPACE       # delete a namespace
ip netns list                # list existing namespaces
ip netns exec NAMESPACE CMD  # run CMD inside NAMESPACE
ip netns monitor             # report namespace events

Creating links and connecting them

# a virtual Ethernet cable with two plugs
ip link add NAME1 type veth peer name NAME2

# a plug can be given a fixed MAC address
ip link add veth0 address "00:00:00:11:11:11" type veth peer name eth-H11

# a Linux bridge: an unmanaged Ethernet LAN switch
ip link add NAME type bridge

# plug one end of a veth into a namespace, the other into a bridge
ip link set NAME netns NAMESPACE     # attach the plug to a namespace
ip link set NAME master BRIDGE       # attach the plug to a bridge

Open vSwitch

ovs-vsctl show                  # list the active switches
ovs-vsctl add-br SW             # create a new switch
ovs-vsctl add-port N_SW N_VETH  # connect a veth end to a switch

Open vSwitch is described as a more recent implementation with more advanced features than the Linux bridge. That difference is not cosmetic: the Linux bridge is a plain unmanaged switch, while OvS is OpenFlow-enabled and is exactly the kind of programmable virtual switch a controller can drive — the reason chapter 3's controller had something to talk to, and the reason the VLAN and tunnelling exercises later in this chapter reach for ovs-vsctl.

3. Exercises 1 to 3: two hosts, three ways to connect them

The first three exercises are the same goal — a point-to-point IP network between two namespaces on 172.0.0.0/30 — solved with three different Layer 2 fabrics. Doing the same thing three ways is the point: it isolates what the fabric does from what the hosts do.

Three checks are required after each: names must be unique within each namespace, the ARP tables must be inspected, and connectivity must be verified. The reference topology for exercise 2/3 is one namespace on each side, a veth from each into the switch:

A concrete, complete version of exercise 3 (Open vSwitch) reads as follows. Every line maps to one of the building blocks above:

# 1. create the two host namespaces
ip netns add Host1
ip netns add Host2

# 2. create two veth cables and hand one plug of each to a host
ip link add veth1 type veth peer name sw-p1
ip link add veth2 type veth peer name sw-p2
ip link set veth1 netns Host1
ip link set veth2 netns Host2

# 3. create the switch and plug the other ends into it
ovs-vsctl add-br SW1
ovs-vsctl add-port SW1 sw-p1
ovs-vsctl add-port SW1 sw-p2
ip link set sw-p1 up
ip link set sw-p2 up

# 4. address the hosts on 172.0.0.0/30 and bring the plugs up
ip netns exec Host1 ip addr add 172.0.0.1/30 dev veth1
ip netns exec Host1 ip link set veth1 up
ip netns exec Host2 ip addr add 172.0.0.2/30 dev veth2
ip netns exec Host2 ip link set veth2 up

# 5. check
ip netns exec Host1 ping -c1 172.0.0.2
ip netns exec Host1 ip neigh          # the arp table, the modern way

4. One switch, one LAN, then two LANs

Exercise 4 scales the switch out: one SW1 with four hosts, all on a single 10.0.1.0/24 network — one switch corresponds to one LAN, a single broadcast domain. Connectivity is tested across all four.

Exercise 5 makes the pivotal change with almost no new equipment: the same four hosts, the same single switch, but the addresses are split into two IP networks, 10.0.1.0/24 and 10.0.2.0/24. Reachability is tested — and the lesson is delivered by what fails. Two hosts on the same switch but on different IP networks cannot reach each other, because a switch does not route between IP networks; it only forwards within one broadcast domain.

5. Adding a router: inter-LAN routing

Exercise 6 adds a router R1 with one leg in each network — 10.0.1.254 on the first, 10.0.2.254 on the second — so the two IP networks can finally talk. A namespace becomes a router the moment it is allowed to forward between its interfaces (IP forwarding enabled) and the hosts point their default route at it.

Lab session 2 refines this into a routed topology with two switches, one per LAN, both connected to R1, and then chains more routers (R1, R2, R3, R4) across intermediate /30 networks. The single most important sentence of the whole routing lab is stated as the "main message to remember":

Manual routes are added with a single command, repeated on every router that needs to know about a remote network:

ip route add <network> via <gateway address>

# e.g. on R1, teach it how to reach the far LAN through R2
ip netns exec R1 ip route add 10.0.2.0/24 via 192.168.0.5

Use the reachability walker below to feel the "every router must know every prefix" rule directly: remove one route and watch a path go dark.

6. ARP, ip neigh and ARP poisoning

The lab makes the deprecation explicit: the arp command is deprecated, and the current tool to manage the ARP table is ip neigh. It shows a table with the IP address, the interface the information was received on, the corresponding MAC address, and a state. The states are worth knowing because they explain the timing behaviour of a LAN:

ARP poisoning

The security exercise turns this machinery into an attack, in the classic three phases. An attacker A (played in the lab by host H12) is connected to the LAN and:

1. Reconnaissance — gather useful information, in this case which IP hosts are active: arp-scan 10.0.1.0/24.
2. Scanning — capture traffic with Wireshark to understand which host is the network gateway.
3. Execution — launch the ARP poisoning to become Man In The Middle: arpspoof -i veth0 -t 10.0.0.11 -r 10.0.0.254.

The study steps use Wireshark on the gateway interface, print the ARP cache in H11 and R1, and run traceroute from H11 to H21 to see the detour. The attack is then made stealthy:

# stop the kernel from advertising a shorter path back
sysctl -w net.ipv4.conf.veth0.send_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0

# hide the extra hop from traceroute
iptables -A OUTPUT -o veth0 -p icmp --icmp-type time-exceeded -j DROP

7. NAT and MASQUERADE

Exercise 6 is then reworked so that the far side is a private network 192.168.0.0/24, and NAT is applied in R1. The lab uses iptables in the nat table:

# translate everything leaving R1, taking the source from the output interface
iptables -t nat -A POSTROUTING -j MASQUERADE

# reset the nat table and apply NAT one way only, on a specific interface
iptables -t nat -F
iptables -t nat -A POSTROUTING -o veth2 -j MASQUERADE

The verification method is instructive: open Wireshark in R1, ping from H11 to H21 analysing veth1 first and veth2 second, then ping the other way analysing veth2 first and veth1 second. Watching the same ping on the two legs of the router is how you actually see the address being rewritten.

MASQUERADE is a special case of source NAT: as the firewall deck (chapter 14) states, it works like SNAT but automatically assigns the packet the address of the output interface — which is why it is the natural choice for a gateway whose external address may change. The connection tracking that makes this work — first packet rewritten by the nat table, the rest handled automatically by conntrack, replies restored to the original address — is developed fully in chapter 14.

8. Forwarding tables and the two paths

The routing lab ends on a subtle and genuinely important point about the difference between a connection and its two directions. The observations from exercise 9 (the four-router topology) are:

• Interconnection does not work if forward and backward paths are not configured correctly.
• But forward and backward paths do not need to be the same.
• Analyse the forwarding tables of R1 and R2: who decides the forward and backward paths?

The answer the question is fishing for is that each router independently decides the next hop for a packet based on its own forwarding table and the packet's destination. Nobody decides a whole path; a path is what emerges from a sequence of independent local decisions. That is why a forward path and a return path can legitimately differ (asymmetric routing), and why a single wrong or missing entry anywhere along either direction is enough to break connectivity even though every other router is configured perfectly.

9. Virtual LANs and IEEE 802.1Q

Lab session 3 attacks the broadcast-domain problem from section 4. In general one switch corresponds to one LAN: broadcast messages go to all ports regardless of IP configuration, a single broadcast domain. For security and efficiency reasons it is better to separate the broadcast domains of different IP networks, and the switch must be configured accordingly. That is a Virtual LAN.

The problem with extended LANs

The interesting case is an extended LAN with multiple switches: how can we say to which VLAN an Ethernet frame belongs when it crosses the inter-switch interface? The answer is IEEE 802.1Q, which allows an Ethernet frame to specify its VLAN by adding a tag to the Ethernet header. Both ends of the cable must support 802.1Q, and the tag is also used to create virtual sub-interfaces on hosts and routers.

Port modes and the commands

# Open vSwitch: an access port on one VLAN
ovs-vsctl set port <interface> tag=<VLAN ID>

# a trunk port carrying several VLANs
ovs-vsctl set port <interface> trunks=ID1,ID2,ID3

# reset
ovs-vsctl clear port <interface> tag trunks vlan_mode

# on a namespace: a tagged sub-interface (router-on-a-stick)
ip link add link <interface> name <sub-interface> type vlan id <VLAN ID>
ip link del <sub-interface>

The last command is the mechanism behind the gateway with a single interface design: a router R1 with one physical leg carries both 10.0.1.254 and 10.0.2.254 as tagged sub-interfaces, and routes between the two VLANs over that one wire.

10. Tunnels: GRE and VXLAN

Lab session 4 starts from a concrete problem. Routing between R1 and R2 requires exchanging routing information across a wide area network — but what if the infrastructure is private and must not be disclosed to the public network? The solution: create a virtual direct connection between R1 and R2 over which the private routing information is exchanged. That virtual wire is a tunnel.

GRE

Generic Routing Encapsulation (GRE, RFC 1701) is a tunnelling protocol over IP for generic protocols. It prepends an outer IP header and a GRE header in front of the original packet — allowing, among other things, IP over IP. The GRE header carries a version, a protocol type (which protocol is encapsulated) and options: checksum, key (authentication of the packet source), sequence number (so the destination can reorder), and routing (source routing policy).

# enable GRE, then create the tunnel endpoint in each router
modprobe ip_gre

ip netns exec R1 ip tunnel add GT1 mode gre \
    remote 192.168.0.5 local 192.168.0.1 ttl 63
ip netns exec R1 ip link set GT1 up

# give the tunnel interface an address on both ends
ip netns exec R1 ip addr add 192.168.100.1/30 dev GT1

# route the tenant networks through the tunnel
ip netns exec R1 ip route add 10.0.2.0/24 via 192.168.100.2
ip netns exec R2 ip route add 10.0.1.0/24 via 192.168.100.1

VXLAN

Virtual Extensible LAN (VXLAN) is a highly scalable distributed Layer 2 overlay network for tenant traffic isolation in cloud computing environments. Its defining properties, straight from the slides:

• It encapsulates Layer 2 traffic in UDP packets (destination port 4789).
• It builds stateless tunnels between VXLAN Tunnel End Points (VTEPs).
• Each isolated L2 segment is identified by a 24-bit VXLAN Network Identifier (VNI) → 16 million VNIs.

That last figure is the punchline of the whole VLAN-to-VXLAN progression: 802.1Q gives you 12 bits and about 4000 segments; VXLAN gives you 24 bits and 16 million — enough to give every tenant of a large cloud its own isolated Layer 2 segment. The application scenario in the lab is exactly that: one single IP network extended over the global network, VXLAN transporting Ethernet frames — including ARP requests — over an IP network so that hosts on 192.168.1.0/24 behave as if they shared one LAN even though a routed network sits between them.

# a VXLAN interface: segment 100, UDP-encapsulated between two VTEPs
ip link add <name> type vxlan id 100 \
    local <local IP> remote <remote IP> nolearning dstport 4789

To make VXLAN carry a broadcast domain, the lab creates a virtual layer-2 broadcast domain using virtual bridges in the routers at the edges of the tunnel, and connects to those bridges every interface whose packets must cross the tunnel. GRE gave a point-to-point virtual wire between two routers; VXLAN gives a whole virtual switch stretched across an IP network.

Check your understanding