Faking Service Chains at Layer 3

In the last post we introduced the concept of Service Function Chaining (SFC). In that post we suggested that SFC occurs at the virtual port layer, somewhere around layer 1 of the OSI model. We can debate whether it is truly layer 1 or not, in part because SFC is usually performed by a Software Defined Network (SDN) of some arbitrary design. However, regardless of the underlying technology, certainly as far as a virtual machine that is part of the chain is concerned, we are connecting a virtual port directly to another virtual port.

Many organizations will choose not to do “pure” SFC and instead deploy service chains at the layer 3 level, essentially looking like the hop-by-hop networking we are all used to, with default gateways, routers, virtual IPs, and the like.

When we build chains of devices at the layer 3 level we are doing so (usually) because:

1. We want to keep things simple, and/or
2. More commonly, we don’t have access to an SDN that can actually provide layer 1-like SFC functionality.

Layer 3 SFC and Infrastructure-as-a-Service

IaaS systems like OpenStack provide the ability to create all manner of virtualized network components. When deploying virtual network functions (VNFs, basically virtual machines, example: a virtual firewall) into IaaS we have much control over what their networking looks like.

For example, we can use OpenStack APIs to create virtual networks and virtual routers, and inject specific static routes, add ports to virtual networks, and also alter the network configuration of the actual VNF in at least three major ways:

1. via Neutron-controlled network settings,
2. via Cloud-init and metadata or config drive and
3. through configuration management tools such as Ansible or Puppet and similar post-provisioning activities.

Layer 3 Chains of Virtual Devices

Using the aforementioned methods, we can build a virtual chain of devices that receive packets to forward through normal layer 3 methods.

For example, say we want to build a chain that consists of a load balancer, a web application firewall, a standard firewall, and then finally a web server, but we don’t have an SDN integrated with our OpenStack system that can provide layer 1 SFC.

We can certainly build that via standard automation using almost any provisioning and configuration management tools and IaaS APIs. We can build virtual networks and routers, provision virtual machines, and once they are running, configure them to use standard layer 3 concepts to connect in a chain. If desired we can also use concepts like “allowed address pairs” in OpenStack to configure virtual IPs between multiple VNF instances.

VNF Forwarding Graphs

The reason we use the word “fake” in this post is because there actually has been a lot of thought put into how creating SFC will be done.

In the field of Network Function Virtualization (NFV) we also have the concept of the VNF Forwarding Graph (VNFFG). VNFFGs are out of the scope of this blog post but suffice it to say most systems that can generate them are currently assuming a standard port-pair SFC model, not a layer 3 one. For example, the OpenStack Tacker VNF Manager project requires the OpenStack networking-sfc system in order to enact VNFFGs. In other words, stopping short of “pure” SFC could mean not being able to take advantage of some advanced automation tooling, though, of course, this is all relatively new technology and certainly things will change.

Conclusion

Ultimately the more technically interesting version of SFC is the layer 1 port-to-port model where packets magically appear on VNF interfaces to be processed and forwarded. But that adds a fair amount of complexity because it usually requires some kind of SDN (though the OpenStack networking-sfc project will reduce that requirement), and, until tools catch up, makes troubleshooting more difficult. Many organizations may simply prefer to create “fake” chains using automation, IaaS APIs, and layer 3 networking. This is completely valid, as the point of the chain is to provide some kind of automatable, customizable, and alterable product that can be sold as a service. Further, not every chain can and will be made up of only non-layer 3 functions.