samedi 30 mai 2015

IPv6-iBGP

Objective: Créer une interconnexion de laboratoire physique utilisant IPv6 avec l’IGP choisit et un numéro d’AS BGP au dessus d’une infrastructure IPv4 existante.

Ci-dessous, la topologie utilisée pour cet atelier.

Figure 1 –Configuration de base

Remarques

Ce module est destiné à la configuration iBGP pour IPv6 de cette séries d’ateliers. Ce module est à compléter après la configuration de l’IGP pour IPv6.

Les routeurs utilises pour cette partie du cours doivent supporter IPv6. N’importe quelle image IP Plus à partir de la version 12.2T inclue devrait convenir (IP Plus a été renommé Advanced IP Services pour la majorité des plateformes à partir de la version 12.3 de la branche principale). Comme toujours, il est recommandé de vérifier sur le Cisco Feature Navigator www.cisco.com/go/fn le set d’images et de plateformes supportant IPv6. Malheureusement IPv6 ne fait pas partie des images basic IP only or Service Provider IOS utilisées par la plupart des ISPs.

Note: Nous supposons que les routeurs utilisent une version d’IOS supérieure ou égale a 12.4 de la branche principale. Nous discutons la syntaxe précédant IOS 12.4 tout au long de l’atelier, dans des sections optionnelles.

Configuration du Laboratoire

1. Configuration des sessions iBGP (Partie 1). Les routeurs sont tous dans le même système autonome, AS10, pour cet exercice. L’extension BGP qui permet le support de plusieurs protocoles (IPv4, IPv6 ,…) est MP-BGP. Un type d’adresse est appelé une address family. IPv4 unicast est l’une des nombreuses familles d’adresses supportées – c’est la plus connue. IPv6 est une autre famille d’adresse supportée par multiprotocol BGP. Nous devons configurer les nouveaux peering IPv6 pour qu’ils appartiennent à la famille d’adresses IPv6. Avant de configurer chaque session iBGP IPv6, il nous faut désactiver l’hypothèse comme quoi les peers BGP sont des peers IPv4 unicast. Ceci ce fait à l’aide de la commande suivante :

Router4(config)#router bgp 10

Router4(config-router)#no bgp default ipv4-unicast

2. Configuration des sessions iBGP (Partie 2). Avant de configurer iBGP avec les voisins dans notre AS, nous avons besoin de faire un peu de préparation de base sur le routeur. Les paramètres par défaut IOS ne sont pas optimisés pour les réseaux des fournisseurs de services, donc avant de lancer les sessions BGP, nous devons définir les paramètres par défaut dont nous avons besoin.

La distance par défaut pour eBGP est de 20, la distance par défaut pour iBGP est de 200, et la distance par défaut pour ISIS est de 115. Cela signifie qu'il y a un potentiel pour un préfixe appris par eBGP de remplacer le préfixe identique porté par ISIS. Rappelons de la présentation sur le routage qu'il y a une séparation nette entre BGP et les processus ISIS – les préfixes présents dans ISIS ne seront jamais trouvés dans BGP, et vice-versa. Pour se protéger contre les accidents1, la distance eBGP est fixée à 200 également. La commande pour ce faire est la sous-commande bgp distance, la syntaxe est la suivante:

distance bgp <external-routes> <internal-routes> <local-routes>

Remarque: Cela devrait être inclus dans toutes les configurations BGP futures dans cet atelier. Par exemple, pour Router4, la configuration peut être:

Router4(config)#router bgp 10

Router4(config-router)#address-family ipv6

Router4(config-router-af)#distance bgp 200 200 200

3. Configuration des sessions iBGP (Partie 3). Nous pouvons maintenant configure les voisins iBGP IPv6. Voici par exemple la configuration pour Router 4. Les sessions iBGP sont établies en utilisant les adresses loopback des routeurs.

Router4(config)#router bgp 10

Router4(config-router)#address-family ipv6

Router4(config-router-af)#neighbor 2001:db8::1 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::1 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::1 description iBGP with Router1

Router4(config-router-af)#neighbor 2001:db8::1 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::2 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::2 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::2 description iBGP with Router2

Router4(config-router-af)#neighbor 2001:db8::2 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::3 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::3 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::3 description iBGP with Router3

Router4(config-router-af)#neighbor 2001:db8::3 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::5 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::5 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::5 description iBGP with Router5

Router4(config-router-af)#neighbor 2001:db8::5 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::6 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::6 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::6 description iBGP with Router6

Router4(config-router-af)#neighbor 2001:db8::6 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::7 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::7 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::7 description iBGP with Router7

Router4(config-router-af)#neighbor 2001:db8::7 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::8 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::8 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::8 description iBGP with Router8

Router4(config-router-af)#neighbor 2001:db8::8 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::9 remote-as 10

Router4(config-router-af)#neighbor 2001:db8::9 update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::9 description iBGP with Router9

Router4(config-router-af)#neighbor 2001:db8::9 activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::a remote-as 10

Router4(config-router-af)#neighbor 2001:db8::a update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::a description iBGP with Router10

Router4(config-router-af)#neighbor 2001:db8::a activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::b remote-as 10

Router4(config-router-af)#neighbor 2001:db8::b update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::b description iBGP with Router11

Router4(config-router-af)#neighbor 2001:db8::b activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::c remote-as 10

Router4(config-router-af)#neighbor 2001:db8::c update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::c description iBGP with Router12

Router4(config-router-af)#neighbor 2001:db8::c activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::d remote-as 10

Router4(config-router-af)#neighbor 2001:db8::d update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::d description iBGP with Router13

Router4(config-router-af)#neighbor 2001:db8::d activate

Router4(config-router-af)#

Router4(config-router-af)#neighbor 2001:db8::e remote-as 10

Router4(config-router-af)#neighbor 2001:db8::e update-source loopback 0

Router4(config-router-af)#neighbor 2001:db8::e description iBGP with Router14

Router4(config-router-af)#neighbor 2001:db8::e activate

Q. Pourquoi update-source loopback 0 est-il nécessaire sur iBGP?

Utilisez show bgp ipv6 summary pour vérifier l'état des connexions voisines d’iBGP. Si la session iBGP n'est pas en place et / ou aucune mise à jour n’est envoyée, travaillez avec l'équipe du routeur de la connexion voisine pour résoudre le problème.

4. Verification de la Configuration. Faites un show run | begin bgp afin de voir a quoi ressemble la configuration BGP. Remarquez comme la partie générique de la configuration BGP est séparée de la configuration spécifique à la famille d’adresses IPv6. Voici ci-dessous un exemple d’output de la commande (Nous ne montrons pas la configuration IPv4 spécifique au module IPv4):

Router4#sh run | b bgp

router bgp 10

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 2001:db8::1 remote-as 10

neighbor 2001:db8::1 description iBGP with Router2

neighbor 2001:db8::1 update-source Loopback0

…

address-family ipv6

neighbor 2001:db8::1 activate

neighbor 2001:db8::2 activate

neighbor 2001:db8::3 activate

…

exit-address-family

5. Vérification d'intégrité. N'oubliez pas d'utiliser les commandes suivantes pour vous assurer d'obtenir les informations que vous êtes supposés avoir:

show bgp ipv6 unicast summary : voir la liste de pairs BGP IPv6 que le routeur voit

show bgp ipv6 unicast : voir la liste de chemins BGP IPv6 que le routeur voit

show ipv6 route : voir toutes les routes IPv6 que le routeur a installé

Q. Y a t-il des routes vues à travers show bgp ipv6 unicast? Si non, pourquoi pas? Y a t-il des routes marquées «B» lorsque vous effectuez show ipv6 route?

6. Ajouter des Réseaux via BGP. Chaque équipe utilise BGP pour annoncer le bloc d'adresse utilisé pour le module. Par exemple, l’équipe routeur 1 ajouterait:

Router1 (config)#router bgp 10

Router1 (config-router)#address-family ipv6

Router1 (config-router-af)#network 2001:db8::/32

Utilisez show bgp ipv6 unicast sur le routeur du voisin pour voir si vous annoncez votre réseau via BGP.

Q. Est-ce que le réseau se présente via BGP? Si non, pourquoi?

Entrez une route statique pour le bloc CIDR. Par exemple, le routeur 1 utiliserait:

Router1 (config)#ipv6 route 2001:db8::/32 Null0

Q. Est-ce que le réseau se présente via le BGP d’un voisin? Utilisez la commande show ip bgp neighbor <neighbour’s IP address> advertised-routes pour voir ce que vous exportez à l'autre routeur. Allez physiquement à l'un des routeurs de votre voisin et vérifiez leur table BGP. Expliquez ce que vous voyez.

Q. Est-ce que le réseau apparait dans la table de transfert du routeur? Utilisez la commande show ipv6 route pour vérifier la table de transfert locale. Si non, pourquoi pas?

7. Ajoutez les commandes suivantes à BGP (IOS antérieur a 12.3):

Router1 (config)#router bgp 10

Router1 (config-router)# address-family ipv6

Router1 (config-router-af)# no synchronization

Q. Est-ce que le réseau apparait dans la table de transfert du routeur? Utilisez la commande show ipv6 route pour vérifier la table de transfert locale. Qu'est-ce que la commande no synchronisation fait dans BGP? Comment ça affecte la table de transfert du routeur?

Checkpoint #1: appelez l'instructeur pour vérifier la connectivité.

8. Ajout d'une route "client" dans BGP (Contexte & exemple). Nous allons maintenant ajouter une route "client" dans BGP sur chaque routeur. Or, dans le laboratoire, nous n'avons pas de "clients" en tant que tels connectés à nos routeurs, donc nous allons simuler la connectivité en utilisant simplement une interface Null0. A titre d'exemple, en situation réelle, la configuration pour connecter un client ressemblerait à quelque chose comme ceci

ipv6 route 2001:db8:10::/48 Serial 0/5/2 permanent

router bgp 64509

address-family ipv6

network 2001:db8:10::/48

Ceci ajouterait une route statique pointant 2001:db8:10::/48 vers Serial 0/5/2 – cette interface serait un lien fixe se connectant au site du client. 2001:db8:10::/48 serait l'espace d'adressage que l'ISP a attribué au client. La déclaration de réseau BGP ajouterait alors le bloc adresse du client dans l’iBGP de l'ISP.

Note: Le mot-clé permanent fait en sorte que la route statique est toujours dans la table de routage, même si l'interface est physiquement en panne. Plusieurs ISP utilisent cela pour s'assurer qu'ils n'ont pas un large échange de messages iBGP, appelé churn en anglais, lorsque les liens de leurs clients tombent en panne.

9. Ajout d'une route "client" dans BGP. L’espace d’adressage «client» que chaque routeur introduira dans iBGP figure ci-dessous – on utilisera chacun un / 48 comme espace minimum pour les end-sites.

R1 2001:db8:1::/48

R2 2001:db8:2::/48

R3 2001:db8:3::/48

R4 2001:db8:4::/48

R5 2001:db8:5::/48

R6 2001:db8:6::/48

R7 2001:db8:7::/48

R8 2001:db8:8::/48

R9 2001:db8:9::/48

R10 2001:db8:a::/48

R11 2001:db8:b::/48

R12 2001:db8:c::/48

R13 2001:db8:d::/48

R14 2001:db8:e::/48

Chaque équipe doit maintenant mettre en place une route statique pointant vers l'interface Null0 pour le / 48 dont elles sont à l'origine. Une fois que la route statique est mise en place, l'équipe doit ensuite ajouter une entrée dans la table BGP. Voici un exemple pour Router11:

Router11 (config)# ipv6 route 2001:db8:b::/48 Null0

Router11 (config)# router bgp 10

Router11 (config-router)# address-family ipv6

Router11 (config-router-af)# network 2001:db8:b::/48

10. Vérifiez le table BGP. Y a t-il des routes vues par show bgp ipv6? Si non, pourquoi pas? Une fois que toutes les équipes de la classe ont terminé leur configuration, chaque équipe doit voir l'agrégat ainsi que les quatorze / 26s introduits à l'étape précédente. Si ce n'est pas le cas, travaillez avec vos voisins pour résoudre le problème.

Review Questions

1. Quelle commande show d’IOS affiche la table de routage BGP IPv6 du routeur?

Configuration iBGP de base-IPv4

Ci-dessous, la topologie couramment utilisée pour la première série de laboratoires.

Figure 1 – Configuration de base de laboratoires ISP

Notes de laboratoires Cet atelier est destiné à être exécuté sur un serveur Dynamips avec les topologies de laboratoire appropriées mises en place. Les routeurs dans le milieu Dynamips utilisent le fournisseur de services IOS. Les configurations et les principes de configuration décrits ci-dessous fonctionneront sur tous IOS Cisco à partir de la parution 12.4. Les versions antérieures d’IOS Cisco ne sont pas pris en charge mais fonctionneront le plus souvent avec les notes ci-dessous ; elles vont manquer quelques-unes des fonctionnalités couvertes.

Le but de ce module est de construire le laboratoire de l’atelier et de présenter à tout le monde les principes de base de la construction et de la configuration d'un réseau. Un point important à retenir, et qui sera souligné à maintes reprises tout au long de cet atelier, c'est qu'il y a une séquence distincte à la construction d'un réseau opérationnel:

Après que la conception physique soit établie, les liens entre les matériaux (hardware) devraient être construits et vérifiés
Ensuite, les routeurs devraient avoir la configuration de base installée, et une sécurité de base mais suffisante mise en place.
Puis la connectivité IP de base devrait être testée et éprouvée. Cela signifie attribuer des adresses IP à toutes les liaisons qui doivent être utilisées, et tester les liens aux dispositifs voisins.
Seulement après qu’un routeur ait pu voir son voisin il serait sensé de commencer à configurer les protocoles de routage. Et commencer par l'IGP (ISIS est choisi pour cet atelier). Il n'y a pas de finalité à la construction de BGP alors que l'IGP choisi (dans ce cas, ISIS) ne fonctionne pas correctement. BGP s'appuie sur ISIS pour trouver ses voisins et les next hops, et un mauvais ou non-fonctionnement de l’ISIS se traduira par beaucoup de temps perdu à essayer de déboguer les problèmes de routage.
Une fois que l'IGP fonctionne correctement, la configuration BGP peut être commencée, d'abord BGP interne puis BGP externe.
Rappelez-vous de RTFM. Qu'est-ce que RTFM? Il est essentiel que les ingénieurs de réseau ISP utilisent pleinement toutes les ressources d'information. La source n ° 1 est la documentation. Lisez le manuel F#$%. (RTFM) est la phase traditionnelle utilisée pour informer les ingénieurs que la réponse est dans la documentation et aller la lire. Nous allons utiliser RTFM tout au long de ces exercices pour mettre en évidence les domaines où l'étudiant doit utiliser la documentation pour approfondir. Il y aura beaucoup de nouvelles commandes. S'il vous plaît se référer au " Command Reference IOS Cisco Connection Online (CCO.cisco.com) " pour plus de détails sur chacune de ces commandes
Enfin, la documentation. La documentation est souvent négligé ou oublié. Il s'agit d'un processus en cours dans cet atelier. Si l'instructeur vous demande de documenter quelque chose, que ce soit sur le tableau blanc dans la classe, ou à la fin de cette brochure, il est dans votre intérêt de le faire. Il ne peut y avoir trop de documentation, et de la documentation au moment de la conception et construction du réseau peut épargner beaucoup de frustration à une date ou événement ultérieur.

Exercice pratique

1. Configurer iBGP. Avant de configurer iBGP avec les voisins dans notre AS, nous avons besoin de faire un peu de préparation de base sur le routeur. Les paramètres par défaut IOS ne sont pas optimisés pour les réseaux des fournisseurs de services, donc avant de lancer les sessions BGP, nous devons définir les paramètres par défaut dont nous avons besoin.

La distance par défaut pour eBGP est de 20, la distance par défaut pour iBGP est de 200, et la distance par défaut pour ISIS est de 115. Cela signifie qu'il y a un potentiel pour un préfixe appris par eBGP de remplacer le préfixe identique porté par ISIS. Rappelons de la présentation sur le routage qu'il y a une séparation nette entre BGP et les processus ISIS – les préfixes présents dans ISIS ne seront jamais trouvés dans BGP, et vice-versa. Pour se protéger contre les accidents , la distance eBGP est fixée à 200 également. La commande pour ce faire est la sous-commande bgp distance, la syntaxe est la suivante:

distance bgp <external routes> <internal routes> <local routes>

Remarque: Cela devrait être inclus dans toutes les configurations BGP futures dans cet atelier. Par exemple, pour Router2, la configuration peut être:

Router2(config)#router bgp 10

Router2(config-router)#distance bgp 200 200 200

2.Journalisation de l'Etat d'adjacence BGP. Activer la journalisation des changements voisins BGP. Il en est ainsi qu’une notification est générée à chaque fois que l'état d'un voisin BGP change, et est utile pour le débogage:

Router2(config)#router bgp 10

Router2(config-router)# bgp log-neighbor-changes

Note: À partir d’IOS 12.3, bgp log-neighbor-changes est activé par défaut lorsque BGP est initialement configuré.

3. Configurer les voisins d’iBGP. Tous les routeurs seront dans le système autonome (AS) 10 pour ce premier laboratoire. Utilisez show ip bgp summary pour vérifier le peering. Le peering BGP sera établi en utilisant les adresses IP des interfaces de loopback.

Router2(config)#router bgp 10

Router2(config-router)#neighbor 10.0.15.241 remote-as 10

Router2(config-router)#neighbor 10.0.15.241 update-source loopback 0

Router2(config-router)#neighbor 10.0.15.241

description iBGP with Router1

Router2 (config-router)#neighbor 10.0.15.243 remote-as 10

Router2 (config-router)#neighbor 10.0.15.243 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.243 description iBGP with Router3

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.244 remote-as 10

Router2 (config-router)#neighbor 10.0.15.244 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.244 description iBGP with Router4

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.245 remote-as 10

Router2 (config-router)#neighbor 10.0.15.245 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.245 description iBGP with Router5

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.246 remote-as 10

Router2 (config-router)#neighbor 10.0.15.246 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.246 description iBGP with Router6

Router2 (config-router)# Router2 (config-router)#neighbor 10.0.15.247 remote-as 10

Router2 (config-router)#neighbor 10.0.15.247 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.247 description iBGP with Router7

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.248 remote-as 10

Router2 (config-router)#neighbor 10.0.15.248 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.248 description iBGP with Router8

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.249 remote-as 10

Router2 (config-router)#neighbor 10.0.15.249 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.249 description iBGP with Router9

Router2 (config-router)# Router2 (config-router)#neighbor 10.0.15.250 remote-as 10

Router2 (config-router)#neighbor 10.0.15.250 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.250 description iBGP with Router10

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.251 remote-as 10

Router2 (config-router)#neighbor 10.0.15.251 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.251 description iBGP with Router11

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.252 remote-as 10

Router2 (config-router)#neighbor 10.0.15.252 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.252 description iBGP with Router12

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.253 remote-as 10

Router2 (config-router)#neighbor 10.0.15.253 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.253 description iBGP with Router13

Router2 (config-router)#

Router2 (config-router)#neighbor 10.0.15.254 remote-as 10

Router2 (config-router)#neighbor 10.0.15.254 update-source loopback 0

Router2 (config-router)#neighbor 10.0.15.254 description iBGP with Router14

Q. Pourquoi update-source loopback 0 est-il nécessaire sur iBGP?

Utilisez show ip bgp summary pour vérifier l'état des connexions voisines d’iBGP. Si la session iBGP n'est pas en place et / ou aucune mise à jour n’est envoyée, travaillez avec l'équipe du routeur de la connexion voisine pour résoudre le problème.

4. Vérification d'intégrité. N'oubliez pas d'utiliser les commandes suivantes pour vous assurer d'obtenir les informations que vous êtes supposés avoir:

show ip bgp summary : voir la liste de pairs BGP que le routeur voit

show ip bgp : voir la liste de chemins BGP que le routeur voit

show ip route : voir toutes les routes que le routeur a installé

Q. Y a t-il des routes vues à travers show ip bgp? Si non, pourquoi pas? Y a t-il des routes marquées «B» lorsque vous effectuez show ip route?

5. Ajouter des Réseaux via BGP. Chaque équipe routeur utilise BGP pour annoncer le bloc d'adresse utilisé pour le module. Par exemple, l’équipe routeur 1 ajouterait:

Router1 (config)#router bgp 10

Router1 (config-router)#network 10.0.0.0 mask 255.255.240.0

Utilisez show ip bgp sur le routeur du voisin pour voir si vous annoncez votre réseau via BGP.

Q. Est-ce que le réseau se présente via BGP? Si non, pourquoi?

Entrez une route statique pour le bloc CIDR. Par exemple, le routeur 1 utiliserait:

Router1 (config)#ip route 10.0.0.0 255.255.240.0 Null0

Q. Est-ce que le réseau se présente via le BGP d’un voisin? Utilisez la commande show ip bgp neighbor advertised-routes pour voir ce que vous exportez à l'autre routeur. Allez physiquement à l'un des routeurs de votre voisin et vérifiez leur table BGP. Expliquez ce que vous voyez.

Q. Est-ce que le réseau apparait dans la table de transfert du routeur? Utilisez la commande show ip route pour vérifier la table de transfert locale. Si non, pourquoi pas?

6. Pour les routeurs avec un IOS antérieur à 12,3 ajoutez les commandes suivantes à BGP:

Router1 (config)#router bgp 10

Router1 (config-router)# no synchronization

Router1 (config-router)# no auto-summary

Q. Est-ce que le réseau apparait dans la table de transfert du routeur? Utilisez la commande show ip route pour vérifier la table de transfert locale. Qu'est-ce que la commande no synchronisation fait dans BGP? Comment ça affecte la table de transfert du routeur?

Note:A partir de IOS 12.3, la synchronisation et l'auto-résumage sont désactivés par défaut et n'apparaissent pas dans la configuration par défaut de BGP. Ces deux caractéristiques n'ont pas été requises par les réseaux des fournisseurs de services depuis que le système de routage sans classe a été introduit à l'Internet en 1994.

ip route 172.16.4.0 255.255.255.128 Serial 0/5/2 permanent

router bgp 64509 network 172.16.4.0 mask 255.255.255.128

Ceci ajouterait une route statique pointant 172.16.4.0/25 vers Serial 0/5/2 - la dernière interface serait un lien fixe se connectant au site du client. 172.16.4.0/25 serait l'espace d'adressage que l'ISP a attribué au client. La déclaration de réseau BGP ajouterait alors le bloc adresse du client dans l’iBGP de l'ISP.

Note: Le mot-clé permanent fait en sorte que la route statique est toujours dans la table de routage, même si l'interface est physiquement en panne. Plusieurs ISP utilisent cela pour s'assurer qu'ils n'ont pas un désabonnement iBGP lorsque les liens de leurs clients tombent en panne

8. Ajout d'une route "client" dans BGP. L’espace d’adressage «client» que chaque équipe de routeur introduira dans iBGP figure ci-dessous – on utilisera chacun un / 26, pour plus de simplicité.

R1 10.0.0.0/26

R2 10.0.0.64/26

R3 10.0.0.128/26

R4 10.0.0.192/26

R5 10.0.1.0/26

R6 10.0.1.64/26

R7 10.0.1.128/26

R8 10.0.1.192/26

R9 10.0.2.0/26

R10 10.0.2.64/26

R11 10.0.2.128/26

R12 10.0.2.192/26

R13 10.0.3.0/26

R14 10.0.3.64/26

Chaque équipe doit maintenant mettre en place une route statique pointant vers l'interface Null0 pour le / 26 dont elles sont à l'origine. Une fois que la statique est mise en place, l'équipe doit ensuite ajouter une entrée dans la table BGP. Voici un exemple pour Router11:

Router11 (config)# ip route 10.0.2.128 255.255.255.192 Null0

Router11 (config)# router bgp 10

Router11 (config-router)# network 10.0.2.128 mask 255.255.255.192

9.Vérifiez le tableau BGP. Y a t-il des routes vues par show ip bgp? Si non, pourquoi pas? Une fois que toutes les équipes de la classe ont terminé leur configuration, chaque équipe doit voir l'agrégat ainsi que les quatorze / 26s introduit dans l'étape précédente. Si ce n'est pas le cas, travaillez avec vos voisins pour résoudre le problème.

Checkpoint # 22: appeler l'assistant de laboratoire pour démontrer la table BGP actuelle.

10. Autres caractéristiques de iBGP. Revoyez la documentation ou utilisez command line help en tapant ? pour voir d'autres commandes show et d'autres éléments de configuration BGP.

11. Configuration avancée. Les équipes routeur qui ont terminé ce module doivent se référer au module 11 de l'atelier avancé de BGP. Les étapes de mis en place (set-up) ont été élargies pour inclure toutes les exigences de base d'un routeur utilisé dans un backbone ISP. En attendant que le module soit complet, maintenant serait un bon moment pour revoir le module avancé et incorporer les ajouts à la configuration utilisée ici.

Déploiement de DNSSEC

1.Introduction

DNSSEC a pour vocation de protéger la résolution DNS contre un certain nombre d’attaques. Cette technologie reste aujourd’hui la seule solution reconnue et effective contre une attaque de type empoisonnement de cache (cache poisoning). Néanmoins, son déploiement nécessite un certain nombre de précautions, car, comme toute technique de sécurisation, une mauvaise mise en oeuvre risque de provoquer des incidents techniques/opérationnels majeurs. Ce document est destiné aux administrateurs système d’un hébergeur DNS1 souhaitant déployer DNSSEC afin de signer les zones qu’ils gèrent en minimisant le risque de problèmes. Pour cela, l’orientation de ce guide se veut didactique et privilégiant les solutions résistantes aux erreurs d’exploitation plutôt que celles qui résistent aux attaques massives. Certains choix pourront donc être simplifiés afin de permettre une mise en place rapide.

Composantes de la chaine de confiance DNSSEC

Le déroulé de ce guide partira des prérequis qu’il convient de valider avant d’envisager un déploiement de DNSSEC en production, puis exposera deux exemples concrets de gestion de DNSSEC avec les logiciels OpenDNSSEC+NSD ou avec BIND.

2. Les prérequis

DNSSEC change le modèle de fonctionnement du DNS.

Sans DNSSEC, le DNS est en général dit statique. Il est initialement configuré, testé avec un logiciel comme Zonecheck, puis ne nécessite plus d’interventions particulières en dehors des modifications volontaires. DNSSEC oblige à penser différemment. En raison de l’expiration des signatures DNSSEC , il est important de re-signer périodiquement. En outre, il peut être utile de changer les clés de temps en temps, notamment pour être prêt si un changement est soudainement nécessaire. Si on ne fait jamais de changements, on sera fort dépourvu le jour où un changement s’impose (en cas de perte ou de compromission d’une clé, par exemple). Dans ce cas, il faut aussi gérer le remplacement de ces clés en complément des signatures. Aussi bien pour les signatures que pour les clés, les changements doivent se faire en respectant les délais imposés par les caches DNS. Ces caches DNS peuvent en effet garder l’information en mémoire et empêchent donc tout changement immédiat.

Avec DNSSEC, il faut avoir une perspective temporelle.

Les signatures doivent être re-générées au moins $TTL avant leur expiration, pour tenir compte des problématiques de cache précitées. Cette opération est difficilement réalisable à la main5 et nécessite donc une automatisation du processus. La suite des prérequis s’adresse aux personnes souhaitant un déploiement en production. Dans le cas d’une simple expérimentation de la technologie DNSSEC, vous pouvez directement passer aux exemples concrets.

Ayez une configuration technique correcte

Avec le DNS « traditionnel », tout marche même en cas d’erreur, en raison de la robustesse de ce protocole. DNSSEC représente un compromis différent : on diminue un peu la robustesse au profit de meilleures garanties d’intégrité. Il est donc nécessaire de bien comprendre et se former à DNSSEC. Un prérequis fondamental : tester l’exactitude de votre configuration DNS. Il existe une multitude d’outils6 en ligne pour cela. Nous nous concentrerons sur Zonecheck. Attention : Vérifiez bien tous les points indiqués par Zonecheck. Si certains vous semblent obscurs, prenez le temps de les étudier et de les comprendre. Rappelez-vous, DNSSEC nécessite une bonne compréhension de l’ensemble des mécanismes. Notamment, les points suivants doivent être testés :

que les serveurs faisant autorité répondent bien tous en EDNS
qu’ils peuvent effectivement envoyer des réponses de taille supérieure à 512 octets8
qu’ils peuvent effectivement envoyer des réponses de taille supérieure à la MTU du lien
qu’ils peuvent répondre en TCP.

DNSSEC est un protocole relativement ancien (la norme actuelle date de 2005) mais certains logiciels n’ont intégré DNSSEC complètement, et sans bogues que depuis deux ou trois ans. Il est donc essentiel de n’utiliser que des logiciels récents. Si, pour une raison d’administration système, vous êtes provisoirement contraint de n’utiliser que des versions anciennes, il est alors plus prudent de requalifier / replanifier vos projets de mise en oeuvre de DNSSEC.

Supervisez...

Un système DNS fiable nécessite une supervision. Même s’il est parfaitement configuré, les choses peuvent changer par la suite, un serveur peut « crasher », un pare-feu être (mal) reconfiguré, etc. Tous les hébergeurs DNS ont une supervision en place avec des outils comme Nagios par exemple. Cette supervision s’avère encore plus nécessaire avec DNSSEC.

Un exemple de problème détectable grâce à des outils de supervision est par exemple le filtrage d’accès : si un serveur esclave ne se met plus à jour en raison d’un filtrage accidentel de son accès, avec le DNS traditionnel, la seule conséquence sera la distribution d’informations éventuellement obsolètes. Mais, avec DNSSEC, lorsque les signatures stockées sur ce serveur auront expiré, toute la zone sera invalidée. Il faut donc être informé rapidement afin de pouvoir y remédier. Des tests supplémentaires doivent aussi être prévus tels que :

• tous les serveurs répondent avec les signatures ;

• que les signatures ne soient pas proches de l’expiration ;

• etc.

Synchronisez vos horloges

DNSSEC dépend d’horloges qui doivent être à l’heure exacte puisque les signatures contiennent une date de début et une date de fin de validité. Si vous signez sur une machine dont l’horloge est en retard, vos signatures pourraient être considérées comme expirées avant même que vous ne les publiiez. Bien sûr, avoir des machines à l’heure fait partie des bonnes pratiques depuis de nombreuses années mais, avant DNSSEC, le non-respect de ces recommandations n’avait pas forcément de conséquences visibles. Les horloges doivent donc être maintenues à l’heure, par exemple via NTP, et ce maintien doit être supervisé par un logiciel de supervision .

Sécurisez votre stockage

DNSSEC utilise la cryptographie et, à cet égard, reprend les mêmes problématiques que d’autres systèmes de cryptographie, par exemple les certificats X.509. Ainsi, il faut garder les clés privées... privées, afin d’éviter leur copie par un attaquant, tout en ayant des sauvegardes qui permettront de les récupérer si le système de stockage est défaillant.

Si vous gérez déjà des systèmes cryptographiques,

DNSSEC ne vous surprendra pas. Si vous débutez la cryptographie avec DNSSEC, prudence.

Une clé DNSSEC privée stockée en mode « lecture pour tous » sur une machine qui est également un serveur Web public avec plein de scripts programmés sans souci de sécurité est sans doute à éviter.

3. Choix Technique

La gestion des clés

Deux choix importants seront à faire au sujet de la gestion des clés.

D’abord, faut-il une clé ou deux pour la zone ? À lire beaucoup de textes sur DNSSEC, on peut avoir l’impression que la séparation en deux clés, la KSK (Key Signing Key) et la ZSK (Zone Signing Key) est obligatoire. Mais ce n’est pas le cas. On peut très bien n’avoir qu’une seule clé. Les conseils que nous donnons sont « si vous gérez vos zones à la main, comme dans l’exemple BIND ci-dessous, n’utilisez qu’une seule clé » et « si vous utilisez un outil de gestion de clés comme OpenDNSSEC, n’hésitez pas à avoir deux clés, l’outil s’occupera de tout ». Il est à noter que le choix du logiciel BIND ou d’OpenDNSSEC est a priori indépendant du choix du nombre de clés, les deux outils permettant d’implanter les deux stratégies de gestion de clés.

Seconde décision à prendre sur la gestion des clés : où conserve-t-on les clés ? La méthode la moins sûre est lorsque les clés sont simplement stockées sur le serveur qui fait les signatures. La plus sûre est celle d’un HSM (Hardware Security Module), un ordinateur spécialisé et durci qui stocke les clés et réalise les signatures. Entre les deux, on peut avoir des clés qui sont gardées sur un support USB enfermé dans un coffre-fort et sorti les jours où l’on signe (soit parce qu’on a modifié les données, soit parce que l’on doit re-signer avant expiration).

L’usage des HSM nécessite un investissement pour leur acquisition et leur appropriation technique (formation). La décision de les utiliser ou pas est a priori guidée par un arbitrage sur les coûts associés aux risques à couvrir/accepter. En pratique, dans le cas de zones considérées importantes/critiques par l’opérateur DNS, ce dernier investit dans des HSM. Dans le cas contraire (zones « ordinaires »), d’autres solutions sont privilégiées.

La solution du coffre-fort est tentante, mais manque de souplesse, elle interdit d’utiliser les outils de re-signature automatiques, comme ceux présentés dans la prochaine section. Cette solution augmente certes le niveau de protection de la clé de signature contre le vol/compromission, mais elle induit un sur-coût en tâches d'administration : mise en ligne manuelle et périodique de la clé pour les signatures et installation d'un système de rappel/surveillance des signatures pour éviter l’oubli de re-signer.

Une solution, la plus pratique dans le cas de zones ordinaires, est de garder les clés sur le serveur de signature. Certes, c’est la moins sûre parmi toutes celles mentionnées dans ce document, mais, actuellement, cette solution a l’avantage de la simplicité ainsi que celui d’éviter de garder le statu quo (pas de signature et donc pas de sécurité du tout). Bien sûr, la clé doit être protégée par les mécanismes habituels de sécurité du serveur (ne pas la mettre dans un répertoire partagé, veiller à ses protections) et le serveur lui-même doit être administré selon les bonnes pratiques de sécurité (ne donner le mot de passe de root qu’aux seules personnes autorisées, appliquer les correctifs de sécurité...).

Les logiciels

Il existe évidemment un grand choix de systèmes et de logiciels pour héberger les fonctions DNSSEC. Nous nous focaliserons sur la plate-forme la plus utilisée pour l’hébergement, Unix. Les exemples donnés ici sont pour une machine utilisant le système d’exploitation Debian et devront être légèrement adaptés pour d’autres systèmes. Pour les logiciels, la priorité a été donnée aux logiciels libres, avec un accent particulier sur deux solutions que nous connaissons et utilisons :

OpenDNSSEC et NSD,
BIND avec auto-dnssec.

Aspects cryptographiques pratiques

Ce document n’est pas un cours de cryptographie et passera donc rapidement sur cette section. Notez bien que, pour faire du DNSSEC, vous n’avez besoin que des aspects opérationnels de la cryptographie, ses facettes mathématiques ne sont pas nécessaires.

Pour les non-cryptographes, le seul choix pratique est « NSEC3 ou pas ». NSEC3, normalisé dans le RFC 5155, permet de limiter les risques d’énumération du contenu de la zone, via le zone walking. Si vos zones sont déjà publiques (transfert de zone autorisé) ou si le contenu de vos zones est trivial à énumérer (par exemple, il n’y a que l’apex et www), alors NSEC3 est inutile. Mais le cas inverse est bien plus fréquent et nous recommandons donc d’utiliser NSEC3. Au final, nous recommandons le choix de l’algorithme RSA + SHA256 (numéro 8 dans le registre IANA des algorithmes14). C’est celui qui est utilisé dans les exemples suivants.

Un exemple avec BIND

BIND dispose, depuis la version 9.9, de la capacité de gérer les signatures et resignatures. Il reste à faire la gestion des clés mais on a vu plus haut qu’un remplacement systématique et automatique des clés n’est nullement obligatoire. Le principe avec BIND est donc le suivant : 1. créer la ou les clés ; 2. indiquer à BIND de gérer seul les signatures et re-signatures de la zone. On installe le seul logiciel nécessaire dans cet exemple, BIND, par exemple (sur Debian) avec : aptitude install bind9. Puis la première étape consiste à appeler dnssec-keygen. Ici, pour le cas d’une seule clé :

dnssec-keygen -a RSASHA256 -3 -f KSK -b 2048 dnssec.fr

Generating key pair.........+++ ...............................................+++

Kdnssec.tn.+008+49734

Remarque : On peut ajouter l’option -n ZONE mais c’est la valeur par défaut, de toute façon. Si l’opération prend longtemps et que vous constatez avec un programme comme top que la machine ne fait pas grand-chose, c’est normal : la génération d’une clé nécessite de l’entropie pour fabriquer des nombres vraiment aléatoires et votre machine ne produit peut-être pas assez d’entropie. Paradoxalement, il faut faire travailler votre machine pour que cela aille plus vite (compiler un très gros programme, par exemple19), les entrées/sorties sur le disque étant la principale source d’entropie. Lorsque dnssec-keygen se termine, il crée deux fichiers :

ls -lt Kdnssec.tn*

-rw-r--r-- 1 bortzmeyer bortzmeyer 598 Jul 19 10:53

Kdnssec.fr.+008+49734.key

-rw------- 1 bortzmeyer bortzmeyer 1776 Jul 19 10:53

Kdnssec.tn.+008+49734.private

La clé privée est précieuse : elle doit être mise en sécurité, sur une machine fiable, tout en ayant des sauvegardes au cas où cette machine aurait une défaillance. Cette gestion des clés est une partie nouvelle et importante de DNSSEC. La clé publique doit être mise dans un répertoire où BIND la trouvera (key-directory voir plus loin).

Ensuite, il faut configurer BIND :

options {

directory "/etc/bind";

key-directory "/var/bind/keys";

recursion no;

dnssec-enable yes;

};

zone "dnssec.tn" in {

inline-signing yes;

auto-dnssec maintain;

update-policy local; # Necessary, says the ARM (otherwise, you cannot freeze/thaw)

type master;

file "dnssec.fr"; ... }

Et cela suffit. BIND trouvera les clés dans key-directory et signera tout seul. Et BIND re-signera lorsque cela sera nécessaire. Vous noterez que la zone a été signée avec NSEC. Pour NSEC3, il va falloir l’expliquer à BIND, et lui fournir un sel, un nombre aléatoire qui servira à rendre les attaques par dictionnaire plus difficiles :

dd if=/dev/random bs=1 count=10 | md5sum | cut -c1-8

10+0 records in

10+0 records out

68f499ee

10 bytes (10 B) copied, 0.00046732 s, 21.4 kB/s

[On utilise ce sel]

rndc signing -nsec3param 1 0 10 68f499ee dnssec.tn

Et on peut voir que la zone est désormais signée avec NSEC3. Si on veut utiliser deux clés, une KSK et une ZSK, on doit d’abord les créer (notez la différence, -f KSK, ainsi que la taille plus petite de la ZSK) :

dnssec-keygen -a RSASHA256 -3 -f KSK -b 2048 dnssec.tn

Generating key pair....+++ ..................+++

Kdnssec.tn.+008+09634 % dnssec-keygen -a RSASHA256 -3 -b 1024 dnssec.tn

Generating key pair...............++++++ ...............++++++

Kdnssec.tn.+008+29433

On copie alors les deux clés dans le répertoire. BIND signera l’enregistrement DNSKEY avec les deux clés et tout le reste avec la ZSK. Une fois votre zone testée en détail, et après que tous les caches auront possédé les nouvelles informations, vous pourrez compléter la chaîne de confiance de DNSSEC en soumettant un enregistrement DS à la zone parente pour publication. Le DS de la zone se calcule avec dnssec-dsfromkey :

dnssec-dsfromkey Kdnssec.tn.+008+49734.key

dnssec.tn. IN DS 49734 8 1 3C5BA1C95F17214536AA8E82E9406321A96FBD22

dnssec.tn. IN DS 49734 8 2

A3B4267E78CF26B4442007E14B55B8F7C83A4EB81015122410B9E47E FEA2DBFD

Si vous êtes Bureau d’Enregistrement, vous envoyez ces enregistrements DS vousmême, a priori en utilisant le protocole EPP. Sinon, vous devrez passer par le mécanisme fourni par votre BE, probablement une interface Web. En cas de changement du contenu, de la zone, vous devez signaler à BIND de resigner et de se recharger :

rndc freeze dnssec.tn

[Éditer le fichier de zone]

rndc thaw dnssec.tn

A zone reload and thaw was started.

Check the logs to see the result.

On l’a vu, il n’est pas nécessaire de remplacer systématiquement les clés. Toutefois, on peut se retrouver dans l’obligation de le faire, par exemple parce qu’on découvre que la clé a été compromise, ou, tout simplement, pour tester les procédures pour le cas d’une telle compromission. Le principe avec BIND, pour le cas d’une clé unique, est le suivant : on crée la nouvelle clé, on la met dans le répertoire des clés, on modifie l’ancienne pour indiquer qu’elle n’est plus utilisée et BIND fera le remplacement :

[Création de la nouvelle clé]

dnssec-keygen -a RSASHA256 -f KSK -b 2048 dnssec.tn

Generating key pair.....+++ .......................................+++

Kdnssec.tn.+008+00847

[Copie dans le répertoire, si nécessaire]

cp Kdnssec.tn.+008+00847* /where/are/the/keys

[Modification de l’ancienne clé, la 49734]

[Révocation immédiate]

dnssec-settime -R +0 Kdnssec.tn.+008+49734.key

[Retrait dans deux jours (le temps que la nouvelle clé soit dans tous les caches]

dnssec-settime -I +2d Kdnssec.tn.+008+49734.key

[Suppression dans six jours (le temps que les signatures avec l’ancienne clé aient disparu des caches)

dnssec-settime -D +6d Kdnssec.tn.+008+49734.key

Attention, les délais doivent être calculés en tenant compte des TTL des enregistrements de la zone. Faites bien attention (ou bien utilisez OpenDNSSEC, qui gère tout cela automatiquement). Un changement de clé (key rollover) n’est pas une opération facile. N’oubliez pas non plus de changer l’enregistrement DS qui se trouve dans la zone parente et de synchroniser ce changement avec les changements faits dans votre zone. Là encore, cela peut s’avérer délicat et il vaut ne pas le réaliser l’opération sans une minutieuse préparation.

Et pour ajouter une nouvelle zone à celles servies ?

Les étapes sont les suivantes :

générer des clés pour la nouvelle zone,
ajouter la zone à la configuration (fichier named.conf), et le fichier de zone dans le répertoire de BIND,
recharger le serveur (par exemple avec rndc reload).

Débogage

Pour les problèmes spécifiquement DNSSEC, l’outil le plus souvent utilisé est DNSviz.

C’est un outil Web qui effectue un certain nombre de tests sur une zone signée et présente les résultats graphiquement, de manière très compréhensible.

4.Conclusion

Des nouvelles techniques permettant d’« améliorer » les attaques DNS par empoisonnement sont publiées régulièrement34. Travailler au déploiement de DNSSEC est donc une nécessité et permet de contribuer à la robustesse de cette ressource partagée qu’est le DNS. Mais DNSSEC est reste une technique nécessitant qualification, méthodologie et précision. Il est donc nécessaire de bien veiller au bon déroulement de son déploiement. Outre les lectures déjà mentionnées, nous attirons votre attention sur le guide nist.dnssec-deployment .

dimanche 26 avril 2015

Introduction à la technologie SDN (Software-Defined Networking)

La plupart des professionnels travaillant aujourd’hui dans l’informatique ont entendu parler du SDN (Software-Defined Networking), ce concept de réseau défini par logiciel qui semble marquer la prochaine étape de l’évolution des réseaux. Aux quatre coins du monde, le terme est repris dans des publications sectorielles, des articles de réflexion ainsi que sur des sites web et blogues ayant trait à l’informatique. Mais ce concept est-il pour autant bien compris ? Sa signification technique et ses implications pour le marché au sens large sont-elles correctement perçues ?

D’après Gary Middleton, directeur du développement commercial – Réseaux de Dimension Data, le SDN fait l’unanimité sur un point : l’impact majeur que cette approche exercera sur le marché. « Concrètement, les commentateurs situés à gauche sur l’échelle d’adoption – les progressistes qui font avancer et bouger le marché – n’hésitent pas à user de qualificatifs démesurés (« raz-de-marée » ou « bouleversement cataclysmique ») pour décrire l’effet auquel ils s’attendent dans les années qui viennent. À l’extrême droite, les plus conservateurs réservent leur jugement ; ils estiment qu’il est trop tôt pour se prononcer, et que mieux vaut faire preuve de prudence. »

Face à ce large spectre de réponses, comment interpréter le SDN et comment déterminer la part de tapage médiatique dans ce phénomène ?

Par-delà les obstacles techniques

Si le concept SDN demeure assez mal compris, c’est parce qu’il est difficile, en règle générale, d’énoncer clairement ses implications pour le réseau d’entreprise sans concevoir précisément ses fondements technologiques. En résumé, un réseau SDN est intelligent, programmable et automatisé. Pour comprendre ce que cela signifie, mieux vaut le comparer au mode de fonctionnement des réseaux traditionnels.

Gary Middleton explique que la façon dont un réseau LAN, WAN ou de centre de données dirige et administre les données qui circulent par son biais dépend du mode de configuration de chaque équipement réseau. « Collectivement, ces paramètres et règles déterminent la destination des données, la cadence de leur flux, la manière dont elles sont contrôlées par rapport aux règles de sécurité, celles qui sont autorisées et celles qui sont bloquées. »

« Toute la difficulté réside dans le fait que le responsable réseau doit configurer individuellement chaque équipement, en effectuant bien souvent des modifications physiques. En présence de plusieurs centaines de routeurs, commutateurs et ports, la configuration optimale du réseau est une opération complexe, consommatrice de main-d’œuvre et chronophage. Les modifications à effectuer pour prendre en compte de nouvelles applications et les allouer à un groupe d’utilisateurs spécifique prennent du temps. Par conséquent, l’administration réseau est une discipline nécessitant des compétences ultra-spécialisées et plusieurs années d’expérience. Le SDN est un concept prometteur appelé à simplifier et perfectionner l’administration des réseaux. »

Intelligence centralisée

Si les équipements réseau traditionnels doivent être configurés séparément, cela tient à la façon dont ils sont construits.

Gary Middleton poursuit : « Chaque routeur, comme chaque commutateur, comprend un certain nombre de couches ou plans différents, notamment le plan de données, par le biais duquel les paquets de données sont transférés, et le plan de contrôle, qui contrôle la manière dont sont gérées les données et l’emplacement où sont intégrées les « applications » réseau. « L’intelligence » réseau – autrement dit, la façon dont est géré le trafic de données – est donc, en grande partie, disséminée entre la totalité des équipements et répartie à l’échelle du réseau. Un réseau traditionnel est dépourvu de contrôle et d’intelligence centralisés … et c’est là où le SDN laisse espérer un changement. »

« Un réseau SDN découple les plans de données, de contrôle et applicatif des équipements. Dissociés du moteur de transmission de paquets et centralisés, certains de leurs éléments intelligents peuvent ainsi devenir programmables. Ce type d’architecture utilise, par conséquent, des équipements réseau matériels qui sont configurés et contrôlés par un programme logiciel centralisé appelé contrôleur. D’où l’expression « défini par logiciel ». Le réseau est configuré et contrôlé par voie logicielle, et non plus au niveau du matériel ou de l’équipement », ajoute-t-il.

Un réseau qui s’auto-pilote

Pour Gary Middleton, le SDN donne accès à une fonctionnalité encore plus performante : l’automatisation. « Le réseau devient une entité programmable avec laquelle les applications peuvent être directement en contact, en communiquant, via le contrôleur, avec chaque équipement. Configuré instantanément et automatiquement, le réseau bénéficie d’une allocation optimale de ses ressources. »

« Résultat ? Un réseau SDN est plus simple à mettre en œuvre, à contrôler et à administrer, et nécessite moins d’interventions humaines ; il s’adapte, de surcroît, de manière nettement plus dynamique aux évolutions constantes des environnements TIC actuels, en particulier dans les centres de données. »

D’ores et déjà, ces caractéristiques procurent des avantages extrêmement convaincants à toute entreprise qui s’efforce de réduire ses coûts et d’en faire toujours davantage avec moins de ressources. Difficile, en revanche, de déterminer comment ce modèle tirera son épingle du jeu, compte tenu des forces antagonistes et alliées qui se côtoient.

Trois méthodes de pilotage logiciel

Un bouleversement technologique s’accompagne souvent d’une certaine dimension « politique » sur le marché. Le SDN ne fait pas exception à la règle. Si ses avantages sont évidents pour la plupart des entreprises utilisatrices, la grande majorité – si ce n’est la totalité – des équipements installés sur leurs réseaux ne peuvent être pilotés par logiciel. S’orienter dans cette voie supposerait de faire table rase de l’existant ― une démarche onéreuse, risquée et perturbatrice.

« Pour compliquer encore la donne, il existe actuellement trois approches différentes pour l’implémentation d’un réseau SDN ― qui, toutes, portent sur la manière dont le contrôleur communique avec les équipements réseau », explique Gary Middleton.

« La première d’entre elles consiste à recourir à un protocole standard tel qu’OpenFlow, mis au point par l’ONF (Open Network Foundation), association comptant, parmi ses membres, Verizon, Deutsche Telecom, NTT, Google, Microsoft, Facebook et Yahoo. »

« OpenFlow étant un standard ouvert, il peut être utilisé par tout contrôleur compatible OpenFlow pour communiquer avec tout équipement réseau compatible OpenFlow, indépendamment du constructeur. Les petits équipementiers réseau, et en particulier les entreprises utilisatrices, prennent en charge ce standard ouvert qui leur confère davantage de souplesse et de liberté dans la conception de réseaux. »

Les équipementiers possédant une part de marché plus importante ont créé une API (Application Programming Interface), qui constitue la deuxième option possible. Gary Middleton explique qu’une API permet à des outils externes, logiciels ou applications de communiquer avec l’infrastructure, sachant que ceux-ci sont propres à un fournisseur donné et propriétaires. Ainsi, l’API d’un fournisseur donné peut uniquement communiquer avec les équipements de celui-ci. L’avantage de cette méthode réside dans le fait qu’une API expose le maximum de fonctionnalités intégrées aux équipements du constructeur du fait de la très forte intégration entre eux. « Il s’agit là d’une excellente solution dans le cas d’un environnement mono-fournisseur ou dominé par un fournisseur. »

Vient enfin la troisième option appelée réseau virtuel superposé (virtual network overlay, VNO).

Selon Gary Middleton, un réseau virtuel est un logiciel qui s’exécute par-dessus le réseau physique, tout en offrant programmabilité et pilotage centralisé. « Il existe plusieurs modes d’implémentation de la virtualisation réseau qui sont très largement pris en charge par les fournisseurs. Le réseau virtuel superposé peut se révéler particulièrement utile dans les réseaux de centres de données. Chaque réseau peut comprendre des configurations différentes et être transféré à n’importe quel endroit du centre de données, ou entre des centres de données, et la vue virtuelle demeurer inchangée. Le fonctionnement des réseaux virtuels s’apparente à celui des environnements de serveurs virtuels ; ils offrent un maximum de souplesse et une évolutivité instantanée. »

Alors, quelle voie les entreprises doivent-elles emprunter ?

Marche à suivre

La dynamique des progrès technologiques est telle que les entreprises utilisatrices ont bien du mal à appréhender ces évolutions et à choisir la meilleure voie à suivre.

« Chaque entreprise est unique en son genre, et chaque réseau l’est aussi. Une super autoroute de l’information pour l’une peut se révéler une impasse pour l’autre. Mieux vaut commencer par cerner les implications techniques du SDN et les atouts qu’il peut procurer à votre structure. »
Les entreprises doivent également faire le point sur l’état de « préparation » de leur réseau, identifier l’état « cible » souhaité, puis définir une feuille de route claire pour y parvenir.

Example simple d'utilisation d' OpenFlow / SDN dans le périphérique du réseau - (Part 1)