SR Linux in Containerlab

This article uses Containerlab to emulate a simple network and experiment with Nokia SR Linux and sFlow telemetry. Containerlab provides a convenient method of emulating network topologies and configurations before deploying into production on physical switches.

curl -O https://raw.githubusercontent.com/sflow-rt/containerlab/master/srlinux.yml

Download the Containerlab topology file.

containerlab deploy -t srlinux.yml

Deploy the topology.

docker exec -it clab-srlinux-h1 traceroute 172.16.2.2

Run traceroute on h1 to verify path to h2.

traceroute to 172.16.2.2 (172.16.2.2), 30 hops max, 46 byte packets
 1  172.16.1.1 (172.16.1.1)  2.234 ms  *  1.673 ms
 2  172.16.2.2 (172.16.2.2)  0.944 ms  0.253 ms  0.152 ms

Results show path to h2 (172.16.2.2) via router interface (172.16.1.1).

docker exec -it clab-srlinux-switch sr_cli

Access SR Linux command line on switch.

Using configuration file(s): []
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ + running }--[  ]--                                                                                                                                                              
A:switch#

SR Linux CLI describes how to use the interface.

A:switch# show system sflow status

Get status of sFlow telemetry.

-------------------------------------------------------------------------
Admin State            : enable
Sample Rate            : 10
Sample Size            : 256
Total Samples          : <Unknown>
Total Collector Packets: 0
-------------------------------------------------------------------------
  collector-id     : 1
  collector-address: 172.100.100.5
  network-instance : default
  source-address   : 172.100.100.6
  port             : 6343
  next-hop         : <Unresolved>
-------------------------------------------------------------------------
-------------------------------------------------------------------------
--{ + running }--[  ]--

The output shows settings and operational status for sFlow configured on the switch.

Connect to the sFlow-RT Metric Browser application, http://localhost:8008/app/browse-metrics/html/index.html?metric=ifinoctets.

docker exec -it clab-srlinux-h1 iperf3 -c 172.16.2.2

Run an iperf3 throughput test between h1 and h2.

Connecting to host 172.16.2.2, port 5201
[  5] local 172.16.1.2 port 38522 connected to 172.16.2.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   675 KBytes  5.52 Mbits/sec   54   22.6 KBytes       
[  5]   1.00-2.00   sec   192 KBytes  1.57 Mbits/sec   18   12.7 KBytes       
[  5]   2.00-3.00   sec   255 KBytes  2.09 Mbits/sec   16   1.41 KBytes       
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    9   1.41 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec   18   1.41 KBytes       
[  5]   5.00-6.00   sec   255 KBytes  2.08 Mbits/sec   17   1.41 KBytes       
[  5]   6.00-7.00   sec   191 KBytes  1.56 Mbits/sec   10   8.48 KBytes       
[  5]   7.00-8.00   sec   191 KBytes  1.56 Mbits/sec    7   7.07 KBytes       
[  5]   8.00-9.00   sec   191 KBytes  1.56 Mbits/sec    7   8.48 KBytes       
[  5]   9.00-10.00  sec   191 KBytes  1.56 Mbits/sec   10   7.07 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.09 MBytes  1.75 Mbits/sec  166             sender
[  5]   0.00-10.27  sec  1.59 MBytes  1.30 Mbits/sec                  receiver

iperf Done.

The iperf3 test results show that the SR Linux dataplane implementation in the Docker container has severely limited forwarding performance, making the image unsuitable for emulating network traffic. In addition, the emulated forwarding plane does not support the packet sampling mechanism available on hardware switches that allows sFlow to provide real-time visibility into traffic flowing through the switch.

For readers interested in performance monitoring, the https://github.com/sflow-rt/containerlab repository provides examples showing performance monitoring of data center leaf / spine fabrics, EVPN visibility, and DDoS mitigation using Containerlab. These examples use Linux as a network operating system. In this case, the containers running on Containerlab use the Linux dataplane for maximumum performance. On physical switch hardware the Linux kernel can offload dataplane forwarding to the switch ASIC for line rate performance. 

containerlab destroy -t srlinux.yml

When you are finished, run the above command to stop the containers and free the resources associated with the emulation.