La programmabilité du réseau (qui inclut SDN , le Software Defined Network) est vue par l’équipe réseau de l’informatique interne de Cisco comme l’une de ses grandes priorités.
SDN est une architecture réseau qui découple le “control plane” (la partie qui construit une table de routage) du « data plane ». Le control plane est placé un contrôleur logiciel centralisé. L’informatique interne de Cisco perçoit la vraie valeur du SDN dans sa capacité de permettre la programmabilité du rseau.
La programmabilité du réseau nécessite deux fonctionnalités :
- accéder à des informations provenant des équipements réseau
- proposer de manière automatiser de nouvelles configurations en réponse à des environnements dynamiques de réseau ou à des demandes de provisionnements en self services.
L’équipe réseau de Cisco n’en est encore que dans les premières étapes pour intégrer la programmabilité du réseau dans les programmes de l’informatique de Cisco. Jusqu’à présent cinq cas d’utilisation interne ont été recensés.
Premier cas d’usage : Automatiser le provisionnement du réseau pour le Cloud privé interne.
Cisco offre en interne de l’entreprise de l’infrastructure as a Services (IaaS) à partir d’un cloud privé appelé Cisco IT Elastic Infrastructure Services (CITEIS). Aujourd’hui le provisionnement du réseau est automatisé pour les utilisateurs du CITEIS en utilisant des Interfaces de programmation (APIs) offertes par le commutateur logiciel Nexus 1000v et le Cisco Prime Network Services Controller (appelé précédemment Cisco Virtual Network Management Center). Une technique d’overlay de réseau virtuel ,vPath disponible dans le Nexus 1000v, est également utilisée pour simplifier l’insertion de services réseaux.
Deuxième cas d’usage: Simplifier les opérations en centralisant la gestion des configurations et des politiques.
Un proof of concept est actuellement en cours pour simplifier la configuration des commutateurs et des routeurs, un cas d’usage classique du SDN.
Les administrateurs réseaux réalisent leurs changements de configuration de manière centralisée sur un contrôleur. Le contrôleur pousse ensuite la nouvelle configuration automatiquement en utilisant la syntaxe de commande appropriée pour chaque équipement et version logicielle. En créant une couche d’abstraction pour la syntaxe spécifique aux équipements on évite aux administrateurs de devoir veiller à la bonne syntaxe pour différentes combinaison d’équipements matériels et de systèmes d’opérations utilisés dans le réseau de Cisco
Troisième cas d’usage : Accroitre l’utilisation du WAN par un pilotage du trafic.
Les protocoles de routage sélectionne les chemins en fonctions de critères tels que la bande passante, le délai et le nombre de sauts (hop), mais le taux d’utilisation des circuits empruntés n’est pas pris en compte. En conséquence, les circuits à basse vitesse du back up WAN sont utilisés seulement quand le circuit primaire est défaillant. Pourquoi, lorsque le circuit primaire fonctionne, ne pas tirer profit du circuit secondaire pour du trafic non critique comme le back up de PC ?
Un prototype de pilotage de traffic a déjà été créé et un proof of concept est attendu en 2014.
Ce prototype utilise les APIs onePK pour piloter les types de trafic appropriés sur les circuits à basse vitesse sous utilisés et augmenter leur utilisation. Lorsque des défauts sont détectés dans le circuit primaire, les APIs font appel automatiquement à d’autres politiques qui demandent au réseau de suspendre tous les trafics non essentiels sur les circuits basse vitesse. La direction informatique de Cisco peut ainsi accroitre l’utilisation du WAN tout en maintenant le meilleur niveau de service pour les applications critiques lorsque le circuit d’un bureau distant devient défaillant.
Quatrième cas d’usage : Détection et gestion des menaces de sécurité
Aujourd’hui si le réseau détecte qu’un laptop est en train d’envoyé un malware ou d’attaquer un autre système, il évite d’autres dommages en bloquant tout le trafic allant ou venant de ce laptop. La conséquence est que l’utilisateur de ce laptop ne peut plus travailler et les ingénieurs sécurité ne peuvent pas avoir accès au laptob pour le remettre en ordre.
L’équipe réseau de Cisco a donc prévu d’utiliser les APIs onePK pour programmer le réseau afin de bloquer de manière sélective uniquement le malware concerné ou le trafic d’attaque en cause, pas les autres trafics. Cette approche plus granulaire de protection permettra aux utilisateurs Cisco de continuer à travailler si leur point d’accès est soumis à une agression. La correction sera également accélérée car les ingénieurs de la sécurité réseau pourront faire leurs diagnostics et apporter leurs corrections dans le réseau.
Cinquième cas d’usage: Centralisation de l’exploitation des données du réseau du DataCenter
De nombreuses équipes de la direction informatique de Cisco exploitent les informations des réseaux du DataCenter pour visualiser le trafic traversant le réseau. Par exemple pour corriger les problèmes, piloter la sécurité et mesurer les performances applicatives. A l’heure actuelle il y a plus de demandes d’analyse que ce que les équipements réseau peuvent supporter.
Il est donc envisagé d’utiliser le contrôleur SDN de Cisco , Cisco eXtensible Network Controller (XNC) pour disposer d’un control programmatique centralisé de l’exploitation des données réseau et permettre à l’équipe de supporter plus de demandes d’analyse. XNC devrait également permettre de fusionner et de filtrer le trafic pour fournir plus d’informations pertinentes.
Authors
