Kubernetes

 How Traffic Actually Moves Inside Kubernetes

There are only two directions traffic can move:
North–South → from outside the cluster into it
East–West → between services inside the cluster
Everything else is just implementation detail.

North–South: When a User Hits Your App
A request doesn’t magically “reach a pod.”
It passes through layers each with a very specific responsibility.
First, an Ingress or Gateway receives the request.

This is your traffic front door , it handles host rules, paths, TLS termination.
Then the request hits a Service.
The Service is not your app.

It’s a stable virtual endpoint that hides the fact that Pods come and go.
Behind the Service, kube-proxy programs routing rules (iptables/IPVS) so traffic is forwarded to one of the healthy Pods.

The Pod itself has a real IP assigned by the CNI plugin (like Calico or Cilium).
That CNI integrates with the Linux kernel networking stack and ensures packets actually move between nodes.
Underneath all of it?

Just standard Linux networking and your cloud/VPC infrastructure.
Nothing mystical.
Just layers doing one job each.

East–West: Service-to-Service Communication
Inside the cluster, things are cleaner.
When one service calls another:
DNS (CoreDNS) resolves the Service name
Traffic goes to the Service IP
kube-proxy forwards it to a backing Pod
CNI ensures packets can travel node-to-node
Kubernetes follows a flat network model:
Every Pod gets its own IP.
Every Pod can reach every other Pod (unless restricted by NetworkPolicy).

If you use a Service Mesh, you’re adding observability, mTLS, retries but the underlying routing model stays the same.

The Mental Model That Changes Everything
Think of Kubernetes networking as three stacked layers:
Abstraction layer → Ingress & Services
Routing layer → kube-proxy rules
Connectivity layer → CNI + Node networking

When something breaks, the issue is almost always in one of those three.
Once you see that separation clearly, debugging stops feeling random.

Kubernetes networking isn’t complicated.
It’s just layered and very opinionated.
Understand the flow once,
and the black box disappears.

If this made Kubernetes networking click for you, consider reposting so it clicks for someone else too.

🌍📡 BGP — The Protocol That Runs the Internet

Every time you open a website, stream a video, or connect to cloud services…
👉 BGP is silently deciding the path your traffic takes.

But here’s the key:

🚫 BGP does NOT choose the shortest path
✅ BGP chooses the best policy-based path

🧠 What is BGP?
✔ Internet routing protocol
✔ Exchanges routes between Autonomous Systems (AS)
✔ Controls how traffic enters and leaves networks
✔ Used by ISPs, enterprises, and cloud providers
👉 Without BGP, the internet wouldn’t function.

🌐 Types of BGP
🔹 eBGP (External BGP)
Used between different AS networks
👉 Example: Enterprise ↔ ISP

🔹 iBGP (Internal BGP)
Used inside the same AS
👉 Example: Core routers inside a data center

🔌 How BGP Actually Works
1️⃣ Configure neighbor
2️⃣ Establish TCP session (Port 179)
3️⃣ Exchange OPEN messages
4️⃣ Send KEEPALIVE messages
5️⃣ Advertise routes
6️⃣ Withdraw routes if links fail
👉 Only ONE best path gets installed in the routing table.

🎯 Key BGP Attributes Engineers Must Know
✔ Weight (Cisco local attribute)
✔ Local Preference (controls exit path)
✔ AS-PATH (loop prevention + path length)
✔ NEXT-HOP (where traffic goes next)
✔ MED (suggest preferred entry point)
✔ COMMUNITY (policy tagging)
👉 These attributes are how engineers control traffic.

🛡️ BGP Security Matters
✔ Prefix filtering prevents route leaks
✔ MD5 authentication secures neighbors
✔ RPKI validation protects against hijacks
👉 Misconfigured BGP can break the internet.

🌍 Real-World Use Cases
✔ Multi-ISP redundancy
✔ Traffic engineering
✔ Cloud connectivity (AWS / Azure / GCP)
✔ ISP peering & global routing

🧠 BGP isn’t just a protocol — it’s the control system of the internet.

 BGP Troubleshooting — Step-by-Step Practical Guide

When BGP fails, traffic stops, routes disappear, and users feel it immediately. Here is a structured method I follow in production networks.

1️⃣ Verify Basic Reachability
BGP runs over TCP port 179. If IP connectivity fails, BGP cannot work.
✔ Ping neighbor loopback / interface
✔ Check routing table for neighbor IP
✔ Verify no ACL or firewall blocking TCP 179
Key idea: No IP reachability = No BGP session.

2️⃣ Check BGP Neighbor State
Run:
Copy code

show ip bgp summary

Look for neighbor state:
• Idle → No TCP connection
• Connect / Active → TCP problem
• Established → Session OK
If not Established, focus on configuration mismatch or network reachability.

3️⃣ Validate Neighbor Configuration
Most BGP issues are configuration mistakes.
✔ Correct neighbor IP
✔ Correct remote-AS
✔ Update-source configured (for loopback peering)
✔ Proper multihop setting (if not directly connected)

Small typo = session down.

4️⃣ Authentication Problems
If MD5 authentication is configured:
✔ Password must match on both sides
✔ Check logs for authentication failure
Mismatch = session resets repeatedly.

5️⃣ Check Route Advertisement
Session up but routes missing? Then check policy.
✔ Network statements present
✔ Route redistribution configured
✔ Route-map / prefix-list not blocking routes
✔ Next-hop reachable

Command:
Copy code

show ip bgp neighbors x.x.x.x advertised-routes

6️⃣ Investigate Route Filtering
Many networks fail because of filtering policies.
✔ Prefix-list direction (in / out)
✔ Route-map deny statements
✔ Maximum-prefix limit reached

Policy errors silently drop routes.

7️⃣ Check BGP Attributes and Path Selection
If route received but not used:
✔ Local Preference
✔ AS Path length
✔ MED value
✔ Weight
✔ Next-hop reachability

Best path selection determines traffic flow.

8️⃣ Monitor Logs and Debug Carefully
Logs give the real story.
✔ Neighbor reset reason
✔ Hold timer expiry
✔ Policy rejection
Use debug only in maintenance window.

9️⃣ Check Physical and L2 Issues
Sometimes problem is not BGP.
✔ Interface flapping
✔ Duplex mismatch
✔ VLAN or trunk issue
✔ High CPU or memory

Transport instability breaks BGP.

🔟 Compare With Working Peer
Best practical trick:
👉 Compare working neighbor vs failing neighbor
👉 Spot configuration differences quickly

Final Tip:
Always troubleshoot in layers → Physical → IP → TCP → BGP → Policy.

This structured approach reduces MTTR and builds strong network stability.