Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment une route statique vers l'interface Null peut empêcher les boucles de routage.
Aucune condition préalable spécifique n'est requise pour ce document.
Les informations de ce document sont basées sur les versions de logiciel et matériel suivantes :
Logiciel Cisco IOS® Version 12.3.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.
L'interface Null est typiquement utilisée pour empêcher les boucles de routage. Enhanced Interior Gateway Routing Protocol (EIGRP), par exemple, crée toujours une route à l'interface Null0 quand elle récapitule un groupe de routes. Chaque fois qu’un protocole de routage résume, cela signifie que le routeur peut recevoir le trafic de n’importe quelle adresse IP dans ce résumé. Puisque toutes les adresses IP ne sont pas toujours en service, il y a un risque de faire une boucle des paquets au cas où les routes par défaut seraient utilisées sur le routeur qui reçoit le trafic pour la récapitulation.
Une route statique vers Null0 est une route statique normale, sauf qu’elle pointe vers l’interface Null0, qui est une interface virtuelle Cisco IOS. Référez-vous à la section ip route du Chapitre : Commandes indépendantes du protocole de routage IP A à R pour plus d'informations sur la commande ip route. La section suivante présente un exemple d'utilisation de la commande ip route pour créer une route statique vers Null0.
Un scénario courant dans lequel vous devez ajouter une route statique à Null0 est celui d'un serveur d'accès qui a de nombreux clients qui composent. Ce scénario entraîne l’installation des routes d’hôte dans la table de routage du serveur d’accès. Pour garantir l’accessibilité à ces clients, sans inonder l’ensemble du réseau de routes hôtes, les autres routeurs du réseau disposent généralement d’une route récapitulative qui pointe vers le serveur d’accès. Dans ce type de configuration, le serveur d'accès doit avoir la même route récapitulative qui pointe vers l'interface Null0 du serveur d'accès. Dans le cas contraire, des boucles de routage peuvent se produire lorsque des hôtes externes tentent d’atteindre des adresses IP qui ne sont pas actuellement attribuées à un client appelé mais qui font partie de la route récapitulative. En effet, le serveur d’accès renvoie les paquets sur la route par défaut du serveur d’accès vers le réseau principal, car le serveur d’accès ne dispose pas d’une route hôte spécifique pour la destination.
Considérez cet exemple :
Topologie du réseau
Un petit FAI (ISP-R1) attribue à l’un des utilisateurs le bloc réseau 192.168.0.0/16. Dans cet exemple, l'utilisateur a divisé 192.168.0.0/16 dans les réseaux /24 et utilise uniquement 192.168.1.0/24 et 192.168.2.0/24 pour le moment. Sur le routeur ISP-R1, le FAI configure une route statique pour 192.168.0.0/16 vers le routeur utilisateur (cust-R2). Le FAI se connecte ensuite à un FAI de réseau fédérateur, représenté par le routeur BB-R3. Le routeur B-R3 envoie une route par défaut à ISP-R1 et reçoit le réseau 192.168.0.0/16 via BGP depuis ISP-R1.
L’accessibilité est désormais garantie d’Internet (routeur fédérateur ISP BB-R3) au routeur utilisateur cust-R2, car cust-R2 a une route par défaut configurée pour pointer vers ISP-R1. Toutefois, si les paquets sont destinés à des blocs réseau qui ne sont pas utilisés en dehors de la plage 192.168.0.0/16, le routeur cust-R2 utilise la route par défaut vers ISP-R1 pour transférer ces paquets. Les packs effectuent ensuite une boucle entre ISP-R1 et cust-R2 jusqu’à l’expiration de la durée de vie. Cela peut avoir un impact considérable sur l'utilisation du processeur et des liaisons du routeur. Les attaques par déni de service, l’analyse des blocs IP pour détecter les hôtes vulnérables, etc., sont autant d’exemples d’où peut provenir ce trafic vers des adresses IP inutilisées.
Configurations appropriées :
cust-R2 |
---|
version 12.3 ! hostname cust-R2 ! ip subnet-zero ! interface Loopback0 ip address 10.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 192.168.1.1 255.255.255.0 ! interface Ethernet1/0 ip address 192.168.2.1 255.255.255.0 ! interface Serial2/0 ip address 10.0.0.2 255.255.255.252 !--- This interface leads to ISP-R1. ! ip classless ip route 0.0.0.0 0.0.0.0 10.0.0.1 !--- Default route going to ISP-R1. ! end |
FAI-R1 |
---|
version 12.3 ! hostname ISP-R1 ! ip subnet-zero ! interface Loopback0 ip address 10.1.1.1 255.255.255.255 ! interface Serial0/0 ip address 10.0.0.1 255.255.255.252 !--- Interface to cust-R2. ! interface Serial1/0 ip unnumbered Loopback0 !--- Interface going to BB-R3. ! router bgp 65501 no synchronization network 192.168.0.0 mask 255.255.0.0 !--- ISP-R1 injects 192.168.0.0/16 into BGP to |
BB-R3 |
---|
version 12.3 ! hostname BB-R3 ! ip subnet-zero ! ! interface Loopback0 ip address 10.3.3.3 255.255.255.255 ! interface Serial2/0 ip unnumbered Loopback0 !--- This interface goes to ISP-R1. ! router bgp 65503 no synchronization bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 65501 neighbor 10.1.1.1 ebgp-multihop 255 neighbor 10.1.1.1 default-originate !--- BB-R3 injects a default route into BGP and |
Remarque : certaines commandes de débogage ont été activées sur les routeurs pour mieux illustrer le flux de paquets, notamment debug ip packet et debug ip icmp. N'activez pas ces commandes dans un environnement de production à moins d'en comprendre parfaitement les conséquences.
BB-R3#ping ip 192.168.20.1 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: *Oct 6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed via FIB *Oct 6 09:36:45.355: IP: s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), len 100, sending. Success rate is 0 percent (0/1) BB-R3# *Oct 6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1
BB-R3 envoie une seule requête ICMP à une adresse IP dans le bloc 192.168.0.0/16 qui n'est pas utilisé sur cust-R2. BB-R3 reçoit un dépassement de délai ICMP en retour de la part d’ISP-R1.
Sur ISP-R1 :
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB 18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward 18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB 18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward 18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB 18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward 18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
Le paquet initial est reçu sur Serial1/0 sur ISP-R1 à partir de BB-R3 et est transféré vers Cust-R2 sur Serial0/0 comme prévu. Le même paquet arrive à ISP-R1 sur serial0/0 et est immédiatement envoyé par la même interface, à cust-R2, en raison de cette route :
ISP-R1#show ip route 192.168.20.1 Routing entry for 192.168.0.0/16, supernet Known via "static", distance 1, metric 0 (connected) Advertised by bgp 65501 Routing Descriptor Blocks: * directly connected, via Serial0/0 Route metric is 0, traffic share count is 1
Que se passe-t-il sur cust-R2 pour qu’il renvoie ce trafic à ISP-R1 ?
Sur cust-R2 :
*Oct 6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward *Oct 6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB *Oct 6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward *Oct 6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB
Vous pouvez voir que cust-R2 renvoie ces paquets à ISP-R1, en raison de cette route :
cust-R2#show ip route 192.168.20.1 longer-prefixes Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 10.0.0.1 to network 0.0.0.0 cust-R2#
Le routeur client-R2 n’a pas de route vers 192.168.20.1, car ce réseau n’est pas utilisé dans le réseau utilisateur. Par conséquent, la meilleure route vers 192.168.20.1 est la route par défaut qui pointe vers ISP-R1.
Il en résulte que les paquets circulent en boucle entre ISP-R1 et cust-R2 jusqu’à l’expiration de la durée de vie.
Si la requête ICMP avait été envoyée à une adresse IP d’un réseau en cours d’utilisation, ce résultat ne se produirait pas. Par exemple, si la requête ICMP était pour 192.168.1.x, qui est directement connecté sur client-R2, aucune boucle n'aurait eu lieu :
cust-R2#show ip route 192.168.1.1 Routing entry for 192.168.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Ethernet0/0 Route metric is 0, traffic share count is 1
La solution à ce problème est de configurer une route statique vers Null0 pour 192.168.0.0/16 sur cust-R2.
cust-R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. cust-R2(config)#ip route 192.168.0.0 255.255.0.0 Null0 cust-R2(config)#end cust-R2# *Oct 6 09:53:18.015: %SYS-5-CONFIG_I: Configured from console by console
cust-R2#show ip route 192.168.20.1 Routing entry for 192.168.0.0/16, supernet Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1
Si vous renvoyez maintenant la requête ICMP de BB-R3 vers 192.168.20.1, cust-R2 envoie ce trafic à Null0, ce qui déclenche la génération d'un ICMP inaccessible.
BB-R3#ping ip 192.168.20.1 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: U Success rate is 0 percent (0/1) BB-R3# *Oct 6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2
Il peut y avoir des situations où l'utilisation d'une route statique récapitulative vers Null0 n'est pas possible. Par exemple, si dans l'exemple précédent :
Le bloc 192.168.1.0/24 est connecté à un autre routeur qui compose le numéro dans client-R2 via RNIS
ISP-R1 n’alloue pas 192.168.0.0/16 mais uniquement 192.168.1.0/24
Une déconnexion de la liaison RNIS se produit
Remarque : le résultat serait que les paquets en transit ou les applications qui tentent d'atteindre ce bloc d'adresses IP créent la même boucle de routage décrite précédemment.
Remarque : pour corriger cette boucle de routage, vous devez utiliser la commande ip route 192.168.1.0 255.255.255.0 Null0 200 pour configurer une route statique flottante vers Null0 pour 192.168.1.0/24. La valeur 200 dans la commande correspond à la distance administrative. Référez-vous à Qu'est-ce que la distance administrative ? pour plus d'informations.
Remarque : comme nous utilisons une distance administrative supérieure à celle de tout protocole de routage, si la route vers 192.168.1.0/24 via la liaison RNIS devient inactive, cust-R2 installe une route statique flottante. Les paquets sont ensuite envoyés à Null0 jusqu’à ce que la liaison RNIS devienne active.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
14-Dec-2001 |
Première publication |