Networking Osi

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

OSI Model Networking for Cloud-Native

Category: networking
Status: Active
Last Updated: 2026-04-22
Primary Reference: OSI Model - ISO/IEC 7498-1

Purpose: Why OSI Layers Matter for CNCF

Understanding the OSI model is essential for cloud-native engineering because:

The 5 Laws of Network Defense

1. Early Exit: Troubleshoot from Layer 1 upward. A physical layer failure at Layer 1 invalidates all upper layers.
2. Parse, Don't Validate: Each layer has a specific data format. Don't try to fix Layer 4 TCP issues by examining Layer 2 frames.
3. Atomic Predictability: Each layer provides deterministic services. TCP guarantees delivery; IP does not. Know what to expect.
4. Fail Fast, Fail Loud: Network failures cascade predictably. Identify the root layer quickly to avoid chasing symptoms.
5. Intentional Naming: Layer 3 = Network (IP routing), Layer 4 = Transport (TCP/UDP ports). Confusing these wastes hours.

CNCF Context

Cloud-native applications span multiple layers:

• Layer 1-2: CNI plugins (Calico, Cilium, Flannel) handle pod networking
• Layer 3: Service discovery, cross-node routing
• Layer 4: Service meshes (Istio, Linkerd) manage traffic at transport layer
• Layer 7: Ingress controllers (NGINX, Contour, Gloo) handle HTTP/HTTPS

OSI Layer Overview

Layer 1: Physical

Key Concepts

The Physical layer handles raw bit transmission over physical media. No addressing, no protocols, just electrical signals.

Key Protocols and Technologies

Common Tools and Commands

# Check interface status and link layer info
ip link show
ip -s link show  # With statistics

# Check physical media type
ethtool eth0
ethtool -i eth0  # Driver info
ethtool -m eth0  # SFP module info

# Monitor interface statistics
ip -s link show docker0

# Watch for errors in real-time
watch -n 1 'ip -s link show eth0 | grep -E "(errors|dropped|overrun)"'

CNCF Project Examples

Real-World Examples

Use Case: Node Network Troubleshooting

# Check if interface is up
ip link show eth0
# Expected: state UP

# Check link speed and duplex
ethtool eth0 | grep -E "(Speed|Duplex|Link detected)"

# Check for hardware errors
dmesg | grep -i "eth0" | grep -iE "(error|fail|drop)"

# Check SFP module status (common in cloud)
ethtool -m eth0 | grep -E "(Temp|Voltage|TxPower|RxPower)"

Troubleshooting Tips

1. "No Carrier" errors: Check physical connections first
2. CRC errors: Faulty cable, bad NIC, or electrical interference
3. Collisions (full-duplex shouldn't have these): Duplex mismatch or hardware issue
4. Interface flapping: Loose cable, faulty NIC, or power issue

Layer 2: Data Link

Key Concepts

The Data Link layer provides node-to-node data transfer, error detection, and MAC addressing. It segments into two sublayers:

• LLC (Logical Link Control): Error checking, flow control
• MAC (Media Access Control): Device addressing, frame delimiting

Key Protocols and Technologies

Common Tools and Commands

# View MAC addresses
ip link show
ip addr show

# View ARP table
ip neigh show
arp -a  # Legacy

# Monitor VLANs
ip link show type vlan

# View switch ports (if available)
ss -p -tuln  # Listening TCP/UDP ports

CNCF Project Examples

Real-World Examples

Use Case: Pod-to-Pod Communication on Same Node

# Get pod IP and MAC
kubectl get pod -o wide
kubectl exec <pod> -- ip addr show eth0

# Check ARP table on node
ip neigh show | grep <pod-ip>

# Check VLAN configuration
ip link show type vlan

Use Case: VLAN Troubleshooting in Kubernetes

# Create VLAN interface (on node)
ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

# CNI configuration for VLAN (Calico)
cat <<EOF | kubectl apply -f -
apiVersion: crd.projectcalico.org/v1
kind: BGPConfiguration
metadata:
  name: default
spec:
  vlan: 100
EOF

Troubleshooting Tips

1. MAC address conflicts: Duplicate MACs cause flapping
2. VLAN mismatch: Pods can't communicate across VLANs
3. MTU issues: Oversized frames get dropped
4. STP blocking: Ports in blocking state don't forward

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

Layer 3: Network

Key Concepts

The Network layer handles logical addressing (IP), routing, and forwarding. It enables communication across different networks.

Key Protocols and Technologies

Routing Protocols

Common Tools and Commands

# View routing table
ip route show
route -n  # Legacy

# Test connectivity (ICMP)
ping <ip>
ping6 <ipv6>  # IPv6

# Trace route
traceroute <ip>
tracepath <ip>  # Without root

# Check IPv6
ip -6 route show

# Monitor ICMP
tcpdump -i eth0 icmp  # IPv4
tcpdump -i eth0 icmp6  # IPv6

CNCF Project Examples

Real-World Examples

Use Case: Cross-Node Pod Communication

# On node 1: Get pod IP
kubectl get pod -o wide

# Ping pod on different node
kubectl exec <pod-on-node1> -- ping <pod-ip-on-node2>

# Check routing table
ip route show | grep <pod-cidr>

# Verify CNI routing (Calico BGP)
kubectl exec -n calico-system -it <calico-node> -- birdc show ip route

Use Case: Troubleshooting Network Partitions

# Check if nodes can reach each other
kubectl get nodes -o wide
for node in $(kubectl get nodes -o name); do
  kubectl exec <some-pod> -- ping $(kubectl get $node -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
done

# Check iptables rules (legacy kube-proxy)
iptables -L -n -v | grep KUBE-SERVICES

Troubleshooting Tips

1. "No route to host": Missing route or default gateway
2. TTL exceeded: Routing loop
3. ICMP unreachable: Firewall blocking or no route
4. Pod can't reach external: Missing egress route or NAT

Layer 4: Transport

Key Concepts

The Transport layer provides end-to-end communication services, including connection management, flow control, and error recovery.

Key Protocols

TCP Features

• Three-way handshake: SYN → SYN-ACK → ACK
• Flow control: Sliding window via advertised window
• Congestion control: Slow start, congestion avoidance
• Error recovery: Retransmission on timeout

UDP Features

• No connection establishment
• No flow control
• No congestion control
• Lightweight, low latency

Common Tools and Commands

# View TCP connections
ss -tuln  # Listening
ss -tulnp # With processes

# TCP state breakdown
ss -s  # Summary
ss -an | awk '{print $1}' | sort | uniq -c

# View port usage
netstat -tuln  # Legacy
lsof -i :8080  # Process using port

# TCP dump analysis
tcpdump -i eth0 port 80 -w capture.pcap
tcpdump -i eth0 tcp[tcpflags] & tcpflags != 0  # TCP flags only

CNCF Project Examples

Real-World Examples

Use Case: Service Mesh Traffic Management

# Istio VirtualService for TCP traffic
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: database-routes
spec:
  hosts:
  - database.default.svc.cluster.local
  tcp:
  - match:
    - port: 5432
    route:
    - destination:
        host: database.default.svc.cluster.local
        port:
          number: 5432
      weight: 90
    - destination:
        host: database-standby.default.svc.cluster.local
        port:
          number: 5432
      weight: 10

Use Case: Troubleshooting Connection Issues

# Check established connections
ss -tnp | grep :443

# Check TIME_WAIT connections (can exhaust ports)
ss -tn state time-wait | wc -l

# View socket buffer sizes
ss -l -t -n | head -5

# TCP dump for handshake analysis
tcpdump -i eth0 host <server> and port <port> -X

Troubleshooting Tips

1. Port exhaustion: Too many TIME_WAIT connections
2. Connection refused: No process listening on port
3. Connection reset: Server reset the connection
4. Slow transfer: Congestion control or flow control issue

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

Layer 5: Session

Key Concepts

The Session layer manages dialog control (cooperation between applications), including establishment, maintenance, and termination of sessions.

Key Functions

• Session establishment: Handshakes, authentication
• Session maintenance: Keep-alive, checkpointing
• Session termination: Graceful close, abort
• Dialog control: Full-duplex, half-duplex

Key Protocols

Common Tools and Commands

# WebSocket debug (browser dev tools or CLI)
wscat -c wss://example.com/ws

# Check RPC services
rpcinfo -p  # NFS, etc.

# NetBIOS session (if enabled)
nmblookup -A <ip>

CNCF Project Examples

Real-World Examples

Use Case: WebSocket Session in Kubernetes

# Example: WebSocket service with proper session handling
apiVersion: v1
kind: Service
metadata:
  name: websocket-service
spec:
  selector:
    app: websocket-app
  ports:
  - name: http
    port: 80
    targetPort: 8080
  - name: ws
    port: 8080
    targetPort: 8080
---
  related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: websocket-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
spec:
  rules:
  - http:
      paths:
      - path: /ws
        pathType: Prefix
        backend:
          service:
            name: websocket-service
            port:
              number: 80

Use Case: Troubleshooting Session Timeouts

# Check HTTP/2 streams (gRPC uses HTTP/2)
tcpdump -i eth0 port 50051 -X | grep -i "WINDOW_UPDATE"

# WebSocket ping/pong (keep-alive)
wscat -c wss://example.com/ws --no-check
# Send: {"type": "ping"}

Troubleshooting Tips

1. Session stuck: Client or server not sending FIN
2. Session timeout: Idle timeout too short for long operations
3. Half-open sessions: Client crashed, server unaware

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

Layer 6: Presentation

Key Concepts

The Presentation layer handles data formatting, encryption/decryption, compression, and translation between application and network formats.

Key Functions

• Data formatting: JSON, XML, protobuf encoding
• Encryption/Decryption: TLS, SSL
• Compression: gzip, deflate, Brotli
• Character encoding: UTF-8, ASCII

Common Protocols

Common Tools and Commands

# SSL/TLS certificate check
openssl s_client -connect example.com:443 -showcerts
curl -v https://example.com  # HTTP with headers

# Check TLS version and ciphers
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# View certificate details
openssl x509 -in cert.pem -text -noout

CNCF Project Examples

Real-World Examples

Use Case: Service Mesh mTLS Verification

# Check if mTLS is enabled between pods
kubectl exec <pod> -- curl -v https://other-pod:8080

# Check Istio sidecar TLS configuration
istioctl proxy-status

# View certificate details from sidecar
istioctl proxy-config secrets <pod> | jq '.dynamicActiveSecrets[0].tlsContext.rootCert'

Use Case: Certificate Troubleshooting

# Check certificate expiry
openssl s_client -connect api.example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -dates

# Check certificate chain
curl --cacert ca.pem --cert cert.pem --key key.pem https://example.com

# Verify certificate with service mesh
istioctl analyze

Troubleshooting Tips

1. Certificate expired: Check expiry dates
2. Certificate chain incomplete: Add intermediate certificates
3. Cipher mismatch: Client/server don't share cipher suite
4. Hostname mismatch: CN/SAN doesn't match hostname

Layer 7: Application

Key Concepts

The Application layer is where user-facing protocols operate. This is where HTTP, DNS, FTP, SSH, and other application protocols function.

Key Protocols

Common Tools and Commands

# HTTP request testing
curl -v https://example.com
wget -S https://example.com -O /dev/null

# DNS lookup
nslookup example.com
dig example.com
host example.com

# HTTP/2 check
curl -v --http2 https://example.com

# WebSocket test
wscat -c wss://example.com/ws

CNCF Project Examples

Real-World Examples

Use Case: Ingress Controller Configuration

# Nginx Ingress Controller with path-based routing
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /static
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80

Use Case: Application Layer Troubleshooting

# Debug HTTP 5xx errors
kubectl exec <pod> -- curl -v http://backend:8080/health

# Check response headers
curl -I https://api.example.com/v1/users

# DNS resolution test
kubectl exec <pod> -- nslookup kubernetes.default.svc.cluster.local

# gRPC health check
grpcurl -plaintext api.example.com:50051 list

Troubleshooting Tips

1. HTTP 404: Route not found, path mismatch
2. HTTP 502: Backend not responding
3. HTTP 503: All backends unhealthy
4. DNS failure: CoreDNS issue or network partition

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

Modern Cloud Implementations: CNCF Project Mappings

CNCF Project to OSI Layer Mapping

Kubernetes Networking Stack

Application Layer (L7)
├── Ingress Controllers (Nginx, Contour, Traefik)
├── Service Meshes (Istio, Linkerd)
├── API Gateway (Kong)
└── CoreDNS

Transport Layer (L4)
├── kube-proxy (iptables/IPVS)
├── CNI Plugins (Calico, Cilium, Flannel)
└── Service Meshes (connection pooling, retries)

Network Layer (L3)
├── IPAM (Calico IPAM)
├── Route Controllers
└── BGP Peering (Calico)

Data Link Layer (L2)
├── veth pairs
├── Linux bridges (cbr0)
├── VLANs (if configured)
└── MAC addresses

Physical Layer (L1)
├── Network interfaces
├── NIC drivers
└── Physical links

Real-World Architecture Example

Multi-Cluster Service Mesh with L7 Load Balancing

                     ┌─────────────────────────┐
                     │  Global Ingress (L7)    │
                     │        Traefik          │
                     └─────────────┬───────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         │                         │                         │
    ┌────▼─────┐             ┌────▼─────┐             ┌────▼─────┐
    │ Cluster  │             │ Cluster  │             │ Cluster  │
    │  A       │             │  B       │             │  C       │
    └────┬─────┘             └────┬─────┘             └────┬─────┘
         │                         │                         │
    ┌────▼─────┐             ┌────▼─────┐             ┌────▼─────┐
    │  Istio   │             │  Istio   │             │  Istio   │
    │  (L4-L7) │             │  (L4-L7) │             │  (L4-L7) │
    └────┬─────┘             └────┬─────┘             └────┬─────┘
         │                         │                         │
    ┌────▼─────┐             ┌────▼─────┐             ┌────▼─────┐
    │  Calico  │             │  Calico  │             │  Cilium  │
    │  (L3-L4) │             │  (L3-L4) │             │  (L2-L7) │
    └──────────┘             └──────────┘             └──────────┘

Best Practices

Network Design Principles

1. Defense in Depth: Layer security controls across OSI layers
2. Segmentation: Use VLANs, network policies to isolate workloads
3. Least Privilege: Network policies should deny by default
4. Redundancy: Multiple paths, ECMP for resilience

Security Best Practices

# Network policy for default deny all ingress
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
EOF

# Allow only specific namespace
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080
EOF

Monitoring Best Practices

# Monitor network policy enforcement
kubectl get networkpolicies --all-namespaces

# Check CNI plugin status (Calico)
kubectl get bgpconfigurations
kubectl get bgppeers
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{end}' | \
  xargs -I {} kubectl get node {} -o jsonpath='{.status.conditions[?(@.type=="NetworkUnavailable")].message}'

# TCP connection tracking
ss -s | grep -E "(TCP|TCPtw|TCPorphan)"

Troubleshooting Methodology

1. Start at Layer 1: Check physical links, interface status
2. Move Up: Verify Layer 2 (MAC, ARP), Layer 3 (routing, IP)
3. Layer 4: Check ports, protocols, firewalls
4. Layer 7: Application-specific issues

# Complete network troubleshooting checklist
echo "=== Layer 1: Physical ==="
ip link show | grep -E "state|link/ether"

echo "=== Layer 2: Data Link ==="
ip neigh show | head -10
ip link show type vlan

echo "=== Layer 3: Network ==="
ip route show
ip route get 8.8.8.8  # Test routing

echo "=== Layer 4: Transport ==="
ss -tuln | head -20
ss -s | grep TCP

echo "=== Layer 7: Application ==="
kubectl get services --all-namespaces
kubectl get ingress --all-namespaces

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

Scaling Considerations

Horizontal Scaling Strategies

1. Layer 4 Load Balancing: Distribute TCP/UDP connections
2. Layer 7 Load Balancing: HTTP-based routing, content switching
3. ECMP: Equal-cost multi-path for network layer load balancing
4. DNS-based: Round-robin DNS for simple load distribution

Service Mesh Scaling

# Istio load balancing policy
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend-loadbalancing
spec:
  host: backend.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # Also: LEAST_CONN, RANDOM, PASSTHROUGH
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000

CDN Integration

# Frontend with CDN fallback
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/configuration-snippet: |
      location /static/ {
        proxy_pass https://cdn.example.com;
        proxy_cache_valid 200 1d;
      }
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Edge Computing

# KubeEdge edge node configuration
# On edge node
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: edge-config
  namespace: kubeedge
data:
  edgehub.conf: |
    {
      "edgehub": {
        "mqtt": {
          "mode": "cloud",
          "server": "tcp://coredns.kube-system.svc.cluster.local:1883"
        }
      }
    }
EOF

Performance Tuning

# TCP tuning for high throughput
echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 15" >> /etc/sysctl.conf
sysctl -p

# Kubernetes pod network tuning
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: cni-config
  namespace: kube-system
data:
  cni.conf: |
    {
      "name": "calico",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "calico",
          "mtu": 1450,
          "log_level": "info"
        },
        {
          "type": "portmap",
          "snat": true,
          "capabilities": {"portMappings": true}
        }
      ]
    }
EOF

related-skills: cncf-aws-route53, cncf-azure-cdn, cncf-azure-traffic-manager, cncf-azure-virtual-networks

References

• OSI Model: ISO/IEC 7498-1 standard
• Kubernetes Networking: https://kubernetes.io/docs/concepts/cluster-administration/networking/
• Calico Documentation: https://docs.tigera.io/calico/latest/about/
• Cilium Documentation: https://docs.cilium.io/
• Service Mesh Interface: https://smi-spec.io/

Quick Reference: Troubleshooting Commands

# One-line network diagnostics
kubectl get pods -o wide && \
  ip link show && \
  ip route show && \
  ss -tuln && \
  curl -s http://kubernetes.default.svc/healthz

# Service mesh health check (Istio)
istioctl proxy-status && \
  istioctl analyze && \
  kubectl get destinationrules,sidecars --all-namespaces

# DNS troubleshooting
kubectl exec -n kube-system -it <coredns-pod> -- nslookup kubernetes.default.svc.cluster.local
kubectl exec <pod> -- nslookup <service>.<namespace>.svc.cluster.local

When to Use

Use this skill when:

• Integrating a CNCF project into Kubernetes infrastructure — You need to configure, deploy, or troubleshoot a cloud-native tool within a cluster
• Designing cloud-native architecture — You are selecting and integrating CNCF tools to solve specific infrastructure challenges
• Resolving operational issues — A CNCF component is misbehaving, underperforming, or needs configuration changes

Core Workflow

1. Assess Requirements — Understand the use case, scale, integration needs, and existing infrastructure. Checkpoint: Document requirements, constraints, and success criteria.

2. Design Architecture — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. Checkpoint: Verify the architecture addresses all requirements and follows CNCF conventions.

3. Implement & Configure — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. Checkpoint: Validate all YAML against schema and test in a staging environment.

4. Deploy & Monitor — Apply manifests to the cluster, verify component health, and confirm observability is working. Checkpoint: Confirm all pods/services are running, probes passing, and metrics/alerts configured.

Constraints

MUST DO

• Include at least one complete working YAML manifest example
• Note when content is auto-generated vs. manually verified
• Reference relevant CNCF project documentation

MUST NOT DO

• Deploy manifests without testing in a staging environment first
• Use deprecated API versions (e.g., apps/v1beta1)
• Omit resource limits and requests in Kubernetes manifests