Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Syntaxe de commande

Exemple

Flux des paquets

Informations connexes

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.

Informations générales

L’interface Null est généralement utilisée pour empêcher les boucles de routage. Le protocole EIGRP (Enhanced Interior Gateway Routing Protocol), par exemple, crée toujours une route vers l’interface Null0 lorsqu’il récapitule un groupe de routes. Chaque fois qu’un protocole de routage récapitule, cela signifie que le routeur peut recevoir du trafic pour 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.

Reportez-vous à la section ip route du chapitre : IP Routing Protocol-Independent Commands 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 le réseau entier de 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 qui pointe vers l'interface Null0 du serveur d'accès. Sinon, 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 numéroté 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 un bloc réseau de 192.168.0.0/16. Dans cet exemple, l’utilisateur a divisé 192.168.0.0/16 dans les réseaux /24 et n’utilise que 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 de l’utilisateur (client-R2). Le FAI se connecte ensuite à un FAI de réseau fédérateur, représenté par le routeur BB-R3. Le routeur BB-R3 envoie une route par défaut au FAI-R1 et reçoit le réseau 192.168.0.0/16 via BGP du FAI-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

!--- 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

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

!--- 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 debug 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 cust-R2 ne dispose pas d’une 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 : 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 que celle 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 est la distance administrative. Référez-vous à Décrire la distance administrative pour plus d'informations.

Remarque : Étant donné que vous utilisez une distance administrative plus élevée que 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