Virtual machines have been around for a long time, but we are beginning to spread our compute workloads in a number of different ways. When you throw in docker containers and bare metal servers, networking becomes a bit more interesting. Network challenges arise when all these components require communication within the same subnet, access to Internet gateways and Layer 3 MPLS/VPN’s.
Data centre networks are moving towards IP underlay fabrics and Layer 2 overlays. Layer 3 data plane forwarding utilizes efficient Equal-cost multi-path routing (ECMP) but by default we lack Layer 2 multipathing. Now, with the overlay approach we can connect dispersed layer 2 segments and leverage all the good features of the IP underlay.
To provide Layer 2 overlays and network virtualization, Juniper has introduced an SDN platform called OpenContrail.
OpenContrail is an open source network virtualization platform. The commercial controller and open source product are identical, they literally share the same checksum on the binary image. Maintenance and support being the only difference. Juniper decided to open source as they wanted to fit into the open ecosystem, which wouldn’t have worked in a closed environment. OpenContrail offers similar features to vmware NSX and has capabilities to apply service chaining, high-level security policies and provide the connection to Layer 3 VPNs for WAN integration. OpenContrail works with any hardware, but integration with Juniper’s product sets offers additional integrated rich analytics for the underlay network. Underlay and overlay visibility is key for troubleshooting. You need to look further than the first header of the packet, you need to look deeper into the tunnel to fully understand what is happening.
Network Virtualization – Isolated Networks
With a cloud architecture, the idea of network virtualization gives the illusion to each tenant they have a separate isolated network. Virtual networks are independent of physical network location or state and nodes within the physical underlay can fail without any disruption to the overlay tenant. A tenant may be a customer or department depending if it’s a public or private cloud. The virtual network sits on top of a physical network, the same way the compute virtual machines sits on top of a physical server. Virtual networks are not created with VLANs, Contrail uses a system of network overlays for multi-tenancy and cross tenant communication. There are way too many problems with large scale VLAN deployments for multi-tenancy in today’s networks. They introduce a lot of state in the physical network and Spanning Tree Protocol (STP) also introduces well-documented problems. There are technologies (THRILL, SPB) to overcome these challenges but they add to complexity to the networks design.
Customers require the ability apply policy at virtual network boundaries. Policies may include ACL and stateless firewalls that may be provided within the virtual switch. But once you require complicated pieces of policy between virtual networks you need a more sophisticated version of policy control and orchestration called service chaining. Service chaining applies intelligent services between traffic from one tenant to another. If a customer requires content caching and stateful services, you need to introduce additional service appliances and force next hop traffic through these appliances. Once you start to deploy virtual appliance you need a scale-out architecture. Scale out is the ability to instantiate multiple physical virtual machines instances and load balance traffic across it. Customers may also require the ability to connect different tenants in dispersed geographic locations or connect to workloads in a remote private cloud or public cloud. Usually, people build a private cloud for the norm and then burst to a public cloud.
Juniper have implemented a virtual networking architecture that meets these requirements. It is based on well-known technology, MPLS/layer 3 VPN. MPLS/layer 3 VPN is the base for Juniper designs.
Virtual Network Implementation
The SDN controller is responsible for the networking aspects of virtualization. When you want to create virtual networks, initiate the Northbound API and issue an instruction that attaches VM to the VN. The network responsibilities are delegated from Cloudstack or OpenStack to Contrail. The Contrail SDN controller automatically creates the overlay tunnel between virtual machines. The overlay can be MPLS-over-GRE, MPLS-over-UDP, and VXLAN.
Juniper Contrail is still a pure MPLS/VPN, using L3VPN for routed traffic and EVPN for bridged traffic. Traffic forwarding between end nodes has one MPLS label (VPN label) but they use various encapsulation methods to carry labelled traffic across the IP fabric. As mentioned above this includes MPLS-over-GRE – traditional encapsulation mechanism, MPLS-over-UDP – a variation of MPLS-over-GRE that replaces the GRE headers with UDP header. And MPLS-over-VXLAN that uses VXLAN packet format but stores the MPLS label in the Virtual Network Identifier (VNI) field.
The forwarding plane takes the packet from the VM and gives it to the “Vrouter”, which does a lookup and determines if the destination is a remote network. If it is a remote network, it encapsulates the packet and sends it across the tunnel. The underlay that sites between the workloads forward based on tunnel source and destination only. There is no state belonging to end hosts VM’s, no MAC addresses or IP’s. This type of architecture gives the Core a cleaner and precise role. Generally, as a best practise, keeping “state” in the Core is a bad design principle.
Northbound and Southbound Interfaces
To implement policy and service chaining use the Northbound Interface and express your policy at a high level. For example, you may require HTTP or NAT and force traffic via load balancer or firewall device. Contrail does this automatically and issues instructions to the Vrouter forcing traffic to the correct virtual appliance. It can create all the right routes and tunnels forcing traffic through the right sequence of virtual machines. Contrail achieves this automatically with southbound protocols, such as XMPP (Extensible Messaging and Presence Protocol) or BGP. XMPP is a communications protocol based on XML (Extensible Markup Language).
For WAN integration, Contrail can connect virtual networks to external Layer 3 MPLS VPN. They gave the controller the ability to peer BGP to gateway routers. For the data plane, they support MPLS-over-GRE and for control plane they speak MP- BGP. Contrail communicates directly with PE-routers, exchanging VPNv4 routes with MP-BGP and using MPLS-over-GRE encapsulation to pass IP traffic between hypervisor hosts and PE-routers. Using standards-based protocols allows you to choose any hardware appliance as the gateway node.
This type of data and control plane makes integration to an MPLS/VPN backbone a simple task. Simply establish MP-BGP between the controllers to PE-routers. Inter-AS Option B next hop self-approach should be used to establish some kind of demarcation point.