Utiliser une route statique vers l'interface Null0 pour éviter les boucles

Introduction

Ce document décrit comment une route statique vers l'interface Null peut empêcher les boucles de routage.

Conditions préalables

Exigences

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

Informations générales

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.

Syntaxe de commande

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.

Exemple

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 :

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

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 
!--- advertise it to BB-R3.

 neighbor 10.3.3.3 remote-as 65503
 neighbor 10.3.3.3 ebgp-multihop 255
 no auto-summary
!
ip classless
ip route 10.3.3.3 255.255.255.255 Serial1/0
ip route 192.168.0.0 255.255.0.0 Serial0/0

!--- The first route is necessary for the eBGP 
!--- session to BB-R3 to come up.
!--- The route to 192.168.0.0/16 points towards cust-R2.

!
!
end

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 
!--- sends it to ISP-R1.

 no auto-summary
!
ip classless
ip route 10.1.1.1 255.255.255.255 Serial2/0

!--- This route points to ISP-R1 and is 
!--- used to establish the eBGP peering.

!
end

Flux des paquets

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.

Informations connexes

• Assistance technique de Cisco et téléchargements