Verwenden Sie eine statische Route zur Null0-Schnittstelle für die Loop-Verhinderung.

Einleitung

Dieses Dokument beschreibt, wie eine statische Route zur Null-Schnittstelle Routing-Schleifen verhindern kann.

Voraussetzungen

Anforderungen

Es sind keine besonderen Voraussetzungen erforderlich, um den Inhalt dieses Dokuments nachzuvollziehen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den Software- und Hardwareversionen:

• Cisco IOS^® Softwareversion 12.3

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den technischen Tipps von Cisco zu Konventionen.

Hintergrundinformationen

Die Null-Schnittstelle wird normalerweise verwendet, um Routing-Schleifen zu verhindern. Enhanced Interior Gateway Routing Protocol (EIGRP) erstellt beispielsweise immer eine Route zur Null0-Schnittstelle, wenn eine Routengruppe zusammengefasst wird. Bei jeder Zusammenfassung eines Routing-Protokolls bedeutet dies, dass der Router Datenverkehr für jede IP-Adresse in dieser Zusammenfassung empfangen kann. Da nicht alle IP-Adressen immer verwendet werden, besteht das Risiko, dass Pakete in Looping-Fällen verwendet werden, wenn auf dem Router, der den Datenverkehr für die Zusammenfassung empfängt, Standardrouten verwendet werden.

Befehlssyntax

Eine statische Route zu Null0 ist eine normale statische Route, mit der Ausnahme, dass sie auf die Null0-Schnittstelle verweist, die eine virtuelle Cisco IOS-Schnittstelle ist. Weitere Informationen zum Befehl ip route finden Sie im Abschnitt IP-Routing-Abschnitt des Kapitels: IP Routing Protocol-Independent Commands A bis R (Unabhängige Befehle des IP-Routing-Protokolls A bis R). Im nächsten Abschnitt wird ein Beispiel für die Verwendung des Befehls ip route zum Erstellen einer statischen Route nach Null0 dargestellt.

Beispiel

Ein gängiges Szenario, in dem Sie eine statische Route zu Null0 hinzufügen müssen, ist das eines Zugriffsservers, der viele Clients hat, die sich einwählen. In diesem Szenario werden in der Routingtabelle des Zugriffsservers Hostrouten installiert. Um die Erreichbarkeit für diese Clients zu gewährleisten, ohne das gesamte Netzwerk mit Host-Routen zu überfluten, verfügen andere Router im Netzwerk in der Regel über eine zusammengefasste Route, die auf den Zugriffsserver verweist. Bei diesem Konfigurationstyp muss der Zugriffsserver über dieselbe zusammengefasste Route verfügen, die auf die Null0-Schnittstelle des Zugriffsservers verweist. Wenn dies nicht der Fall ist, können Routing-Schleifen auftreten, wenn externe Hosts versuchen, IP-Adressen zu erreichen, die derzeit nicht einem gewählten Client zugewiesen sind, aber Teil der zusammengefassten Route sind. Der Grund hierfür ist, dass der Zugriffsserver die Pakete über die Standardroute des Zugriffsservers zurück in das Core-Netzwerk zurücksenden würde, da der Zugriffsserver keine spezifische Hostroute für das Ziel hat.

Betrachten Sie dieses Beispiel:

Netzwerktopologie

Ein kleiner ISP (ISP-R1) gibt einem Benutzer den Netzwerkblock 192.168.0.0/16. In diesem Beispiel hat der Benutzer 192.168.0.0/16 in /24-Netzwerke unterteilt und verwendet derzeit nur 192.168.1.0/24 und 192.168.2.0/24. Auf dem Router ISP-R1 konfiguriert der ISP eine statische Route für 192.168.0.0/16 in Richtung des Benutzer-Routers (cust-R2). Der ISP stellt dann eine Verbindung zu einem Backbone-ISP her, der durch den Router BB-R3 repräsentiert wird. Router BB-R3 sendet eine Standardroute an ISP-R1 und empfängt das Netzwerk 192.168.0.0/16 per BGP von ISP-R1.

Die Erreichbarkeit vom Internet (Backbone-ISP-Router BB-R3) bis zum Benutzer-Router cust-R2 ist nun gewährleistet, da cust-R2 über eine Standardroute verfügt, die so konfiguriert ist, dass sie auf ISP-R1 verweist. Wenn Pakete jedoch für Netzwerkblöcke bestimmt sind, die außerhalb des Bereichs 192.168.0.0/16 nicht verwendet werden, verwendet der Kunde-R2-Router die Standardroute zu ISP-R1, um diese Pakete weiterzuleiten. Die Pakete werden dann zwischen ISP-R1 und cust-R2 hin und her geschleift, bis der TTL abläuft. Dies kann sich erheblich auf die CPU- und Verbindungsauslastung des Routers auswirken. Ein Beispiel dafür, woher dieser Datenverkehr zu nicht verwendeten IP-Adressen kommen kann, sind Denial-of-Service-Angriffe, das Scannen von IP-Blöcken, um anfällige Hosts zu finden, usw.

Relevante Konfigurationen:

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

Paketfluss

Hinweis: Einige Debug-Befehle wurden auf den Routern aktiviert, um den Paketfluss besser zu veranschaulichen, insbesondere debug ip packet und debug ip icmp. Aktivieren Sie diese Befehle nicht in einer Produktionsumgebung, es sei denn, Sie kennen die Konsequenzen genau.

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 sendet eine einzelne ICMP-Anforderung an eine IP-Adresse innerhalb des Blocks 192.168.0.0/16, der auf cust-R2 nicht verwendet wird. Der BB-R3 empfängt eine ICMP-Zeit, die von ISP-R1 überschritten wurde.

Auf 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

Das erste Paket wird auf seriell1/0 auf ISP-R1 von BB-R3 empfangen und wie erwartet an cust-R2 auf seriell0/0 weitergeleitet. Dasselbe Paket erreicht ISP-R1 über serial0/0 und wird aufgrund der folgenden Route sofort über dieselbe Schnittstelle an cust-R2 gesendet:

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

Was passiert mit Kunde-R2, das diesen Datenverkehr an ISP-R1 zurücksendet?

Bei Kunde-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

Sie können sehen, dass cust-R2 diese Pakete aufgrund der folgenden Route an ISP-R1 zurücksendet:

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#

Router cust-R2 hat keine Route zu 192.168.20.1, da dieses Netzwerk im Benutzernetzwerk nicht verwendet wird. Die beste Route zu 192.168.20.1 ist daher die Standardroute, die auf ISP-R1 verweist.

Das Ergebnis ist, dass die Pakete zwischen ISP-R1 und cust-R2 schleifen, bis der TTL abläuft.

Wenn die ICMP-Anforderung an eine IP-Adresse in einem Netzwerk gegangen wäre, das gerade verwendet wird, würde dieses Ergebnis nicht auftreten. Wenn die ICMP-Anforderung beispielsweise für 192.168.1.x galt, die direkt mit cust-R2 verbunden ist, wäre keine Schleife aufgetreten:

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

Die Lösung für dieses Problem besteht darin, eine statische Route zu Null0 für 192.168.0.0/16 auf cust-R2 zu konfigurieren.

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

Wenn Sie nun die ICMP-Anforderung von BB-R3 erneut an 192.168.20.1 senden, sendet cust-R2 diesen Datenverkehr an Null0, wodurch ein ICMP generiert wird, bei dem keine Erreichbarkeit mehr möglich ist.

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

Es kann Situationen geben, in denen die Verwendung einer zusammengefassten statischen Route zu Null0 nicht möglich ist. Wenn im vorherigen Beispiel:

• Block 192.168.1.0/24 ist mit einem anderen Router verbunden, der sich über ISDN in cust-R2 einwählt

• ISP-R1 weist 192.168.0.0/16 nicht zu, sondern nur 192.168.1.0/24

• Eine Trennung der ISDN-Verbindung erfolgt

Hinweis: Das Ergebnis wäre, dass übertragene Pakete oder Anwendungen, die versuchen, diesen Block von IP-Adressen zu erreichen, dieselbe Routing-Schleife erzeugen, die zuvor beschrieben wurde.

Hinweis: Um diesen Routing-Loop zu beheben, müssen Sie den Befehl ip route 192.168.1.0 255.255.0 Null0 200 verwenden, um eine schwebende statische Route für 192.168.1.0/24 auf Null0 zu konfigurieren. Die 200 im Befehl ist die administrative Distanz. Weitere Informationen finden Sie unter Was ist die administrative Distanz?.

Hinweis: Da wir eine größere administrative Distanz als jedes Routing-Protokoll verwenden, installiert cust-R2 eine variable statische Route, wenn die Route zu 192.168.1.0/24 über die ISDN-Verbindung inaktiv wird. Pakete werden dann an Null0 gesendet, bis die ISDN-Verbindung aktiv wird.

Zugehörige Informationen

• Technischer Support und Downloads von Cisco