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

Introduction

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. Toutes les fois qu'un protocole de routage récapitule, ceci signifie que le routeur pourrait recevoir le trafic pour n'importe quelle adresse IP dans cette récapitulation. 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.

Conditions préalables

Conditions requises

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

Components Used

L’information fournie dans ce document est basée sur les versions logicielles et matérielles suivantes :

• Logiciel Cisco IOS® Version 12.3.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

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 IOS virtuelle. Reportez-vous à la section ip route du chapitre : IP Routing Protocol-Independent Commandes 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 devrez peut-être ajouter une route statique à Null0 est celui d’un serveur d’accès auquel de nombreux clients se connectent. 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, tout en ne diffusant pas l’intégralité du réseau avec des routes d’hôte, 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 disposer de la même route récapitulative pointant vers l’interface Null0 du serveur d’accès. Si ce n’est pas le cas, 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 numéro composé dans le client, mais qui font partie de la route récapitulative. En effet, le serveur d’accès rebondirait les paquets sur la route par défaut du serveur d’accès dans 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 :

Un petit FAI (ISP-R1) fournit à l’un de ses clients un bloc réseau de 192.168.0.0/16. Dans cet exemple, le client 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 client (cust-R2). Le FAI se connecte ensuite à un FAI de backbone, représenté par le routeur BB-R3. Le routeur BB-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 à partir d’Internet (routeur BB-R3 du FAI de backbone) vers le routeur client cust-R2, car cust-R2 a une route par défaut configurée pour pointer vers ISP-R1. Cependant, si des paquets sont destinés à des blocs réseau qui ne sont pas utilisés dans 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 font ensuite une boucle entre ISP-R1 et cust-R2 jusqu’à l’expiration de la durée de vie. Cela peut avoir un impact énorme sur l'utilisation du processeur du routeur et des liaisons. Par exemple, les attaques par déni de service, l’analyse de blocs IP pour trouver des hôtes vulnérables, etc., pourraient être un exemple de l’origine de ce trafic vers des adresses IP inutilisées

Configurations pertinentes :

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 de paquets :

Remarque : Nous avons activé certaines commandes debug 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 que vous ne compreniez 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 requête ICMP unique à 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élai ICMP dépassé en retour du routeur 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 transmis à cust-R2 sur serial0/0 comme prévu. Le même paquet revient à 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

Nous voyons 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 cust-R2 n’a pas de route vers 192.168.20.1, car ce réseau n’est pas utilisé dans le réseau du client. Par conséquent, la meilleure route vers 192.168.20.1 est la route par défaut qui pointe vers ISP-R1.

Le résultat est que les paquets forment une boucle entre ISP-R1 et cust-R2 jusqu’à l’expiration de la durée de vie.

Notez que si la demande ICMP était passée à une adresse IP dans 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ée sur cust-R2, aucune boucle n'aurait eu lieu :

cust-R2# show ip rou 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# conf t
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 nous renvoyons maintenant la requête ICMP de BB-R3 à 192.168.20.1, cust-R2 envoie ce trafic à Null0, ce qui déclenche la génération d'un ICMP inaccessible.

BB-R3# p 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

Remarque : 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 de cust-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 : Il en résulte 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. 200 dans la commande correspond à la distance administrative. Reportez-vous à Qu'est-ce que la distance administrative ? pour plus d'informations.

Remarque : Étant donné que nous utilisons une distance administrative supérieure à 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

• Support et documentation techniques - Cisco Systems