Automatisation et SDN

août 22, 2017  |   Actualités,Blog   |     |   0 commentaire

Parmi les nouveaux termes de l’écosystème SDN et NFV, les termes d’Automatisation (ou en anglais Automation) et d’ “Infrastructure as Code” sont souvent mis en avant.

Le but de cet article est de positionner ces langages, ces technologies, ces outils et concepts.

Nous rappelons que le concept global de SDN dépasse de loin l’automatisation des tâches: le but est de piloter de façon logicielle et centralisée le réseau au profit des nouveaux usages (containers, NFV, VM ..).

YANG (RFC6020) est un langage de modélisation des fonctions réseaux. Il vise à traiter les difficultés de consistance des configurations.

NETCONF (messages XML sous SSH) ou bien RESTCONF (utilisation d’API REST, format JSON) permettent de transmettre des configuration ou modifier/restituer des états opérationnels.

Voici un exemple du jumelage de YANG et RESTCONF pour traiter l’état d’une interface réseau :

Exemple de fonctions actionnables en API REST

Exemple de fonctions actionnables en API REST

 

Des travaux ont lieu en ce moment à l’IETF pour la modélisation standardisée de fonctions réseau (ex stateless firewall) sous forme de NFV (Network Function Virtualization).

En parallèle, le groupe de travail OPENCONFIG, initié par des opérateurs télécom vise à modéliser (en YANG) des fonctions réseau, de façon neutre et indépendante des constructeurs/éditeurs. Après plusieurs annonces du support d’OpenConfig par des constructeurs majeurs (Arista, Cisco , Juniper) en 2016, ce projet semble à nos yeux s’essouffler ou du moins adopter une vitesse de croisière.

Ce qui réunit l”IETF et Openconfig est de résoudre ce deux défis :

  • des constructeurs différents ont des commandes / syntaxes CLI différentes
  • des constructeurs différents restituent des données identiques dans des formats différents

En marge de ces formalisations et nouveaux protocoles interopérable, les solutions de gestions de configuration de fonctions réseau permettent dès aujourd’hui l’automatisation de type SDN. Parmi les solutions structurées (Python n’est finalement qu’un langage doté de bibliothèques réseau évoluées), Ansible est clairement devenue la plus populaire, devant Chef , SaltStack, ou Puppet.

Résultat de l'enquête NetDevOps Falls 2016

Résultat de l’enquête NetDevOps Falls 2016

Le lecteur notera que ces outils savent aussi bien traiter des serveurs (i.e systèmes) que des équipements réseaux (load-balancers, routeurs, switches et autres firewall). C’est bien le signe de l’avènement du Software Defined network ou Infrastructure as Code : tous les éléments sont pilotés par du logiciel ouvert.

Avec Ansible, il suffit juste d’avoir un accès SSH vers l’équipement (logiciel ou matériel) et de créer des playbooks au format YAML.

En voici un exemple (source) pour des routeurs Cisco (module ios_config d’Ansible) :

- name: Create an access-list
ios_config:
lines: access-list 180 permit tcp any any eq 80

Ou un autre exemple :

- name: ACL - ACL-IN
ios_config:
parents: ["ip access-list extended ACL-IN"]
commands:
- permit tcp any any eq 22
- permit tcp any any eq www
- permit udp any any eq snmp
match: exact
replace: block
before:
- interface GigabitEthernet0/1
- no ip access-group ACL-IN in
- no ip access-list extended ACL-IN
after:
- interface GigabitEthernet0/1
- ip access-group ACL-IN in
notify: save configuration

Attention : le respect de l’indentation avec des espaces est fondamental pour que votre fichier YAML soit correct.

Une des forces d’Ansible est le fait que les nouvelles configurations ne sont pas appliquées systématiquement mais seulement quand elles sont nécessaires.

Certains d’entre vous objecteront que l’on peut obtenir ce genre de résultat avec un scruipt Bash ou Perl, un serveur TFTP, des extraits de configuration au format texte et un déclenchement par SNMP… depuis des dizaines d’années.

Certes. Cependant cette fois-ci, on utilise des briques standards, testées, maintenues et extensibles en OpenSource.

De plus, des surcouches d’abstraction telles que Napalm (et ansible-napalm) permettent de voir ou modifier des configurations de façon générique pour les plateformes supportées ( Arista EOS, Cisco IOS,Cisco IOS-XR, Cisco NX-OS, Fortinet Fortios, Juniper JunOS, Mikrotik RouterOS, Palo Alto NOS et d’autres). L’auteur de Napalm est David BAROSO, qui en décrit bien les enjeux dans une présentation d’Avril 2017.

En parallèle de ces nouveaux moyens de modifier et contrôler les configuration, le besoin de remonter des statistiques beaucoup plus détaillées que SNMP a émergé. Ce nouveau paradigme de streaming continu de données de mesure est nommé Télémétrie (en anglais Telemetry). Il est activement utilisé dans les réseaux SDN et SD-WAN. Un prochain article sera consacré à ce concept et à son implémentation protocolaire majeure, gRPC.

N’hésitez pas à nous faire vos remarques dans les commentaires ou à nous contacter si vous souhaitez plus de détails ou de l’accompagnement.