anitsh
commented
4 years ago - [ ] Make a chapter5.md file
- [ ] Create a summary in the .md file
Open anitsh opened 4 years ago
anitsh
commented
4 years ago anitsh
commented
4 years ago Learning Objectives
By the end of this chapter, you should be able to:
Explain what a network operating system is.
Discuss what the available open source and commercial network operating systems are on the market.
Load a NOS using ONIE.A Review of the Disaggregated Model
In this chapter, we will discuss about Network Operating Systems (NOS) in disaggregated networking devices. First, let’s look again at our disaggregated model. We already learned about the networking hardware and abstraction layers in previous chapters.
he hardware is based on two main components:
The packet processing chipset/silicon
The CPU which runs the network operating system.The hardware abstraction is a set of drivers and APIs such as the Switch Abstraction Interface (SAI), the Protocol Independent Switch Architecture (PISA), or the switchdev. SAI was created by Microsoft and was later open sourced and contributed to the indystry in 2015. SAI is currently hosted by the Open Compute Project. Switchdev is a Linux kernel mode abstraction platform. The basic switch states are kept in the Linux kernel, while switchdev synchronizes the states to the switch hardware via the ASIC drivers. The ASIC driver is the most important part to allow communication between NOS or the hardware abstraction and the switch hardware. ASIC drivers are mostly closed source, and, in recent years, vendors have started providing the binary of their drivers.
Apart from using the above hardware abstraction methods, you can still use the ASIC vendor’s SDK to build an application and communicate with the switch chipset. However, this model is slowly getting deprecated as it is complex, hard to maintain, requires low-level programming, and it is not scalable.
Using hardware abstraction methods, communication between NOS and networking applications is streamlined via the abstraction layer, which can help in building parallel ASIC communications.
anitsh
commented
4 years ago OpenSwitch (OPX)
OpenSwitch (OPX) is an open source network operating system hosted and maintained by The Linux Foundation. OpenSwitch started a few years ago with an ambition to build an open source Layer 2/Layer 3 network operating system for open networking and bare metal switches.
The OpenSwitch project was initially started by Hewlett Packard. The initial OpenSwitch had a CLI interface similar to the industry-standard command line interface and support of Layer2 and Layer3 protocols (BGP, OSPF, etc.). Back in 2016, Dell EMC and SnapRoute contributed new code to OpenSwitch, which ended up replacing the core of the OpenSwitch software. The code changed by adding an OPX suffix, and the previous code was removed. Another major change was the removal of the CLI interface of the initial OpenSwitch.
Currently, there are multiple developers from different companies (such as Dell EMC, HP, Broadcom, Intel, etc.) working on the development of OpenSwitch.
Name | OpenSwitch (OPX) By | The Linux Foundation Where it runs | On a compatible bare metal switch, mostly Dell EMC bare metal switches What it does | Layer 2, Layer 3 routing and switching Features | Layer 2 and Layer 3 features, BGP, OSPFv2/3, VRRP, VRF, ACL, QoS policing, shaping, automation with Ansible, Puppet, Chef, Python What it can do out-of-the-box | You can load and use OpenSwitch on a compatible hardware and use it as a standard L2/L3 switch. It supports automation out-of-the-box, which can help you build an infrastructure as a code platform. OpenSwitch has some command line utilities, but it uses standard Linux commands for routing configuration.
OpenSwitch Architecture
OpenSwitch OPX uses the Switch Abstraction Interface (SAI) for hardware abstraction. It has ASIC drivers included in its packages, which makes it compatible with the switches they support within their Hardware Compatibility List. The compatible hardware is mostly Dell EMC bare metal switches and Edge-Core, all based on Broadcom ASICs, ranging from 1G to 100G.
OpenSwitch uses Open Network Install Environment (ONIE) to install and load the OpenSwitch on a bare metal switch.
OpenSwitch OPX uses a Control Plane Services (CPS) component which acts as a center point of communication between networking applications and other components (mainly the network abstraction) of the switch. CPS acts as a server for networking applications; it uses a publisher/subscriber model. The server application publishes its relevant events, and the client application registers for those events.
To communicate with the switch hardware, OpenSwitch uses the Network Adaption Service (NAS). NAS acts as an aggregate point for communication and synchronization with the switch hardware for all Layer 1 (physical interfaces, SFP, etc.), Layer 2 (VLANs, 802.q tagging, LAG, etc.) and Layer 3 (IPv4/6 routing), as well as security features for filtering.
OpenSwitch Commands
To use OpenSwitch, you can just use the Linux networking shell commands. Below are some examples.
Create VLAN 500, add Port 1 and Port 5 as tagged interfaces:
$ brctl addbr br500 $ ip link add link e101-001-0 name e101-001-0.500 type vlan id 500 $ ip link add link e101-005-0 name e101-005-0.500 type vlan id 500 $ brctl addif br500 e101-001-0.500 $ brctl addif br500 e101-005-0.500
Create a static route:
$ ip route add 10.0.0.0/24 via 192.168.1.2 $ ip route show
OpenSwitch has also its own utilities, such as:
Enable logging and debugging
opx_logging_cli enable
Show system alarms
opx-show-alms
Show version
opx-show-version
Enable SAI-specific logging
opx-switch-logOpenSwitch Supports Automation OpenSwitch supports automation with Puppet and other automation tools. You can see below an example of automation with Puppet:
node 'Switch1.LNF.org' {
$int_enabled = true
$int_loopback = '10.0.0.1'
$int_layer3 = {
e101-001-0 => {'int'=>'e101-001-0', 'address' => '10.1.1.1', 'netmask' =>
'255.255.255.0', 'cidr_netmask' => 24},
e101-002-0 => {'int'=>'e101-002-0', 'address' => '10.2.2.2', 'netmask' =>
'255.255.255.0', 'cidr_netmask' => 24},
}
$bgp = {
myasn => 65002,
peergroupv4 => [ { name => 'Router-101', asn => 65000, peers => [ '192.168.0.2','192.168.10.2' ] } ]
}
include ibgp::switch
}Open Switch Video Demo
anitsh
commented
4 years ago Disaggregated Network Operating System (DANOS)
According to DANOS website,
"The Disaggregated Network Operating System (DANOS) project enables community collaboration across network hardware, forwarding, and operating layers (...) it incorporates contributions from complementary open source communities in building a standardized distributed Network Operating System (NOS) to speed the adoption and use if white boxes in a service provider's infrastructure".
DANOS is based on AT&T's dNOS software framework. AT&T open sourced its dNOS project through The Linux Foundation in March of 2018.
Name | Disaggregated Network Operating System (DANOS) By | The Linux Foundation Where it runs | Not yet disclosed, but expected ti run on a compatible bare metal switch What it does | As per the AT&T whitepaper, it supports Layer 2 and Layer 3 routing and switching Features | Not yet disclosed, but expected to have Layer 2, Layer 3, BGP, OSPFv2/3, VRRP, VRF, ACL, QoS, MPLS, MP-BGP, and other BGP extensions What it can do out-of-the-box | Not yet disclosed or available
At the time of this writing (July 2018), there is no information available from The Linux Foundation related to this project. From AT&T, there is a public whitepaper, "Towards an Open, Disaggregated Network Operating System", about their vision for creating and building dNOS. However, there are no other public documents to provide more details about the real implementation and features of DANOS.
What we know about dNOS from the AT&T whitepaper:
Supports ONIE for installation environment
Supports the P4 language, and possibly, data plane programming
Support SDN agents such as OpenFlow
Supports automation and YANG models
Supports a CLI
Uses Forwarding Abstraction Layer (FAL) for communication with switch silicon
Will be orchestrated with ONAP.Stratum
Stratum is a new open source project hosted by the Open Networking Foundation/The Linux Foundation:
"Stratum is an open source, silicon-independent switch operating system for software-defined networks".
Stratum is not only a NOS, but it is a full network control platform and a solution to migrate from traditional networking to software defined networking. Stratum is still in early stages; the source code is not yet publicly available.
Name | Stratum By | The Linux Foundation - Open Networking Foundation Where it runs | On a compatible bare metal switch What it does | Not fully disclosed. Stratum launched in March 2018 - it is a NOS that can run a switch as an L2/L3 or fully managed by a network controller Features | Traditional L2/L3, data plane programming using P4, OpenConfig, SDN agent What it can do out-of-the-box | Although Stratum is still in an incubation stage, it is a NOS running on bare metal switches. Stratum is considered as a NOS that you can use to slowly migrate your network to a fully SDN, traffic-engineered network. Stratum can run traditional networking protocols such as BGP, STP, OSPF, etc., while allowing you to program the switches using OpenFlow.
Stratum supports P4 and data plane programming, but it is not mandatory to have a switch silicon that supports P4 and that is data plane programmable. Instead, Stratum has an engine that converts the P4 runtime to silicon API calls, which perform almost the same functions.
To configure Stratum, it is planned to use gNMI with OpenConfig data models to manage the configuration of the switches.
Google is one of the main contributors to the Stratum project; Google provided the initial source code, which is based on the software used to run Google’s production network.
Stratum packaging is designed as a set of executables which can be run on a standard Linux distribution, on a bare metal switch, (such as ONL), or as a full package NOS which can be installed via ONIE.
Stratum can work as a traditional NOS for a bare metal switch:
Stratum also supports hybrid mode for migration from traditional networking to a fully SDN network:
Finally, Stratum supports a full SDN-based system:
anitsh
commented
4 years ago Open Network Linux (ONL)
Open Network Linux or ONL is an open source Linux operating system for bare metal switches. ONL is a base-level operating system which does not include the ASIC switch drivers to program the switch silicon. ONL supports ONIE installation, which makes it very easy to deploy it on a bare metal switch. Also, ONL has a Hardware Compatibility List (HCL) which supports bare metal switch hardware. If you are wondering why ONL doesn’t support all and every switch hardware since it doesn’t have ASIC drivers, the answer is because a NOS still requires to include drivers for CPU board, drivers for managing the switch motherboard, and CPLDs in order to control the temperature sensors, fans, LEDs, etc. The CPU boards on switches are different, they use a different type of flash memory, system chipset, etc., and require a set of correct drivers.
Name | Open Network Linux (ONL) By | OCP and Open Network Linux Community, backed by Big Switch Networks, Inc. Where it runs | On a compatible bare metal switch What it does | ONL is a base-level operating system that can boot a full fledged Linux on a bare metal switch Features | ONL is based on Debian Wheezy. It allows the installation of any Linux-compatible applications or the ASIC driver What it can do out-of-the-box | ONL includes a comprehensive HCL that allows you to install it on most bare metal switches. After installing ONL, you can download the switch silicon drivers from the switch chipset manufacturer's website, and install them on ONL. This will enable ONL to control the switch ASIC. In Broadcom-based bare metal switches, a very common method is to download Broadcom's OFDPA (OpenFlow Data Plan Architecture) or OpenNSL (Open Network Switch Library) SDKs and deploy them on ONL. This is a simple way to make an OpenFlow-capable switch.
The ONL project was started by Big Switch Networks. The development of ONL is up-to-date and currently supports new switches based on Broadcom Tomahawk. (The ASIC driver is not included in ONL)
Installing ONL
Follow the simple steps below to install ONL or any other NOS that supports ONIE.
First, you need to have a basic connectivity from your computer to the switch. Both LAN and console ports should be connected.
After the switch boots the ONIE, it shows a GRUB menu:
Once you choose the ONIE: Install OS option, the switch boots in the ONIE shell to allow you to load the NOS from a server (tftp, ftp, http, etc.) and install the NOS. Within the ONIE shell, you can enter the following command telling ONIE to download the NOS:
install_url tftp://172.17.172.103/latest-amd64.installer
This command tells ONIE to download the NOS from a tftp server at 172.17.172.104. ONIE will download the ONL package, and will extract and start running the installation script. Once the installation is complete, the switch reboots and you will have ONL installed.
ONL includes some tools for managing the switch hardware. It is bundled with drivers required to manage the switch peripherals, such as fans, LEDs, etc.
ONL Video Demo
anitsh
commented
4 years ago Free Range Routing (FRR)
Free Range Routing (FRR) is a Linux Foundation collaborative project that has its roots in the Quagga project (the routing software for Linux). FRR receives contributions from Cumulus Networks, Big Switch Networks, 6WIND, Volta Networks, and others. FRR includes all the features of Quagga, and more. According to its FRR website,
"FRRouting (FRR) is an IP routing protocol suite for Linux and Unix platforms which includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIN, and RIP".
Name | Free Range Routing (FRR) By | The Linux Foundation Where it runs | On a Linux host, or a bare metal switch that runs Linux What it does | IP routing protocol suite for Linux Features | In addition to the Quagga features, it provides VRF, EVPN, LSP, BFD, LDP for MPLS, CLI, support for JSON outputs What it can do out-of-the-box | You can use FRR out-of-the-box on a Linux system to build a full-fledged router. There are other use cases as well, such as: Routing on a host (on a compute node) to establish BGP with data center switches Using FRR on an ONL to build an L3 Ethernet switch (requires additional components to program the switch chipset)
FR is a suite of routing protocol daemons that work together to build a routing table. Each protocol has its own dedicated daemon. FRR uses Zebra as a single point of management and configuration of all the routing daemons and the kernel. Zebra can also communicate routing updates to a switch chipset silicon via a driver.
If you need to configure a static route using pure Quagga without FRR, you need to add it to the Zebra configuration. If you need to configure a BGP neighbor, it must be added to the bgpd configuration file. FRR solves these problems by providing a single CLI interface called vtysh. With vtysh, you can configure all daemons and save the configuration. vtysh connects to each daemon via a socket and acts as a proxy for user commands on its CLI.
FRR DEMO
anitsh
commented
4 years ago P4 Language P4 stands for Programming Protocol-Independent Packet Processors and is a domain-specific programming language that was designed to describe data plane oriented tasks and functions. You can describe how packets should be routed or manipulated (for example, rewriting the MAC address source and destination headers) by a simple match-and-action process within P4. It was started by companies such as Barefoot Networks, Netronome and others.
Name | P4 By | P4 Community, joined the Open Networking Foundation and The Linux Foundation (March 2018) What it does | Language to define the behavior of data planes Features | Supports the match-and-action model with flexibility of matching different headers in a packet or a frame What it can do out-of-the-box | P4 is a language used to describe the behavior of a data plane. You can build various applications in a data plane, such as DDOS protections, firewalls, IPS, IDs, etc.
P4 Language Components
Headers
A header is a definition used for matching in the P4 language. You can define and map the information of a packet to header variables. You can define the header fields based on their location in the packet or frame. For example, and IPv4 packet header definition might be called IP_Packet, consists of a 4 bytes source address field named IP_SRC, and a destination address sized 4 bytes named IP_DST, which is exactly after the source address. You can see an example defining a header to match the Ethernet and IPv4 fields below:
header ethernet_t {
macAddr_t dstAddr;
macAddr_t srcAddr;
bit<16> etherType;
}
header ipv4_t {
bit<4> version;
bit<4> ihl;
bit<8> diffserv;
bit<16> totalLen;
bit<16> identification;
bit<3> flags;
bit<13> fragOffset;
bit<8> ttl;
bit<8> protocol;
bit<16> hdrChecksum;
ip4Addr_t srcAddr;
ip4Addr_t dstAddr;
}Parsers A parser looks in incoming byte-streams, searches for headers and extracts the header information from the byte-streams. For example, a parser can extract the IPv4 source and destination IP address from a stream of bytes entering an interface. Below you can see an example defining a parser to extract Ethernet headers:
parser MyParser(packet_in packet,
out headers hdr,
inout metadata meta,
inout standard_metadata_t std_meta) {
state start {
packet.extract(hdr.ethernet);
transition accept;
}
} Tables
P4 tables contain the state used to forward packets. Tables are composed of lookup keys and a corresponding set of actions and their parameters. A trivial example might be to store a set of destination MAC addresses as the lookup keys, and the corresponding action could set the output port on the device, and/or increment a counter. Tables and their associated actions are almost always chained together in sequence to realize the full packet forwarding logic, although in the abstract it is possible to build a single table that includes all the lookup key information and the full output action set.
table ipv4_lpm {
key = {
hdr.ipv4.dstAddr: lpm;
}
actions = {
ipv4_forward;
drop;
NoAction;
}
size = 1024;
default_action = NoAction(); }
Actions Actions are information about some manipulations on the information of the packet. For example, updating the TTL value of a packet when the packet is routed, or changing the destination MAC address of a packet when it is routed. In addition to this, the P4 programmer can set custom actions to change the other fields of a packet, such as the DSCP value or change the source IP (Source NATing), etc. Below you can see an example of defining an action to swap a MAC address of an Ethernet frame.
control MyIngress(inout headers hdr,
inout metadata meta,
inout standard_metadata_t std_meta) {
action swap_mac(inout bit<48> src,
inout bit<48> dst) {
bit<48> tmp = src;
src = dst;
dst = tmp;
}
apply {
swap_mac(hdr.ethernet.srcAddr,
hdr.ethernet.dstAddr);
std_meta.egress_spec = std_meta.ingress_port;
}
}Control Flow The control flow describes the sequence of tables, and allows for conditional execution of tables based on if/the/else statements.
anitsh
commented
4 years ago SONiC
SONiC (Software for Open Networking in the Cloud) is an open source project for network routers and switches that was created by Microsoft and contributed to the industry as a full operating system with ONIE installer, which can be installed and deployed on supported bare metal switches. SONiC supports a variety of bare metal switches, including Dell, Edge-Core, Arista, Barefoot, Marvell, etc.
SONiC manages its configuration via a single source of truth, a redisDB instance that is referred as ConfigDB. Applications subscribe to ConfigDB and generate their running configuration accordingly.
SONiC - Quick Summary
-- Name | Software for Open Networking in the Cloud (SONiC) By | Created by Microsoft, open source NOS Where it runs | On a supported bare metal switch What it does | Layer 2 and Layer 3 networking on a bare metal switch Features | Supports a variety of switch chipsets. Has a CLI, which makes the interaction with the software easier. What it can do out-of-the-box | You can download and install SONiC on your bare metal switch and start using it as a leaf, spine, or other interconnects for routing and switching.
SONiC is based on Linux and uses SAI to manage and drive the switch chipset.
SONiC Configuration Management
SONiC manages and stores the configuration in a single ConfigDB, which is a redisDB instance. Each networking software component subscribes to ConfigDB and generates its running configuration.
Similar to traditional networking, where there was a running configuration and a Startup Configuration, in SONiC, the ConfigDB (the redisDB) serves as a running-config function, and, to save the configuration, you need to issue a config save command which saves a dump of ConfigDB in a .json format file /etc/sonic/config_db.json.
During the SONiC bootup, the /etc/sonic/config_db.json configuration file will be loaded into redisDB.
By deleting the /etc/sonic/config_db.json you will almost reset the switch configuration.
The redisDB has multiple tables. For example:
BGP Table:
Stores configuration related to BGP neighbors, advertisements.
Port:
Contains configuration related to interfaces, speeds.
PortChannel:
Contains configuration of Link Aggregations (bonding/etherchannel, port channel).
VLAN:
Contains VLAN IDs, member ports.
VLAN members:
Contains configuration for individual ports for 802.1q tagging.
Layer 3 tables:
INTERFACE, PORTCHANNEL_INTERFACE, and VLAN_INTERFACE to store IP address details of Layer 3 interfaces.
ACL_RULE:
Contains configuration of access lists.SONiC Commands
SONiC has a user-friendly command line interface. It contains the famous industry-standard show and config commands. Some examples are listed below.
Show MAC:
admin@sonic:~$ show mac No. Vlan MacAddress Port
1 1000 E2:8C:56:85:4A:CD Ethernet12
Configure VLANs and member ports:
root@sonic:/# config vlan add 1200 root@sonic:/# config vlan member add 1200 Ethernet1 root@sonic:/# config vlan member add 1200 Ethernet9 –u (Defining Untagged) root@sonic:/# config vlan member add 1200 Ethernet8
BGP show commands:
admin@sonic:~$ show bgp neighbors 192.168.1.161 admin@sonic:~$ show bgp neighbors 192.168.1.161 advertised-routes admin@sonic:~$ show bgp neighbors 192.168.1.161 received-routes admin@sonic:~$ show bgp neighbors 192.168.1.161 routes
anitsh
commented
4 years ago FBOSS
As one of the initial contributors to the Open Compute Project, Facebook started sharing its own development in both networking hardware and software. Apart from sharing their hardware designs and making them open source hardware (the Facebook wedge bare metal switches), they also published their own open source software, called FBOSS (Facebook Open Switching System).
FBOSS is not a full operating system. Instead, it is a set of applications and daemons used to manage the switch ASIC and provide an API access to a network controller to manage the switch. FBOSS receives the configuration and information from the FBOSS controller software and programs the relevant routing and forwarding tables in the switch chipset.
FBOSS can run on a standard Linux distribution. ONL is a good platform to run FBOSS, as it already includes relevant hardware drivers for a switch. FBOSS also includes OpenBMC for managing the system board and hardware components.
FBOSS - Quick Summary
-- Name | Facebook Open Switching System (FBOSS) By | Facebook Where it runs | On a Linux OS that is installed on a bare metal switch What it does | FBOSS provides an agent software that can be remotely managed via API calls to manage the switch chipset silicon. FBOSS should be used with an external controller Features | FBOSS abstracts and provides APIs to remotely program a hardware switch (mainly based on Broadcom Trident and Tomahawk chipsets) What it can do out-of-the-box | You can install FBOSS on a bare metal switch that is running ONL. With FBOSS, you can control the switch silicon using a controller software. You can build your own controller software to interact with FBOSS. Your controller software can be a routing protocol software such as BIRD or Quagga, that can be connected to FBOSS
FBOSS mainly uses the Broadcom OpenNSL library to communicate with a Broadcom chipset.
FBOSS Daemons
FBOSS has multiple components and daemons.
Agent Daemon
The main FBOSS component is the FBOSS agent. The agent manages the switch chipset. The agent publishes northbound APIs to other systems that can manage the routing and forwarding of a switch. The agent requires a configuration file to define and specify the switch ports, VLANs, IP interfaces. This configuration file is in a .json format.
Configuring a port:
{ "ports": [ { "logicalID": 1, "state": 2, "minFrameSize": 64, "maxFrameSize": 1500, "parserType": 1, "routable": true, "ingressVlan": 1000, "speed": 0 } }
Configure a routed interface:
"interfaces": [
{
"intfID": 1000,
"routerID": 0,
"vlanID": 1000,
"ipAddresses": [
"169.254.0.10/16",
"2001:db:1111:1150::a/64"
],
"ndp": {
"routerAdvertisementSeconds": 4,
"curHopLimit": 255,
"routerLifetime": 1800,
"prefixValidLifetimeSeconds": 2592000,
"prefixPreferredLifetimeSeconds": 604800,
"routerAdvertisementManagedBit": true,
"routerAdvertisementOtherBit": true
}
}Configure a VLAN IP interface (SVI):
{
"intfID": 3004,
"routerID": 0,
"vlanID": 3004,
"ipAddresses": [
"10.11.24.111/31",
"2001:db:3336:e01:1000::aa/127"
]
}
Configure a VLAN and 802.1q (VLAN 1000 tagged on interface 1, untagged on interface 2):
"vlanPorts": [
{
"vlanID": 1000,
"logicalPort": 1,
"spanningTreeState": 2,
"emitTags": false
},
{
"vlanID": 1000,
"logicalPort": 2,
"spanningTreeState": 2,
"emitTags": true
}Routing Daemon
FBOSS currently doesn’t have a real routing protocol daemon that can run on FBOSS or the switch. Instead, you need to run a routing protocol software (either inside the switch or outside of the switch) and connect the routing protocol software to FBOSS. The FBOSS agent includes a Python tool which can be used and tweaked for a routing protocol software to manage the switch routing. This tool allows you to synchronize the routing table entries from your routing protocol software to the switch ASIC. The FBOSS agent acts as a mediator between the routing protocol software and the ASIC driver.
For example, you can use Quagga , BIRD, FRR or any other routing stack and connect it to FBOSS to program the ASIC routing table entries. To allow communication between such routing protocols and FBOSS, you can use the netlink channel. Routing software will be able to communicate with the Linux kernel via the netlink channel, FBOSS provides a netwlink manager tool along with FBOSS which listens to such a netlink channel and sends API calls to the FBOSS agent to program the switch silicon chipset.
anitsh
commented
4 years ago Cumulus Linux
Cumulus Networks is one of the first companies that started offering commercial NOS for bare metal switches. Cumulus Networks offers a network operating system that supports multiple bare metal switches from different hardware manufacturers and various chipsets such as Broadcom and Mellanox. The supported switches vary in port speeds from 1G to 100G.
Name | Cumulus Linux NOS By | Cumulus Networks Where it runs | On supported bare metal switches, Linux hosts What it does | Layer 2, Layer 3 automation Features | Layer 2 and Layer 3 features, VRF, compatibility with automation tools such as Puppet and Ansible. Also, it provides a CLI tool. What it can do out-of-the-box | Cumulus Linux is a commercial network operating system that can run on a supported bare metal switch. Cumulus use cases include mainly datacenter networks (CLOS-based leaf, spine).
Cumulus Linux is packaged as a full NOS, and is based on Debian Jessie and Linux kernel 4.1. It has an ONIE installer, which makes it easy to install and deploy on bare metal switches. Cumulus Linux includes tools to manage Layer 2 and Layer 3 more easily. It uses an enhanced version of Quagga for routing protocols. Cumulus Linux uses a process called switchd, which is a daemon for synchronizing and communicating the routing and switching states with chipset silicons.
Cumulus Linux includes readymade playbooks for automation tools such as Ansible and Puppet for performing configuration.
To configure and manage Cumulus Linux, you need to use pure Linux networking commands and configuration. For example:
Use ifupdown2 to manage interfaces, bonds (Ethernetchannels)
Use brctl to configure and manage bridges (VLANs, tagging)
Use cl-acltool (Cumulus Access List Tool) to manage access lists
Use vtysh to manage routing daemons such as bgpd, ospfd, etc.To simplify the configuration, Cumulus has a wrapper command line called NCLU or network command line utility, which allows you to configure and operate with a single net command.
The Cumulus interface naming uses the swp (Switch Port) prefix and a number indicating the interface number. For example, swp1 refers to interface 1.
Below are a few examples of how to use Cumulus Linux to configure an Ethernet switch.
To create VLANs:
Create VLAN 100 to 110:
switch# net add vlan 100-110
Add port 10 to VLAN 100 as untagged:
switch1# net add int swp10 bridge access 100
Add port 18 to VLAN 100 as 802.1q tagged:
net add int swp18 bridge trunk vlans 100
Create a bridge IP interface (AKA Switch Virtual Interface SVI or vlan interface):
net add vlan 100 ip address 172.16.17.1/24
For routing configuration, you can use the quagga or the net commands.
Cumulus Linux provides you will full access to the switch operating system. You can download any application on your switch and run it, or you can build and compile your own applications.
anitsh
commented
4 years ago Learning Objectives (Review)
You should now be able to:
Explain what a network operating system is.
Discuss what the available open source and commercial network operating systems are on the market.
Load a NOS using ONIE.Summary
In this chapter, we learned about network operating systems that are designed to work on disaggregated network devices. We reviewed a few commercial and open source network operating systems and familiarized ourselves with their features. We should mention also that there are other network operating systems available on the market which we didn’t discuss here. For example, Pica8 and IPinfusion’s OCNOS are also network operating systems which can be deployed on bare metal switches.
You may consider testing and trying some of the operating systems that we listed in this chapter.
| NOS | Type | Runs on | Features |
|---|---|---|---|
| OpenSwitch | Open Source | Bare metal switch | L2/L3, Linux commands |
| DANOS | Open Source | Bare metal switch | N/A |
| Open Network Linux | Open Source | Bare metal switch | Base Linux OS |
| SONiC | Open Source | Bare metal switch | L2/L3 |
| FBOSS | Open Source | Bare metal switch | Only FBOSS remote configuration agent |
| Cumulus Linux | Commercial, closed source | Bare metal switch | L2/L3 |
| FRR | Open Source | Linux hosts | L3 |
| Stratum | Open Source | Bare metal switch | L2/L3, SDN |