The OSI Model: Advanced Concepts

# Check which AS announces an IP
whois -h whois.radb.net 1.1.1.1

# View BGP path to a prefix
traceroute -A 1.1.1.1

# Query a route server for BGP info
dig +short TXT 1.1.1.1.origin.asn.cymru.com
# Returns: "13335 | 1.1.1.0/24 | US | arin | 2014-03-28"

# Check BGP session status
sudo birdc show protocols

# View received routes
sudo birdc show route

# Check specific prefix
sudo birdc show route for 10.0.0.0/24

# Check RPKI validation status of a prefix
curl -s https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24

User in Tokyo    → routes to Tokyo server      (same IP: 1.1.1.1)
User in London   → routes to London server     (same IP: 1.1.1.1)
User in New York → routes to New York server   (same IP: 1.1.1.1)

# Same IP resolves to different servers depending on your location
dig +short whoami.cloudflare.com @1.1.1.1

# Trace to see which PoP you hit
traceroute 1.1.1.1
mtr --report 1.1.1.1

# Create a network namespace
sudo ip netns add app1

# List namespaces
ip netns list

# Run a command inside the namespace
sudo ip netns exec app1 ip addr show
# Only sees loopback — fully isolated

# Create a veth pair (virtual cable between namespaces)
sudo ip link add veth-host type veth peer name veth-app1

# Move one end into the namespace
sudo ip link set veth-app1 netns app1

# Assign IPs
sudo ip addr add 10.0.0.1/24 dev veth-host
sudo ip netns exec app1 ip addr add 10.0.0.2/24 dev veth-app1

# Bring interfaces up
sudo ip link set veth-host up
sudo ip netns exec app1 ip link set veth-app1 up

# Test connectivity
ping -c 2 10.0.0.2

# View Docker's bridge network
docker network inspect bridge

# See veth pairs connecting containers to the bridge
bridge link show

# View NAT rules Docker creates
sudo iptables -t nat -L -n | grep DOCKER

# Debug container DNS
docker exec mycontainer cat /etc/resolv.conf

# View Pod IPs and node assignments
kubectl get pods -o wide

# Check CNI configuration
ls /etc/cni/net.d/

# View routes on a node (Calico)
ip route | grep cali

# Debug connectivity between pods
kubectl exec pod-a -- ping <pod-b-ip>
kubectl exec pod-a -- traceroute <pod-b-ip>

Client                          Server
  │                               │
  ├── ClientHello ───────────────→│
  │←── ServerHello + ServerCert ──┤
  │←── CertificateRequest ────────┤  (server asks for client cert)
  ├── ClientCert + Verify ───────→│  (client proves identity)
  │                               │
  │←── Encrypted connection ─────→│  (both sides verified)

# Generate CA
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca-cert.pem -days 365 -nodes -subj "/CN=MyCA"

# Generate server cert
openssl req -newkey rsa:4096 -keyout server-key.pem -out server-csr.pem -nodes -subj "/CN=server.local"
openssl x509 -req -in server-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 365

# Generate client cert
openssl req -newkey rsa:4096 -keyout client-key.pem -out client-csr.pem -nodes -subj "/CN=client-app"
openssl x509 -req -in client-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 365

# Connect with mTLS
curl --cacert ca-cert.pem --cert client-cert.pem --key client-key.pem https://server.local:8443/

Packet arrives at NIC
  → XDP (before kernel networking stack)      ← fastest, can drop/redirect
    → tc (traffic control, after sk_buff allocation)
      → Netfilter/iptables
        → Socket layer
          → Application

# Install bcc tools (eBPF toolkit)
sudo dnf install bcc-tools

# Trace TCP connections in real time
sudo tcptracer-bpfcc

# Monitor TCP retransmissions
sudo tcpretrans-bpfcc

# Track TCP connection latency
sudo tcpconnlat-bpfcc

# Snoop DNS queries without tcpdump
sudo gethostlatency-bpfcc

# Check Cilium status
cilium status

# View eBPF-enforced network policies
cilium endpoint list

# Monitor packet drops with reason
cilium monitor --type drop

# Trace a specific flow
cilium monitor --from-ip 10.0.0.5 --to-ip 10.0.0.10

Service A → [Envoy Sidecar] → network → [Envoy Sidecar] → Service B
                 ↕                              ↕
            Control Plane (Istio/Linkerd)

# Route 90% of traffic to v1, 10% to v2 (canary)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1
          weight: 90
        - destination:
            host: my-service
            subset: v2
          weight: 10

# Check sidecar proxy status
istioctl proxy-status

# View Envoy configuration for a pod
istioctl proxy-config routes deploy/my-service

# Check if mTLS is active between services
istioctl authn tls-check my-service.default

# View traces (requires Jaeger/Zipkin)
# Each span shows:
#   - DNS resolution time (L7)
#   - TCP connection time (L4)
#   - TLS handshake time (L6)
#   - Application processing time (L7)

# Watch for interface errors
watch -n 5 'ip -s link show eth0 | grep -E "errors|dropped"'

# Monitor conntrack table usage
watch -n 5 'cat /proc/sys/net/netfilter/nf_conntrack_count; echo "/"; cat /proc/sys/net/netfilter/nf_conntrack_max'

# Alert on TCP retransmissions (quick one-liner)
while true; do
  retrans=$(netstat -s | grep "segments retransmitted" | awk '{print $1}')
  echo "$(date): $retrans retransmissions"
  sleep 60
done

# Packet drop reasons (requires dropwatch or perf)
sudo dropwatch -l kas

# Capture flow summaries (not full packets)
sudo tcpdump -i eth0 -n -q -t | awk '{print $1, $3, $5}' | sort | uniq -c | sort -rn | head -20

# Conntrack flow accounting
sudo conntrack -L -o extended | awk '{print $3}' | sort | uniq -c | sort -rn