Understanding CF Networking

This topic provides an overview of how CF Networking works. For more information about how to enable and use CF Networking, see the Administering CF Networking topic.

The CF Networking feature enables app instances to communicate with each other directly. When the CF Networking feature is disabled, all app-to-app traffic must go through the Gorouter.

Architecture

Overview

CF Networking integrates with Garden-runC in a Diego deployment. The CF Networking BOSH release includes several core components, as well as swappable components.

To understand the components and how they work, see the diagram and tables below. The diagram displays the CF Networking components in blue and other CF components in gray. The diagram also highlights swappable components in yellow.

c2c architecture diagram

Core Components

The CF Networking BOSH release includes the following core components:

Part Function
Cloud Foundry Command Line Interface (CF CLI) plugin A plugin that you download to control network access policies between apps.
Policy Server A central management node that does the following:
  • Maintains a database of policies for traffic between apps. The CF CLI plugin calls an API to create or update a record in the policy database whenever you create or remove a policy.
  • Exposes a JSON REST API used by the CF CLI plugin
Garden External Networker A Garden-runC add-on deployed to every Diego cell that does the following:
  • Invokes the CNI plugin component to set up the network for each app
  • Forwards ports to support incoming connections from the Gorouter, TCP Router, and Diego SSH Proxy. This keeps apps externally reachable.
  • Installs outbound whitelist rules to support Application Security Groups (ASGs).

Swappable Components

The CF Networking BOSH release includes the following swappable components:

Part Function
Flannel CNI plugin
A plugin that provides IP address management and network connectivity to apps.
  • Acquires IP address of container and relays to Garden
  • Installs network interface in container using the the flannel VXLAN backend. This is a shared, flat L3 network.
VXLAN Policy Agent
Enforces network policy for traffic between apps as follows:
  • Discovers desired network policies from the Policy Server Internal API
  • Updates iptables rules on Diego cell to allow whitelisted inbound traffic
  • Tags outbound traffic with the unique identifier of the source app using the VXLAN Group-Based Policy (GBP) header

App Instance Communication

Without CF Networking

The diagram below illustrates how two app instances communicate in a deployment without CF Networking enabled. Traffic from App A must route out and back in through the Gorouter, which restricts performance and the protocol used to send the traffic. In this scenario, App B does not know the real source of the traffic it receives and must trust all inbound traffic.

Pre CF Networking

With CF Networking

The diagram below illustrates how app instances communicate in a deployment with CF Networking enabled. In this example, the operator creates two policies to regulate the flow of traffic between App A, App B, and App C.

  • Allow traffic from App A to App B
  • Allow traffic from App A to App C

If traffic and its direction is not explicitly allowed, it is denied. For example, App B cannot send traffic to App C.

Post CF Networking

CF Networking versus ASGs

Both application security groups (ASGs) and CF Networking policies affect traffic from app instances. The following table highlights differences between ASGs and CF Networking policies.

ASGs CF Networking Policies
Policy granularity From a space to an IP address range From a source app to a destination app
Scope For a space, org, or deployment For app to app only
Traffic direction Outbound control Policies apply for incoming packets from other app instances
Source app Is not known Is identified because of direct addressability
Policies take affect After app restart Immediately

Policies

Enabling CF Networking for your deployment allows you to create policies for communication between app instances. The CF Networking feature also provides a unique IP address to each app container and provides direct IP reachability between app instances.

The policies you create specify a source app, destination app, protocol, and port so that app instances can communicate directly without going through the Gorouter, a load balancer, or a firewall. CF Networking supports UDP and TCP, and you can configure policies for multiple ports. These policies apply immediately without having to restart the app.

Alternative Network Stacks

The BOSH release that contains the CF Networking feature is composed of a pluggable network stack. Advanced users or third-party vendors can integrate a different network stack. For more information about third-party plugins, see the CF Networking BOSH release documentation.

View the source for this page in GitHub