Les service de sécurité

Authentification des pairs dans IPSEC :

IPsec vérifie l’identité de chaque partenaire grâce à des méthodes d’authentification telles que les clés pré-partagées (PSK) et les certificats numériques.

Confidentialité des données dans IPSEC

IPsec protège les données contre les écoutes clandestines en utilisant des algorithmes de chiffrement tels que AES, DES, et 3DES. Il est important de noter que l’utilisation de DES et 3DES est désormais dépréciée en raison de leurs vulnérabilités.

Intégrité des données dans IPSEC

IPsec empêche les attaques man-in-the-middle (MitM) en garantissant que les données n’ont pas été falsifiées pendant leur transit. Pour ce faire, IPsec utilise HMAC (Keyed-Hash Message Authentication Code) avec des algorithmes tels que HMAC-SHA-1, HMAC-SHA-256, et HMAC-SHA-512. Notons que l’utilisation de HMAC-MD5 est dépréciée.

Détection de relecture dans IPSEC

Psec protège également contre les attaques MitM où un attaquant capture et rejoue le trafic VPN. Chaque paquet reçoit un numéro de séquence unique, et les périphériques VPN rejettent tout paquet avec un numéro de séquence déjà traité. Ces services sont disponibles dans deux en-têtes de paquet : Authentication Header (AH) et Encapsulation Security Payload (ESP). AH assure l’intégrité, l’authentification et la détection de relecture, mais ne traverse pas les NAT et ne peut pas être chiffré, d’où la recommandation d’utiliser ESP, qui corrige ces limitations.

Les modes de transports dans IPSEC

IPSec offre deux modes de transport de paquets:

Mode tunnel: crypte l’intégralité du paquet d’origine et ajoute un nouvel ensemble d’en-têtes IPsec. Les nouveaux en-têtes sont utilisés pour acheminer le paquet. Ce mode sera adapté pour un VPN Site-to-Site

Mode de transport: chiffre et authentifie uniquement la charge utile du paquet. Ce mode ne fournit pas de routes basées sur les en-têtes IP d’origine. Ce mode sera adapté pour un VPN Client-to-Site

Les algorithmes de chiffrement pris en charge par IPSec

IPsec est une technologie éprouvée pour protéger activement les communications sur les réseaux non sécurisés. Au cœur de cette solution, les algorithmes de chiffrement jouent un rôle essentiel. Ces algorithmes chiffrent les données sensibles, empêchant toute interception non autorisée. Explorons comment IPsec utilise ces algorithmes pour assurer une sécurité maximale.

Exempe d’alorithme et description

Voici une liste non-exhaustif des algorithmes intégrées à l’IPSEC :

•  Advanced Encryption Standard (AES): algorithme de cryptage symétrique utilisé pour le cryptage des données développé pour remplacer DES et 3DES. AES prend en charge des longueurs de clé de 128 bits, 192 bits ou 256 bits et est basé sur l’algorithme Rijndael.

• Secure Hash Algorithm (SHA): algorithme de hachage unidirectionnel de 160 bits utilisé pour l’authentification des données. Les périphériques Cisco utilisent le SHA-1 HMAC, qui offre une protection supplémentaire contre les attaques MitM.

• Diffie-Hellman (DH): protocole d’échange de clé asymétrique qui permet à deux homologues d’établir une clé secrète partagée utilisée par des algorithmes de chiffrement tels que AES sur un canal de communication non sécurisé. Un groupe DH fait référence à la longueur de la clé (taille du module) à utiliser pour un échange de clé DH. Par exemple, le groupe 1 utilise 768 bits, le groupe 2 utilise 1024 et le groupe 5 utilise 1536, où plus le module est grand, plus il est sécurisé. Le but de DH est de générer des clés symétriques secrètes partagées qui sont utilisées par les deux homologues VPN pour des algorithmes symétriques, tels que AES. L’échange DH lui-même est asymétrique et gourmand en ressources processeur, et les clés secrètes partagées qui en résultent sont symétriques. Cisco recommande d’éviter les groupes DH 1, 2 et 5 et d’utiliser à la place les groupes DH 14 et supérieurs.

•  Signatures RSA: système cryptographique à clé publique (certificats numériques) utilisé pour authentifier mutuellement les homologues.

•  Clé pré-partagée (PSK): mécanisme de sécurité dans lequel une clé configurée localement est utilisée comme information d’identification pour authentifier mutuellement les pairs.

Transform-set

Le transform set est une combinaison spécifique de protocoles de sécurité et d’algorithmes cryptographiques. Il joue un rôle important dans la sécurisation des communications au sein d’un VPN IPsec. Ce transform-set définit comment les données seront protégées lorsqu’elles sont transmises à travers le tunnel VPN.

Lors de la phase de négociation IKE (Internet Key Exchange), qui est prépondérante dans l’établissement d’une connexion VPN sécurisée, les équipements qui formeront les extrémités du VPN échangent des informations pour sélectionner et valider cette combinaison de sécurité. IKE, que ce soit en version 1 ou 2, permet aux deux parties de s’accorder sur les protocoles de sécurité à utiliser, notamment pour le chiffrement, l’authentification et l’intégrité des données.

Cette phase de négociation est cruciale car elle détermine la sécurité globale du tunnel VPN. Une fois la négociation terminée, le transform-set choisi sera appliqué pour chiffrer et authentifier les données transmises entre les deux extrémités du tunnel. En fonction des besoins spécifiques de sécurité, différents algorithmes et protocoles peuvent être sélectionnés, tels que AES pour le chiffrement et SHA-256 pour l’intégrité des données..

Internet Key Exchange (IKE)

Pour permettre une communication sécurisée entre nos deux équipements, notamment pendant la phase de négociation, nous devons créer un tunnel de communication sécurisé. Pour cela, nous utiliserons le protocole IKE. Ce protocole existe en deux versions : IKEv1 (RFC 2409) et IKEv2 (RFC 7296). IKEv2 améliore plusieurs aspects du protocole, comme la prise en charge de l’authentification basée sur les certificats (EAP), l’intégration de mécanismes anti-DoS, et la réduction du nombre de messages nécessaires par rapport à IKEv1.

Dans IKEv2, les communications se composent de paires de demandes et de réponses, appelées échanges. Le premier échange, IKE_SA_INIT, négocie les algorithmes cryptographiques (transform set), échange des nonces, et effectue un échange Diffie-Hellman. Cela crée le canal sécurisé.

Bon à savoir

Un nonce en cryptographie est un nombre aléatoire qui ne peux être utilisée une seule fois.

Le deuxième échange, IKE_AUTH, authentifie les messages précédents et échange les identités et les certificats. Ensuite, il établit une IKE SA et une IKE SA Enfant (SA Security Association– Association de sécurité IKE). Ses deux échanges vont nous permettre de créer un tunnel de gestion.

Le deuxième échange, IKE_AUTH, authentifie les messages précédents et échange les identités et les certificats. Ensuite, il établit une IKE SA et une IKE SA Enfant (Security Association – Association de sécurité IKE). Ces deux échanges permettent de créer un tunnel de gestion.

Nous allons faire transiter des données à travers ce tunnel.

Configurer IPSEC pour chiffrer les données transitant dans un VPN GRE

Dans cette mise en pratique, nous ferons passer dans un tunnel IPsec des paquet GRE. Cela permettra de chiffrer les messages dans le tunnel. Repartons de la topologie de l’article qui traite du VPN GRE.

Comme nous l’avons constaté dans l’article VPN GRE, les paquets circulent en clair dans le tunnel. Pour sécuriser ces communications, nous allons utiliser IPsec pour chiffrer les messages. Nous opterons donc pour une configuration de VPN GRE over IPsec.

Dans la partie théorique de ce chapitre, nous avons expliqué qu’il est essentiel de créer un premier tunnel avec la phase 1 d’IKE pour permettre la négociation entre les pairs. Ensuite, un second tunnel est établi à l’intérieur de ce premier, assurant ainsi la confidentialité des données dans un VPN IPsec.

Étant donné que notre tunnel GRE est déjà configuré, nous ne reviendrons pas sur la configuration de base, la mise en place du NAT et du tunnel GRE. Nous nous concentrerons plutôt sur la configuration d’IPsec pour sécuriser notre VPN IPsec.

IKE Phase 1 Configuration

Commençons par configurer la phase 1 d’IKE pour notre VPN IPsec.

RT-ETS-1(config)#crypto isakmp policy 1
RT-ETS-1(config-isakmp)#encryption aes
RT-ETS-1(config-isakmp)#hash sha
RT-ETS-1(config-isakmp)#authentication pre-share
RT-ETS-1(config-isakmp)#group 14

Pour cette configuration de VPN IPsec, nous allons d’abord utiliser une clé partagée pour l’authentification. Ensuite, nous devons configurer cette clé et spécifier l’adresse IP avec laquelle nous allons la partager. Enfin, l’adresse IP publique du routeur RT-ETS-2 identifiera le destinataire de cette clé.

RT-ETS-1(config)#crypto isakmp key maclepartage address 192.0.0.6

Ensuite, nous allons configurer notre transform set pour garantir que la phase de négociation aboutisse. Cette étape est cruciale pour assurer le succès du processus.

RT-ETS-1(config)#crypto ipsec transform-set montransformset esp-aes esp-sha-hmac

IKE Phase 2 Configuration

Maintenant, nous passons à la seconde phase d’IKE, qui consiste à chiffrer les données. Pour cela, nous allons configurer un ensemble de paramètres que nous placerons dans une « crypto map ».

« La crypto map associe les règles de sécurité à une interface réseau, déterminant quel trafic sera chiffré et sécurisé par le VPN IPsec. »

Bon à savoir

Une crypto map est une configuration sur un routeur ou un pare-feu qui associe des règles de sécurité, telles que les protocoles de chiffrement et les algorithmes d’authentification, à une interface réseau. Cette map détermine quel trafic doit être chiffré et sécurisé avant de traverser le VPN IPsec.

RT-ETS-1(config)#crypto map CRYPTOMAP 10 ipsec-isakmp

Ensuite, dans cette crypto map, nous spécifions l’autre extrémité du tunnel VPN IPsec

RT-ETS-1(config-crypto-map)# set peer 192.0.0.6

Ensuite, le transform set que nous utiliserons déterminera les protocoles de sécurité et les algorithmes de chiffrement pour notre tunnel VPN IPsec

RT-ETS-1(config-crypto-map)# match address 100

Puisque cette access-list n’est pas encore créée, nous allons la configurer maintenant. Elle chiffrera les données provenant de 10.0.0.1 vers 10.0.0.2, c’est-à-dire les données qui transitent dans le tunnel GRE

RT-ETS-1(config-crypto-map)#access-list 100 permit ip host 10.0.0.1 host 10.0.0.2

Appliquer la crypto map a notre interface

Ensuite, nous appliquons cette crypto map sur notre interface WAN

RT-ETS-1(config-crypto-map)# Interface gig 0/0
RT-ETS-1(config-if)# crypto map CRYPTOMAP

Nous configurerons RT-ETS-2 de la même manière, en ajustant simplement les adresses IP.

RT-ETS-2#conf terminal
RT-ETS-2(config)#crypto isakmp policy 1
RT-ETS-2(config-isakmp)#encryption aes
RT-ETS-2(config-isakmp)#hash sha
RT-ETS-2(config-isakmp)#authentica
RT-ETS-2(config-isakmp)#authentication pre-share
RT-ETS-2(config-isakmp)#group 14
RT-ETS-2(config-isakmp)#crypto isakmp key maclepartage address 192.0.0.2
RT-ETS-2(config)#crypto ipsec transform-set montransformset esp-aes esp-sha-hmac
RT-ETS-2(config)#crypto map CRYPTOMAP 10 ipsec-isakmp 
RT-ETS-2(config-crypto-map)#set peer 192.0.0.2
RT-ETS-2(config-crypto-map)# set transform-set montransformset 
RT-ETS-2(config-crypto-map)# match address 100
RT-ETS-2(config-crypto-map)#access-list 100 permit ip host 10.0.0.2 host 10.0.0.1
RT-ETS-2(config)#Interface gig 0/0
RT-ETS-2(config-if)#crypto map CRYPTOMAP

Vérifier que votre VPN GRE over IPSEC fonctionne

Pour vérifier que les associations de sécurité fonctionne sur les routeurs exécutons la commande suivante :

show crypto ipsec sa

Cette commande affiche les SA IPsec en cours, y compris les paquets chiffrés et déchiffrés. Cela permet de s’assurer que le tunnel VPN GRE over IPsec est actif.

Pour vérifier que la phase 1 IKE est bien établie en utilisant la commande suivante :

show crypto isakmp sa

Cette commande montre l’état des associations de sécurité IKE, indiquant si les échanges IKEv1 ou IKEv2 pour le VPN GRE over IPsec sont réussis.

Conclusion

Comme vous l’aurez compris, ici, nous n’avons pas configurer un VPN IPSec mais un VPN GRE over IPSEC. EN effet un VPN IPSEC est idéal pour des scénarios simples où tu as besoin de sécuriser le trafic IP entre deux points, sans avoir besoin de transporter d’autres types de trafic ou de gérer du routage dynamique. alors qu’un VPN GRE over IPSEC sera préféré ans des environnements plus complexes où tu as besoin de transporter plusieurs types de trafic (y compris non-IP), utiliser du routage dynamique, ou gérer du trafic multicast comme cela sera le cas dans le prochain article qui traitera du DMVPN.

L’article VPN IPSEC est apparu en premier sur Pandawan.

Une des solutions idéales est de créer un tunnel avec plusieurs points d’entrée et de sortie, appelé Dynamic Multipoint VPN (DMVPN). Notons ici que DMVPN est une technologie propriétaire de Cisco, et à ce titre, elle est principalement disponible sur les équipements Cisco. Cependant, certains concepts et technologies utilisés par DMVPN, tels que mGRE (Multipoint GRE), NHRP (Next Hop Resolution Protocol), et IPsec, sont standards et peuvent être implémentés sur d’autres plateformes.

Cette technologie permet de créer des tunnels entre plusieurs sites à la demande, c’est-à-dire lorsque le trafic d’un LAN doit être acheminé vers un autre LAN.

Composants Clés du DMVPN

mGRE (Multipoint GRE) :

Le mGRE fonctionne de manière similaire au GRE, mais au lieu d’être point à point, il est multipoint, structuré en architecture Hub & Spoke. Le Hub est connecté à plusieurs Spokes. Par exemple, le siège central joue le rôle de Hub, tandis que les succursales agissent comme des Spokes.

NHRP

Le NHRP fonctionne en mode Client/Serveur. Chaque client s’enregistre auprès du serveur NHS (Next Hop Server), qui est le Hub. Les Spokes jouent le rôle de NHC (Next Hop Client). Lorsqu’un routeur Spoke souhaite envoyer un paquet à un autre Spoke, il envoie une requête à son NHS, qui lui répond en envoyant l’adresse IP du Spoke cible. Cette information est ensuite conservée dans le cache NHC pour une utilisation future.

Dans le cas où le routeur Succursale 1 souhaite envoyer un paquet à Succursale 2. Succursale 1 enverra une requête à son NHS, qui lui répondra en envoyant l’adresse IP de Succursale 2. Succursale 1 conservera cette information dans le cache NHC. L a prochaine fois qu’il en aura besoin, il la récupérera dans son cache. Succursale 1 pourra alors envoyer le paquet à Succursale 2.

Les requêtes NHRP sont appelées des requêtes underlay, tandis que les communications utilisant le VPN sont appelées overlay.

Configuration de base du DMVPN

Partons d’une topologie composée de trois sites, chacun hébergeant un seul LAN. Pour ce laboratoire, nous utiliserons le VLAN 1 par défaut (qui ne doit pas être utilisé en production). Sur chaque LAN, le NAT overload est configuré pour permettre aux machines du LAN de rejoindre le réseau WAN, simulé par un routeur.

Commençons en configurant le routeur du siège en lui appliquant une configuration de base :

Router#enable
Router#configure terminal
Router(config)#hostname RT-SIEGE
RT-SIEGE(config)#interface gig 0/0
RT-SIEGE(config-if)#ip address 192.0.0.1 255.255.255.252
RT-SIEGE(config-if)#no shutdown
RT-SIEGE(config-if)#interface gig 0/1
RT-SIEGE(config-if)#ip address 192.168.0.254 255.255.255.0
RT-SIEGE(config-if)#no shutdown
RT-SIEGE(config-if)#interface gig 0/0
RT-SIEGE(config-if)#ip nat outside
RT-SIEGE(config-if)#interface gig 0/1
RT-SIEGE(config-if)#ip nat inside
RT-SIEGE(config-if)#ip access-list standard NAT-ACL
RT-SIEGE(config-std-nacl)#permit 192.168.0.0 0.0.0.255
RT-SIEGE(config-std-nacl)#ip nat inside source list NAT-ACL interface gig 0/0
RT-SIEGE(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0

Testons maintenant que notre configuration est fonctionnelle. Depuis le PC du LAN du SIEGE, après lui avoir attribuer une adresse IP, nous enverrons un PING sur l’interface LAN de notre routeur puis sur son interface WAN.

Une fois que nous nous sommes assurés du bon fonctionnement, nous continuerons.

Configurons maintenant le routeur « succursale 1 » nommé RT-SUC1

Router#enable
Router#configure terminal
Router(config)#hostname RT-SUC1
RT-SUC1(config)#interface gig 0/0
RT-SUC1(config-if)#ip address 192.0.0.5 255.255.255.252
RT-SUC1(config-if)#no shutdown
RT-SUC1(config-if)#interface gig 0/1
RT-SUC1(config-if)#ip address 192.168.1.254 255.255.255.0
RT-SUC1(config-if)#no shutdown
RT-SUC1(config-if)#interface gig 0/0
RT-SUC1(config-if)#ip nat outside
RT-SUC1(config-if)#interface gig 0/1
RT-SUC1(config-if)#ip nat inside
RT-SUC1(config-if)#ip access-list standard NAT-ACL
RT-SUC1(config-std-nacl)#ip nat inside source list NAT-ACL interface gig 0/0
RT-SUC1(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0

Nous effectuerons les même test que pour le siège.

Nous enchainerons avec le routeur RT-SC2 de la succursale 2.

Router#enable
Router#configure terminal
Router(config)#hostname RT-SUC2
RT-SUC2(config)#interface gig 0/0
RT-SUC2(config-if)#ip address 192.0.0.9 255.255.255.252
RT-SUC2(config-if)#no shutdown
RT-SUC2(config-if)#interface gig 0/1
RT-SUC2(config-if)#ip address 192.168.2.254 255.255.255.0
RT-SUC2(config-if)#no shutdown
RT-SUC2(config)#interface gig 0/0
RT-SUC2(config-if)#ip nat outside
RT-SUC2(config-if)#interface gig 0/1
RT-SUC2(config-if)#ip nat inside
RT-SUC2(config-if)#ip access-list standard NAT-ACL
RT-SUC2(config-std-nacl)#permit 192.168.2.0 0.0.0.255
RT-SUC2(config-std-nacl)#ip nat outside source list NAT-ACL interface gig 0/0
RT-SUC2(config)#ip route 0.0.0.0 0.0.0.0 gig 0/0

Testons son bon fonctionnement

Pour la configuration du routeur qui simulera Internet, il n’y aura qu’une configuration d’interface.

Router#enable
Router#configure terminal
Router(config)#hostname INTERNET
INTERNET(config)#interface gig 0/0
INTERNET(config-if)#ip address 192.0.0.2 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/1
INTERNET(config-if)#ip address 192.0.0.6 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/2
INTERNET(config-if)#no shutdown
INTERNET(config-if)#ip address 192.0.0.10 255.255.255.252
INTERNET(config-if)#no shutdown

Vérifions que la configuration est opérationnelle.

Depuis les PC d’un des trois LAN vous devriez pouvoir envoyer des requêtes sur les différentes adresse IP public de votre lab.

Test depuis PC1

Configuration DMVPN

Configuration du Routeur RT-SIEGE [HUB]

Nous allons commencer par configurer le GRE en créant notre réseau DMVPN avec l’adresse 10.0.0.0/24 :

RT-SIEGE(config)#interface tunnel 0
RT-SIEGE(config-if)#ip address 10.0.0.1 255.255.255.0

Par défaut, le GRE est en mode point à point. Nous allons donc activer le mode mGRE pour notre VPN Multi-site :

RT-SIEGE(config-if)#tunnel mode gre multipoint

Ensuite, nous associons l’interface GigabitEthernet 0/0 à notre interface tunnel 0 :

RT-SIEGE(config-if)#tunnel source gig 0/0

Pour sécuriser la communication, nous ajoutons une authentification via une clé partagée :

RT-SIEGE(config-if)#ip nhrp authentication mdpdmvpn

Nous activons la communication multicast pour permettre aux clients de s’enregistrer dynamiquement :

RT-SIEGE(config-if)#ip nhrp map multicast dynamic

Enfin, nous attribuons un identifiant unique à notre réseau DMVPN pour permettre la coexistence de plusieurs réseaux DMVPN sur le même routeur :

RT-SIEGE(config-if)#ip nhrp network-id 1

Configuration du Routeur RT-SUC1 [Spoke]

Nous commençons par créer l’interface réseau pour RT-SUC1 :

RT-SUC1(config)#interface tunnel 0
RT-SUC1(config-if)#ip address 10.0.0.2 255.255.255.0

Ensuite, nous indiquons la clé de sécurité pour rejoindre notre réseau de tunnel :

RT-SUC1(config-if)#ip nhrp authentication mdpdmvpn

Nous devons mapper notre spoke au Hub. En bref, on précisera l’adresse IP de l’interface tunnel du Hub ainsi que son adresse IP publique :

RT-SUC1(config-if)#ip nhrp map 10.0.0.1 192.0.0.1

Activons le multicast avec le Hub :

RT-SUC1(config-if)#ip nhrp map multicast 192.0.0.1

Nous spécifions l’identifiant du réseau DMVPN que notre spoke doit rejoindre :

RT-SUC1(config-if)#ip nhrp network-id 1

Ensuite, nous enregistrons notre spoke auprès du NHS du Hub :

RT-SUC1(config-if)#ip nhrp nhs 10.0.0.1

Nous associons notre interface tunnel à l’interface WAN du routeur RT-SUC1 :

bashCopier le codeRT-SUC1(config-if)#tunnel source gig 0/0

8. Indication de la Destination du Tunnel :
Enfin, nous indiquons l’autre extrémité de notre tunnel :

RT-SUC1(config-if)#tunnel destination 192.0.0.1

Pour vérifier que le tunnel est actif, vous pouvez utiliser la commande suivante :

RT-SUC1#show dmvpn

Cette commande montre que nous formons un réseau NBMA (Non-Broadcast Multi Access) avec l’adresse 192.0.0.1.

Afin de permettre la communication entre le LAN du siège et celui de la succursale 1, il est nécessaire de configurer les routes appropriées. Bien qu’il soit possible de créer des routes statiques, nous tirerons parti du support du multicast dans notre tunnel pour mettre en place un protocole de routage dynamique. Pour cela, nous utiliserons OSPF.

Configuration du Routage Dynamique avec OSPF

Nous configurons OSPF pour indiquer les adresses réseau du LAN et du tunnel :

RT-SIEGE(config)#router ospf 1
RT-SIEGE(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SIEGE(config-router)#network 192.168.0.0 0.0.0.255 area 0

Ensuite, nous limitons la découverte de voisinage OSPF à l’interface tunnel :

RT-SIEGE(config-router)#interface tunnel 0
RT-SIEGE(config-if)#ip ospf network broadcast

2. Configuration OSPF sur RT-SUC1 [Spoke] :
Nous suivons la même logique de configuration pour RT-SUC1 :

RT-SUC1(config)#router ospf 1
RT-SUC1(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SUC1(config-router)#network 192.168.1.0 0.0.0.255 area 0
RT-SUC1(config-router)#interface tunnel 0
RT-SUC1(config-if)#ip ospf network broadcast

Ensuite, nous veillons à ce que les spokes ne deviennent jamais DR ou BDR en fixant la priorité à 0 :

RT-SUC1(config)#interface tunnel 0
RT-SUC1(config-if)#ip ospf priority 0

Tentons maintenant d’envoyer une requête ICMP depuis le LAN du siège vers le LAN de la succursale 1.

Lorsque la requête est envoyée, elle déclenche l’ouverture du tunnel, qui se fermera une fois la requête terminée. Ainsi, les premières requêtes peuvent échouer le temps que le tunnel s’établisse.

Configuration du routeur RT-SUC2[Spoke]

La configuration de RT-SUC2 en tant que second spoke, se configurera de la même façon que RT-SUC1 (en vert les éléments qui diffère de RT-SUC1)

RT-SUC2(config)#interface tunnel 0
RT-SUC2(config-if)#ip address 10.0.0.3 255.255.255.0
RT-SUC2(config-if)#ip nhrp authentication mdpdmvpn
RT-SUC2(config-if)#ip nhrp map 10.0.0.1 192.0.0.1
RT-SUC2(config-if)#ip nhrp map multicast 192.0.0.1
RT-SUC2(config-if)#ip nhrp network-id 1
RT-SUC2(config-if)#ip nhrp nhs 10.0.0.1
RT-SUC2(config-if)#tunnel source gig 0/0
RT-SUC2(config-if)#tunnel destination 192.0.0.1
RT-SUC2(config-if)#router ospf 1
RT-SUC2(config-router)#network 10.0.0.0 0.0.0.255 area 0
RT-SUC2(config-router)#network 192.168.2.0 0.0.0.255 area 0
RT-SUC2(config-router)#interface tunnel 0
RT-SUC2(config-if)#ip ospf network broadcast
RT-SUC2(config-if)#ip ospf priority 0

Ensuite, envoyons une requête depuis le LAN de la succursale 2 vers le LAN du siège et le LAN de la succursale 1. Les premières requêtes peuvent échouer, car elles servent à activer le tunnel, mais une fois le tunnel établi, les communications se déroulent normalement.

Sécurisation du GRE avec IPsec

Nous avons vu plus tôt que GRE n’assure pas la confidentialité des données. Pour remédier à cela, nous allons encapsuler le GRE dans un tunnel IPsec. Cette stratégie doit être configurée sur les trois routeurs [RT-SIEGE ; RT-SUC1 ; RT-SUC2 ] de notre LAB :

ROUTER(config)#crypto isakmp policy 10
ROUTER(config-isakmp)#encryption aes
ROUTER(config-isakmp)#hash sha
ROUTER(config-isakmp)#authentication pre-share
ROUTER(config-isakmp)#group 14

Nous créons une clé partagée pour tous les routeurs de notre tunnel :

bashCopier le codeROUTER(config-isakmp)#crypto isakmp key clepartage address 0.0.0.0

3. Configuration du Transform-set :
Nous configurons ensuite le transform-set :

ROUTER(config)#crypto ipsec transform-set montransformset esp-aes esp-sha-hmac

Avec IPsec, comme nous l’avons vu dans l’article VPN IPSEC il existe deux modes : Tunnel et transport. Nous utilisons IPsec en mode transport pour chiffrer les données, tandis que le tunnel est monté par GRE :

ROUTER(config)#mode transport

Nous créons un profil IPsec dans lequel nous intégrons notre transform-set :

ROUTER(config)#crypto ipsec profile monprofile
ROUTER(ipsec-profile)#set transform-set montransformset

Enfin, nous appliquons ce profil à notre interface tunnel 0 :

ROUTER(ipsec-profile)#interface Tunnel 0
ROUTER(config-if)#tunnel protection ipsec profile monprofile

En capturant le trafic entre les sites, par exemple sur la liaison WAN de mon routeur, nous observerons que toutes les communications entre mes sites sont encapsulées dans le payload des paquets IPsec (ESP), rendant impossible la lecture des données.

L’article DMVPN est apparu en premier sur Pandawan.

Le VPN GRE utilise le protocole GRE pour créer des tunnels. Ce protocole encapsule tout type de paquet IP. Ensuite, il fait passer ces paquets encapsulés à travers un tunnel sur le WAN.

Le principal inconvénient du VPN GRE est l’absence de chiffrement. Les données ne sont pas protégées lorsqu’elles traversent le tunnel. De plus, le protocole ne nécessite aucune authentification entre les deux extrémités. En conséquence, il est risqué d’y faire transiter des informations sensibles.

Regardons cela dans la pratique avec GNS3 ! Pour ceux qui ne l’aurait pas encore installé, vous pouvez vous rendre sur le site IT-Connect où vous trouverez des articles vous expliquant les étapes à suivre.

Configuration VPN GRE

Pour la mise en pratique, nous partirons de la topologie suivante :

Configuration de base de notre LAB

Dans ce lab, nous utilisons le VLAN1 pour la configuration. Pour rappel, n’utilisez pas le VLAN1 en production. Pour plus de réalisme, nous configurerons le NAT. Cela permettra aux machines clientes d’accéder au WAN, représenté par les réseaux 192.0.0.0/30 et 192.0.0.4/30. Un routeur simulera le réseau internet. RT-ETS-1 sera le routeur de l’entreprise ETS1. RT-ETS-2 sera celui de l’entreprise ETS2.

Nous commencerons par configurer les interfaces des nos routeurs. Pour le routeur qui simulera Internet la configuration des interfaces sera la suivante :

Router#configure terminal
Router(config)#hostname INTERNET
INTERNET(config)#interface gig 0/0
INTERNET(config-if)#ip address 192.0.0.1 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/1
INTERNET(config-if)#ip address 192.0.0.5 255.255.255.252
INTERNET(config-if)#no shutdown

Pour le routeur de ETS1, nous configurerons le routeur de la façon suivante :

Router#configure terminal
Router(config)#hostname RT-ETS-1
RT-ETS-1(config)#interface gig 0/0
RT-ETS-1(config-if)#ip address 192.0.0.2 255.255.255.252
RT-ETS-1(config-if)#no shutdown
RT-ETS-1(config-if)#interface gig 0/1
RT-ETS-1(config-if)#ip address 192.168.0.254 255.255.255.0
RT-ETS-1(config-if)#no shutdown

Et nous terminerons la configuration des interfaces sur le routeur de ETS2 en exécutant les commandes suivante :

Router#configure terminal
Router(config)#hostname RT-ETS-2
RT-ETS-2(config)#interface gig 0/0
RT-ETS-2(config-if)#ip address 192.0.0.6 255.255.255.252
RT-ETS-2(config-if)#no shutdown
RT-ETS-2(config-if)#interface gig 0/1
RT-ETS-2(config-if)#ip address 192.168.1.254 255.255.255.0
RT-ETS-2(config-if)#no shutdown

Ensuite, nous configurerons les routes par défaut sur RT-ETS-1 et sur RT-ETS-2

RT-ETS-1(config-if)#ip route 0.0.0.0 0.0.0.0 gig0/0

RT-ETS-2(config-if)#ip route 0.0.0.0 0.0.0.0 gig0/0

Vérifions que RT-ETS-1 peut communiquer avec RT-ETS-2 et que RT-ETS-2 peut communiquer avec RT-ETS-1 sur les interface connecter au routeur qui simule Internet.

Une fois que cette vérification a été faite, nous testerons que nos machines de nos LAN puissent communiquer avec leurs passerelles. Pour cela, nous attribuerons une adresse IP au client de notre LAN. Ensuite, nous enverrons une requêtes ICMP depuis le client vers l’interface du routeur côté LAN.

Ensuite nous configurerons le NAT sur RT-ETS-1

RT-ETS-1(config)#interface gig 0/0
RT-ETS-1(config-if)#ip nat outside
RT-ETS-1(config-if)#interface gig 0/1
RT-ETS-1(config-if)#ip nat inside
RT-ETS-1(config-if)#exit
RT-ETS-1(config)#access-list 1 permit 192.168.0.0 0.0.0.255
RT-ETS-1(config)#ip nat inside source list 1 interface gig 0/0 overload

Puis sur RT-ETS-2

RT-ETS-2(config)#interface gig 0/0
RT-ETS-2(config-if)#ip nat outside
RT-ETS-2(config-if)#interface gig 0/1
RT-ETS-2(config-if)#ip nat inside
RT-ETS-2(config-if)#exit
RT-ETS-2(config)#access-list 1 permit 192.168.1.0 0.0.0.255
RT-ETS-2(config)#ip nat inside source list 1 interface gig 0/0 overload

Avant d’aller plus loin, testons la configuration de la translation d’adresse.

Notre infrastructure pour nos LAB est maintenant terminé ! Dans le chapitre suivant, nous passerons à la configuration de notre VPN GRE.

Configuration du GRE

Avant de passer à la configuration, il est crucial de bien comprendre le concept de tunnel. Nous allons prendre un instant pour expliquer certaines choses. Un tunnel possède deux extrémités, qui sont des interfaces, plus spécifiquement des interfaces connecté à Internet. C’est par ce tunnel que font passer les flux. Ses flux transiterons dans un réseau dédié à cela. Reprenons la partie Internet de notre LAB.

Pour que le paquet IP puisse arrivée à destination, le paquet sera encapsulé dans un paquet GRE.

A gauche de ma flèche, nous sommes sur l’interface connecté à Internet de RT-ETS-1 et à droite de la flèche, nous somme sur l’interface RT-ETS-2 de RT-ETS-2 par exemple.

Une fois le paquet IP encapsulé, il pourra passer dans le tunnel GRE. Une fois que le paquet GRE sort du tunnel, il est dans le LAN « partenaire » et le paquet pourra être désencapsuler. Le paquet pourra être traiter.

Comme nous avons vu les choses de façon théorique, maintenant passons à la pratique, c’est à dire à la configuration.

Configuration du tunnel GRE côté ETS-1

Tout d’abord, concentrons-nous sur le routeur RT-ETS-1, qui est une extrémité du tunnel. Par conséquent, nous créerons une interface « tunnel ».

RT-ETS-1(config)#interface tunnel1

Comme une interface tunnel est finalement une interface logique, nous devons l’associer à une interface physique pour assurer le transit des paquets à travers le réseau.

RT-ETS-1(config-if)#tunnel source gig 0/0

Ensuite, Nous allons attribuer une adresse IP à l’interface tunnel1. Par conséquent, cette adresse IP sera l’entrée du tunnel de l’entreprise ETS1.

RT-ETS-1(config-if)#ip address 10.0.0.1 255.255.255.252

Aussi, nous indiquerons la destination, c’est-à-dire l’autre extrémité du tunnel, définie par l’adresse WAN du ‘partenaire’, donc l’adresse IP publique de RT-ETS-2.

RT-ETS-1(config-if)#tunnel destination 192.0.0.6

Pour finir, nous allons créer une route indiquant au routeur que, pour atteindre le réseau 192.168.1.0, qui est le LAN de l’entreprise ETS2, il doit passer par l’interface tunnel1.

RT-ETS-1(config)#ip route 192.168.1.0 255.255.255.0 tunnel1

L’extrémité RT-ETS-1 est maintenant terminé.

Configuration du tunnel GRE côté ETS-2

Pour terminer la création de notre tunnel, nous allons faire une configuration miroir de RT-ETS-1 sur RT-ETS-2.

RT-ETS-2(config)#interface tunnel1
RT-ETS-2(config-if)#tunnel source gig 0/0
RT-ETS-2(config-if)#ip address 10.0.0.2 255.255.255.252
RT-ETS-2(config-if)#tunnel destination 192.0.0.2
RT-ETS-2(config-if)#ip route 192.168.0.0 255.255.255.0 tunnel1

Test du tunnel VPN GRE

Testons maintenant notre configuration en utilisant la commande « PING » depuis les machines du LAN. le LAN de ETS-1 doit pouvoir communiquer avec ETS-2 et l’inverse doit être également possible.

En sniffant le réseau en utilisant Wireshark à la sortie de RT-ETS-1, nous voyons qu’une couche GRE a été ajouter.

Nous pouvons notamment voir que le message ICMP est en clair. Pour chiffre la communication, il nous faudra passer par le framework IPSEC. En effet, nous regarderons cela dans un prochaine article qui traitera du VPN IPSEC.

L’article VPN GRE [ Generic Routing Protocol] est apparu en premier sur Pandawan.

Dans cette situation, une question se pose : quelle sera l’adresse IP de la passerelle ? Est-ce que notre passerelle sera l’adresse IP du côté LAN du FAI1 ou du FAI2 ? En effet, en cas de défaillance de l’un des deux FAI (ou routeurs), il serait trop laborieux de passer sur chaque machine du parc informatique pour modifier les passerelles, sans parler de la reconfiguration de l’adresse de passerelle dans le serveur DHCP. Ce travail serait beaucoup trop fastidieux.

L’idée générale est d’avoir une adresse IP qui redirige le trafic vers un routeur fonctionnel. Cette adresse IP est appelée adresse IP virtuelle, ou VIP (Virtual IP), et c’est cette adresse qui sera notre passerelle.

Il existe trois protocoles qui permettent de mettre en place ce type de dispositif :

• HSRP (Hot Standby Router Protocol) – Propriétaire Cisco
• VRRP (Virtual Router Redundancy Protocol) – Standard
• GLBP (Gateway Load Balancing Protocol) – Propriétaire Cisco
  

Les deux premiers protocoles, HSRP et VRRP, fonctionnent de manière similaire. On désigne un routeur passif et un routeur actif. Lorsque le routeur ou la liaison Internet du routeur actif n’est plus disponible, le routeur passif prend le relais et devient le routeur actif.

Le GLBP, quant à lui, fonctionne en mode actif/actif. Cette méthode permet de répartir le trafic de manière équitable sur plusieurs routeurs.

Le protocole HSRP

Lorsque la décision de router un paquet est prise dans un LAN, la trame est envoyée au routeur via son adresse MAC. Pour connaître l’adresse MAC de la passerelle, la machine s’appuie sur le protocole ARP, qui permet d’associer une adresse MAC à une adresse IP. Ainsi, en HSRP, la création d’une IP virtuelle génère également une adresse MAC.

Pour HSRP dans sa première version, l’adresse MAC sera 00:00:0C:07 :XX, les XX étant remplacés par l’identifiant du groupe. En effet, dans un réseau LAN, il peut être nécessaire de configurer plusieurs passerelles, notamment lorsqu’on subdivise le LAN en plusieurs VLAN. Chaque VLAN aura sa propre passerelle. Dans cette version, il peut y avoir jusqu’à 0xFF (0x indiquant une valeur en hexadécimal), soit 255 en décimal, ce qui permet de créer jusqu’à 256 groupes (de 0 à 255).

Dans la version 2 du protocole HSRP, l’adresse MAC utilisée sera 00:00:0C:9F:FX :XX , les XX étant également remplacés par le numéro du groupe. Ici, il est possible d’avoir jusqu’à 0xFFF groupes, soit 4095 en décimal, offrant ainsi la possibilité de créer 4096 groupes.

Une autre différence entre les deux versions réside dans l’adresse multicast. Pour connaître l’état des routeurs composant le groupe, des messages « HELLO » sont envoyés sur leur adresse multicast.

Le routeur actif sera considéré comme défaillant après 3 messages Hello manqués plus 1 seconde sans réponse, soit un total de 10 secondes. Le routeur en mode veille (standby) deviendra alors le routeur actif, et le routeur en mode écoute (listen) passera en mode passive.

Les priorités

Dans le chapitre précédent, nous avons vu que différents statuts sont attribués à nos routeurs :

• Un routeur aura le statut Actif.
• Un routeur aura le statut Passif (Standby)
• Les autres routeurs du groupe auront le statut Écoute (Listen).
  

Ces statuts sont associés à des priorités. Le routeur avec la priorité la plus élevée sera en statut Actif. Par défaut, lorsque nous activons le protocole HSRP, la priorité est fixée à 100, et elle peut varier de 0 à 255. Par conséquent, par défaut, les priorités sont égales. Le protocole HSRP utilise donc un autre critère pour départager les priorités : l’adresse IP. Le routeur avec l’adresse IP la plus élevée du groupe se verra attribuer le statut Actif.

La configuration du protocole HSRP

Nous avons vu la théorie, regardons maintenant en pratique ce que cela donne. Ce protocole peut être configuré sur un équipement de niveau 3, c’est-à-dire un switch de niveau 3 ou un routeur. Pour ce laboratoire, nous utiliserons un routeur. Cette maquette sera réalisée sur GNS3, mais elle est également réalisable sur Packet Tracer.

Commençons par configurer les routeurs

Configuration d’un nom et d’une IP sur :

FAI1

Router#configure terminal
Router(config)#hostname FAI1
FAI1(config)#interface gig 0/0
FAI1(config-if)#ip address 192.168.1.253 255.255.255.0
FAI1(config-if)#no shutdown

FAI2

Router#configure terminal
Router(config)#hostname FAI2
FAI2(config)#interface gig 0/0
FAI2(config-if)#ip address 192.168.1.252 255.255.255.0 
FAI2(config-if)#no shutdown 

FAI3

Router#configure terminal
Router(config)#hostname FAI3
FAI3(config)#interface gig 0/0 
FAI3(config-if)#ip address 192.168.1.251 255.255.255.0 
FAI3(config-if)#no shutdown 

Après avoir configure le réseau du PC, nous pouvons tester la connectivité entre les PC et les 3 Routeurs.

Dans l’illustration « -c 1 » indique que nous souhaitons envoyer une seule requête ICMP.

Nous allons maintenant configurer le protocole HSRP sur les 3 routeurs.

Configuration HSRP sur FAI1

L’interface HSRP se configure sur des interfaces. Nous devons nous rendre sur l’interface G0/0, puis nous allons créer notre premier groupe HSRP, nous allons également indiquer l’adresse de notre IP virtuelle.

FAI1(config)#interface gig 0/0
FAI1(config-if)#standby 1 ip 192.168.1.254

Nous exécuterons également cette configuration sur FAI2 et sur FAI 3

Configuration HSRP sur FAI2

FAI2(config)#interface gig 0/0
FAI2(config-if)#standby 1 ip 192.168.1.254

Configuration HSRP sur FAI3

FAI3(config)#interface gig 0/0
FAI3(config-if)#standby 1 ip 192.168.1.254

L’IP virtuelle que nous avons configuré est maintenant joignable depuis mon PC.

En affichant la table ARP de mes routeurs, nous pouvons vois que l’adresse MAC de notre adresse IP virtuelle est 00:00:00:07:AC:01

  FAI1#show ip arp

Nous pouvons en déduire que par défaut la version du protocole HSRP est la version 1.Passons là en version 2, cette version prend en charge IPv6. De plus, la version 1 du protocole HSRP rentre en conflit CGMP (Cisco Group Management Protocol) de CISCO du fait qu’il utilise la même adresse de broadcast.

Changegement de la version sur FAI1

FAI1(config)#interface gig 0/0
FAI1(config-if)#standby version 2

Modification de la version sur FAI2

FAI2(config)#interface gig 0/0
FAI2(config-if)#standby  version 2

Modification de la version sur FAI3

FAI3(config)#interface gig 0/0
FAI3(config-if)#standby version 2

En consultant une nouvelle fois notre table ARP, nous pouvons voir que l’adresse MAC de notre adresse IP virtuelle a bien été modifié.

  FAI1#show ip arp

Il existe une façon plus simple de voir la version est plus généralement la configuration du protocole HSRP, il nous suffit d’exécuter la commande suivante :

  FAI1#show standby

Dans cette capture d’écran, nous avons un peu plus d’information, nous avons en effet la version.

Nous pouvons également voir qu’elle est le routeur Active et qu’elle est le routeur mise en standby et aussi la priorité. Ici la priorité n’a pas été modifié c’est donc la valeur par défaut.

Le routeur FAI est le retour active, non pas parce que sa priorité est la plus élevé, mais parce que son adresse IP est la plus élevé.

Modifions l’adresse IP pour avoir une adresse mois élevé que les deux autres par exemple l’adresse 192.168.1.250/24.Nous éteindrons puis rallumons l’interface pour que le protocole HSRP prenne en compte cette nouvelle adresse.

FAI1#configure terminal
FAI1(config)#interface gig 0/0
FAI1(config-if)#ip address 192.168.1.250 255.255.255.0
FAI1(config-if)#shutdown
FAI1(config-if)#no shustdown

Consultons maintenant la configuration du protocole HSRP.

Si nous souhaitons que FAI1 reste le routeur Active, nous pouvons modifier la priorité, par exemple, une priorité de 150.

FAI1#configure terminal
FAI1(config)#interface gig 0/0
FAI1(config-if)#standby 1 priority 150

Regardons maintenant si notre routeur FAI1 est bien notre routeur Active.

On peut voir à travers cette capture d’écran que cela n’a pas marché. Ce n’est pas une erreur de notre part, cela est dû au fait que pour qu’il y ait un changement de statut, il faudrait que FAI2, ne réponds plus pendant 10 secondes aux messages Hello. Ici notre routeur FAI2 est fonctionnel, et il n’a pas de raison de changer d’état.

Si nous voulons que cela soit toujours le routeur qui a la priorité la plus élevé qui soit notre routeur active, il faut l’indiquer en activant l’option préemption. Cette configuration sera à faire sur tous les routeurs

FAI1(config)#interface gig 0/0
FAI1(config-if)#standby 1 preempt

FAI2(config)#interface gig 0/0
FAI2(config-if)#standby 1 preempt

FAI3(config)#interface gig 0/0
FAI3(config-if)#standby 1 preempt

Nous allons aussi tester que la haute disponibilité de nos passerelles fonctionne correctement. Lançons des requêtes ICMP en continue depuis notre PC sur l’adresse de l’IP virtuelle.

  PC1> ping 192.168.1.254 -t

Eteignons l’interface gig 0/0 du routeur FAI1.

Nous avons bien une continuité de service même si nous avons perdu une requête, ce qui est acceptable.

Nous pouvons voir dans la configuration du protocole HSRP, que FAI2 a pris le relais de FAI1 en passant en actif et que FAI2 à laisser sa place de standby à FAI3.

L’article Haute disponibilité des PASSERELLES avec le protocole HSRP est apparu en premier sur Pandawan.

Introduction à la QoS

Les routeurs se trouvent généralement à la périphérie du WAN, avec à la fois des interfaces WAN et des interfaces LAN. Ces interfaces LAN fonctionnent généralement à des vitesses beaucoup plus rapides que les interfaces WAN. Lorsque l’interface WAN plus lente est occupée à envoyer les paquets en attente dans le routeur, des centaines, voire des milliers de paquets IP supplémentaires pourraient arriver dans les interfaces LAN, tous devant être transférés vers cette même interface WAN. Que doit faire le routeur ? Les envoyer tous, dans le même ordre dans lequel ils sont arrivés? Prioriser les paquets, en envoyer certains plus tôt que d’autres, préférer un type de trafic à un autre? Supprimer certains des paquets lorsque le nombre de paquets en attente de sortie du routeur devient trop important? Le routeur pourrait mettre en file d’attente les paquets en attendant que l’interface WAN soit disponible, il pourrait également utiliser un algorithme de planification de file d’attente pour déterminer quels paquets doivent être envoyés en premier, en utilisant un autre ordre que l’ordre d’arrivée – donnant à certains paquets une meilleur  qualité de service.

Cisco propose une large gamme d’outils QoS sur les routeurs et les commutateurs. Tous ces outils vous donnent les moyens de gérer quatre caractéristiques du trafic réseau:

• Bande passante
• Retard
• Gigue
• Perte

La bande passante fait référence à la vitesse d’un lien, en bits par seconde (bps). Mais si nous considérons la bande passante comme une vitesse, il est utile de penser également à la bande passante comme la capacité du lien, en termes de nombre de bits pouvant être envoyés sur le lien par seconde. Les outils QoS du périphérique réseau déterminent quel paquet est l’ordre des paquets envoyé sur la liaison, de sorte que le périphérique réseau contrôle quels messages utilise la bande passante et quelle part de cette bande passante (capacité) est alloué aux types de trafic. Prenons l’exemple d’un routeur qui a des centaines de paquets en attente. Un administrateur réseau peut configurer un outil de mise en file d’attente pour réserver 10% de la bande passante pour le trafic vocal, 50% pour les applications de données critiques, et laisser le reste de la bande passante pour tous les autres types de trafic.

Le retard peut être décrit comme un retard unidirectionnel ou un retard bidirectionnel. Le délai unidirectionnel fait référence au temps entre l’envoi d’un paquet et l’arrivée de ce même paquet à l’hôte de destination. Le délai bidirectionnel compte le délai unidirectionnel plus le temps nécessaire au récepteur du premier paquet de renvoyer un paquet – en d’autres termes, le temps nécessaire pour envoyer un paquet entre deux hôtes et en recevoir un. De nombreuses actions individuelles différentes peuvent avoir un impact sur le retard.La gigue fait référence à la variation du délai unidirectionnel entre des paquets envoyés consécutivement par la même application. Par exemple, imaginons qu’une application envoie quelques centaines de paquets à un hôte particulier. Le délai unidirectionnel du premier paquet est de 300 millisecondes (300 ms ou 0,3 seconde). Le délai unidirectionnel du paquet suivant est de 300 ms; il en va de même pour le troisième; etc. Dans ce cas, il n’y a pas de gigue. Cependant, si à la place le premier paquet a un retard unidirectionnel de 300 ms, le suivant a un retard unidirectionnel de 310 ms, et le suivant a 325 ms, alors il y a une certaine variation dans le retard; 10 ms entre les paquets 1 et 2, et 15 ms supplémentaires entre les paquets 2 et 3. Cette différence est appelée gigue.

Type de trafic

La raison qui peut amener un administrateur réseau de prioriser des flux dans un réseau peut être de plusieurs nature. La première des raisons peut être motivé par l’architecture de l’infrastructure informatique. En effet, si les applications critiques de l’entreprise se trouve dans un sous réseau spécifique, l’administrateur réseau peut prendre la décision de prioriser les flux d’entrée / sortie de ce réseau. Dans d’autres cas, le choix de la façon d’appliquer les outils QoS est lié à la nature des différents types d’applications. Certaines applications ont des besoins QoS différents des autres.

Applications de données

Tout d’abord, considérons une application Web de base, avec un utilisateur sur un PC ou une tablette. L’utilisateur saisit un URI pour demander une page Web. Cette demande peut nécessiter qu’un seul paquet soit envoyé au serveur Web, mais elle peut générer le retour de centaines ou de milliers de paquets vers le client Web.

Alors, quel est l’impact de la bande passante, du retard, de la gigue et de la perte sur une application Web interactive? Premièrement, les paquets nécessitent une certaine capacité de bande passante. En ce qui concerne le retard, chacun de ces paquets du serveur au client prend une certaine quantité de retard unidirectionnel, avec également une certaine gigue. La logique TCP du serveur sera de retransmettre les données perdues, ce qui fera que certaines parties de la page Web risquent de ne pas s’afficher immédiatement.

Alors que les outils QoS se concentrent sur la gestion de la bande passante, du retard, de la gigue et de la perte, l’utilisateur se soucie principalement de la qualité de l’expérience globale. Par exemple, avec une application Web, combien de temps après avoir cliqué voyez-vous quelque chose d’utile dans votre navigateur Web? Ainsi, en tant qu’utilisateur, vous vous souciez de la qualité d’expérience (QoE), qui est un terme faisant référence à la perception des utilisateurs de leur utilisation de l’application sur le réseau. Les outils QoS ont un impact direct sur la bande passante, le retard, la gigue et la perte, ce qui devrait alors avoir un effet globalement positif pour influencer la QoE des utilisateurs. Et vous pouvez utiliser les outils QoS pour créer une meilleure QoE pour un trafic plus important; par exemple, vous pouvez donner à certaines applications critiques pour l’entreprise un meilleur traitement QoS, ce qui améliore la QoE pour les utilisateurs de ces applications.

En revanche, une application de données non interactive (historiquement appelée trafic par lots) – par exemple, la sauvegarde de données ou les transferts de fichiers – a des exigences de QoS différentes de celles des applications de données interactives. Les applications par lots envoient généralement plus de données que les applications interactives, mais comme personne n’est assis là à attendre de voir quelque chose apparaître à l’écran, le retard et la gigue n’ont pas beaucoup d’importance. Il est beaucoup plus important pour ces applications de répondre au besoin d’accomplir la tâche plus importante (transfert de fichiers) dans un laps de temps plus large. Les outils QoS peuvent être utilisés pour fournir une bande passante suffisante pour répondre aux besoins de capacité de ces applications et gérer les pertes pour réduire le nombre de retransmissions.

Flux vidéo et voix

Les flux vidéo et la voix s’appuie sur le protocole UDP, qui, comme nous l’avons plus tôt est un protocole pour utiliser pour la priorisation des flux, il n’y aura donc pas de correction d’erreur ce qui peut, potentiellement générer des pertes de paquet.

Pour rappel, l’utilisation des flux vidéo et voix s’appuie sur l’utilisation d’un codec, ce qui revient à traiter l’information avant sont utilisation et qui aura un impact sur le délai de retransmission et sur la gigue. En effet,

Si nous ne prioriserons pas les flux vidéo et voix la QoE sera très largement impacté lorsque nous utilisons ce type de flux. Une vidéo sera de moins bonne qualité, ce qui entrainera une insatisfaction utilisateur, il en va de même si un échange téléphonique devient inaudible. Il devient donc logique d’attribuer une priorisation en utilisant les outils QoS fournit par les équipements réseaux

Outils QoS

Les outils QoS ce compte au nombre des quatre :

• «Classification et marquage» concerne le marquage des paquets et la définition des limites de confiance.
• « La mise en file d’attente » décrit la planification des paquets pour donner à un type de paquet la priorité sur un autre.
• « Stratégie et formatage » sont utilisés aux extrémités opposées d’un lien.
• « La prévention de la congestion » explique comment gérer la perte de paquets qui se produit lorsque les périphériques réseau sont trop occupés
  

Classification et marquage

Le premier outil QoS discuté dans ce chapitre, la classification et le marquage, ou simplement le marquage, fait référence à un type d’outil QoS qui classe les paquets en fonction de leur contenu d’en-tête, puis marque le message en modifiant certains bits dans des champs d’en-tête spécifiques.

Principes de base de la classification

Les outils QoS s’inscrivent dans le chemin emprunté par les paquets lorsqu’ils sont transmis via un routeur ou un commutateur, tout comme le positionnement des ACL. Comme les ACL, les outils QoS sont activés sur une interface. Tout comme les ACL, les outils QoS sont activés pour une direction: les paquets entrant dans l’interface(avant la décision de transfert) ou pour les messages sortant de l’interface (après la décision de transfert).

Le terme classification fait référence au processus de mise en correspondance des champs dans un message pour faire le choix de prendre une action QoS. Donc, encore une fois en comparant les outils QoS aux ACL, les ACL effectuent la classification et le filtrage; c’est-à-dire que les ACL correspondent (classifient) les en-têtes de paquets. Les ACL peuvent avoir pour but (action) de choisir les paquets à rejeter. Les outils QoS effectuent une classification (mise en correspondance des champs d’en-tête) pour décider sur quels paquets effectuer certaines actions QoS. Ses actions pourront être :

• Mise en attente
• Stratégie et formatage
• Prévention de la congestion
  

Les commutateurs et les routeurs ont la capacité de créer un marquage qui sera ensuite utilisé pour classifier le paquet. Le marquage peut d’effectuer en entrée ou en sortant de vos équipements réseau. Selon la complexité de la classification, cela peut prendre du temps et des ressources matériels qui pourrait engendrer une dégradation de service de vos réseaux. Il est donc recommandé de marque les paquets dès la conception de son entrée dans le réseau.

Marquage de l’en-tête IP

Le marquage d’un champ QoS dans l’en-tête IP fonctionne bien avec QoS car l’en-tête IP existe pour tout le chemin de l’hôte source à l’hôte de destination. Lorsqu’un hôte envoie des données, l’hôte envoie une trame de liaison de données qui encapsule un paquet IP. Chaque routeur qui transmet le paquet IP rejette l’ancien en-tête de liaison de données et ajoute un nouvel en-tête. Étant donné que les routeurs ne suppriment pas et ne réinsèrent pas les en-têtes IP, les champs de marquage dans l’en-tête IP restent avec les données du premier endroit où ils sont marqués jusqu’à ce qu’ils atteignent l’hôte de destination.

IPv4 définit un octet de type de service (ToS) dans l’en-tête IPv4. La RFC d’origine définissait un champ IP Precedence (IPP) 3 bits pour le marquage QoS. Ce champ nous a donné huit valeurs de 000 à 111 soit en décimale de 0 à 7.

Le concept est encore valable aujourd’hui même si le terme IPP n’est plus utilisé et qu’il a été remplacé par le DSCP qui est un concept introduit dans la RFC 2474. Le DSCP va permettre de faire de la différentiation de service (Diffserv) et par conséquent permettre de classifier le trafic en fonction du service (VOIP, Video, etc). Le champs DSCP pèse 6 octets ce qui nous permet d’avoir 64 valeurs distant.

Marquage de l’en-tête Ethernet 802.1Q

Un autre champ de marquage utile existe dans l’en-tête 802.1Q, dans un champ initialement défini par la norme IEEE 802.1p. Ce champ se trouve dans le troisième octet de l’en-tête 802.1Q de 4 octets, sous la forme d’un champ de 3 bits, fournissant huit valeurs possibles à marquer Il porte deux noms différents : Classe de service ou CoS, et Point de code prioritaire, ou PCP.

Bon à savoir

La champs CoS pourra être utilisé exclusivement sur les liaisons « trunké »

Zone de confiance de marquage DSCP

Le périphérique de l’utilisateur final peut marquer le champ DSCP et même le champ CoS si le trunk est utilisée sur la liaison. En tant qu’administrateur réseau, feriez-vous confiance à ces paramètres par défaut et laisser vos périphériques réseau faire confiance et réagir à ces marquages pour leurs différentes actions QoS?

La plupart d’entre nous ne le feraient pas du fait qu’un utilisateur pourrait avoir la possibilité de modifier le marquage DSCP de son poste client en indiquant par exemple un marquage DSCP 46 qui correspond à une marque dédiée au donnée voix.

Lorsque nous créons un plan de qualité de service, il faudra définir qu’elle DSCP sera de confiance. Par exemple en excluant les PC des utilisateurs. En revanche le téléphone IP sera généralement la limite de confiance.

Les valeurs de marquage suggéré par DiffServ

Les valeurs DSCP sont indiqué dans des RFC, ce qui permet aux constructeurs de l’implémenter directement dans les équipements. Ainsi lorsque sur vous brancherez un téléphone, il sera marqué par une valeur DSCP adéquate pour classifier les flux comme des flux voix. Les DSCP est caractérisé par 3 éléments :

• Transfère accélérer
• Expédition assurer
• Sélecteur de classe
  

Transfère accélérer

DiffServ définit la valeur DSCP transfère accélérer ou Expedited Forwarding (EF) qui est une valeur unique qui est suggéré pour une utilisation pour les paquets qui nécessitent une faible latence (retard), une faible gigue et une faible perte. La RFC Expedited Forwarding (RFC 3246) définit la valeur DSCP spécifique (décimal 46) et un nom explicite (Expedited Forwarding). Les commandes de configuration QoS permettent l’utilisation de la valeur décimale ou du nom de texte. Pour une facilité de mémorisation, l’utilisation de l’acronyme EF sera utilisé.

Le plus souvent, les plans QoS utilisent EF pour marquer les paquets de charge utile vocale. Avec les appels vocaux, certains paquets transportent des données voix et d’autres paquets transportent des messages de signalisation d’appel. Les messages de signalisation d’appel configurent (créent) l’appel vocal entre deux appareils et ne nécessitent pas de faible délai, gigue et perte. Les paquets transportant les données voix ont besoin d’une meilleure qualité de service. Par défaut, les téléphones IP Cisco marquent la charge utile vocale avec EF et marquent les paquets de signalisation vocale envoyés par le téléphone avec une autre valeur appelé CS3.

Expédition assurer

Le DiffServ RFC (2597) Assured Forwarding (AF) définit un ensemble de 12 valeurs DSCP destinées à être utilisées de concert les unes avec les autres. Premièrement, il définit le concept de quatre files d’attente distinctes dans un système de file d’attente. Ensuite, il définit trois niveaux de priorité de dépôt dans chaque file d’attente à utiliser avec les outils d’évitement de congestion.

Avec quatre files d’attente et trois classes de priorité de suppression par file d’attente, vous avez besoin de 12 marquages DSCP différent.

Les noms DSCP suivent un format AFXY, X faisant référence à la file d’attente (1 à 4) et Y faisant référence à la priorité de suppression (1 à 3).

Par exemple, si nous marquons les paquets avec les 12 valeurs, ceux avec AF11, AF12 et AF13 iraient tous dans la file d’attente A; ceux avec AF21, AF22 et AF23 entreraient dans la file d’attente B, etc… Dans la file d’attente avec tout le trafic AF2y, vous traiteriez les AF21, AF22 et AF23 chacun différemment en ce qui concerne les actions de suppression (évitement de la congestion), AF21 obtenant le traitement préféré à AF23.

Sélecteur de classe

À l’origine, l’octet ToS était défini avec un champ IP Precedence (IPP) de 3 bits. Lorsque DiffServ a redéfini l’octet ToS, il était logique de créer huit valeurs DSCP pour une compatibilité descendante avec les valeurs IPP. Les valeurs DSCP du sélecteur de classe (CS) sont ces paramètres. Fondamentalement, les valeurs DSCP ont les mêmes 3 premiers bits que le champ IPP, et avec des 0 binaires pour les 3 derniers bits, comme indiqué sur le côté gauche de la figure. CSx représente les noms de texte, où x est la valeur IPP correspondante (0 à 7).

Exemple de plan de QoS

DSCP EF: voix

AF4x: vidéo interactive (par exemple, vidéoconférence)

AF3x: vidéo en streaming

AF2x: données à haute priorité (faible latence)

CS0: données standard

Les files d’attentes

Tous les périphériques réseau utilisent des files d’attente. Les périphériques réseau reçoivent des messages, prennent une décision de transfert, puis envoient le message, mais parfois l’interface sortante est occupée. Ainsi, l’appareil garde le message sortant dans une file d’attente, en attendant que l’interface sortante soit disponible.

Le terme mise en file d’attente fait référence à l’ensemble d’outils QoS pour gérer les files d’attente qui contiennent des paquets pendant qu’ils attendent leur tour pour quitter une interface. Dans un routeur, lorsque les paquets sont en file d’attente, le routeur peut être amené à faire des actions sur ce dernier, c’est le cas lorsque que nous avons configurer le NAT ou les ACL où là il y a eu un traitement du paquet. Dans ce cas, la file d’attente n’est pas seulement un sasse d’attente où chaque paquet attends passivement son tour.

Un équipement réseau, comme nous l’avons vu plus tôt peut avoir plusieurs files d’attente. Nous allons donc avoir besoin d’un ordonnanceur pour hiérarchiser et prioriser les files d’attentes.

Ordonnancement Round-Robin

Un des algorithmes utilisé par les routeurs et commutateur CISCO utilise une logique circulaire. Dans sa fonction le plus simple, le round robin parcours les files d’attentes dans l’ordre. Sur chaque file d’attente, il laissera passer un certain nombre de paquet. Le nombre de paquet peut être pondéré. Pour la mise en place de cette pondération, le round-robin va s’appuyer sur un élèment clé des équipement réseau appelé le Class-Based Weighted Fair Queuing (CBWFQ) qui permet d’allouer un minimum de bande passante par classe. C’est en fait la valeur du CBWFQ qui va être pondéré avec un pourcentage.

File d’attente à faible latence

L’ordonnancement à bien des qualités mais il peut poser un problème. En effet, en nous appuyons sur le schéma précédent, imaginons qu’un utilisateur souhaite passer un appel téléphonique juste après que l’ordonnancement à fini de traiter la file d’attente des paquets voix, l’utilisateur devra attendre que l’ordonnanceur Round Robin termine de traiter la file d’attente Vidéo et Data, ce qui entrainera un latence et augmentera la gigue (pour information la téléphonie nécessite une gigue inférieur à 30 ms).

Pour pallier cela, nous nous appuierons sur la technologie de la file d’attente à faible latence, plus souvent appelé LLQ (Low Latence Queuing). Cette technologie permettra de marquer des paquets en flux prioritaire et ne sera pas concerné par l’ordonnanceur.

Là aussi nous avons un problème, en effet imaginons que la file d’attente voix dans l’illustration précédente ait toujours du flux en continu, cela ne laissera pas de place pour les autres flux. Nous devrons donc mettre en place une stratégie de gestion des flux. Nous verrons ce point dans le chapitre suivant.

Stratégie et formatage

La régulation et la mise en forme surveillent le débit binaire des messages combinés qui transitent par un périphérique. Une fois activé, le régulateur ou le shaper (pour le formatage) note chaque paquet qui passe et mesure le nombre de bits par seconde au fil du temps. Les deux tentent de maintenir le débit binaire à ou en dessous de la vitesse configurée, mais en utilisant deux actions différentes: les régulateurs rejettent les paquets et les shaper maintiennent les paquets dans des files d’attente pour retarder les paquets.

Les shaper et les régulateurs surveillent le débit de trafic (les bits par seconde qui se déplacent dans le shaper ou le régulateur) par rapport à un débit de mise en forme ou à un taux de régulation.

Evitement de la congestion

La fonctionnalités évitement de la congestion s’appuient sur les segments TCP. Pour rappel, le protocole TCP, permet de faire de la correction, c’est-à-dire, de récupérer les paquets perdus. En prenant en considération, cette particularité du protocole TCP, un paquet pourra être supprimé de sa file d’attente pour libérer de la place et pourra être redemander par le biais du protocole TCP.

Le faites de supprimer des paquets de la file d’attentes permettra d’éviter de la congestion, c’est à dires des « embouteillage » de données. Ainsi nous pourrons définir que nous ne devons pas dépasser un taux de remplissage de la file d’attente.

Mise en place d’une QoS

Pour la mise en place de ce lab, nous utiliserons Cisco Packet Tracer, ce qui nous évitera de déployer des outils de téléphonie sur IP ou encore de la vidéo par IP.

Dans ce schéma, nous avons 3 Vlan distinct, un vlan voix, vidéo et données. Nous pouvons voir que le commutateur SW1 est un point de congestion. Comme pour un carrefour routier, nous allons y intégrer des règles. Le vlan voix sera paramétré avec le LLQ, le vlan vidéo et données par le biais du CBWFQ en réservant 60 % de la bande passante pour la vidéo et 40 % pour la donnée. Nous créerons 2 files d’attentes et nous laisserons le vlan data avec la configuration par défaut.

Configuration du LAB

Sur le commutateur, seul les VLAN sont créés et les ports configurés soit la configuration suivante.

Switch>enable
Switch#configure terminal 
Switch(config)#hostname SW1 
SW1(config)#vlan 2 
SW1(config-vlan)#name VOIX 
SW1(config-vlan)#vlan 3 
SW1(config-vlan)#name VIDEO 
SW1(config-vlan)#vlan 4 
SW1(config-vlan)#name DATA 
SW1(config-vlan)#interface range gig 1/0/1-2 
SW1(config-if-range)#switchport mode access 
SW1(config-if-range)#switchport voice vlan 2 
SW1(config-if-range)#interface range gig 1/0/3-4 
SW1(config-if-range)#switchport mode access 
SW1(config-if-range)#switchport access vlan 3 
SW1(config-if-range)#interface gig 1/0/5 
SW1(config-if)#switchport mode access 
SW1(config-if)#switchport access vlan 4 
SW1(config-if)#interface gig 1/0/6 
SW1(config-if)#switchport trunk encapsulation dot1q 
SW1(config-if)#switchport mode trunk 
SW1(config-if)#switchport trunk allowed vlan 2-4 

Dans cette configuration, nous pouvons noter que sur les interfaces Gig 1/0/1 et Gig 1/0/2, nous précisons que c’est un vlan voix. De plus, vous aurez remarqué qu’une liaison trunk est créer entre le routeur et le commutateur. En effet, c’est notre routeur qui hébergera nos passerelles. De plus sur le routeur, nous configurerons un serveur DHCP.

Router>enable
Router#configure terminal
Router(config)#interface fa0/0 
Router(config-if)#no shutdown 
Router(config-if)#interface fa0/0.2 
Router(config-subif)#encapsulation dot1q 2 
Router(config-subif)#ip address 192.168.0.254 255.255.255.0 
Router(config-subif)#interface fa 0/0.3 
Router(config-subif)#encapsulation dot1q 3 
Router(config-subif)#ip address 192.168.1.254 255.255.255.0 
Router(config-subif)#interface fa 0/0.4 
Router(config-subif)#encapsulation dot1Q 4 
Router(config-subif)#ip address 192.168.2.254 255.255.255.0 
Router(config-subif)#ip dhcp pool VLAN2 
Router(dhcp-config)#network 192.168.0.0 255.255.255.0 
Router(dhcp-config)#default-router 192.168.0.254 
Router(dhcp-config)#ip dhcp pool VLAN3 
Router(dhcp-config)#network 192.168.1.0 255.255.255.0 
Router(dhcp-config)#default-router 192.168.1.254 
Router(dhcp-config)#ip dhcp pool VLAN4 
Router(dhcp-config)#network 192.168.2.0 255.255.255.0 
Router(dhcp-config)#default-router 192.168.2.254 
Router(dhcp-config)#ip dhcp excluded-address 192.168.0.254 
Router(config)#ip dhcp excluded-address 192.168.1.254 
Router(config)#ip dhcp excluded-address 192.168.2.254 

Pour la partie téléphonie sur IP nous allons configurer le call manager.

Router(config)#telephony-service 

Nous allons ensuite indiquer le nombre de téléphone maximum qui pourra être supporté par le call manager. Ici, nous avons 2 téléphones, c’est donc cette valeur que nous allons renseigner.

Router(config-telephony)#max-ephone 2

Nous allons également indiquer combien de numéro privé nous allons gérer

Router(config-telephony)#max-dn 2

Nous indiquons l’adresse serveur de notre call manager ainsi que son port d’écoute

Router(config-telephony)#ip source-address 192.168.0.254 port 2000

Nous allons également créer nos téléphones, ainsi le téléphone demandera au call manager une configuration, cela évitera de configurer manuellement les téléphones. Ici, nous allons configurer 2 numéros de téléphone privé

Router(config-telephony)#auto assign 1 to 2

Router(config-telephony)#ephone-dn 1
Router(config-ephone-dn)#number 100
Router(config-ephone-dn)#ephone-dn 2
Router(config-ephone-dn)#number 101

Pour que les téléphones puissent récupérer cette configuration (TFTP), nous devons ajouter une option dans l’étendue VLAN2.

Router(config-subif)#ip dhcp pool VLAN2
Router(dhcp-config)#option 150 ip 192.168.0.254

Noter que l’option 150 du DHCP permet d’indiquer une liste d’adresse IP de serveurs TFTP. C’est une particularité du Call Manager. Bien souvent chez d’autres éditeurs de solution VoIP, vous ne pourrez renseigner qu’une seule adresse (ou nom de machine) TFTP. Dans ce cas, il faudra utiliser l’option 66.

Les téléphones devraient maintenant être correctement configuré est avoir un numéro.

Le premier avec le numéro 100 et le second avec le numéro 101.

Pour le Vlan vidéo, il y aura donc une caméra, qui est un IoT, il nous faudra donc un serveur (passerelle IoT), c’est la raison pour laquelle, vous avez un serveur dans ce VLAN. Avant de commencer à configurer le serveur pour notre IoT, prenez en considération les adresse IP suivantes :

• Caméra : 192.168.1.1
• Serveur : 192.168.1.2
  

Sur Packet Tracer, fait un double-clic sur le serveur, puis dans la fenêtre de configuration du serveur, rendez-vous dans l’onglet « Services ». Dans le menu latéral, sélectionner « IoT » est activé le service. Une fois que cela est fait, vous pouvez fermer la fenêtre.

Rendez-vous maintenant sur l’onglet « Desktop » puis sélectionner l’outil « Web Brower »

Dans le champ « URL » renseigner l’adresse IP du serveur précédé de http://. Puis créer un compte en cliquant sur le lien « Sign up now »

Indiquer ensuite un nom d’utilisateur et un mot de passe, puis valider en cliquant sur le bouton « Create »

Une fois le compte créer, nous allons configurer l’IoT (webcam). Pour cela, nous devons faire un double-clic sur la caméra, puis nous rendre dans l’onglet config. En bas de la partie principale, sélectionner « Remote Server » est renseigné les champs Server Adresse, Admin, Password. Terminer par cliquer sur le bouton « Connect »

Retourner sur l’interface Web de votre serveur IoT, vous devrez voir votre Webcam. Cliquer sur bouton « Rouge » Pour allumer votre « Webcam »

QoS VLAN VOIX

Sans rentrer dans le détail la voix sur IP se fait en deux temps :

• Signalisation avec le protocole SIP ou SCCP
• L’envoie des flux voix (RTP)
  

QoS Signalisation

Vu que nous utilisons CISCO Packet tracer le protocole de signalisation qui est utilisé est le SCCP.

En nous référant à la RFC 2474, nous marquerons les paquets de signalisation, c’est à dire le protocole SCCP avec un DSCP 40 (101000) soit un Classe Selector de 5.

Sur le commutateur, nous commencerons par classifier les paquets SCCP, on créera une classe map que l’on nommera QoS_SCCP

SW1(config)#class-map QoS_SCCP
SW1(config-cmap)#match protocol skinny
SW1(config-cmap)#exit

Nous créerons une stratégie qui s’appliquera sur la classe QoS_SCCP que nous avons précédemment créer.

Dans cette stratégie, nous indiquons le code 40 du service de la différentiation de service (DSCP), ce qui se traduit par la valeur CS5.

SW1(config)#policy-map strategie_qos
SW1(config-pmap)#class QoS_SCCP
SW1(config-pmap-c)#set ip dscp cs5

Pour terminer, nous indiquerons à notre commutateur que cette stratégie s’appliquera pour tous les paquets qui sortirons par l’interface gig 1/0/6.

SW1(config-pmap-c)#interface gig 1/0/6
SW1(config-if)#service-policy output strategie_qos

Pour vérifier que la configuration fonctionne bien, sur Cisco Packet Tracer, nous passerons en mode simulation, puis nous cliquerons sur le bouton « Show All/None ».

Puis sur le bouton « Edit Filters »

Dans l’onglet « Misc », cochez « SCCP »

Cliquer ensuite sur le premier téléphone et appeler le second.

Dans les outils Play Control appuyer 1 fois sur le bouton (Capture then Forward)

L’enveloppe SCCP doit être sur le Switch. Ouvrez cette enveloppe en faisant un double-clic dessus, puis rendez-vous sur l’onglet « Inbound PDU Details », qui est le message d’entrée. Nous voyons que le DSCP à une valeur de 0x00 donc un CS0.

Intéressons-nous au PDU de sortie, celle qui doit être modifier par la configuration que nous avons mis en place. Cliquons sur l’onglet « Outbound PDU Details », nous constatons que le DSCP à une valeur hexadécimal de 28 soit en binaire 101000, c’est-à-dire CS5. La stratégie que nous avons mis en place est donc bien fonctionnelle.

QoS des flux voix

Comme nous l’avons indiqué le protocole pour le transport de la voix est le RTP (Real-Time Protocole). Nous allons donc créer une classification s’appuyant sur ce protocole puis nous ajouterons cette classe à la stratégie précédemment créer.

Ici, la stratégie sera de faire du LLQ Latence Low Queuing, c’est-à-dire faire un marquage EF (Expedition forwarding)

SW1(config-if)#class-map QoS_RTP
SW1(config-cmap)#match protocol rtp
SW1(config-cmap)#policy-map strategie_qos
SW1(config-pmap)#class QoS_RTP
SW1(config-pmap-c)#set ip dscp ef
SW1(config-pmap-c)#bandwidth 2000

Noter que nous allouons une bande passante de 2Mb/s, cette limite permettra de laisser passer les autres flux à un moment données (La bande passante pour la VoIP se calcul en prenant en compte les codecs utilisées, si nous utilisons le codec G.711, avec 2Mb/s nous pourrions avoir 20 conversation téléphonique en simultanées en considérant que la bande passant est de 100 kb/s )

QoS VLAN VIDEO

Ici, nous nous baserons sur le VLAN et non plus sur le protocole, nous allouerons à ce VLAN 60 % de la bande passant laissant ainsi les 40 % restant pour le VLAN Data.

Nous devons observer la même logique que celle utiliser pour le VLAN Voix, c’est-à-dire :

1. Classifier
2. Définir la stratégie à cette classe
3. Indiquer l’interface concernée.
   

Ici, nous ne classifierons pas par protocole mais par adresse IP. Il nous faut créer une liste de nos adresses. Nous créerons donc une ACL étendue.

SW1(config)#access-list 100 permit ip 192.168.1.0 0.0.0.255 any

Notre ACL, nous permettra de classifier toutes les machines du VLAN 3, dans une classe que nous appellerons QoS_VIDEO.

SW1(config)#class-map QoS_VIDEO
SW1(config-cmap)#match access-group 100

Nous allons maintenant créer la stratégie pour cette classe.

SW1(config-pmap)#policy-map strategie-video
SW1(config-pmap)#class QoS_VIDEO
SW1(config-pmap-c)#set ip dscp af31
SW1(config-pmap-c)#priority percent 60

Ici, nous utiliserons le dscp af qui nous permet assurer l’envoie de la trame. La priorité de la file d’attente est de 3 sur 4. Ce choix est dû au fait que nous réserverons la priorité 4 aux vidéos interactifs, comme de la visio (Microsoft Teams, Cisco Webex, ZOOM). Ici, nous somme plus sur de la vidéo surveillance. Nous indiquerons tout de même une priorité 1 qui est la plus basse concernant la priorité de suppression du paquet.

L’article Comprendre le concept de la qualité de service QoS est apparu en premier sur Pandawan.

À l’origine du réseau public Internet, chaque organisation souhaitant utiliser ce réseau devait demander un pool d’adresses correspondant à une classe d’adresse. L‘IANA, en charge de la distribution de ces adresses, veille à ce que chaque adresse soit utilisée par un seul équipement. Permettant ainsi le bon fonctionnement du routage de l’information. Ajoutons que sans cette régulation, nous aurions rapidement été à court d’adresses IP, ce qui aurait fortement ralenti le développement du réseau Internet. La mise en place du VLSM ne résolvait qu’une partie du problème. L’élément clé qui nous a permis d’atteindre le déploiement de l’IPv6 est la translation d’adresse, plus communément appelée NAT (Network Address Translation).

Concept de la translation d’adresse NAT.

Le fonctionnement du NAT est défini dans la RFC 3022. La translation d’adresse est une technologie permet de modifier l’adresse source d’un paquet. Prenons l’exemple d’un utilisateur du LAN souhaitant ce connecter à un site internet. L’utilisateur enverra un paquet sur le réseau publique. Le paquet aura l’adresse source du pc de l’utilisateur. Le paquet, une fois arrivée sur le router, changera l’adresse IP source en indiquant l’addresse de l’interface Wan du routeur. Ce mécanisme s’appelle une translation.. Par conséquent, cette translation d’adresse permettra au paquet d’avoir une adresse source qui sera routable sur internet (IP publique) et ainsi permettra au à l’émetteur de recevoir une réponse de la part du récepteur.

Les types de NAT

Il existe plusieurs types type que nous allons décrire dans les prochains chapitres :

• Le NAT statique
• Le NAT Dynamique
• Le NAT avec surcharge
  

NAT statique

Rappellons que l’illustration présentant le concept du NAT que nous vous avons précédemment illustre ce qu’est le NAT statique. Le NAT statique permet de translater l’IP d’une machine cliente avec une adresse IP. Cela implique que deux machines d’un même réseau ne pourront pas naviguer sur Internet simultanément. En effet, si l’adresse est déjà utilisée pour une translation, elle ne pourra être utilisée. Ce type de NAT n’est plus vraiment utilisé mais nous verrons tout de même sa mise en pratique en partant du lab suivant :

• Configuration de base R1

Router#configure terminal 
Router(config)#hostname R1
R1(config)#interface gig 0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.0.254 255.255.255.0
R1(config-if)#interface gig 0/1
R1(config-if)#no shutdown
R1(config-if)#ip address 1.0.0.1 255.255.255.252

• Configuration de base INTERNET

Router#configure terminal
Router(config)#hostname INTERNET
INTERNET(config)#interface gig 0/0
INTERNET(config-if)#ip address 1.0.0.2 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/1
INTERNET(config-if)#ip address 1.0.0.6 255.255.255.252
INTERNET(config-if)#no shutdown

• Configuration de base R2

Router#configure terminal
Router(config)#hostname R2
R2(config)#interface gig 0/1
R2(config-if)#ip address 1.0.0.5 255.255.255.252
R2(config-if)#no shutdown
R2(config-if)#interface gig 0/0
R2(config-if)#ip address 192.168.1.254 255.255.255.0
R2(config-if)#no shutdown

• Configuration sur R1

Dans un premier temps, nous devons indiquer à notre routeur qu’elle est l’interface LAN et qu’elle est l’interface WAN. Notre interface LAN est identifiée par le paramètre INSIDE. Pour notre interface WAN l’interface OUTSIDE.

R1(config-if)#interface gig 0/0
R1(config-if)#ip nat inside
R1(config-if)#interface gig 0/1
R1(config-if)#ip nat outside

La configuration du NAT statique nécessite la création d’une règle. Nous indiquerons dans cette règle, qu’elle est adresse de notre LAN sera translatée. Ensuite, nous indiquerons explicitement notre IP publique. Dans le cas de R1 cela sera l’adresse 1.0.0.1.

R1(config-if)#ip nat inside source static 192.168.0.1 1.0.0.1

• Configuration sur R2

Nous observerons la même logique que pour R1.

R2(config)#interface gig 0/0
R2(config-if)#ip nat inside
R2(config-if)#interface gig 0/1
R2(config-if)#ip nat inside
R2(config-if)#ip nat inside source static 192.168.1.1 1.0.0.5

• Mise en place du routage par défaut sur R1

R1(config)#ip route 0.0.0.0 0.0.0.0 1.0.0.2

Mise en place du routage par défaut sur R2

R2(config)#ip route 0.0.0.0 0.0.0.0 1.0.0.6

Vérifions maintenant notre configuration depuis PC1, nous tenterons de communiquer avec l’interface WAN de R2.

Avec un outil tel que Wireshark, qui nous permet de sniffer notre réseau, nous pouvons voir que l’adresse source est bien l’adresse IP de l’interface WAN du routeur R1.

Depuis le routeur R1, vous pouvez également voir les translations via la commande

R1#show ip nat translations

Vous pouvez également avoir des statistiques relatives aux translation d’adresse avec la commande.

R1#show ip nat statistics

Si nous voulant connaitre le nombre de paquet translaté nous regarderons l’information « CEF Translated packets».

NAT Dynamique et NAT overload

Dans le NAT statique, nous avons vu qu’une seule adresse peut être translater, ce qui ne répond pas souvent à la demande des entreprises à savoir, permettre à l’ensemble des salariés de pouvoir naviguer sur internet. Le NAT dynamique va nous permettre de nous appuyer sur un pool d’adresse IP publique. Cela nous permettra de pouvoir autoriser autant d’utilisateur que d’adresse IP publique disponible dans notre pool, en d’autres termes si nous avons 250 utilisateurs vous devriez avoir un pool de 250 adresses IP publiques.

Bien que cette solution soit fonctionnelle, cela demande beaucoup d’adresse IP publique or nous avons vu plus tôt que nous en manquons. FInalement La solution se trouve dans le 3^ème type de NAT. Il faut dire que nous retrouvons ce type de NAT dans les box des fournisseurs d’accès internet (FAI).

Le NAT avec la surcharge aussi appelé NAT overload ou encore PAT permet d’utiliser l’adresse IP publique et les ports éphémère (port de 49152 à 65535) ainsi avec une seul adresses IP, nous pouvons translater 16383 paquets. La table de translation ne va plus faire correspondre une adresse IP privé et une adresse publique mais va surcharger l’information en indiquant le port utilisé par l’adresse publique pour envoyer sa requête

Schéma de fonctionnement

Examinons cela à l’aide d’une mise en application, nous partirons d’une infrastructure ressemblante à ce que nous avons pu voir dans le chapitre NAT statique.

• Configuration de base de R1

Router#configure terminal
Router(config)#hostname R1
R1(config)#interface gig 0/0
R1(config-if)#ip address 192.168.0.254 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#interface gig 0/1
R1(config-if)#ip address 1.0.0.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#ip route 0.0.0.0 0.0.0.0 gig0/1

• Configuration de base de R2

Router#configure terminal
R2(config)#interface gig 0/0
R2(config-if)#ip address 192.168.1.254 255.255.255.0
R2(config-if)#no shutdown
R2(config-if)#interface gig 0/1
R2(config-if)#ip address 1.0.0.5 255.255.255.252
R2(config-if)#no shutdown
R2(config-if)#ip route 0.0.0.0 0.0.0.0 gig0/1

• Configuration de base Internet

Router#configure terminal
Router(config)#hostname INTERNET
INTERNET(config)#interface gig 0/0
INTERNET(config-if)#ip address 1.0.0.2 255.255.255.252
INTERNET(config-if)#no shutdown
INTERNET(config-if)#interface gig 0/1
INTERNET(config-if)#ip address 1.0.0.6 255.255.255.252
INTERNET(config-if)#no shutdown

• Configuration sur R1

Précédemment, pour le NAT statique, nous avons défini LAN (inside) et l’interface WAN ((outside), Ici, nous en ferrons de même.

R1(config)#interface gig 0/0
R1(config-if)#ip nat inside
R1(config-if)#interface gig 0/1
R1(config-if)#ip nat outside

Nous allons définir qu’elles seront les hôtes pour lesquelles nous permettons la translation de l’adresse, nous passerons donc à la création d’une ACL standard.

R1(config)#access-list 1 permit 192.168.0.0 0.0.0.255

Ensuite, Après avoir créer notre ACL, nous configurerons la translation d’adresse.

R1(config)#ip nat inside source list 1 interface gig 0/1 overload

• Configuration sur R2

R2(config)#interface gig 0/0
R2(config-if)#ip nat inside
R2(config-if)#interface gig 0/1
R2(config-if)#ip nat outside
R2(config-if)#access-list 1 permit 192.168.1.0 0.0.0.255
R2(config)#ip nat inside source list 1 interface gig 0/1
R2(config)#no ip nat inside source list 1 interface gig 0/1
R2(config)#ip nat inside source list 1 interface gig 0/1 overload

En conclusion, nous pouvons passer à la vérification de notre configuration en exécutant un « ping » de PC1 et PC2 vers l’interface WAN de R2.En observant la table de translation, nous pouvons voir que les deux machines, PC1 et PC2, bénéficient dans la translation d’adresse.

L’article Tout ce que vous devez savoir sur la Translation d’Adresse NAT est apparu en premier sur Pandawan.

Fonctionnement du protocole DHCP

Dans un réseau local, lorsqu’une machine client se connecte au réseau, va chercher à obtenir une configuration réseau si aucune information n’a été renseigné par l’utilisateur. Cette recherche d’information passera par une requête DHCP qui est appelé DHCP Discover. Pour ce faire la trame DHCP Discover sera en mode de communication Broadcast.

Vu que la trame est en broadcast, elle sera dupliquée et envoyée sur tous les ports du switch à l’exception du port qui a reçu la trame.

Lorsqu’une machine du réseau reçoit la trame, deux choix sont possibles, soit elle n’est pas concernée par la requête et dans ce cas la trame sera supprimé, soit elle est concernée est dans ce cas, elle répond avec une requête DHCP Offer, qui proposera au client qui a envoyé la trame DHCP Discover une offre de bail. Cette communication pourra se faire en unicast du fait que la trame DHCP Discover qui a été reçu contenait l’adresse MAC source de l’expéditeur de la trame.

Dans cette offre, nous retrouverons l’adresse IP du serveur DHCP ainsi qu’une adresse IP est un masque de sous-réseau. Il faut noter que dans le cas où il existe plusieurs serveur DHCP dans le réseau local, le client peut recevoir plusieurs propositions.

Dès que le client, représenté dans les illustrations en vert, il annonce au réseau à travers une trame broadcast nommée DHCP Request qu’il est maintenant associé à un serveur DHCP.

Le serveur qui a été désigné comme serveur DHCP pour le poste client reçoit aussi cette information qu’il est le serveur DHCP désigné, il lui répondra à travers une trame DHCP « Ack » qu’il acte cette association en lui envoyant les options nécessaires à la configuration du réseau. Parmi ses options nous retrouverons l’adresse du routeur par défaut (la passerelle du lan), les adresses des serveurs dns, la durée du bail, c’est-à-dire combien de temps cette configuration lui sera attribué, etc…

La listes options proposées par le protocole DHCP sont disponible dans la RFC 2132

En résumé, nous pourrions indiquer que l’attribution des configurations réseau automatiques, s’appuient sur 4 trames :

• DHCP Discover
• DHCP Offer
• DHCP Request
• DHCP Ack

Un mémo-technique est souvent utilisé pour s’en rappeler : DORA.

Configuration d’un serveur DHCP sur un équipement CISCO

S’il est plutôt d’usage d’utiliser un serveur pour configurer le rôle DHCP, il n’en reste pas moins que cela peut se révéler pratique et moins coûteux d’installer un serveur DHCP sur un équipement réseau. En effet, prenant l’exemple d’un réseau de type SOHO, il serait relativement coûteux, voir disproportionné de mettre un serveur sur place. Ce type de réseau aura forcément besoin d’équipement réseau, ne serait-ce que pour se connecter à internet pour consulter sa messagerie. Par conséquent, il aura un équipement réseau de type routeur ou pare-feu. Ici, nous nous concentrerons sur le routeur (la configuration sera la même sur un switch de niveau 3). Nous partirons d’une topologie relativement simpliste avec une machine et routeur qui hébergera le rôle DHCP.

Configuration de l’interface Gig 0/0

Router>enable
Router#configure terminal
Router(config)#interface gig 0/0
Router(config-if)#ip address 192.168.0.254 255.255.255.0
Router(config-if)#no shutdown

Ensuite nous allons configurer notre serveur DHCP, il faut savoir qu’un serveur DHCP peut être serveur de plusieurs réseaux. Chaque réseau aura une étendue qui lui sera propre. Pour configurer notre serveur DHCP, nous allons commencer par créer notre étendue en lui attribuant un nom par exemple LAN.

 Router(config-if)#ip dhcp pool LAN

Ensuite, nous devons indiquer le réseau pour lequel, il sera amené à distribuer des configurations réseaux. Dans notre exemple, cela sera le réseau 192.168.0.0/24

Router(dhcp-config)#network 192.168.0.0 255.255.255.0

Nous terminerons par ajouter la passerelle de notre réseau et le serveur DNS de notre LAN.

Router(dhcp-config)#default-router 192.168.0.254
Router(dhcp-config)#dns-server 8.8.8.8

Notre serveur DHCP étant maintenant fonctionnelle, depuis ma machine cliente (un VPCS), je peux constater que mon serveur DHCP a bien été associé à mon client.

Relais DHCP

Nous avons vu plus tôt que le client, pour s’associer à un serveur DHCP, va commencer par envoyer une trame en broadcast or, comme nous l’avons déjà vu plus tôt, une trame de broadcast est limitée à son réseau local. Dans beaucoup de contexte d’entreprise, un vlan est dédié aux serveurs, donc par sur le même sous-réseau que les machines clientes. Nous devons donc permettre à notre trame de broadcast de pouvoir aller jusqu’à un autre réseau. Cette fonctionnalité est assurée par la fonctionnalité du relais DHCP.

Le mécanisme du relais DHCP permet d’encapsuler une trame DHCP Offer dans un paquet avec une destination prédéfini qui sera le serveur DHCP. Cela aura pour conséquence de transformer une communication broadcast (DHCP) vers une communication unicast.

Cela laisse sous-entendre que l’interface qui reçoit la trame devra être un relais entre la trame et le paquet qui sera envoyé au serveur DHCP distant.

Pour la mise en application partons de la topologie suivante :

Dans ce lab, l’interface Gig 0/0 de RT-2 sera configurer via un serveur DHCP hébergé sur RT-3.

Configuration de RT-3

RT-3>enable
RT-3#configure terminal
RT-3(config)#interface gig 0/1
RT-3(config-if)#ip address 192.168.1.254 255.255.255.0
RT-3(config-if)#no shutdown
RT-3(config-if)#ip DHCP pool LAN-192.168.1.0
RT-3(dhcp-config)#network 192.168.1.0 255.255.255.0
RT-3(dhcp-config)#default-router 192.168.1.254
RT-3(dhcp-config)#dns-server 8.8.8.8
RT-3(dhcp-config)#ip DHCP pool LAN-192.168.0.0
RT-3(dhcp-config)#network 192.168.0.0 255.255.255.0
RT-3(dhcp-config)#default-router 192.168.0.254
RT-3(dhcp-config)#dns-server 8.8.8.8
RT-3(dhcp-config)#ip dhcp excluded-address 192.168.1.254
RT-3(config)#ip dhcp excluded-address 192.168.0.254

Noter que la commande « IP DHCP excluded-address » permet d’exclure du pool de distribution des adresses IP. On exclura les IP que l’on fixe sur des interfaces réseaux

L’interface qui recevra notre trame DHCP offer est l’interface gig0/0 de RT-1 qui aura comme adresse 192.168.0.254.

RT-1#enable
RT-1#configure terminal
RT-1(config)#interface gig 0/1
RT-1(config-if)#ip address 192.168.1.253 255.255.255.0
RT-1(config-if)#no shutdown
RT-1(config-if)#interface gig 0/0
RT-1(config-if)#ip address 192.168.0.254 255.255.255.0
RT-1(config-if)#no shutdown

L’interface gig 0/0 du routeur RT-1, sera chargé de relayer le message DHCP Offer vers RT-3, ce qui se traduira par la commande suivante :

RT-1(config-if)#interface gig 0/0
RT-1(config-if)#ip helper-address 192.168.1.254

Nous finirons par configure le routage, nous utiliserons le protocole de routage dynamique OSPF.

RT-1

RT-1(config)#router ospf 1
RT-1(config-router)#network 192.168.0.0 0.0.0.255 area 0
RT-1(config-router)#network 192.168.1.0 0.0.0.255 area 0

RT-2

RT-2(config)#router ospf 1
RT-2(config-router)#network 192.168.0.0 0.0.0.255 area 0

RT-3

RT-3(config)#router ospf 1
RT-3(config-router)#network 192.168.0.0 0.0.0.255 area 0

Testons maintenant la configuration.

RT-2(config)#interface gig 0/0
RT-2(config)#no shutdown
RT-2(config)#ip address DHCP

Après quelques secondes, vous devriez avec un message 

  %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.3, mask 255.255.255.0, hostname RT-2

Retourner sur le routeur hébergeant le serveur DHCP pour lister les baux en cours.

  RT-3#show ip dhcp binding

Sécurité DHCP

DHCP Sniffing

Le DHCP est un protocole qui ne nécessite pas d’authentification, de ce fait, un client peut recevoir une configuration réseau de n’importe quel serveur DHCP se trouvant dans le LAN, notamment un serveur DHCP « pirate » (Usurpation DHCP). Cette attaque est connue sous le nom de « DHCP Spoofing ». Les conséquences peuvent être par exemple, un serveur proposerait une passerelle qui serait une interface ayant une sniffer ceux qui permettra de récupérer tout le trafic d’une ou de plusieurs machines. Il pourra aussi indiquer un faux serveur DNS permettant renvoyant sur des clones de site internet.

Une solution doit donc être mise en place pour empêcher ce type d’attaque. Cette contre mesure est le DHCP « snooping ». Cette solution visera à indiquer quel port pourra se voir retransmettre une trame DHCP offer qui sera le port sur lequel est connecté le serveur DHCP, soit dans l’illustration précédent l’interface Gig 0/0. Cette interface sera donc une interface de confiance, dans la configuration du commutateur nous allons donc devoir l’indiquer qu’elle est notre port de confiance.

Pour la mise en pratique, nous allons appuyer sur le schéma précédent, pour une question de simplicité, les serveurs DHCP seront installés sur des routeurs.

Configuration du DHCP (vert)

Router#configure terminal
Router(config)#hostname DHCP
DHCP(config)#interface gig 0/0
DHCP(config-if)#ip address 192.168.0.254 255.255.255.0
DHCP(config-if)#no shutdown
DHCP(config-if)#ip dhcp pool LAN
DHCP(dhcp-config)#network 192.168.0.0 255.255.255.0
DHCP(dhcp-config)#default-router 192.168.0.254
DHCP(dhcp-config)#dns-server 192.168.0.254

Configuration du DHCP PIRATE (rouge)

Router(config)#hostname DHCP-PIRATE
DHCP-PIRATE(config)#interface gig 0/1
DHCP-PIRATE(config-if)#ip address 192.168.0.253 255.255.255.0
DHCP-PIRATE(config-if)#no shutdown
DHCP-PIRATE(config-if)#ip dhcp pool PIRATE-LAN
DHCP-PIRATE(dhcp-config)#network 192.168.0.0 255.255.255.0
DHCP-PIRATE(dhcp-config)#default-router 192.168.0.253
DHCP-PIRATE(dhcp-config)#dns-server 192.168.0.253

Le serveur DHCP pirate se trouvant sur le même switch que le serveur, il répondra plus rapidement que le DHCP légitime et par conséquent le serveur DHCP pirate sera le serveur du client.

Comme il a été noté précédemment, nous devons indiquer que le port de confiance est le gig 0/0 du commutateur ACCESS-1. Pour ce faire nous devons activer la fonctionnalité « IP DHCP snooping »

ACCESS-1(config)#ip dhcp snooping

Par défaut lorsque nous activons le DHCP snooping, l’option 82 « Option information » s’active. Cette option est nécessaire lorsque le commutateur est un relais DHCP, ce qui n’est pas notre cas. Il ne faut donc désactiver cette option.

ACCESS-1(config)#no ip dhcp snooping information option

Ensuite nous allons identifier le VLAN sur lequel le DHCP snooping va être opérationnel. Ici, nous n’avons pas créer de vlan donc nous sommes sur le VLAN par défaut, c’est-à-dire le VLAN 1.

ACCESS-1(config)#ip dhcp snooping vlan 1

Nous allons maintenant sélectionner l’interface qui sera notre interface de confiance, et nous la taguons comme tel.

ACCESS-1(config)#interface gig 0/0
ACCESS-1(config-if)#ip dhcp snooping trust

Sur notre client, nous libérons le bail DHCP qui nous a été fournit précédemment et nous demandons une nouvelle configuration réseau à notre serveur DHCP.

L’article Configuration d’un serveur DHCP sur un routeur CISCO est apparu en premier sur Pandawan.

Les routeurs CISCO permettent d’attribuer des règles de filtrages sur les ports d’entrée ou sur les ports de sorties des paquets. Lorsque nous indiquons au port d’entrée, nous ferons en sorte que le paquet n’arrive pas jusqu’au processus de routage, ainsi nous économisons de la ressource matérielle. En règle générale une ACL, nous configurerons le filtrage au plus près de la restriction.

Pour illustrer ses propos, nous nous appuierons sur l’illustration suivant :

Dans ce schéma, si nous souhaitons que le PC vert ne communique pas avec le PC gris, nous devons configurer la règle de filtrage sur le port Gig0/0.

La correspondance des paquets

La correspondance des paquets fait référence à la manière de configurer les ACL, en indiquant qu’elles sont les informations utilisées pour filtrer, cela peut être une adresse IP ou un protocole. En d’autres termes la première phase de la configuration d’une règle de filtrage va être la recherche d’information. Nous configurerons de tel façon que le routeur qui reçoit le paquet puisse se poser la question « Est-ce que l’adresse IP ou le protocole qui a été indiquer dans l’ACL est présent dans ce paquet ?». Cette question, il se la posera lorsqu’un paquet arrive et pour toutes les ACLs qui auront été créé. Nous pourrions représenter ce processus dans le diagramme suivant :

Ce digramme représente un logigramme, en effet, les ACL suivent une logique. Ainsi, dès qu’une correspondance est trouvé, il n’ira pas plus loin. Par exemple, si nous indiquons explicitement un refus en première règle de filtrage et qu’en deuxième règle de filtrage nous acceptons tous les paquets, tous les paquets seront refusé. Dans le cas où nous inversons ses règles tous les paquets seront acceptés.

Les types des ACL

Pour créer des règles de filtrage, nous pouvons nous appuyer sur 3 types de liste de contrôle que nous allons décrire dans ce chapitre.

ACL standard

Les ACL standard sont identifiées par un nombre de 1 à 99 et de 1300 à 1999. Ce type d’ACL se concentre uniquement sur les adresses IP. Nous pourrons ainsi autoriser ou interdire un réseau de communiquer avec un autre réseau.

Pour illustrer ses propos, nous allons partir de la topologie suivante

Sur le routeur nous aurons la configuration suivante :

Router(config)#interface GigabitEthernet0/0
Router(config-if)#ip address 192.168.0.254 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#interface GigabitEthernet0/1
Router(config-if)#ip address 192.168.1.254 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#interface GigabitEthernet0/2
Router(config-if)#ip address 192.168.2.254 255.255.255.0
Router(config-if)#no shutdown

A ce stade, les machines réseaux sont interconnecté par le routeur et sont donc en mesure de communiquer entre eux.

Nous allons maintenant interdire le réseau 192.168.0.0 de communiquer avec le réseau 192.168.1.0. Nous allons donc interdire sur l’interface gig 0/0 de laisser passer le trafic extérieur émanant du réseau 192.168.1.0

Pour traduire cela en ligne de commande nous devons faire 3 choses :

1. Créer la règle
2. Sélection l’interface qui sera concerné par la règle
3. Appliquer la règle

Créer la règle

Router(config)#access-list 1 deny 192.168.1.0 0.0.0.255

Ici, nous déclarons le réseau avec son masque inversé.

Sélection l’interface qui sera concerné par la règle

Router(config)#interface gigabitEthernet 0/0

Appliquer la règle

Router(config-if)#ip access-group 1 out

Dan cette partie on applique l’ACL n°1 que nous avons créé à l’étape « Créer la règle » puis nous indiquons que cette règle s’applique pour les paquets extérieurs au réseau de l’interface.

Nous créerons aussi une seconde règle qui autorisera le réseau 192.168.2.0

Router(config)#access-list 2 permit 192.168.2.0 0.0.0.255
Router(config)#interface gig 0/0
Router(config-if)#ip access-group 2 out

Nous pouvons maintenant tester que les règles sont bien opérantes.

En bref, notre première règle était le refus des paquets avec, dans l’entête, une adresse source du réseau 192.168.1.0. Mais pour accepter les paquets venant du réseau 192.168.2.0, nous sommes obligées de créer la règle. En effet, si nous ne créons pas cette adresse, il n’y aura pas de correspondance entre l’IP source contenu dans l’entête du paquet et les règles, ce qui entrainera un « deny » implicite. En partant de ce principe, dans ce contexte, nous aurions très bien pu ne configurer que la règle pour le réseau 192.168.2.0, ce qui aurait implicitement interdit le réseau 192.168.1.0.

ACL étendues

Les ACL étendues, comme son nom le laisse supposer, étendrons les possibilités de la liste de contrôle, nous allons pouvoir filtrer en se basant sur les adresses IP de l’entête du paquet mais nous allons pouvoir aussi étendre les informations vers des informations du segment à savoir le port ou le protocole contenu dans les entêtes de segment. Cela nous permettra de créer des règles de filtrage qui soit le plus fin possible, on pourrait ainsi interdire les requêtes ping vers un serveur de fichier mais pas l’accès aux dossiers partagés qu’il héberge.

Les ACL étendues sont, comme les ACL étendues, identifiable par un numéro, de 100 à 199 et de 2000 à 2699.

La configuration observera les mêmes étapes que les ACL standard à savoir :

1. Création de la règle
2. Sélection de l’interface
3. Appliquer la règle à l’interface

Pour la mise en place d’une ACL étendue, nous repartirons de la même topologie que nous avons utilisé pour les ACL standard. Il faudra bien évidemment effacer les fichiers de configuration.

Nous créerons une règle qui interdit le requête ICMP de PC2 vers PC3 et nous autoriserons les requêtes ICMP de PC2 vers PC1

Pour la configuration des interfaces nous garderons la même configuration que nous avons utilisé dans la partie ACL standard.

Router(config)#interface GigabitEthernet0/0
Router(config-if)#ip address 192.168.0.254 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#interface GigabitEthernet0/1
Router(config-if)#ip address 192.168.1.254 255.255.255.0
Router(config-if)#no shutdown
Router(config-if)#interface GigabitEthernet0/2
Router(config-if)#ip address 192.168.2.254 255.255.255.0
Router(config-if)#no shutdown

Puis nous créerons les règles

Router(config)#access-list 100 deny icmp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router(config)#access-list 100 permit icmp 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
Router(config-if)#interface gig 0/1
Router(config-if)#ip access-group 100 out

Nous pouvons maintenant tester depuis PC2

ACL nommées

Les ACL nommées regroupent les ACL standard et les ACL étendues mais contrairement à ses types d’ACL, les ACL nommées ne sont pas identifiées par un nombre mais par une valeur qui peut être alphanumérique. Elle apporte également une flexibilité dans l’ordre des ACL. En effet, lorsque que vous créer une ACL standard ou ACL étendues, un numéro de séquence est créé par règle, ce numéro de séquence indique l’ordre qui sera utilisé par le processus correspondance de paquet. Le numéro de séquence est incrémenté de 10 à chaque nouvelles règles. Ainsi la première règle d’une liste de contrôle aura comme numéro de séquence 10, la seconde 20 et ainsi de suite.

Nous pouvons le vérifier en nous basant sur le TP de mise en pratique d’une ACL étendue, via la commande permettant d’afficher les contrôles d’une liste

On voit dans cette capture que les règles ont bien un numéro de séquence.

Si nous souhaitons créer une règle qui autorise la machine 192.168.2.1 à envoyer des requêtes ICMP, il faudra donc la place avec la première règle, c’est-à-dire attribuer à la règle valeur inférieur à 10 et par conséquent créer une ACL nommée.

Commençons par supprimer l’ACL étendue

Router(config)#no access-list 100

Nous pouvons maintenant créer notre liste de règle.

Nous devons explicitement indiquer si elle est de type standard ou étendue. Dans notre cas, nous agissons sur le protocole ping donc c’est une ACL étendue. Nous devons également lui attribuer un nom. Cela se traduira par la commande :

Router(config)#ip access-list extended ICMP_192.168.2.1_AUTORISER

Ensuite, nous créerons la règle, ici le numéro de séquence doit être inférieur à 10 par exemple 8. De plus, nous allons autoriser une IP d’une machine et non un réseau entier.

Router(config)# 10 deny icmp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router(config)# 20 permit icmp 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
Router(config)#8 permit icmp host 192.168.2.1 192.168.1.0 0.0.0.255

Nous allons sélectionner l’interface qui sera concerné par cette règle

Router(config-ext-nacl)#interface gig 0/1

Pour nous terminerons, en attribuant la règle à l’interface.

Router(config-if)#ip access-group ICMP_192.168.2.1_AUTORISER out

Pour faire les tests de bon fonctionnement, nous modifierons la topologie de la façon suivante

PC2 devra pouvoir communiquer avec PC3 mais pas avec PC4.

L’article Les Access Control List sur des Routeur CISCO (ou Switch L3) est apparu en premier sur Pandawan.

Chaque LSA à un identifiant, ce qui permet d’optimiser l’envoie. Avant d’envoyer un LSA, le routeur enverra un message demandant à son voisin s’il a déjà ce LSA. Dans le cas où le routeur voisin réponds qu’il ne l’a pas, il l’envoie, dans le cas contraire l’envoie ne se fait pas. Une fois les LSA « inondés », c’est-à-dire envoyé à tous ses voisins, il enverra de manière occasionnelle les mises à jour (par exemple lorsqu’un lien change d’état (UP<->DOWN) ou lorsque le LSA arrive en fin de vie (30 minutes par défaut). L’ensemble de ses processus permettent que l’ensemble des routeurs d’un même zone partage le même LSDB, c’est-à-dire les mêmes informations.

La LSDB même si elle contient toutes les informations, n’indique pas la meilleure route à utiliser par le paquet. Le routeur va devoir lui-même calculer la meilleure route en utilisant l’algorithme de Dijkstra. Cet algorithme permet de découvrir le plus court chemin entre deux points, c’est ce même algorithme que nous allons retrouver dans les applications GPS par exemple. En s’appuyant sur toutes les données contenues dans la LSDB, il va définir les routes qui devront être ajouter dans les tables de routage.

Nous avons ici trois étapes clé quant au fonctionnement du protocole OSPF sur un routeur :

• Devenir voisin
• Echange des LSAs pour avoir une LSDB commune
• Calcul de la meilleure route

Pour qu’il y ait relation de voisinage entre deux routeurs exécutant le protocole OSPF, il faut bien évidemment qu’il soit lié, c’était membre d’un même réseau (ou sous réseau) mais cette condition n’est pas la seule. En effet, pour que la relation de voisinage puisse se faire, les routeurs envoie des messages Hello toutes les 10 secondes sur l’adresse multicast 224.0.0.5, si les deux routeurs ont une configuration compatible, il pourra y avoir une relation de voisinage. Ce mécanisme permettra d’apprendre les changements et permet de calculer les nouvelles routes possibles et éventuellement de modifier les routes déjà présente pour proposer une route plus fiable ou plus pertinente. Dans le message Hello, nous retrouverons l’identifiant du routeur (Router ID) codé sur 32 bits. Par défaut, le RID est une adresse ip d’une interface du routeur. Cette identifiant unique sera dans le LSA est permettra de savoir qui a envoyé quoi. De ce fait si un routeur ne reçoit plus de message Hello au bout de l’intervalle qui a été défini (10 seconde pas défaut), il attendra 4 fois cette intervalle. Passé ce délai, le routeur ne fera plus parti des voisins, il recalculera les chemins les plus courts. Les LSAs intégrerons ses nouvelles informations et mettrons à jours les LSDB. Pour s’assurer que les routeurs partagent la même LSDB, une autre action sera réalisée par les routeurs, qui est une action de vérification. En effet, toutes les 30 minutes (valeur par défaut), les routeurs inonde le réseau de LSA pour s’assurer que tous les LSDB sont identiques. Regardons cela en pratique, nous repartirons de la même topographie que pour le protocole de routage RIP.

Configuration des interfaces R1

Router#enable 
Router#configure terminal
Router(config)#hostname R1
R1(config)#interface gig 0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 10.0.0.5 255.255.255.252
R1(config-if)#interface gig 0/1
R1(config-if)#no shutdown
R1(config-if)#ip address 10.0.0.9 255.255.255.252

Configuration des interfaces R2

Router#enable
Router#configure terminal
Router(config)#hostname R2
R2(config)#interface gig 0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.0.254 255.255.255.0
R2(config-if)#interface gig 0/1
R2(config-if)#no shutdown
R2(config-if)#ip address 10.0.0.1 255.255.255.252
R2(config-if)#interface gig 0/2
R2(config-if)#no shutdown
R2(config-if)#ip address 10.0.0.6 255.255.255.252

Configuration des interfaces R3

Router#enable 
Router#configure terminal
Router(config)#hostname R3
R3(config)#interface gig 0/0
R3(config-if)#no shutdown
R3(config-if)#ip address 192.168.1.254 255.255.255.0
R3(config-if)#interface gig 0/1
R3(config-if)#no shutdown
R3(config-if)#ip address 10.0.0.2 255.255.255.252
R3(config-if)#interface gig 0/2
R3(config-if)#no shutdown
R3(config-if)#ip address 10.0.0.10 255.255.255.252

Configuration de l’OSPF sur R1

La configuration n’est pas très différente que celle que nous avons vu pour le protocole RIP. Nous allons commencer par activer le protocole OSPF sur le R1. Nous devons luis indiquer un identifiant de processus. En effet, sur un même routeur nous pouvons avoir plusieurs processus OSPF qui s’exécute.

R1(config)#router ospf 1

Nous allons indiquer le router ID manuellement.

  R1(config-router)#router-id 1.1.1.1

Nous pouvons maintenant indiquer nos réseaux. Le protocole OSPF a une particularité quant aux déclarations de réseau, en effet, nous devons indiquer le masque inversé. Nous allons donc déclarer nos réseaux adjacents avec leur masque. Nous allons tous mettre dans la même zone.

R1(config-router)#network 10.0.0.4 0.0.0.3 area 0 
R1(config-router)#network 10.0.0.8 0.0.0.3 area 0

Configuration de l’OSPF sur R2

R2(config)#router ospf 1 
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 192.168.0.0 0.0.0.255 area 0
R2(config-router)#network 10.0.0.0 0.0.0.3 area 0
R2(config-router)#network 10.0.0.4 0.0.0.3 area 0

Dans la table de routage, nous pouvons voir une router précédé par la lettre « O », ce qui indique que cette route a été apprise via le protocole OSPF.

Configuration de l’OSPF sur R3

R3(config-if)#router ospf 1
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 192.168.1.0 0.0.0.255 area 0
R3(config-router)#network 10.0.0.0 0.0.0.3 area 0
R3(config-router)#network 10.0.0.8 0.0.0.3 area 0

Table de routage R3

Ici, nous pouvons lire que la distance administrative est de 110, donc le protocole OSPF est prioritaire sur le protocole RIP est à coté de cela nous avons une métrique de « 2 ». Cette métrique est calculée à partir de la bande passante qui sera divisé par la bande passant de référence qui est définit par défaut à 100 000 000 bit/s. L’opération effectué sera alors « bande passante de référence / bande passante de l’interface en bit/s ». Le résultat ne peut être qu’un entier et ne peut pas être inférieur à 1. Si toutefois la valeur est inférieure, le coût sera égale à 1, dans ce cas, il peut être pertinent de modifier la valeur de la bande passante de référence. En effet, en partant de la formule de calcul nous pourrions avoir le tableau suivant :

Nous constatons que les liens 10 Gb ou 1 Gb ou 1 Fa auront les mêmes coûts si nous conserverons cette valeur alors que nous savons qu’il sera plus pertinent d’utiliser une liaison 10Gb/s plutôt qu’une liaison de 100Mb/s. La ligne de commande pour modifier cette valeur est la suivante :

R1(config-router)#auto-cost reference-bandwidth 1000

Pour connaître le cout d’une route, nous devons additionnées l’ensemble des liaisons emprunté par un paquet. L’OSPF est donc un protocole à état de lien.

Une capture WireShark nous permet de voir les messages Hello envoyé toute les 10 secondes.

En désactivant une interface, nous pouvons voir, toujours sur Wireshark, que nous voyons un nouveau type de paque LS Update aussi appelé LSU. Les LSU contient un ensemble de LSA pour la mise à jour.

Si nous nous attardons sur cette capture de paquet, nous voyons que 2 Type de LSA sont envoyé :

• Les paquets LSA Type 1 (routeur LSA) sont envoyés entre les routeurs dans la même zone d’origine et ne quittent pas la zone. Un routeur OSPF utilise des paquets LSA de type 1 pour décrire ses propres interfaces, mais transporte également des informations sur ses voisins vers des routeurs adjacents dans la même zone.
  
• Les paquets LSA Type 2 (Network LSA) sont générés par le routeur désigné (DR) pour décrire tous les routeurs connectés directement à son segment. Les paquets LSA de type 2 sont inondés entre des voisins dans la même zone d’origine et restent dans cette zone.

Il existe en effet de type de LSA.

Nous pouvons également voir que nos LSDB est identique à l’aide de la commande

  RX#show ip ospf database

LSDB R1

LSDB R2

LSDB R3

Election DR/BDR

Mais que se passerait-il si deux LSDB n’était pas identique ? Qu’elle LSDB sera prise en compte ? Nous allons retrouver un peu les mêmes mécanismes que nous avons vu avec le spanning-tree. Nous aurons une élection d’un routeur désigné (DR), il sera le juge de paix. Il y aura aussi l’élection d’un Router désigner secondaire BDR), qui prendra le relais si le routeur désigné est défaillant. Rappelons-nous les LSA sont connecté sur un même réseau, donc si nous voulons partir d’un cas pratique, nous utiliserons la topologie suivante :

Nous allons configurer les routeurs de la façon suivante :

Configuration R1

Router#enable
Router#configure terminal
Router(config)#hostname R1
R1(config)#interface gig 0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 10.0.0.1 255.255.255.248
R1(config-if)#interface gig 0/1
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.0.254 255.255.255.0
R1(config-if)#router ospf 1
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 10.0.0.0 0.0.0.7 area 0
R1(config-router)#network 192.168.0.0 0.0.0.255 area 0

Configuration R2

Router#enable
Router#configure terminal
Router(config)#hostname R2
R2(config)#interface gig 0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 10.0.0.2 255.255.255.248
R2(config-if)#interface gig 0/1
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.1.254 255.255.255.0
R2(config-if)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 10.0.0.0 0.0.0.7 area 0
R2(config-router)#network 192.168.1.0 0.0.0.255 area 0

Configuration de R3

Router#enable
Router#configure terminal
Router(config)#hostname R3
R3(config)#interface gig 0/0
R3(config-if)#no shutdown
R3(config-if)#ip address 10.0.0.3 255.255.255.248
R3(config-if)#interface gig 0/1
R3(config-if)#no shutdown
R3(config-if)#ip address 192.168.2.254 255.255.255.0
R3(config-if)#router ospf 1
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 10.0.0.0 0.0.0.7 area 0
R3(config-router)#network 192.168.2.0 0.0.0.255 area 0

Configuration de R4

Router#enable
Router#configure terminal
Router(config)#hostname R4
R4(config)#interface gig 0/0
R4(config-if)#no shutdown
R4(config-if)#ip address 10.0.0.4 255.255.255.248
R4(config-if)#interface gig 0/1
R4(config-if)#no shutdown
R4(config-if)#ip address 192.168.3.254 255.255.255.0
R4(config-if)#router ospf 1
R4(config-router)#router-id 4.4.4.4
R4(config-router)#network 10.0.0.0 0.0.0.7 area 0
R4(config-router)#network 192.168.3.0 0.0.0.255 area 0

Nous pouvons vérifier si les routes ont bien été apprise sur nos différents routeur. Par exemple sur la table de routage de R1, nous voyons les routes apprissent par l’OSPF (route précédée par la lettre « O »).

Nous pouvons également constater que les LSDB des 4 routeurs sont identiques.

Maintenant que nous savons que notre configuration OSPF est fonctionnelle, nous allons identifier le routeur désigné appelé aussi DR (Designed Router). Pour ce faire, nous allons consulter la table de voisinage du protocole OSPF et plus particulièrement la colonne « State » de cette table.

Nous consulterons la commande du routeur R1, pour ce faire, nous exécuterons la commande suivante :

  R1#show ip ospf neighbor

Nous avons plusieurs états :

• 2WAY/DROTHER : 2 WAY est la relation de base de voisinage, il a reçu un LSA contenant son nom par un voisin et par conséquent, il est connu de son voisin. DROTHER, nous indique qu’il n’est ni DR, ni BDR.
  
• FULL/BDR : Lorsque nous activons le protocoles OSPF, le routeur se mets en statut « Loading » et envoie des paquets LSR (Link State Request) afin de demander les informations à ses voisins, ses informations sont envoyées intégrée dans les paquets LSA qui sont eux même regrouper dans des LSU. Lorsque cette phase est terminée, il rentre en statut « FULL ». Ce statut lui permet de créer la table de routage OSPF et de router le trafic. Le voisin est le BDR.
  
• FULL/DR : Dans cet état, le protocole OSPF du voisin est opérationnel et il est le DR.
  

Le DR est celui qui a l’identifiant routeur le plus élevé. L’identifiant du routeur le plus élevé est le router-id 4.4.4.4 qui a été configuré sur le routeur R4. Router-id étant un paramètre optionnel, nous allons le supprimer de notre configuration est ceux, sur les 4 routeurs de notre lab.

Rx(config)#router ospf 1
Rx(config-router)#no router-id
Rx(config-router)#end
Rx#clear ip ospf process

Nous aurons à confirmer l’opération

Retournons voir la table de voisinage sur notre routeur R1.

Les identifiants de nos voisins est l’adresse IP la plus élevé configurer sur le voisin. Le DR est encore une fois l’adresse IP la plus élevé.

Dans notre contexte, nous sommes « par défaut », nous pouvons choisir le DR en modifiant sa priorité. Dans la capture de la table de voisinage ci-dessus, nous voyons que la priorité à 1, c’est la priorité la base (0 étant une exclusion du processus d’élection) et 255 la priorité la plus forte. On pourrait très bien configurer notre router avec le Router ID 192.168.1.254 DR, le Router ID 192.168.3.254 BDR. Cette configuration se fera sur l’interface que recevra les LSA (ou plutôt les LSU).

Le Router ID 192.168.1.254 est le router R2, la configuration pour le faire passer DR devra donc se faire sur Gig 0/0.

R2(config)#interface gig 0/0
R2(config-if)#ip ospf priority 255

Le Router ID 192.168.3.254 est le router R4, la configuration pour le faire passer BDR devra donc se faire sur Gig 0/0.

R4(config)#interface gig 0/0
R4(config-if)#ip ospf priority 254

Nous devons ensuite relancer le processus OSPF sur tous les routeurs.

Rx(config)#router ospf 1
Rx(config-router)#no router-id
Rx(config-router)#end
Rx#clear ip ospf process

Consultons maintenant notre table de voisinage sur R1.

Il peut être pertinent d’attribuer le statut de routeur désigné à un routeur qui se trouve au centre de votre infrastructure.

Les zones OSPF

Pour bien comprendre l’utilité des zones OSPF, il faut imaginer un réseau d’entreprise avec plusieurs centaines de routeurs. Les mises à jour de LSDB serait volumineux et le calcul du chemin le plus court prendrait beaucoup de ressource matérielle (CPU, RAM, …). Il y aura donc de la latence qui aura pour conséquence d’avoir des LSDB rarement identique. La solution sera alors de créer des regroupements de router qui se partagerons la même LSDB.

Ici, nous avons 3 zones une zone rouge, une zone bleue et une zone violette. Dans cette topologie, nous voyons que la liaison entre la zone rouge et la zone bleu est assuré par le routeur R2. La liaison entre la zone bleue et violette est assuré par le routeur R3. Dans le protocole OSPF, R2 et R3 sont des ABR (Area Border Router ou en français Router en bordure de zone). R4 va annoncer ses réseaux à R2 et R5 va annoncer ses routes à R3. Les routeurs qui ne sont pas ABR et qui sont à l’extrémité d’une zone, par exemple R1 ou R4 ou R5 peut être des ASBR (Autonomous System Border Router). Ses routeurs ont la particularité de se connecter à des réseaux partenaires et pourront faire la passerelle entre les protocoles de routages. En effet, un administrateur réseaux ne peux pas imposer un protocole de routages à un autre administrateur réseau. Il faudra donc utiliser un système autonome (Autonomous System) qui permettra de créer une cohérence entre les différents protocoles de routage.

L’article Protocole de routage dynamique OSPF est apparu en premier sur Pandawan.

Il existe 3 versions du protocole RIP :

• RIPv1 : Ne prends pas en charge le VLSM, c’est-à-dire es sous-réseau. Il se basera sur les classes d’adresse. On dira alors que c’est un protocole « fullclass »
• RIPv2 : Prends en charge le VLSM mais pas l’IPv6
• RIPng : Prends en charge l’IPv6
  

Mise en place d’un protocole de routage RIP

Pour notre Lab, nous partirons d’une infrastructure simple à 3 routeurs.

Avant de rentrer dans vif du sujet à savoir la configuration du protocole RIP, nous allons attribuer un noms et des adresses IP à nos interfaces.

Pour R1

Router#enable 
Router#configure terminal 
Router(config)#hostname R1 R1(config)#interface gig 0/0 
R1(config-if)#ip address 10.0.0.5 255.255.255.252 
R1(config-if)#no shutdown
R1(config-if)#interface gig 0/1 
R1(config-if)#ip address 10.0.0.9 255.255.255.252 
R1(config-if)#no shutdown 

A l’aide de la commande « show ip interface brief », nous pouvons voir que la configuration de nos interfaces est bien fonctionnelle.

Pour R2

Router#enable 
Router#configure terminal 
Router(config)#hostname R2 
R2(config)#interface gig 0/0
R2(config-if)#ip address 192.168.0.254 255.255.255.0
R2(config-if)#no shutdown
R2(config-if)#interface gig 0/1
R2(config-if)#ip address 10.0.0.1 255.255.255.252 R2(config-if)#no shutdown
R2(config-if)#interface gig 0/2
R2(config-if)#ip address 10.0.0.6 255.255.255.252
R2(config-if)#no shutdown	

Nous vérifions que notre configuration a bien été prise en compte.

Nous pouvons également tester la communication entre R1 et R2 via le réseau 10.0.0.4/30.

Pour R3

Router#enable 
Router#configure terminal 
Router(config)#hostname R3 
R3(config)#interface gig 0/0
R3(config-if)#ip address 192.168.1.254 255.255.255.0 
R3(config-if)#no shutdown
R3(config-if)#interface gig 0/1
R3(config-if)#ip address 10.0.0.2 255.255.255.252 
R3(config-if)#no shutdown
R3(config-if)#interface gig 0/2
R3(config-if)#ip address 10.0.0.10 255.255.255.252
R3(config-if)#no shutdown

Nous vérifions que la configuration a bien été pris en charge.

Nous pouvons aussi tester la communication entre R1-R2 et R2-R3

A ce stade, les tables de routages ne connaissent que les réseaux qui sont directement connecté aux routeurs.

Table de routage R1

Table de routage R2

Table de routage R3

En nous appuyant sur ses différentes tables de routage nous pouvons en conclure que le PC1, ne pourra pas connecter avec PC2. En effet le routeur R2 qui héberge la passerelle par défaut du réseau 192.168.0.0/24 sur lequel PC1 est connecté, ne connait pas le réseau 192.168.1.0/24 sur lequel PC2 est connecté.

Nous allons faire converger ses 3 tables de routage, ainsi R2 communiquera la route pour accéder au réseau 192.168.0.0/24 et R3 communiquera la route pour se rendre sur le réseau 192.168.1.0/24.

Dans cette topologie, nous avons utilisé du VLSM (les réseaux en /30 ) et de l’IPv4, donc nous utiliserons la version 2 du protocole RIP. Nous commencerons par le routeur R1.

Sur R1

Nous allons activer le protocole de routage RIP et nous configurons la version

R1(config)# router rip 
R1(config-router)# version 2 

Ensuite nous devons indiquer les réseaux dont les routes vont être propagés via le protocole RIP et que le routeur connait, c’est-à-dire ses routes adjacentes.

R1(config-router)# network 10.0.0.0
R1(config-router)# network 10.0.0.4

Nous ferons de même pour R2 et R3

Sur R2

R2(config)#router rip R2(config-router)#version 2

R2(config-router)#network 10.0.0.4 
R2(config-router)#network 10.0.0.0
R2(config-router)#network 192.168.0.0

Sur R3

R3(config)#router rip 
R3(config-router)#version 2
R3(config-router)#network 10.0.0.8
R3(config-router)#network 10.0.0.0
R3(config-router)#network 192.168.1.0

Regardons maintenant ce qu’il s’est passé au niveau de nos tables de routages. Sur la table de routage de R1.

Nous voyons de nouvelle route précédée du code « R », ce code indique que la route a été apprise via le protocole RIP. Après l’adresse réseau vous retrouvé sa valeur de la distance administrative est 120 et que ça métrique est de 1. Pour rappel, plus la valeur de la distance administrative sera faible, plus elle sera considérée fiable, en cas d’égalité c’est la métrique qui sera utilisé qui observera la même logique. Plus c’est faible, plus c’est fiable.

Nous pouvons maintenant tester que PC1(192.168.0.1/24) communique bien avec PC2 (192.168.1.1/24)

SI nous voulons voir la route qui a été prise par le paquet émis par PC1 pour arriver sur PC2, nous pouvons nous rendre sur R2 et afficher la table de routage.

Le paquet est passé par Gig 0/1 soit le chemin bleu dans l’illustration ci-dessous

Si nous désactivons l’inter Gig0/1, pour simuler une panne il devra donc redéfinir une nouvelle route et ainsi faire passer les paquets sur Gig0/2 sur R2. Nous allons donc faire ce test et pour voir s’il y a une interruption, nous effectuerons un ping en continu (avec l’option -t) entre PC1 et PC2 avant d’éteindre l’interface Gig0/1.

Ping en continu sur un PC1

Désactivation de l’interface Gig0/1sur R2

R2(config)#interface gig 0/1 
R2(config-if)#shutdown 

La communication est interrompue jusqu’à ‘ à la nouvelle mise à jour de la table de routage, qui prendra au maximum 30 secondes.

L’avantage ici est qu’il n’y a pas eu besoin d’intervention humaine pour que la redéfinir, ce qui aurait été le cas si nous avions déployer une route statique. L’inconvénient en revanche c’est le délai de rétablissement

qui est long. Imaginons un site comme www.amazon.fr qui serait indisponible 30 secondes ; Cette latence est liée au fonctionnement même du protocole. En effet, le RIP ne m’est pas à jour les tables de routage comme pourrait le faire le protocole OSPF ou EIGRP, il envoie l’intégralité de la table de routage.

Dans la table de routage, nous pouvons également constater que la route a été modifié.

Nous voyons également que la métrique a été changer. En effet, pour passer de PC1 à PC2, nous faisons 2 sauts.

Analysons plus en détails ce qu’il se passe sur les routeurs, pour cela nous allons nous rendre sur le routeur R1 est exécuter la commande suivante :

  R1# debug ip rip	

Nous constatons que tous les 25 à 30 secondes des paquets de mise à jour avec tout le contenu de la table est envoyé même si la topologie n’a pas eu de modification.

Pour désactiver le mode debugage du protocole RIP exécuter la négation de la commande précédente.

  R1#no debug ip rip	

La commande « debug » est à utiliser avec parcimonie, elle peut s’avérer très consommatrice en ressource et rendre votre équipement réseau inutilisable provoquant un déni de service, elle est a utiliser en dernier recours.

Nous aurons plus d’information quant à la configuration du protocole dans la section à l’aide de la commande

« show ip protocole » et nous filtrerons la section concernant le protocole RIP.

  R1#show ip protocols | s Routing Protocol is "rip"	

Nous avons ici toutes les informations qui seront nécessaire pour le dépannage.

La mise à jour se fait toutes les 30 secondes, la route est considérée comme invalide après 180 secondes de dysfonctionnement où elle passera en down. La route sera effacée de la table de routage après 240 secondes. Le protocoles RIP envoie et reçois des informations via l’interface gig 0/0 et gig0/1.

En exécutant la même commande sur R2, on voit que Gig 0/0 envoie et reçois des paquets des MàJ RIP, or les machines hébergées dans le réseau 192.168.0.0 n’ont pas besoin de recevoir les informations de mise à jour.

Pour une question d’optimisation, il serait intéressant d’exclure l’interface gig 0/0 des MàJ du RIP. Pour ce faire, il nous faudra rendre notre interface passive au paquet RIP.

R2(config)#router rip
 R2(config-router)#passive-interface gigabitEthernet 0/0

Nous pouvons vérifier que la commande a bien été prise en compte en exécutant la commande « show ip protocols » et en filtrant la section qui nous intéresse

  R2#show ip protocols | s Routing Protocol is "rip"	

Ainsi notre routeur ne consommera pas de la ressource inutilement.

La commande auto-summary permet de regrouper les réseaux d’une même classe en une seule entrée pour réduire la taille de la table. Par défaut cette option est activée. En RIPv2, il est possible de la désactivé en exécutant le commande « no auto-summary », ce qu’il sera nécessaire, si vous avez des réseaux avec des adresses IP discontinu

L’article Protocole de routage dynamique RIP est apparu en premier sur Pandawan.