BT

Project Calico v1.0 'Layer 3' Virtualised Networking Solution Released

| by Daniel Bryant Follow 698 Followers on Aug 19, 2015. Estimated reading time: 7 minutes |

Project Calico have released Calico v1.0, a virtualised layer 3 networking solution for VM and container workloads, which enables flexible, scalable and secure IP-based communication without the need for an overlay network. The release includes integration with the OpenStack 'Neutron' networking stack (including the support of VM live migration), and ‘proof of concept level’ integrations with container management and orchestration systems, such as Docker, Kubernetes and other related technologies.

Calico supports IPv4 and IPv6 traffic, and provides a flexible security policy using whitelists for permitted traffic and ‘bookended’ access control lists (ACLs). The Project Calico blog also states that the Calico team have conducted extensive testing to ensure the technology is deployable at scale, and details of the results will be published on the blog over the coming weeks.

InfoQ sat down with Martin Taylor, Metaswitch CTO and Project Calico evangelist and asked questions about virtual networking, Project Calico and the recent Calico version 1.0 release.

InfoQ: Could you explain a little about what Project Calico is, and also introduce the key concepts of virtual networks and the differences between layer 2 and layer 3 networking?

Taylor: Calico is an open source software solution for providing secure network connectivity to all kinds of virtualized workloads running in cloud environments, including virtual machines running on top of hypervisors and containers running in Docker, rkt, runc, and other container solutions.

Currently, most solutions for networking virtualized workloads are based on the concept of providing an emulation in software of an Ethernet segment, i.e. a Layer 2 network, as the basis for connecting the workloads together.  This runs on top of an IP-routed physical network (i.e. a Layer 3 network) that connects the physical hosts together in the data center.  Emulating Ethernet L2 segments on top of a physical IP L3 network is known as an “overlay”, and it involves the software constructing a mesh of tunnels that allow Ethernet packets to flow between workloads on different hosts.  Overlay networks are complex, hard to troubleshoot and suffer significant scaling limitations.  Also, they force application developers to wrestle with networking concepts such as L2 segments, virtual routers, network address translation etc.

Calico takes a much simpler approach, and involves connecting all virtualized workloads directly to the IP-routed L3 network fabric in the data center via a software-based router in each compute node.  Isolation between different tenants in the cloud is provided by configuring firewall rules on the router software in each compute node.  By applying the same design principles and control plane technologies as those on which the Internet is based, Calico scales almost without limit.  And since workloads communicate with each other directly over IP, all the usual diagnostic tools such as ping and traceroute just work.  Calico also offers application developers a much more natural way of describing how they want their workloads connected together, and supports fine-grained policy rules that enable connectivity between workloads to be securely locked down to meet the precise needs of each application.

InfoQ: We are hearing quite a lot about overlay networks in the context of containers and cluster managers (Mesos, Kubernetes etc.), and also the performance impact. What are your thoughts on this?

Taylor: Overlays are currently the predominant networking solution in cloud technologies that are oriented towards virtual machines such as OpenStack and VMware, and so naturally the overlay approach is going to be considered as a candidate for networking containers.  In our view, overlay-based networking approaches are not well suited for containers, since it is usual to pack many more containers onto each compute node than is typical with VMs, and this tends to exacerbate the scaling issues with overlay networks.  Also, containers tend to come and go far more rapidly than VMs, and this puts a lot of stress on the complex control plane of overlay networks, which struggles to keep up.  Containers are a lightweight approach to virtualizing workloads, and Calico is a lightweight technique for networking virtualized workloads, so Calico is very well aligned with the philosophy behind containers.  Calico has been proven to handle networking of containers at very large scale and with high churn (e.g. 50,000 containers with a setup rate of 20 containers per second), and is gaining a lot of traction in the communities around containers and container orchestration.

InfoQ: We know Project Calico is a pure L3 approach to virtual networking. What are the advantages and disadvantages of this?

Taylor: We’ve already covered many of the advantages of Calico’s L3 approach to virtual networking, but to summarize:

  • It’s more scalable because it embodies Internet-style architecture
  • It’s easier to troubleshoot because workloads communicate natively in IP rather than over tunnels
  • It’s simpler to setup and configure than any overlay solution
  • It offers application developers a simpler and more natural abstraction for describing the connectivity required for virtualized workloads than overlay solutions
  • It’s more interoperable because it does not require Network Address Translation to provide connectivity to physical machines or external Internet access, unlike overlay solutions
  • It’s more secure by virtue of its built-in distributed firewall functionality

There are very few disadvantages with Calico’s L3 approach.  One obvious challenge is where a virtualized workload specifically requires L2 connectivity, for example to support some legacy fault-tolerance mechanism such as IP address swapping.  But we see the focus on new data center rollouts today being more about new application development embracing new technologies like containers and modern application architectures such as microservices, and Calico is a perfect fit for these kinds of environments.

InfoQ: What are the security implications of using a virtual network?

Taylor: Security is obviously a hugely important topic with virtual networking in cloud environments.  The L2-centric overlay approach to networking is all about replicating the physical world of isolated L2 segments, routers and firewalls in the virtual world, but we see this as a clumsy and inefficient way to implement security.  Calico supports the configuration of fine-grained connectivity policies for each workload, and these policies are rendered into firewall rules that are automatically applied between each and every workload and the physical network fabric in both ingress and egress directions.  This provides for the maximum possible network security without the inefficiency inherent in moving packets between overlay L2 segments via separate and distinct firewall functions in the cloud.

InfoQ: How do you see network technology evolving over the next twelve months?

Taylor: We’ve seen a lot of frustration building up among early adopters of OpenStack with the challenges of overlay networks.  Calico is hugely appealing to many of these because of its simplicity, its scalability and its ease of troubleshooting.  We think that over the next 12 months, L3 networking approaches such as Calico are going to achieve wide recognition as valid alternatives to the overlay model.  Also, the container space is really hot right now, with Docker, CoreOS, Kubernetes, Mesosphere and others attracting a huge amount of interest.  Over the next 12 months we expect to see these technologies becoming sufficiently mature to start supporting production-grade cloud deployments, and we expect to see L3 networking approaches like Calico being strongly favored in these deployments.

InfoQ: If someone wants to get started with Project Calico, what is the best way?

Taylor: Visit http://projectcalico.org to access more information about Calico, including full and detailed documentation, and to download Calico software.

InfoQ: Thanks for your time today. Is there anything else you would like to share with the InfoQ readers?

Taylor: Every now and then, a completely new approach to a technical problem arrives on the scene which, in retrospect, seems blindingly obvious – and we wonder why no-one has solved the problem this way already.  Calico is just such a solution in the virtual networking space.  If you’re designing a new data center, you should ask yourself whether you really need an overlay-based virtualized network.  If you don’t have a strong and explicit reason to need overlays, then an L3-based approach like Calico is likely to make your life a good deal easier.

Ed Harrison, core developer and evangelist on Project Calico recently presented a high-level overview of Calico at the Docker London Meetup, and a video recording of this talk is available on the Docker Youtube channel. Additional information on Project Calico can be found on the Calico website, and details of the recent version 1.0 release can found in the ‘Announcing Calico v1.0’ blog post.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Weave by David Dawson

how does this compare?

Re: Weave by Daniel Bryant

From my understanding David, Weave works as an L2 overlay network, which is described in one of Martin's answers above. Did you have any specific comparison points you were interested in? I could then try and provide more info

I've also pinged out the question to the Weaveworks team to see if they want to add anything here :-)

Re: Weave by alexis richardson

Calico started as an OpenStack solution and is consequently operator focussed, but Weave has been designed only for developers as a 100% container native play.

Weave takes *very little time* to set up and use, and REALLY does not require developers to understand anything about networking in order to build applications. See eg the guides and docs - weave.works/guides/ and github.com/weaveworks/weave#readme

I am not sure that Calico can ever be as developer friendly as Weave. Calico is more aimed at network operators and has a more involved set-up. For example, as far as I can tell, it depends on using and understanding things like BGP to get full value - www.projectcalico.org/why-bgp/ Weave has *zero* dependencies, which is one reason it is so easy to set up. Calico depends on etcd.

As a result of this, we see lots of people using Weave but fewer using Calico.

You can and should run lots of Weave networks! With Calico, I think the idea is that your operators set up one big network. This means that we can envisage customers using Calico with Weave. This would happen when customers choose Calico over (say) VMware, and Weave as a solution for developers.

alexis

A few more points:

Weave includes other application developer friendly tools like service discovery, load balancing and automatic address management, and the team is extending into areas like monitoring and management with Weave Scope - weave.works/scope/ But Calico is a network-only solution, aimed at challenging products like VMware NSX (formerly Nicira).

The claims made above about being designed to work 'like the internet' are equally true of Weave as Calico. Claims are made about the superiority of L3 over L2 which seem rather ideological. Of course there are differences but is one approach obviously better than the other? (Hint: Answer is No). For example, Weave is indeed an L2 network, whereas Calico is L3. This means that Weave can do multicast for example. Some more great features, eg crypto, are listed here - weave.works/net/index.html

I think the key point though is that Calico really wants to be a data center wide "big network for everything". This is why it emphasises that you can set up routing rules to segregate traffic between apps. Whereas Weave is about connectivity inside an app - it really wants to share a lifecycle with your app and its containers. See eg See eg weave.works/articles/weave-net-overview.html

Re: Weave by alexis richardson

A more complete list of features - docs.weave.works/weave/latest_release/features....

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT