Sergei Gotchev, Juniper Networks
Juniper Day, Praha, 13.5.2015
Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf (kliknutím na tlačitko v dolní liště snímků).
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Contrail Deep-dive - Cloud Network Services at Scale
1. CONTRAIL DEEP-DIVE
Cloud Network Services at Scale
Sergei Gotchev
sgotchev@juniper.net
Juniper Networks Proprietary and Confidential -- printed copies of this document are for reference only
Scaling Secure Virtual Networks Within and Across Data Centers and Clouds
With OpenContrail, virtual network workloads are able to leverage automation and policy-based IP network services within and across data centers and heterogeneous cloud environments. OpenContrail’s standards based interoperability means that virtual networks can be extended from the data center overlay to existing multi-tenant WAN environments. This is critical to support emerging application environments required to efficiently scale simplified, interoperable and elastic cloud networks.
This is the Contrail software stack that we are going to discuss in detail in this section.
As we mentioned earlier, Contrail consists of two parts: a logically centralized but physically distributed controller, and a set of vRouters that serve as software forwarding elements implemented in the hypervisors of general purpose virtualized servers.
Contrail Controller provides northbound REST APIs used by applications. These APIs are used for integration with the cloud orchestration system, for example for integration with OpenStack via a neutron (formerly known as quantum) plug-in. The REST APIs can also be used by other applications and/or by the operator’s OSS/BSS. Finally, the REST APIs are used to implement the web-based GUI included in the Contrail System.
The Contrail System provides three interfaces: a set of north-bound REST APIs that are used to talk to the Orchestration System and the Applications, southbound interfaces that are used to talk to virtual network elements (vRouters) or physical network elements (gateway routers and switches), and an east-west interface used to peer with other controllers. OpenStack and CloudStack are the supported orchestrators, standard BGP is the east-west interface, XMPP is the southbound interface for vRouters, BGP and Netconf and the southbound interfaces for gateway routers and switches.
Internally, the controller consists of three main components:
Configuration nodes, which are responsible for translating the high-level data model into a lower level form suitable for interacting with network elements;
Control nodes, which are responsible for propagating this low level state to and from network elements and peer systems in an eventually consistent way;
Analytics nodes, which are responsible for capturing real-time data from network elements, abstracting it and presenting it in a form suitable for applications to consume.
Let’s take a closer look into the compute node.
The compute node is a general-purpose x86 server that hosts VMs. Those VMs can be tenant VMs running customer applications, such as web servers, database servers, or enterprise applications, or those VMs can be host virtualized services used to create service chains. The standard configuration assumes Linux is the host OS and KVM or Xen is the hypervisor. The vRouter forwarding plane sits in the Linux Kernel, replacing the Linux Bridge or OVS module; and the vRouter Agent is the local control plane sitting in the Linux user space. Other host OSs and hypervisors such as VMware ESXi or Windows Hyper-V may also be supported in future.
The vRouter functions at Layer 3 instead of Layer 2, so it has enhanced service capabilities to carry out Security Policies, NAT, Multicast, Mirroring and Load Balancing right at the server hypervisor.
Each VM is mapped into one or more VRFs on the vRouter. The vRouter Agent populates the VRFs using information learnt over XMPP. The traffic that leaves the server is MPLS over GRE traffic, so only IP transport is needed to instrument these VNs. The performance numbers are very close to Linux bridge performance.
Let me walk you through how communications are happening between two VMs (VM1 and VM2) with IP addresses VN-IP1 and VN-IP2 on different physical servers but belonging to the same virtual network. We will worry about how the forwarding tables on both routers are set up but let’s assume that they are there already.
1. An application in VM1 sends an IP packet with destination IP address of VM 2a VN-IP2.
2. VM1 has a default route pointing to a 169.254.x.x link-local address in routing instance 1.
3. VM 1a sends an ARP request for that link local address. The ARP proxy in routing instance 1 responds to it.
4. VM 1a sends the IP packet to routing instance 1.
5. IP FIB on routing instance 1 contains a /32 route to each of the other VMs in the same virtual network including VM2. This route was installed by using the control node using XMPP. The next-hop of the route does the following:
Imposes an MPLS label, which was allocated by vRouter 2 for routing instance 2.
Imposes a GRE header with the destination IP address of Compute Node 2.
6. vRouter 1 does a lookup of the new destination IP address of the encapsulated packet (IP address of Compute Node 2) in global IP FIB 1.
7. vRouter on compute node 1 sends the encapsulated packet to Compute Node 2. How exactly this happens depends on whether the underlay network is a Layer 2 switched network or a Layer 3 routed network. For now we will skip this part and assume the encapsulated packet makes it to Compute Node 2.
8. Compute Node 2 receives the encapsulated packet and does an IP lookup in its global IP FIB. Since the outer destination IP address is local, it decapsulates the packet, i.e., it removes the GRE header which exposes the MPLS header.
9. Compute Node 2 does a lookup of the MPLS label in the global MPLS FIB 2 and finds an entry which points to routing instance 2. It decapsulates the packet, i.e., it removes the MPLS header and injects the exposed IP packet into routing instance 2a.
10. Compute Node 2 does a lookup of the exposed inner destination IP address in IP FIB 2. It finds a route that points to the virtual interface connected to VM2.
11. Compute Node 2 sends the packet to VM2.
Bare-Metal Server (BMS) and Virtual Machine (VM) Interconnect
Layer-2 Gateway using VXLAN + EVPN
Layer-3 Gateway using MX, VXLAN + EVPN
Integration with ESXi using Openstack
Multi- DC Distributed Cloud (DC Interconnect)
Interconnect with Legacy VLAN architecture running ESXi
These are the Use Cases/Applications for NFV by Juniper services and third party best-of-the-breeds