This post is to cover one of the most (to my mind) interesting and powerful features of OpenContrail at the moment which is the service chaining. As part of the NVF approach we are looking to virtualise services (read boxes) that are already part of current networks.
The basic idea is to get away from services as appliances e.g. Firewall, Load Balancer, DPI, etc. are added to the network as boxes/appliances – when more capacity is required you add bigger boxes, and when you hit the largest size of box available from the vendor you either buy more or wait for the ‘next-generation’ platform to be released.
While there are good reasons for the box/appliance approach:
- Simpler troubleshooting for TAC
- Tested and verified performance levels – will do X pps for average packet size of Y
- Easy scoping of scale – we have N Mbps of traffic, what do we need to DPI this at the current levels of growth
if we are going down the SDN/NFV route obviously this approach will not work anymore since you have a virtualised appliance living somewhere in a data center, and ideally there is no contention/undercapacity where that appliance is living. As the demands scale up more appliances are activated to handle the new load, and as demand drops resources can be released back into the pool.
Traditional Service Chains
Standard network deployments consist of service chains, though they are not very flexible or dynamic. Consider the path a typical webserver would take to reach the Internet. From the internet, through a gateway towards a firewall (typically providing NAT services). From there through a Load Balancer and then to the server farm. Typically each link in the chain is a logically separated path e.g. a VLAN.
Dynamic Service Chaining
The more ideal approach is to have the different services e.g. Firewall, NAT, etc. provided on virtualised appliances that can also be hosted in our data center and scaled as required. These services can be added and removed from the traffic path as required, either by the customer or the hosting provider. Consider the use case of having vCPE [virtualised Customer Premises Equipment] – a simple box is installed on the customer site and all configuration and services and be added and removed in the Data Center.
One potential offer could be of a basic unfiltered connection, with firewall and DPI as a basic services package for €N per month, with other optional services on top of that. A simple web front end could effectively provide an ‘app store’ for network services, with pre-packaged services available for quick and easy deployment.
Service Chaining in Contrail
Network Policies allow the tenant to define what traffic is allowed to flow between which networks. As part of the policy configuration a set of service instances can also be included, to be applied in the order in which they are configured e.g. svc1, svc2, svc3 will have Network A -> svc1_vm -> svc2_vm -> svc3_vm -> Network B, with the reverse path also created automatically.
This is achieved through manipulation (automatically) of the BGP Next-Hops between the created routing instances (also automatic).
Service Instance
The Service Instance is simply a virtual machine that is providing the service. A most basic example would be a linux VM acting as a router between two virtual networks (not required of course since policies can do this for us, but any service that a linux server can provide can be chained). The convention is that there is a Left interface attached to the source network and a right interface attached to the destination network. We typically also include a 3rd interface on a Management interface to allow for the service VMs to be managed out-of-band of the traffic flow.
Configuring Service Chaining
This requires 3 elements:
- Service Template
- Service Instance
- Service Policy
Service Template
The service templates are defined within the Domain and can be used, and re-used, across Projects as many times as required. Main points for Template configuration are:
Service type – main types are:
- transparent – used for non-routed L2 services e.g. L2 Firewall
- In-Network – provides gateway services and the traffic is routed e.g. HTTP Proxy, NAT, LB
- In-Network NAT – same as In-Network but the return traffic doesn’t need to be routed back to the source network
Image – the GLANCE VM image that is used to provide the service
Service Instance
The service instance is the actual instantiation of the template. The main point is to add the correct virtual networks to the interfaces e.g. VN_source to Left interface and VN_destination to the Right interface.
Service Policy
The service policy allows the traffic between the virtual networks and instructs the system to chain that traffic through the service instances – in-order.
