It’s been almost two years since Nokia announced its Data Center Fabric solution. The three-layered solution ranged from hardware platforms all the way up in the stack to the DC fabric lifecycle management suite - Fabric Services System (FSS).
At the very heart of the DC Fabric solution lies a purpose-built, modern Network OS - SR Linux.
SR Linux comes with quite some interesting and innovative ideas. By being able to design the NOS from the ground up, the product team was freed from the legacy burdens which will be there have they decided to built the NOS on top of the existing one. Features like:
- YANG-first APIs
- Protobuf based SDK
- Disaggregated application stack
- Programmable CLI
are the result of taking a fresh look at the modern data center networks and building the NOS for the Netdevops era.
No wonders engineers around the world wanted to play with SR Linux and take those features for a spin first hand. And today it is finally possible!
I am a firm believer that Network Operating Systems should be available for testing to everybody. The reality, unfortunately, is quite different, with vendors either not allowing you to download virtual NOS at all, or requiring you to have an account, a registration with their system or a license file to run it.
With SR Linux, we are making a big step into the openness by pushing SR Linux container to the public container registry so everyone can it pull without any registration, payments, or active service accounts. Absolutely free and open.
Containerized NOSes have a lot of benefits that come from the container packaging. One of them being lightweight compared to the VM-based counterparts.
On average, a single SR Linux container will consume about 0.5vCPU and ~1GB RAM1. That allows you to spin up labs of decent size having only an entry-level VM at your disposal.
For example, one of the most typical labs is a Clos fabric with a few leafs and spines. The lab like that will fit into 2vCPU and 6GB RAM VM.
You can even run this lab on a free Github Actions runner, which has 8GB RAM. Imagine the sheer possibilities in writing CI pipelines for testing your DC features which can run in the public cloud for free.
When working with virtual networking products one needs to be aware of any limitations the virtual appliance imposes. Quite often the virtual images we work with in labs are crippled both in dataplane and control plane functions.
These limitations of the virtual images make it hard to create a reliable and “real” automated testing pipeline.
it should be a virtual instance of the actual hardware product or at minimum the NOS with identical data plane/control plan functionality. Or as close as possible.— Ryan Booth (@that1guy_15) July 21, 2021
Cumulus CVX is a perfect example both from a solution and how they maintain it.
SR Linux container has the same code inside that actually runs on our hardware platforms. There is no control or data plane deviations2, so by using this image in your CI pipelines you can be sure that when deployed to production, it will behave the same.
And all that with a small resource footprint. Imagine running a fully functional 3-stage mini-Clos fabric with 6 nodes on a machine with 2vCPU and 6GB RAM? That will fit into a free GitHub runner!
Being able to pull SR Linux NOS as any other container image is big on its own, but we also wanted to make sure that you can use right away. To do that, we made licensing optional, so once you pulled an image you can use it to its full extent!
We plan to push every public release of SR Linux to the container registry so that you can pull a specific version or the
:latest one. The SR Linux version is a tag on the container image, so there is an easy way to match a release to its image.
We will keep all versions available for you to pull.
The decision use GitHub container registry was made specifically to allow you to get the image without facing the pull restrictions that Docker has in place.
We do that because we think that one of the very promising applications for public SR Linux container is to use it in CI pipelines. And in CI your jobs can pull the images quite frequently, so having limitations for pulling, is an important improvement.
SR Linux was designed to answer the needs of today and tomorrow, with a strong focus on automation teams. With that forward-looking design, it is clear that many things will look new to the users who worked with traditional Networks OSes in the past.
To help you navigate the SR Linux world, we are launching a community-oriented documentation portal - learn.srlinux.dev
The main goal of the portal is to introduce you to the SR Linux by means of the interactive tutorials. All the tutorials are based on a certain lab scenario that we go through explaining the technology and how SR Linux implements it.
The lab scenarios are deployed with containerlab so both the tutorial authors and the readers follow along the same path and can reproduce the whole tutorial.
We start with explaining how to actually run SR Linux container and build arbitrary topologies, and then offer you to follow one of the use-cases centric tutorials.
One of the objectives for the tutorials that we put on this portal was to make them stand out, and this is achieved with the following:
Backed by runnable labs
As have already been mentioned, every tutorial is actually created using a lab deployed with SR Linux containers. And we share those labs for you to follow along the configuration journey.
That is very important to us, because completing a hands-on tutorial beats reading experience every day.
Complete, top-to-bottom explanations
Every tutorial is built from the ground-up, with every step explained and demonstrated. If there are any pre-requisites which needs to be met, we explain how to do that.
For example, if there is a routing underlay that we use to deploy overlay services on top, we always explain how this is configured and provide you with config snippets to achieve the same required state.
Control & Data planes verification A large part of the tutorials are dedicated to control plane and data plane verifications. It is not enough to just configure a feature, we want to show you also how to verify that the applied configuration results in a proper control/data plane function.
Yes, where applicable we will also share the PCAP files with control and data plane traffic captured. The truth is always in PCAPs, so by analyzing them we can see how control plane protocols operate and what encapsulations are used in the data plane.
Although it is extremely easy to run SR Linux on your own system, it is always nice to have a system running on the Internet which you can access.
Please welcome, an Always ON SR Linux instance.
As the diagram shows, we are exposing every management interface the NOS has for you to explore them.
- The modern-looking CLI is accessible via SSH
- The fully potent gNMI interface is open for everyone to try out getting information with gNMI Get and stream it with gNMI Subscribe
- The third interface - JSON-RPC over HTTP - is a REST API like interface for teams who prefer to deliver automation via it, or those who find gNMI specification limiting.
The Always-ON SR Linux instance has a few pre-configured services that you can explore either via CLI, or with other interfaces such as gNMI.
The pre-configured services are:
- Layer 2 EVPN with VXLAN dataplane with
- Layer 3 EVPN with VXLAN dataplane with
SR Linux has lots to offer to various groups of engineers…
Those with a strong networking background will find themselves at home with proven routing stack SR Linux inherited from Nokia SR OS.
Automation engineers will appreciate the vast automation and programmability options thanks to SR Linux NetOps Development Kit and customizable CLI.
Monitoring-obsessed networkers would be pleased with SR Linux 100% YANG coverage and thus through-and-through gNMI-based telemetry support.
We are happy to chat with you all! And the chosen venue for our new-forming SR Linux Community is the SR Linux Discord Server which everyone can join!