J’ai déjà eu l’occasion de parler du NOS (Network Operating System) SONIC. Dans cet article, je proposais de découvrir SONIC en le faisant tourner sur Docker, mais lorsqu’il s’agit de simuler une architecture, il est tout de même plus démonstratif de faire tourner la simulation sur EVE-NG. La version Pro de EVE-NG arrive avec un template déjà prêt : /opt/unetlab/html/templates/intel/sonicsw.yml.
---
type: qemu
name: S-SW
description: Sonic Switch
cpulimit: 1
icon: Switch L32.png
cpu: 2
ram: 4096
ethernet: 10
eth_format: Ethernet{0}
console: telnet
shutdown: 1
qemu_arch: x86_64
qemu_version: 3.1.0
qemu_nic: e1000
qemu_options: -machine type=pc,accel=kvm -vga std -usbdevice tablet -boot order=cd
...
J’ai pour habitude de récupérer l’image sonic-vs.img.gz une fois générée sur l’intégration continue Jenkins de SONIC. Pour respecter le mode de fonctionnement de EVE-NG, un répertoire avec la racine sonicsw est créé afin d’y déposer l’image renommée en virtioa.qcow2.
mkdir /opt/unetlab/addons/qemu/sonicsw-201911-242 wget https://sonic-jenkins.westus2.cloudapp.azure.com/job/vs/job/buildimage-vs-201911/lastSuccessfulBuild/artifact/target/sonic-vs.img.gz gunzip sonic-vs.img.gz cp sonic-vs.img /opt/unetlab/addons/qemu/sonicsw-201911-242/virtioa.qcow2 /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
Il faut noter que le système tourne sur ONIE et que la première connexion s’effectue avec les credentials admin / YourPaSsWoRd. L’interface de management eth0 de SONiC est configurée, par défaut, pour utiliser le client DHCP afin d’obtenir l’adresse IP du serveur DHCP. L’adresse IP reçue du serveur DHCP peut être vérifiée à l’aide de la commande Linux /sbin/ifconfig eth0.
Une fois le système démarré, les configurations sont chargées à partir du fichier /etc/sonic/config_db.json dans l’espace de noms Redis DB appelé ConfigDB. En général, le contenu de config_db.json peut être considéré comme une configuration de démarrage, alors que l’état actuel de ConfigDB peut être considéré comme une configuration en cours d’exécution. Chaque fois que vous modifiez la configuration SONiC à partir du CLI, vous modifiez le contenu de ConfigDB qui ne sera pas réécrit automatiquement dans le fichier config_db.json tant qu’on ne lance pas la sauvegarde. Il est possible d’interagir avec ce fichier au travers de commandes dont voici un exemple :
sudo config hostname spine1 sudo config save
Si vous choisissez de modifier directement le fichier /etc/sonic/config_db.json, il faut penser à recharger la configuration ConfigDB à l’aide de la commande : sudo config reload -y. Il existe plusieurs méthodes pour restaurer une configuration par défaut, mais celle que je trouve la plus simple est celle qui utilise la commande sonic-cfggen pour générer la configuration par défaut qui est identique à celle générée après l’installation d’ONIE.
La commande show platform summary permet de récupérer les informations nécessaires pour lancer la commande sonic-cfggen.
sudo sonic-cfggen -H -p /usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000/port_config.ini --preset t1 -k Force10-S6000 > ~/default.log sudo cp default.log /etc/sonic/config_db.json sudo config reload -y
Le fait de posséder toute la configuration dans un seul fichier JSON permet d’entrevoir les possibilités d’automatisation que le système SONIC propose au travers d’Ansible ou de Python en utilisant Jinja2.
Si on veut décoder un peu le contenu du fichier /etc/sonic/config_db.json, voici une clé importante. L’abstraction des noms des interfaces dans SONIC, oblige à se pencher sur la notion de ports. Ces noms dépendent de la plateforme sur laquelle tourne SONIC, et dans notre cas, peuvent être affichés à l’aide de la commande cat /usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000/port_config.ini.
La colonne d’index aide à comprendre quel est le nom d’interface approprié pour un port. L’interface d’administration (eth0) n’est pas affichée ici, donc l’indice 0 identifie le premier port du « Data plane ». Les « lanes » sont les voies de l’ASIC, qui sont connectées à chaque port. Tous ces éléments permettent de compléter le fichier /etc/sonic/config_db.json en fonction du besoin.
SONIC est une base Linux Debian et à ce titre on peut avoir accès à toute la configuration système, mais il y a également des commandes supplémentaires comme show ou config qui ont été rajoutées directement sur le BASH.
L’application de la commande show version permet d’afficher tous les conteneurs qui embarquent les fonctions disponibles dans SONIC. Si on veut se persuader qu’il s’agit bien d’un système Docker sous-jacent, on peut tester la commande docker ps.
La meilleure façon de se convaincre de l’intérêt du système SONIC, c’est de l’essayer…
