CF Networking provides policy-driven container networking for Cloud Foundry.
CF Networking has several components. Some are "core" to the Cloud Foundry platform, others are "swappable" by operators who wish to use a 3rd party network system instead. For more information on integrating a 3rd-party networking solution, see here.
- Policy Server, a central management node, exposes a JSON REST API used by the CLI plugin
- Garden External Networker, a Garden-runC add-on deployed to every Diego cell
- Invokes an operator-configured CNI Plugin to set up the network for each app instance (container)
- Forwards ports to support incoming connections from the CF HTTP Router, TCP Router and Diego SSH Proxy.
On every Diego cell
- Silk, provides IP address management and network connectivity to app instances (containers)
- Uses a VXLAN overlay for sending traffic between cells
- Every CF app instance gets a unique IP on a shared, flat L3 network
- VXLAN Policy Agent enforces network policy for network traffic between applications
- Discovers desired network policies from the Policy Server's Internal API
- Updates IPTables rules on Diego cell to allow whitelisted ingress traffic
- Egress traffic is tagged with a unique identifier per source application, using the VXLAN GBP header
- Optionally limit bandwidth in and out of each container
- Traffic destined for container IPs travels in the overlay network. This traffic is subject to container to container network policies.
- Traffic destined for the Internet or any other non container IPs travels in the underlay network. This traffic is subject to application security groups and dynamic egress network policies.
| Multi Diego Cell |
|---|
 |
| Single Diego Cell | ASG |
|---|---|
 |
 |
Here is a summary of the network-related actions that occur when a new container is created.
