Service Chaining - Cloud Network Services at Scale
•Download as PPSX, PDF•
3 likes•2,080 views
Virtualization Forum 2015, Praha, 7.10.2015 sál Juniper Networks Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Service Chaining - Cloud Network Services at Scale
Similar to Service Chaining - Cloud Network Services at Scale (20)
More from MarketingArrowECS_CZ
More from MarketingArrowECS_CZ (20)
Recently uploaded
Recently uploaded (20)
Service Chaining - Cloud Network Services at Scale
- 1. SERVICE CHAINING Cloud Network Services at Scale Sergei Gotchev sgotchev@juniper.net Juniper Networks Proprietary and Confidential -- printed copies of this document are for reference only
- 2. 2 Copyright © 2014 Juniper Networks, Inc. www.juniper.net HIGH LEVEL CONTRAIL ARCHITECTURE
- 3. 3 Copyright © 2014 Juniper Networks, Inc. www.juniper.net CONTRAIL ARCHITECTURE Analytics CONTRAIL CONTROLLER ControlConfiguration x86 Host + Hypervisor ORCHESTRATOR x86 Host + Hypervisor Physical IP Network (no changes) vRouter vRouter Gateway Internet / WAN Legacy Infra. (VLAN, etc.) Bi-directional real-time message bus using XMPP Network orchestration Standard protocol (M-BGP) to talk with other Contrail controller instances Compute / Storage orchestration … Others
- 4. 4 Copyright © 2014 Juniper Networks, Inc. www.juniper.net CONTRAIL STACK Configuration Nodes Control Plane Compute Node (Virtual Router) Service Node (SRX, Firefly, JSP, ...) Gateway Node (MX, EX/QFX, ...) Control Plane Control Plane Analytics Engine Analytics Engine Analytics Engine REST APIs (Configuration, Operational, and Analytics) OpenstackCustomer OSS/BSS Cloudstack
- 5. 5 Copyright © 2014 Juniper Networks, Inc. www.juniper.net COMPUTE NODE – HYPERVISOR, VROUTER Compute Node Virtual Machine (Tenant B) Virtual Machine (Tenant C) Virtual Machine (Tenant C) vRouter Forwarding Plane Virtual Machine (Tenant A) Routing Instance (Tenant A) Routing Instance (Tenant B) Routing Instance (Tenant C) vRouter Agent Flow Table FIB Flow Table FIB Flow Table FIB Overlay tunnels MPLS over GRE, UDP or VXLAN JUNOSV CONTRAIL CONTROLLER CONTRAIL CONTROLLER XMPP Eth1Kernel Tap Interfaces (vif) pkt0 User Eth0 EthN Config VRFs Policy Table Top of Rack Switch XMPP • vRouter replaces the Linux Bridge or OVS module in Hypervisor Kernel • vRouter performs bridging (E-VPN) and routing (L3VPN) • vRouter performs networking services like Security Policies, NAT, Multicast, Mirroring, and Load Balancing • No need for Service Nodes or L2/L3 Gateways for Routing, Broadcast/Multicast, NAT • Routes are automatically leaked into the VRF based on Policies • Support for Multiple Interfaces on the Virtual Machines • Support for Multiple Interfaces from Compute Node to the Switching Fabric
- 6. 6 Copyright © 2014 Juniper Networks, Inc. www.juniper.net COMPUTE NODE – FORWARDING/TUNNELING Overlay tunnels MPLS over GRE or VXLAN Compute Node 1 vRouter Forwarding Plane Virtual Machine 1 (VN-IP1) Routing Instance 1 Flow Table FIB Eth1 (Phy-IP1) Tap Interfaces (vif) Compute Node 2 vRouter Forwarding Plane Virtual Machine 2 (VN-IP2) Routing Instance 2 Flow Table FIB Eth1 (Phy-IP2) Tap Interfaces (vif) VIRTUAL PHYSICAL Virtual-IP2 Payload Virtual-IP2 Payload MPLS / VNI Phy-IP2 Virtual-IP2 Payload Virtual-IP2 Payload MPLS / VNI Phy-IP2 1. Guest OS ARPs for destination within subnet or default GW 2. VRouter receives the ARP and responds back with VRRP MAC 3. Guest OS sends traffic to the VRRP MAC, Vrouter encapsulates the packet with appropriate MPLS/VNI tag and GRE header 1. Physical Fabric Routers on Physical IP Address 1. Returning packets get forwarded to appropriate Routing Instance by the MPLS/VNI tag 1. VRouter de-capsulates the packet, and forwards it to the Guest OS
- 7. 7 Copyright © 2014 Juniper Networks, Inc. www.juniper.net CONTRAIL SERVICE CHAINING R1 R2 SVC 1 VM Virtual Network Red Virtual Network Green G1 G2 SVC 2 VM L3 L5 L3 L4L2 L6 R1 R2 L1 L4 Srvr = S1 Server = S2 S4 L5 L6 S3 Locally significant MPLS Labels Seamless insertion of Juniper & unmodified 3rd Party services using existing L3VPN connections Allows multiple Services in a chain Allows multiple service chains between virtual networks Supports L3 services without the use of a gateway RI for non-svc-chain traffic LOGICALPHYSICAL G1 G2 VIF 2 L2 Interf = VIF 1 Label = L1 VIF 4 L8 Interface = VIF 3 Label = L7 Dst Next Hop G1 S2 L3 G2 S2 L3 R1 VIF 1 R2 VIF 2 Dst Next Hop R1 S1 L1 R2 S1 L2 Dst Next Hop G1 S3 L5 G2 S3 L5 Dst Next Hop R1 S2 L4 R2 S2 L4 Dst Next Hop G1 S4 L7 G2 S4 L8 Dst Next Hop R1 S3 L6 R2 S3 L6 G1 VIF 3 G2 VIF 4 SVC 1 VM SVC 2 VM X86 Servers L1 L7 L8 Routing Instances IP Fabric
- 8. 8 Copyright © 2014 Juniper Networks, Inc. www.juniper.net SERVICE CHAINING FOR THE SP
- 9. 9 Copyright © 2014 Juniper Networks, Inc. www.juniper.net9 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SERVICE COMPLEX TODAY LOAD BALANCING Appliance LOAD BALANCING Appliance Router LIMITATIONS Even coarse service chains are complex Over provisioned network appliances to meet total demand Simplified tenant isolation for security and regulation compliance Inefficient chains with duplicate packet processing PARENTAL CONTROL Appliance APPLICATION Appliance CACHING & CONTENT Appliance FIREWALL Appliance NETWORK ADRESSING Appliance DPI/TDF Appliance WEB AWARE Appliance Tie awareness to policy to monetization Multiple routing platforms Appliances limit flexibility; add complexity
- 10. 10 Copyright © 2014 Juniper Networks, Inc. www.juniper.net SERVICE CONTROL GATEWAY FUNCTIONALITY Contrail Controller SCG
- 11. 11 Copyright © 2014 Juniper Networks, Inc. www.juniper.net SCG - SERVICE CHAINING Service Control Gateway VPN Internet GGSN/PGW Mobile accessLaptop Smartphone (S)Gi Feature Phone PCRFSPR AAA Wireline access Gx BNG OCS Sy Subscriber State Machine BSS Systems OSS Systems Gy ServiceCard DPI HE/URL Caching Gx/ Sd Gyn PFE Forwarding / Flow Table PFE VRF/ Tunnel Flow control API Data Center Servers VMs VASApplicationseg. DPI VASApplicationseg. TCPProxy VSwitch OtherApps Analytics Billing Hypervisor VMs VMs OtherApps AAA Gx Gx SRC AAA Contrail Controller Can manage service chaining without an SDN Controller within the confines of SCG Requires SDN Controller to chain services outside the confines of SCG
- 12. 12 Copyright © 2014 Juniper Networks, Inc. www.juniper.net Contrai l INT GWSubs Contrai lSN 1 SN 2 SN nMX GW INTERNET Contrai l INT GWSubs SN 1 SN 2 SN n MX GW INTERNET OPEN/Close Service Chain CLOSED Asymmetric / Symmetric NAT @ Leaf Service Node? Single/Multiple Service Hop OPEN DC SERVICES CHAIN TYPES
- 13. 13 Copyright © 2014 Juniper Networks, Inc. www.juniper.net CLOUD CPE
- 14. 14 Copyright © 2014 Juniper Networks, Inc. www.juniper.net Simple CPE Cloud CPE Physical CPE’s Routing WOC FirewallDPI Cloud CPE Customer Site Network Service Provider Virtualized Services Services Gateway/ Branch Router Junos Space OpenStack NOVA NEUTRON Contrail
- 15. 15 Copyright © 2014 Juniper Networks, Inc. www.juniper.net Internet SP IMPLEMENTATION OF VIRTUAL SERVICES CHAIN Junos Space Create Networks Contrail Controller OpenStack NOVA NEUTRON Create VM FW, DPI Enterprise FW, DPI, NAT, INTERNET
- 16. 16 Copyright © 2014 Juniper Networks, Inc. www.juniper.net MANAGED ENTERPRISE SERVICE Enterprise Customer Edge Services decoupled from Access – Centralized Complexity– Everything as a Service Customer & network context in service chain mediation JS vCPE Self-care Network Services (VPN, FW, NAT, IPS) Data Center BUSINESS EDGE Virtual CE Router Service
- 17. 17 Copyright © 2014 Juniper Networks, Inc. www.juniper.net MANAGED ENTERPRISE SERVICE OpenStack & Contrail Controller Security Virtual Services (vSRX, vSA, etc) Dynamic Service Chain Customer & network context in service chain mediation JS vCPE Self-care Network Services (VPN, FW, NAT, IPS) Data Center Security BUSINESS EDGE Contrail SDN Controller Edge Enterprise Customer Services decoupled from Access – Centralized Complexity– Everything as a Service
- 18. 18 Copyright © 2014 Juniper Networks, Inc. www.juniper.net MANAGED ENTERPRISE SERVICE OpenStack & Contrail Controller Security Virtual Services (vSRX, vSA, etc) Dynamic Service Chain Customer & network context in service chain mediation JS vCPE Self-care Network Services (VPN, FW, NAT, IPS) Data Center Security BUSINESS EDGE Contrail SDN Controller Edge DDoS Cache 3rd Party Enterprise Customer Services decoupled from Access – Centralized Complexity– Everything as a Service
- 19. 19 Copyright © 2014 Juniper Networks, Inc. www.juniper.net CONTRAIL PARTNERSHIP HIGHLIGHTS
- 20. 20 Copyright © 2014 Juniper Networks, Inc. www.juniper.net THANK YOU
Editor's Notes
- 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 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.
- 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.
- VM’s can deploy virtualized L4-L7 network services such as firewalls, Deep Packet Inspection (DPI), HTTP header enrichment, caching, L7 load balancing, etc. The coordination with local and global control planes is designed to support the concept of service chaining. The actual services logic running on top of VM’s does not need to worry about the mechanics of chaining. Contrail supports service chaining, which allows virtual networks to be connected subject to policy constraints. A simple rule allows HTTP traffic to flow from virtual network Red to virtual network Green and forces the traffic through a service chain which consists of service svc 1 followed by service svc 2. The rules are applied to entire virtual networks, not to individual virtual machines. In the above example, the rule applies when any virtual machine in virtual network Red sends traffic to any virtual machine in virtual network Green. A service is simply a virtual machine. Contrail is only concerned with traffic steering, i.e. with injecting the traffic flows into the right virtual machines using a virtual interface. The provisioning of the services themselves is outside of the scope of Contrail. The traffic is steered: By manipulating the route targets for routes to influence importing and exporting routing from one routing instance to another routing instance. By manipulating the next-hops and/or the labels of the routes as they are leaked from routing instance to routing instance to force the traffic through the right sequence of routing instances and the right sequence of corresponding virtual machines.
- Typical Services LAN are based on physical boxes delivering functions like Load Balancing, Parental Control, Deep Packet Inspection (DPI), Video optimization, Network Address Translation (NAT) and Firewall. Issues for scaling those services are based on different scaling requirements per service / hardware, which has to be always designed for a maximum capacity. If the projection is not correct it is hard to quickly react and scale a given service. In general, due to changes in the user behavior and adaptation to new trends or application usage in the Internet (IOS9 as example last week crashed the Apple service), it is hard to dynamically adjust the resources on the Service Provider site. So today Service Providers have to deploy each service for the expected peak utilization. This is clearly a problem that can be addressed with a flexible service offering leveraging the Contrail’s services chaining and SCG to enable Service Providers to transition from a physical to more virtualized service components.
- the Juniper Service Control Gateway (SCG), based on the Juniper MX-3D platform, acts as a subscriber- and application-aware edge node integrated with an existing wireline or mobile edge that enables implementation of per-subscriber control of services through policy actions. The enhanced Traffic Detection Function (TDF) provides per subscriber policy and charging control at the application level by using L3-4 policies or up to layer 7 through Deep Packet Inspection (DPI) signatures. It performs policy controlled steering of subscriber/application flows into service chains that concatenate a set of Value Added Services (VAS) resources, deployed on physical or virtualized resources. Virtualized resources could be managed by the Juniper Contrail SDN Controller, which automates the provisioning and establishment of the Service chain (which is implemented by creating an overlay MPLS/GRE tunnel between the Service chain attachment points (the SCG)).
- An MX acting as a Services Control Gateway requires a dedicated JUNOS version, running on an MX-240, 480 or 960. In addition you must have at least one service card. On the service card you host two functions. At least one service PIC and one session PIC need to be configured. A session PIC supports access subscriber session setup and management, enabling the steering of subscriber traffic to the correct services PIC. The session PIC also sets up a session with the policy and charging rules function (PCRF) so it can receive subscriber PCC rules from the PCRF and send application-start messages to the PCRF. A service PIC provides subscriber-aware policy enforcement and traffic steering that is application-aware. Traffic steering refers to the capability to direct or traverse traffic from a specified source to an endpoint or the adjacent network element in a routing path. The service PIC is configured with software plugins to perform the configured or requested services, which include the policy and charging enforcement function (PCEF), application detection and control, HTTP header enrichment, HTTP redirect, and network address translation. There are multiple types of service chains – Open and Close, where you may see specific requirements for supporting Asymmetric or Symmetric traffic across a single or multiple service hop chain.
- Open service chain starts wide open to remote service complex and is not closed by the subscribers interface in order to take a decision how to send the packet. So, only single service chain will be used to steer upstream traffic to virtual service complex. In open type service chain, NAT can be used to steer return traffic to service complex back again to develop symmetric path. Using NAT is very simple and easy way to solve a symmetric path issue, as return traffic’s destination address will be part of NAT pool prefix. This means you do have a simple routing look up decision in the core network and you will forward return traffic back to NAT service. Closed service chain type contains all service chain complex under MX GW control (more specifically the subscriber interface) here – traffic steering, service chain start/end – there is no major external impact on the access and core facing network at all. Compared to open service chain, NAT does not need to be applied on last leaf node of service chain path as the MX GW can provide symmetric path without using NAT.
- The current setup on most of the with business customers is based on multiple devices providing different functionality such as switching, firewalling, deep packet inspection, WAN optimization, etc. on the customer premises. This assumes that each and every device has specific capacity which shall cover maximum capacity without any possibility to upgrade without HW replacement. Deploying new services (for example proxy or content filtering) requires new device, down-time, re-configuring the devices etc. and the whole process from ordering the service until deploying it on site may take months. On another hand the Cloud CPE allows to replace the complex layer 3 CPEs on site by simple layer 2 or L3 CPEs. The CPE functions are moved to the data center on the MX (or external x86 appliances), which is acting as a provider edge in the service provider network. The network consists of MXs providing L3 connectivity to CPEs at customer sites and providing Internet and VPN access. The Cloud CPE context for each customer site is implemented by a routing instance to provide separate routing, DHCP, SNMP, and other services.L3 Services like IPSec, NAT for Internet access, and stateful firewalls are implemented by either on the services cards or VM’s running on top of hypervisor. The management and provisioning solution is based on Junos Space. Network Activate can optionally be used to provision the network, create end customers, and associate L3 VPN services with customers. Service templates providing Cloud CPE specific functions (for example routing protocols, DHCP servers or relay, and NAT services) can be attached to Network Activate services for provisioning of Cloud CPE functionality when L3 VPNs are deployed.
- Walk through the provisioning flow to describe Contrail/Openstack configuration step. Tearing down the service works in the opposite direction and the monitoring is seen on a per Service instance.