The SR Linux Command Line Interface (CLI) stands out as one of the most advanced and user-friendly CLI systems I've encountered. It breaks away from the conventional "industry standard" and introduces several innovative concepts that greatly enhance the ease of configuring and managing the network operating system. Among these innovations are "CLI wildcards and ranges," which, once mastered, can significantly improve your overall experience and efficiency.
The idea of using wildcards and ranges is not novel, as some CLI systems already include support for them. Nevertheless, SR Linux takes the concept of ranges and wildcards one step further, and in this post, we will explore how to harness their power effectively.
In the era of applications, it is easy to forget about the underlying infrastructure that interconnects them. However, the network is still the foundation of any application as it provides the connectivity and services that applications rely on.
The most popular container orchestration system - Kubernetes - is no exception to this rule where infrastructure is essential for several reasons:
DC fabric: Almost every k8s cluster leverages a DC fabric underneath to interconnect worker nodes.
Communication Between Services: Kubernetes applications are often composed of multiple microservices that need to communicate with each other. A well-designed network infrastructure ensures reliable and efficient communication between these services, contributing to overall application performance.
Load Balancing: Kubernetes distributes incoming traffic across multiple instances of an application for improved availability and responsiveness. A robust network setup provides load balancing capabilities, preventing overload on specific instances and maintaining a smooth user experience.
Scalability and Resilience: Kubernetes is renowned for scaling applications up or down based on demand. A resilient network infrastructure supports this scalability by efficiently routing traffic and maintaining service availability even during high traffic periods.
Getting familiar with all these features is vital for any network engineer working with a fabric supporting a k8s cluster. Wouldn't it be great to have a way to get into all of this without the need of a physical lab?
In this blog post we will dive into a lab topology that serves as a virtual environment to test the integration of a Kubernetes cluster with an IP fabric. The emulated fabric topology consists of a SR Linux-based Clos fabric with the Kubernetes cluster nodes connected to it. The k8s cluster features a MetalLB load-balancer that unlocks the capability of announcing deployed services to the IP fabric.
Throughout the lab, we will explore the way k8s services are announced to the IP fabric, and how L3 EVPN service with Anycast Gateway can be leveraged to create a simple and efficient overlay network for external users of the k8s services.
As for the tooling used to bring up the lab we will use Minikube to deploy a personal virtual k8s cluster and Containerlab will handle the IP fabric emulation and the connection between both environments.
In the past year, there has been a lot of buzz around gRPC and Openconfig services. Network engineers started to hear more g-acronyms: gNMI, gNOI, gRIBI. The bravest ones started to play with them, and those who like to live on the edge even started to use them in production. But the majority of network engineers are still not familiar with these technologies. The lack of tools to explore and understand these new technologies is one of the reasons for this.
You probably know that in srl-labs we strive for quality tools, and we are not afraid to build them ourselves. The famous gnmic, gnoic, gribic by Karim Radhouani are stellar examples of our effort to make gRPC and Openconfig services more accessible to network engineers.
Today we are happy to announce another initiative by our team - gnxi.srlinux.dev - a documentation UI for Openconfig gRPC services. It is a simple web application that allows you to explore Openconfig gRPC services and their protobuf definitions.
We hope that it will help network engineers to get familiar with gRPC and Openconfig services and we wanted to tell you how we built it.
Ever since we released a tutorial that showed how to use Ansible's URI module with SR Linux, we couldn't shake off the feeling that we would need to do more with Ansible. And we did. We are happy to announce that we have released an official Ansible collection for SR Linux - nokia.srlinux - that has four modules inside and leverages JSON-RPC interface.
In this blog post, we would like to share some details about our design decisions and why we think this collection is a great addition to the Ansible ecosystem.
In a not-so-distant past, manually extracting, parsing, and reading log files produced by network elements was standard practice for a sysadmin. With arcane piping of old-but-good grep, awk, and sed tools, one could swiftly identify a problem in a relatively large system. This was a viable approach for quite some time, but it became prey to a massive scale.
Today's network infrastructures often count thousands of elements, each emitting log messages. Getting through a log collection of this size with CLI tools designed decades ago might not be the best tactic. As well as correlating logs between network elements and application logs might be impossible without software solutions built with such use cases in mind.
The unprecedented growth in the application world boosted the development of multi-purposed centralized/cloud data collectors that make observability and discovery over huge data sets a reality. Elasticsearch / Logstash / Kibana (or ELK for short) is one of the most known open-source stacks tailored for the collection and processing of various documents, logs included.
To enable the processing of captured logs and deliver performant and robust search analytics log collectors rely on structured data. Unfortunately, the networking world is infamous for iterating slowly. For example, an outdated and informational Syslog interface still dominates the networking space when it comes to managing and transferring logs. Syslog RFC31644 was not designed to allow extensible structured payloads, which adds a fair share of problems with integrating such systems with modern log collectors.
This post explains how an SR Linux-powered DC fabric can be integrated with a modern logging infrastructure based on the Elasticsearch / Logstash / Kibana stack to collect, transform, handle, and view logs.
For a very long time, I wanted to make a syntax highlighter for the SR Linux command-line interface mainly because I belong to a cohort of readers who appreciate visual aids in lengthy CLI snippets. Give me a piece of code that is not syntax highlighted, and my reading speed will significantly drop.
And even though the Network OS CLI snippets do not contain code per-se, they have markers (such as a current command, IP addresses, up/down statuses, etc.) that when highlighted, contribute to the clarity of the provided snippet.
So during a lazy first Thursday of 2023 I finally made myself looking into it and created the srlinux-pygments - a Pygments lexer to highlight SR Linux CLI snippets.
A few days after we fleshed out our JSON-RPC Basics tutorial, and we are releasing another one. While basics tutorial is essential to read to understand how the interface works, the curl utility we used in the examples there is not something you would like to automate your network with.
Quite a lot of network ops teams we've been talking to used Ansible to manage their infra, and they wanted to keep using it for network automation as well. While this is a questionable tactic, we still can give you the "fishing rod".
Nokia SR Linux Network OS architecture has been built on strong principles of model-driven APIs and interfaces. Not a single thing in SR Linux datastores can get away without having a matching YANG module describing it.
The ground-up model-driven approach allowed us to build management interfaces that don't have shortness of sight as every interface, in essence, uses the common API layer presented by the management server. One of such interfaces - JSON-RPC - that SR Linux offers has been in the shade of a cool-kid gNMI, though JSON-RPC has lots to offer.
We are glad to present you with an in-depth tutorial on SR Linux's JSON-RPC interface - JSON-RPC Basics.
In this tutorial, we explain the JSON-RPC capabilities and provide practical examples for every method this interface offers. Be it retrieval of state, model-driven configuration using JSON, or pushing CLI-styled commands - JSON-RPC has you covered.
Almost every Internet eXchange Point (IXP) leverages a Router Server (RS) to simplify peering between members of the exchange who exercise an open policy peering. A Route Server is a software component connected to the IXP network which acts as a BGP speaker with whom members peer to receive BGP updates from each other.
Nowadays, IXPs predominantly use BIRD routing daemon as a Route Server, but for diversity and sustainability reasons Route Server Support Foundation initiated a program to introduce other software solutions, like OpenBGPd, to the IXP market.
While OpenBGPd is not a new kid on the block of software BGP implementations, it is less known in the IXP domain (compared to BIRD). Lots of IXPs are interested in introducing OpenBGPd as a second Route Server in their networks and this lab opens the doors to explore "OpenBGPd as a Route Server" use case.
Openness, extensibility, innovation and community focus make a large part of the Nokia SR Linux core. Mix it up with our engineering background and you get a resource where we share technical content in the engineers-to-engineers fashion.
Today we would like to take it one step further and augment the learn.srlinux.dev portal with a community blog section where Nokia engineers and our community members can post content relevant to modern network technologies.
This blog post explains how to contribute a blog article to our portal and what visual candies you can use to make your post look awesome.