Who routes what, where
"Layer 4 vs layer 7" is a compact way to test whether you understand the whole traffic chain — and with F5 on your resume, it's a question designed for you to win. The trick: describe the hop-by-hop path in their stack, not textbook definitions.
One decision, one table
| Layer 4 (transport) | Layer 7 (application) | |
|---|---|---|
| Sees | IP + port (TCP/UDP tuple) | Full protocol: HTTP host/path, cookies, TLS SNI, headers |
| Routing decision | Destination IP:port, hashed across backends | Host header, URI, cookie, client IP, any request attribute |
| Speed / cost | Fast, low CPU, transparent-ish | Heavier: terminate/parse per request — but vastly smarter |
| Can do | Port-based VIPs, TCP health checks, source-IP persistence | A/B routing, canary, sticky sessions, TLS termination, WAF, rewrites, rate limiting |
| Blind to | Request content | Nothing at the app layer — that's the point |
The traffic chain at Proforma
Every hop has a job. Map it cold:
- Client hits a VIP — announced by MetalLB (L4: pure IP delivery, BGP-announced /32s) or by F5 BIG-IP (if an F5 fronts the cluster).
- Node receives it — kube-proxy / OVN-Kubernetes (L4) DNATs the VIP:port to a pod IP (or first to the Router, depending on the Service).
- OpenShift Router (HAProxy, L7) terminates TLS, reads the HTTP Host/SNI, and routes to the right Service by Ingress/Route rules.
- Service → pods — another L4 hop (kube-proxy) to the actual pod, round-robined.
Where F5 fits (your home turf)
- North-south front door: LTM virtual servers → MetalLB VIPs or directly to node ports; GTM/GSLB for multi-site DNS-based failover
- Edge TLS termination + WAF where the Router shouldn't be the public termination point
- Legacy + new side by side: F5 fronts Windows apps that haven't moved yet and routes that now land in OpenShift — the migration story in routing form
F5 specifics to have ready
- Virtual server + pool + health monitor; profiles: FastL4 (L4, packet-forwarding speed) vs Standard (full proxy/L7)
- iRules — Tcl event scripts for L7 decisions (this + APM + GTM on your resume is a differentiator)
- Persistence: source-address (L4) vs cookie (L7); SNAT/automap for return-path safety
- LTM = local LB, GTM = DNS-based global LB, APM = auth at the edge (your Entra ID/SAML story plugs in here)
Terminate where? Three honest answers
Edge termination
TLS ends at F5 or the Router; plaintext inside the cluster. Simplest cert lifecycle, easiest WAF — but plaintext east-west (mitigate with mTLS/Service Mesh or accept the trust boundary).
Re-encryption
Terminate at the edge, re-encrypt to the backend. Certs at two hops; the compliance-friendly middle ground for PCI-shaped environments.
Passthrough (SNI)
Router doesn't decrypt; SNI-based routing only. Certs live on the app, but no L7 inspection at the edge. Used when apps must hold their own keys (or regulation demands it).
If asked "L4 or L7 for X?", the senior answer names the tradeoff and picks per workload: L4 when you need throughput and don't need request intelligence; L7 when you need routing, security, or session logic. And remember — MetalLB is L4 only; anyone who says it does L7 routing has just failed the question.
Questions to answer out loud
A request to app.proforma.com times out. Walk your investigation layer by layer.
DNS resolves? → GTM/GSLB pointing at the right site → VIP reachable (F5/MetalLB health) → pool/backends up (monitors green) → Router route matches the host → Service endpoints exist → pod actually listening. Each hop has its own status command; the fix is usually at exactly one of them.
Why keep F5 when MetalLB + the OpenShift Router exist?
Different jobs: MetalLB is IP delivery (L4), the Router is HTTP routing inside the cluster (L7). F5 earns its place as the front door when you need WAF, APM/auth, GTM/GSLB across sites, or one control point for traffic that still spans Windows and OpenShift during the migration. It's not either/or — it's which hop owns which concern.
Sticky sessions on a migrated app — where do they live?
Depends on the layer: L4 stickiness = source-address persistence (F5), L7 stickiness = cookie-based (F5 Standard profile or Router annotation). On OpenShift, the Router supports cookie-based affinity via route annotations. But the deeper answer: prefer stateless apps and let stickiness die — session affinity is a scalability crutch, and the migration is the moment to challenge it.