Network Operating System SONIC

Dernière modification le 23 décembre 2020

La désagrégation entamée par le mouvement du SDN (Software-Defined Networking) a, tout logiquement, entraîné la banalisation de la couche « Infrastructure Layer » ou « Data Plane ». Des fabricants de commutateurs ODM (Original Design Manufacturers) proposent des matériels appelés « Bare-metal » par analogie à des serveurs que l’on a pour habitude d’acheter sans aucun système d’exploitation installé. En tant que ODM on peut citer, par exemple, Dell, Mellanox, Facebook, Supermicro, mais surtout, Edgecore Networks, Quanta Cloud Technology ou Netberg. Les plus grand DataCenters comme Facebook ont été moteurs pour explorer cette voie qui leur laissait présager des économies d’échelle. Facebook a poussé le mouvement « Open Compute Project » pour proposer de couvrir différents aspects d’un DataCenter avec des matériels banalisés et des projets Open Source. Mais il ne faut surtout pas croire que l’approche consistant à fabriquer ses propres commutateurs n’est réservée qu’aux plus grands acteurs.

Dans ce domaine, il y a souvent une confusion entre « Bare-metal », « White box » et « Brite box » (BRanded whITEBOX). L’idée générale reste de ne plus accepter des systèmes propriétaires sur des matériels propriétaires. Les commutateurs « Bare-metal » sont livrés, comme des serveurs, avec un matériel et un firmware prêts à recevoir le « Network Operating System » de son choix. Le firmware qui s’est imposé s’appelle ONIE (Open Network Install Environment) et les « Network Operating Systems » les plus répandus sont OpenSwitch et ONL (Open Network Linux) dans le monde de l’Open Source et Pica8, ainsi que Cumulus Networks pour ce qui est de l’offre commerciale. Le concept de « White box » consiste, pour un acteur hors des fabricants traditionnels de matériel réseau, de prendre des commutateurs « Bare-metal » et d’intégrer un « Network Operating Systems » de leur choix ou même de leur fabrication.

Cumulus Networks est probablement le fournisseur de NOS (Network Operating System) le plus connu. Si on observe les plateformes compatibles avec ce système, on remarque que seuls les ASICs Broadcom et Mellanox sont supportés.

SONiC est un NOS Open Source basé sur Linux qui s’exécute sur des commutateurs de plusieurs fournisseurs et sur différents types d’ASICs (Broadcom, Nephos, Cavium, Barefoot, Innovium, Centec, Marvell, Mellanox). SONiC offre une suite complète de fonctionnalités réseau qui ont été consolidées en production dans les DataCenter de certains des plus grands fournisseurs de services cloud. Il offre aux équipes la flexibilité de créer les solutions réseau dont elles ont besoin tout en tirant parti de la force collective d’un vaste écosystème et d’une grande communauté.

L’architecture SONIC a la particularité de s’appuyer sur la technologie de conteneurisation et sur une couche d’abstraction SAI (Switch Abstraction Interface) définissant l’API pour fournir un moyen, indépendant du fournisseur, de contrôler les éléments tels qu’un ASIC , un NPU (Network Processing Unit) ou un commutateur logiciel, et ceci de manière uniforme. La question qui vient immédiatement à l’esprit est : comment mettre en place une simulation virtuelle avec SONIC ?

SONiC-P4 (dernier build stable #613 utilisé pour la démonstration) est un commutateur logiciel qui s’exécute sur un SAI offrant les APIs pour accéder à un ASIC P4 émulé. Ceci permet d’exécuter la vraie pile réseau SONiC. Dans la démonstration proposée ci-dessous, deux commutateurs sont interconnectés en eBGP et chacun d’eux possède un serveur directement connecté. L’ensemble est monté sur Docker avec des liens réalisés à l’aide d’Open vSwitch.

{
    "VLAN": {
        "Vlan15": {
            "members": [
                "Ethernet0"
            ],
            "vlanid": "15"
        },
        "Vlan10": {
            "members": [
                "Ethernet1"
            ],
            "vlanid": "10"
        }
    },
    "VLAN_MEMBER": {
        "Vlan15|Ethernet0": {
            "tagging_mode": "untagged"
        },
        "Vlan10|Ethernet1": {
            "tagging_mode": "untagged"
        }
    },
    "VLAN_INTERFACE": {
        "Vlan15|10.0.0.0/31": {},
        "Vlan10|192.168.1.1/24": {}
    }

hostname bgpd
password zebra
enable password zebra
log file /var/log/quagga/bgpd.log
!
router bgp 10001
  bgp router-id 192.168.1.1
  network 192.168.1.0 mask 255.255.255.0
  neighbor 10.0.0.1 remote-as 10002
  neighbor 10.0.0.1 timers 1 3
  neighbor 10.0.0.1 send-community
  neighbor 10.0.0.1 allowas-in
  maximum-paths 64
!
access-list all permit any

{
    "VLAN": {
        "Vlan14": {
            "members": [
                "Ethernet0"
            ],
            "vlanid": "14"
        },
        "Vlan9": {
            "members": [
                "Ethernet1"
            ],
            "vlanid": "9"
        }
    },
    "VLAN_MEMBER": {
        "Vlan14|Ethernet0": {
            "tagging_mode": "untagged"
        },
        "Vlan9|Ethernet1": {
            "tagging_mode": "untagged"
        }
    },
    "VLAN_INTERFACE": {
        "Vlan14|10.0.0.1/31": {},
        "Vlan9|192.168.2.1/24": {}
    }

hostname bgpd
password zebra
enable password zebra
log file /var/log/quagga/bgpd.log
!
router bgp 10002
  bgp router-id 192.168.2.1
  network 192.168.2.0 mask 255.255.255.0
  neighbor 10.0.0.0 remote-as 10001
  neighbor 10.0.0.0 timers 1 3
  neighbor 10.0.0.0 send-community
  neighbor 10.0.0.0 allowas-in
  maximum-paths 64
!
access-list all permit any