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-RTMetric 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.