Juniper Contrail’s key components

Juniper Networks announced yesterday the highly anticipated Contrail solution. Although this was spoken about May last year, yesterdays announcement was special. For a long time Juniper ran with the marketing strategy of “Everyone’s talking SDN. We’re defining it.” Rather bold from the Sunnyvale company considering the hyperbole around software defined networking. Well Juniper drew a big defining line in the sand yesterday. This very sound solution went Opensource.

So what makes up contrail and makes it special? The next few blog posts hope to encapsulate what Contrail is and how you could use it. It is important to look at what pieces make up this solution individually.

Four devices make up the Contrail overlay. This overlay comprises of the following:

Analytics Engine

This node provides REST interface to a series of databases containing the state information of virtual-networks, virtual-machines, configuration, control nodes. This also includes traffic flow records too. Stored in a distributed NoSQL database, this allows the scale out of information in a orderly fashion. Objected are defined using an IDL which allows database schemas to be easily communicated. Information is collected periodically or based on event triggers.

Control Node

The control node enables a distributed database that houses the rapidly changing system state. Federations between control nodes using BGP. BGP is utilized for communication with routers that support BGP/MPLS L3VPNs. To help achieve this distributed state, XMPP messaging protocols are used to distributed the desired network configuration state information. This includes such information as virtual-network interfaces to compute-nodes.

IF-MAP subsystems allow the correct information to be extracted from the configuration database and sent to the correct compute nodes. This allows the correct subset of information sent to the compute node. Control nodes recieve subscriptions styled messaging from agents for routing information for the specific routing instance.

Compute Node

This is a user space agent with a data plane component which executes on the host operating system. There are two parts known as the vRouter agent and vRouter data path. The agent is a process which communicates with the control node. This resourceful service is consumed by the compute node with nova or XAPI to enable the virtual-interface assigned to the VM. The data plane is associated to each instance with a VRF table. It then performs overlay encapsulation functionality enabling ACL, NAT, Multicast replication and some port mirroring.

Configuration Node

A REST API residing on the configuration node will allow orchestration of virtual networks, interfaces, and network policies to control the flow of traffic between virtual networks. It has the responsibility of remembering and storing the persistent network state. This allows the system to define the desired network state.

There are multiple processes which run upon the configuration node. The API server, which aids in publishing the evolving state of schema objects and the information to the IF-MAP server. The Schema transformer, which converts basic input into layered, complex output. The Service monitor, which creates and monitors VM instances which implements technologies such as NAT, firewalls, WAF, or load balancers. The Discovery service, which seeks to publish IP address and port information and finally, the DNS Server, which is a multi-tenant aware DNS server.

Closing thoughts

This is a strong overlay solution in which Juniper that goes boldly where only few have gone. The potential is huge for inter-operability between other solutions like Nuage with a common operating interface. to The ability to provide pockets of capability then further expansion increase the appetite for potential buyers. I see a strong movement of contributions through the open-sourcing of Contrail which can only help Junipers solution.