Gateway Overview
Bridge integrates with external gateways to provide tenant-facing connectivity, load balancing, NAT, and security group enforcement at the edge of the data center network. The gateway bridges tenant-isolated VxLAN/VRF overlay networks with external networks, cloud connectivity, or the public internet.
Gateway Role in the Fabric
Each tenant's network is confined to its own VRF within the switch fabric. External access requires traffic to exit the tenant VRF and pass through the gateway, which applies per-tenant policies before routing to the external network.
At the border leaf switches, Bridge configures:
| Component | Purpose |
|---|---|
| Exit VRF | Shared VRF for traffic leaving the fabric toward the gateway |
| Per-tenant external VRF | Isolated routing context per tenant |
| Route leak to Exit VRF | Controlled forwarding from tenant VRF to the exit point |
Supported Gateways
| Gateway | Deployment | Use Case |
|---|---|---|
| F5 BIG-IP Virtual Edition (VE) | VM on the data center fabric | NAT, L4/L7 load balancing, security groups |
| F5 BIG-IP Next | Deployed on BF3 DPUs, managed by Bridge | Distributed per-tenant gateway, WAF |
Service Exposure Models
Bridge supports two models for exposing tenant services externally:
Option 1: Ingress-Based Exposure
Traffic reaches an L7 gateway (Ingress controller) via a single external IP. DNS wildcard records resolve multiple service hostnames to the same gateway IP, and the Ingress controller routes to the appropriate backend service.
https://modelA.tenant.example.com → 203.0.13.25 → Ingress → inference.modelA.svc
https://modelB.tenant.example.com → 203.0.13.25 → Ingress → inference.modelB.svc
The gateway performs DNAT from the public IP to the internal Ingress IP, and the Ingress rules are added dynamically as services are deployed.
Option 2: LoadBalancer Service Exposure
Each service gets a dedicated external IP. Traffic for each IP is DNAT'd directly to the corresponding Kubernetes service with type LoadBalancer.
https://modelA.example.com → 203.0.13.25 → service (172.17.8.8)
https://modelB.example.com → 203.0.13.26 → service (172.17.8.9)
An L4 load balancer at the gateway is required when multiple endpoints serve the same model across Kubernetes clusters.
Related Pages
- F5 BIG-IP VE — External gateway configuration with F5 BIG-IP Virtual Edition
- F5 BIG-IP Next — Distributed gateway on BF3 DPUs