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.

Composants utilisés

Les informations dans ce document sont basées sur les versions de logiciel et de matériel ci-dessous.

• Version de logiciel 12.3 de Cisco IOS®.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). 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 utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

Syntaxe de commande

Une artère statique à Null0 est une artère statique normale, sauf qu'elle indique l'interface Null0, qui est une interface IOS virtuelle. Référez-vous aux commandes de protocoles de Routage IP : Je sectionne de la référence de commandes IP de Cisco IOS, le volume 2 de 4 : Protocoles de routage, version 12.3 pour plus d'informations sur la commande d'artère d'IP. La section suivante présente un exemple de la façon utiliser la commande d'artère d'IP de créer une artère statique à Null0.

Exemple

Un scénario commun où vous pouvez devoir ajouter une artère statique à Null0 est celui d'un serveur d'accès qui a se connecter de beaucoup de clients. Ce scénario cause des routes hôte d'être installées dans la table de routage de serveur d'accès. Pour assurer l'accessibilité à ces clients, tout en n'inondant pas le tout le réseau avec des routes hôte, d'autres Routeurs dans le réseau ont typiquement une route récapitulative qui indique le serveur d'accès. Dans ce type de configuration, le serveur d'accès devrait avoir que la même route récapitulative indiquant l'interface du serveur d'accès Null0. Sinon, les boucles de routage peuvent se produire quand la tentative extérieure d'hôtes d'atteindre des adresses IP pas actuellement assignées à un client connecté mais font partie de la route récapitulative. C'est parce que le serveur d'accès rebondirait les paquets de retour au-dessus du default route de serveur d'accès dans le principal réseau, parce que le serveur d'accès manque d'une artère d'hôte spécifique pour la destination.

Considérez cet exemple :

Un petit ISP (ISP-R1) donne à un de ses clients un bloc de réseau de 192.168.0.0/16. Dans cet exemple, le client a divisé 192.168.0.0/16 dans les réseaux et seulement les utilisations 192.168.1.0/24 et 192.168.2.0/24 de /24 à l'heure actuelle. Sur le routeur ISP-R1, l'ISP configure une artère statique pour 192.168.0.0/16 vers le routeur client (cust-R2). L'ISP se connecte alors à un ISP de circuit principal, représenté par le routeur BB-R3. Le routeur BB-R3 envoie un default route à ISP-R1 et reçoit le réseau 192.168.0.0/16 par l'intermédiaire du BGP d'ISP-R1.

L'accessibilité est maintenant garantie de l'Internet (routeur de l'ISP BB-R3 de circuit principal) au routeur client cust-R2 parce que cust-R2 a un default route configuré pour indiquer ISP-R1. Cependant, si des paquets sont destinés aux blocs de réseau qui sont non utilisables hors de la plage 192.168.0.0/16, puis le routeur cust-R2 emploie le default route à ISP-R1 pour expédier ces paquets. Les paquets font une boucle alors entre ISP-R1 et cust-R2 jusqu'à ce que le TTL expire. Ceci peut avoir une incidence énorme sur la CPU de routeur et joindre l'utilisation. Un exemple d'où ce trafic aux adresses IP inutilisées pourrait provenir pourrait être des attaques par déni de service, balayage des blocs IP pour trouver les hôtes vulnérables, etc.

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

Écoulement de paquet :

Remarque: Nous avons activé quelques commandes de débogage sur les Routeurs d'illustrer mieux l'écoulement de paquet, notamment debug ip packet et debug ip icmp. N'activez pas ces commandes dans un environnement de production à moins que vous comprenniez entièrement 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 demande simple d'ICMP à une adresse IP dans le bloc 192.168.0.0/16 qui est non utilisable sur cust-R2. BB-R3 reçoit un temps d'ICMP dépassé de retour 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 de BB-R3 et est expédié à cust-R2 de serial0/0 comme prévu. Le même paquet arrive de retour à ISP-R1 sur serial0/0 et est envoyé immédiatement à la même interface, à cust-R2, en raison de cette artère :

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 produit sur cust-R2 qui le fait envoyer ce trafic de nouveau à 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 envoie ces paquets de nouveau à ISP-R1, en raison de cette artère :

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 une artère à 192.168.20.1 parce que ce réseau est non utilisable dans le réseau client, ainsi la meilleure route à 192.168.20.1 est le default route qui indique ISP-R1.

Le résultat est que les paquets font une boucle entre ISP-R1 et cust-R2 jusqu'à ce que le TTL expire.

Notez que si la demande d'ICMP était allée à une adresse IP dans un réseau qui est en service, ce résultat ne se produirait pas. Par exemple, si la demande d'ICMP était pour 192.168.1.x, qui est directement connecté sur cust-R2, aucun bouclage ne se serait produit :

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 au problème est de configurer une artère statique à 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 demande d'ICMP de BB-R3 à 192.168.20.1, cust-R2 envoie ce trafic à Null0, qui déclenche un ICMP inaccessible pour être généré.

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ésumée à Null0 n'est pas faisable. Par exemple, si dans l'exemple précédent :

• Le bloc 192.168.1.0/24 est connecté à un autre routeur qui introduit dans cust-R2 par l'intermédiaire du RNIS

• ISP-R1 n'alloue pas 192.168.0.0/16 mais seulement 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 plus tôt.

Remarque: Pour réparer cette boucle de routage, vous devez utiliser la commande de 192.168.1.0 255.255.255.0 Null0 200 d'artère d'IP de configurer une Route statique flottante à Null0 pour 192.168.1.0/24. Les 200 dans la commande est la distance administrative. Référez-vous à ce qui est distance administrative ? pour plus d'informations.

Remarque: Puisque nous utilisons une distance administrative plus élevée que n'importe quel protocole de routage, si l'artère à 192.168.1.0/24 par l'intermédiaire de la liaison RNIS devient inactive, cust-R2 installe une Route statique flottante. Des paquets sont alors envoyés à Null0 jusqu'à ce que la liaison RNIS devienne active.

Informations connexes

• Support technique - Cisco Systems