Learn Linux - Advanced Networking & Packet Analysis

#Introduction

After episode 20 where we covered Network File Sharing (NFS & Samba) & DNS Basics — building inter-server shares and understanding name resolution — you can now make machines work together. But there's one question still unanswered: how do you know what's really happening on the network? When an application is slow, NFS frequently times out, or an SSH session looks "suspicious", the diagnostic tools from episode 17 (ping, curl, ss) only give external indications. To see the actual packet contents, you need packet analysis.

This is a different episode from the previous ones. Here we don't just use ready-made tools — we start thinking like a network: reading packet headers, understanding how ethernet frames carry VLAN tags, and how Linux separates network worlds from each other via namespaces. These are the skills that distinguish a regular admin from one who can answer "why is this slow?" with evidence, not feelings.

In this episode 21, we'll cover four pillars: tcpdump for dissecting packet traffic, network bonding for resilience and throughput, VLAN for separating virtual networks, and network namespaces as the basis for isolated network experiments — capped with a glimpse of nftables which we already met in episode 19. This is also the final episode of this series' networking block.

#Main Discussion

#tcpdump: Stealing a Glimpse Inside Packets

tcpdump is the classic tool for packet capture on Linux. It works at the packet level — far deeper than ss or ping. Think of ss as looking at the guest list at the entrance, while tcpdump is like recording the entire conversation word for word.

sudo tcpdump -i eth0

sudo tcpdump -i eth0 -n

sudo tcpdump -i eth0 -c 10

The -n option isn't just cosmetic: without -n, tcpdump does reverse-DNS for every address — slow, and can raise questions on a production network. Always use -n.

Filtering with expressions. This is tcpdump's true power — BPF (Berkeley Packet Filter):

sudo tcpdump -i eth0 -n host 192.168.1.10

sudo tcpdump -i eth0 -n tcp port 443

sudo tcpdump -i eth0 -n udp port 53

sudo tcpdump -i eth0 -n icmp

#Saving to a .pcap File for Analysis with Wireshark

Capturing in the terminal is good, but deep analysis — following the TCP handshake flow, inspecting payloads — is far more comfortable in Wireshark. Save your captures to a .pcap file:

sudo tcpdump -i eth0 -n -w capture.pcap

sudo tcpdump -r capture.pcap

sudo tcpdump -r capture.pcap -n tcp port 443

Open capture.pcap in Wireshark to visually see the three-way TCP handshake flow (SYN, SYN-ACK, ACK) — a highly sought-after debugging skill in DevOps teams, aligned with the observability topics in other series.

#Network Bonding: Two Cables Are Stronger Than One

Network bonding combines several physical interfaces into one logical interface bond0. Its two goals: redundancy (one cable breaks, the connection stays alive) and throughput (traffic load spread across several cables).

The bonding modes you should know:

#Creating Bonding with Netplan (modern Ubuntu)

Netplan is the declarative way to manage networking on Ubuntu (briefly covered in episode 17). Config files live in /etc/netplan/:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      parameters:
        mode: active-backup
        primary: eth0
      addresses: [192.168.1.10/24]
      routes:
        - to: default
          via: 192.168.1.1

sudo netplan apply

cat /proc/net/bonding/bond0

#Creating Bonding with nmcli (RHEL/Rocky)

On the RHEL family, the default network manager is NetworkManager, and its command-line tool is nmcli:

sudo nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup

sudo nmcli connection add type bond-slave ifname eth0 master bond0
sudo nmcli connection add type bond-slave ifname eth1 master bond0

sudo nmcli connection modify bond0 ipv4.addresses 192.168.1.10/24
sudo nmcli connection modify bond0 ipv4.gateway 192.168.1.1

sudo nmcli connection up bond0

nmcli device status

#VLAN: Separating Virtual Networks on the Same Interface

VLAN (Virtual LAN) lets a single physical cable carry many isolated logical networks. Each VLAN is marked with a 12-bit tag (ID 1–4094) inside the ethernet frame. This is the common way to separate management traffic, service traffic, and guest traffic in a datacenter.

sudo ip link add link eth0 name eth0.100 type vlan id 100

sudo ip addr add 192.168.100.10/24 dev eth0.100
sudo ip link set eth0.100 up

ip -d link show eth0.100

With netplan, VLANs are declared permanently:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
  vlans:
    vlan100:
      id: 100
      link: eth0
      addresses: [192.168.100.10/24]

sudo netplan apply

#Network Namespaces: Isolated Network Worlds

Network namespaces are one of the technologies that make containers work — each container has its own network stack: interfaces, routing table, ARP table, and firewall rules fully separated. Understanding this is the bridge to Docker/Kubernetes in the later episodes of this series.

ip netns list

sudo ip netns add red
sudo ip netns add blue

sudo ip netns exec red ip addr

The two namespaces are fully isolated — they can't talk to each other until we create a veth pair (virtual ethernet) connecting them:

sudo ip link add veth-red type veth peer name veth-blue

sudo ip link set veth-red netns red
sudo ip link set veth-blue netns blue

sudo ip netns exec red ip addr add 10.0.0.1/24 dev veth-red
sudo ip netns exec red ip link set veth-red up
sudo ip netns exec blue ip addr add 10.0.0.2/24 dev veth-blue
sudo ip netns exec blue ip link set veth-blue up

sudo ip netns exec red ping -c 2 10.0.0.2

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.083 ms

Two virtual "worlds" can now talk. This is the core of container network architecture: every pod/container gets its own namespace, connected to each other and to the host via veth. You've seen the foundation before entering the container world in the coming episodes.

#A Glimpse of nftables: Touching Filtering at a New Level

In episode 19 we touched nftables as iptables' successor. In this deep-networking episode, let's complete the picture. nftables unifies all tables (filter, nat, mangle) in a single syntax and a single ruleset:

sudo nft list ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        tcp dport 22 accept
        ct state established,related accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

The rules above apply default-deny for input and forward, only accepting SSH and already-established connections. nftables' advantages: a clear hierarchy, better performance, and one tool (nft) for everything — unlike iptables which is split per table. Modern UFW and many new distros already use it as their backend.

#Common Mistakes (Common Pitfalls)

1. tcpdump without sudo. Without a raw socket, the command refuses to run. And don't capture on the wrong interface — check ip -brief addr first.

2. Bonding mode without switch support. Choosing 802.3ad without LACP on the switch = traffic jam. Start with active-backup if in doubt.

3. Forgetting to load the bonding module. On some kernels, the bonding module must be loaded first (remember /etc/modules-load.d/ from episode 16). The symptom: bond0 doesn't appear in ip link.

4. One-sided VLAN. A VLAN tag on the server without trunk config on the switch = silently lost packets. Always debug with tcpdump -i eth0 vlan.

5. Namespaces accidentally left behind. Namespaces aren't deleted at reboot, and can pile up on production systems. Clean them with ip netns del <name> after the experiment is done.

6. Changing the primary network config remotely without a backup. Netplan apply / nmcli up on the interface used by SSH = dropped session. Keep an alternative path first — the same lesson from episodes 18 and 19.

#Conclusion

In this episode 21, we've broken deeper into Linux's network layers: dissecting packets with tcpdump and saving them to .pcap for Wireshark analysis, building network resilience with network bonding (from active-backup to 802.3ad), separating segments with VLAN, experimenting with network namespaces and veth pairs — the real foundation of container network architecture — and completing the filtering picture with a glimpse of nftables.

Key points to take home:

• tcpdump is your third eye: without sudo, without the right interface, without clear filters, it won't help.
• active-backup bonding gives redundancy without touching the switch; other modes need infrastructure preparation.
• A VLAN is always two-sided — server and switch must be in sync, and tcpdump vlan is the best witness.
• Network namespaces are how Linux isolates networking — and they're the gateway to the container world.
• Every remote network change must have a rescue path.

With episode 21 complete, the networking block of the Belajar Linux series is finished: from the foundations in episode 17, secure access via SSH in episode 18, firewall defense in episode 19, file sharing in episode 20, to packet analysis in episode 21. In the next episode 22 we'll enter a new world that uses all this foundation — the topic Container & Virtualization, where you'll apply the network namespaces, cgroups, and image layering you already know conceptually, now in tangible form with Docker and Podman. See you there!