Fehlerbehebung bei Cisco Express Forwarding Routing Loops

Download-Optionen

  • PDF     (145.5 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (106.1 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (124.5 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:10. August 2005
Dokument-ID:26083

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

Dieses Dokument unterstützt Sie bei der Fehlerbehebung von Cisco Express Forwarding (CEF)-Routing-Schleifen und suboptimalem Routing, die durch eine gültige zwischengespeicherte Cisco Express Forwarding-Adjacency verursacht werden, die auf die falsche Schnittstelle hinweist. Eine Adjacency mit einer falschen Schnittstelle wird aus folgenden Gründen erstellt:

Voraussetzungen

Anforderungen

Verwenden Sie diese Ressourcen, um einige der in diesem Dokument verwendeten Konzepte besser zu verstehen:

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Netzwerkdiagramm

Der Router R1 ist über serielle 8/0 mit R3 verbunden, der Router R2 über serielle 8/0 mit R4. R1 und R2 sind über Ethernet 0/0 verbunden, wie die folgende Abbildung zeigt.

trouble_cef_01.gif

  • R2 empfängt eBGP-Prefix-Updates (externes Border Gateway Protocol) für 10.10.34.0/24 von R4. R2 propagiert dieses Präfix über internes BGP (iBGP) an R1.

  • R2 verfügt über eine statische Standardroute (0.0.0.0/0), die auf die IP-Adresse 10.10.24.4 von R4 für Serial 8/0 verweist.

  • R2 verfügt außerdem über eine Backup-Floating-Standardroute (IP-Route 0.0.0.0 0.0 Ethernet0/0 10), die auf Ethernet 0/0 verweist, um Pakete weiterzuleiten, wenn die serielle Verbindung zwischen R2 und R4 ausfällt.

  • R1 verfügt über eine Standardroute, die auf die Serial 8/0 von R3 mit der IP-Adresse 10.10.13.3 zeigt.

Problem

IP-Datenverkehr, der für 10.10.34.0/24 bestimmt ist, wird zwischen R1 und R2 hin- und hergeleitet. Beachten Sie die Ausgabe des Traceroute-Befehls auf R1. 

R1#traceroute 10.10.34.4 
 
Type escape sequence to abort. 
Tracing the route to 10.10.34.4 
 
  1 192.168.12.2 20 msec 20 msec 20 msec 
  2 192.168.12.1 8 msec 12 msec 8 msec 
  3 192.168.12.2 8 msec 8 msec 12 msec 
  4 192.168.12.1 12 msec ...

Beachten Sie, dass der Datenverkehr für 10.10.34.4-Hops zwischen dem Ethernet 0/0 von R1 (IP-Adresse 192.168.12.1) und dem Ethernet 0/0 von R2 (IP-Adresse 192.168.12.2) bestimmt ist. Im Idealfall muss der Datenverkehr von R1, der für 10.10.34.0/24 bestimmt ist, aufgrund des vom iBGP erlernten Präfix 10.10.34.0/24 an R2 weitergeleitet werden. Anschließend sollte der Datenverkehr von R2 an R4 weitergeleitet werden. Die Ausgabe des Traceroute-Befehls bestätigt jedoch eine Routing-Schleife zwischen R1 und R2.

R1 
hostname R1 
! 
ip subnet-zero 
! 
ip cef 
! 
interface Ethernet0/0 
 ip address 192.168.12.1 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.13.1 255.255.255.0 
! 
router bgp 11 
 no synchronization 
 bgp log-neighbor-changes 
 neighbor 10.10.13.3 remote-as 12
 neighbor 192.168.12.2 remote-as 11 
 no auto-summary 
!  
ip route 0.0.0.0 0.0.0.0 10.10.13.3

R2 
hostname  R2 
! 
ip cef 
! 
interface Ethernet0/0 
  ip address 192.168.12.2 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.24.2 255.255.255.0 
! 
router bgp 11 
 no synchronization 
bgp log-neighbor-changes 
 network 192.168.12.0 
 neighbor 10.10.24.4 remote-as 10 
 neighbor 192.168.12.1 remote-as 11 
 neighbor 192.168.12.1 next-hop-self 
 no auto-summary 
! 
ip route 0.0.0.0 0.0.0.0 10.10.24.4 
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10 
!

Fehlerbehebung

Da die Pakete, die für 10.10.34.4 bestimmt sind, zwischen R1 und R2 schleifen, beginnen Sie mit der Fehlerbehebung. Überprüfen Sie zunächst das IP-Routing auf R1. Die Befehlsausgabe show ip route 10.10.34.0 bestätigt den nächsten Hop von 192.168.12.2 für Pakete, die für 10.10.34.0/24 bestimmt sind. Dies stimmt mit dem Befehl traceroute first hop überein, bei dem Pakete an den nächsten Hop 192.168.12.2 gesendet werden, wodurch bestätigt wird, dass Pakete auf R1 ordnungsgemäß geswitcht werden. 

R1#show ip route 10.10.34.0 
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 200, metric 0
  Tag 10, type internal
  Last update from 192.168.12.2 00:22:59 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 192.168.12.2, 00:22:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

Im nächsten Schritt wird die IP-Routing-Tabelle von R2 überprüft. Wie diese Ausgabe des Befehls show ip route 10.10.34.0 zeigt, sollten Pakete, die für 10.10.34.0 bestimmt sind, auf Serial 8/0 an den nächsten Hop 10.10.24.4 weitergeleitet werden. Der Befehl traceroute zeigt jedoch Pakete an, die zurück zu R1 an die IP-Adresse 192.168.12.1 gesendet wurden. Es ist eine weitere Untersuchung erforderlich, warum Pakete, die für 10.10.34.0 bestimmt sind, auf R2 auf den nächsten Hop 192.168.12.1 (wie bei der Ausgabe des Befehls traceroute) anstatt auf 10.10.24.4 umgestellt werden. 

R2#show ip route 10.10.34.0
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 20, metric 0
  Tag 10, type external
  Last update from 10.10.24.4 00:42:32 ago
  Routing Descriptor Blocks:
  * 10.10.24.4, from 10.10.24.4, 00:42:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

An diesem Punkt ist es wichtig zu verstehen, dass in einem Cisco Express Forwarding-Switched-Netzwerk eine Entscheidung für die Paketweiterleitung besteht aus:

  • Eine Suche in der Routing-Tabelle nach der längsten Präfix-Übereinstimmung.

  • Eine FIB-Suche (Forwarding Information Base).

Da die Routing-Tabelle verifiziert ist, sehen Sie sich die FIB für Cisco Express Forwarding an. In den Ergebnissen des Befehls show ip cef 10.10.34.4 detail beachten Sie, dass Cisco Express Forwarding 10.10.34.4 out Ethernet 0/0 anstatt Next Hop 10.10.24.4 out Serial 8/0 (wie in der show ip route 10.10 gezeigt) Befehlsausgabe 34.0). Diese Diskrepanz erzeugt Schleifen im Netzwerk. 

R2#show ip cef 10.10.34.4 detail
10.10.34.4/32, version 19, cached adjacency 10.10.34.4
0 packets, 0 bytes
  via 10.10.34.4, Ethernet0/0, 0 dependencies
    next hop 10.10.34.4, Ethernet0/0
    valid cached adjacency

Im nächsten Schritt sehen Sie sich die Adjacency-Tabelle von Cisco Express Forwarding an, und erfahren Sie, wie Cisco Express Forwarding lernt, Pakete über Ethernet 0/0 auszutauschen. Beachten Sie, dass die Adjacency durch ARP erstellt wird. 

R2#show adjacency ethernet 0/0 detail | begin  10.10.34.4 
IP       Ethernet0/0               10.10.34.4(5)
                                   50 packets, 2100 bytes
                                   AABBCC006500AABBCC0066000800
                                   ARP        03:02:00

Diese Ausgabe des Befehls show ip arp ist eine Bestätigung. 

R2#show ip arp 10.10.34.4
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.34.4             60   aabb.cc00.6500  ARPA   Ethernet0/0

Finden Sie anschließend heraus, warum dieser ARP-Eintrag erstellt wurde, wenn in der Routing-Tabelle eine IP-Route vorhanden ist. Überprüfen Sie die Routing-Tabelle noch einmal. 

R2#show run | include ip route 0.0.0.0
ip route 0.0.0.0 0.0.0.0 10.10.24.4
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10

Wenn die serielle Verbindung zwischen R2 und R4 ausfällt, wird der gesamte Datenverkehr mithilfe einer fließenden statischen Route über Ethernet 0/0 geroutet, da R2 über eine bewegliche statische Route verfügt, die auf die Multizugriffsschnittstelle Ethernet 0/0 und nicht auf die Ethernet-IP-Adresse 192.168.12.1 von R1 zeigt. Daher sendet Router R2 für alle unbekannten Ziele eine ARP-Anfrage über die Ethernet0/0-Schnittstelle. In diesem Fall hat R2 die spezifischere Route zum Netzwerk 10.10.34.0 verloren. Wenn das Datenpaket für die Hosts in diesem Netzwerk eingeht, generiert es daher eine ARP-Anforderung über die Ethernet-Schnittstelle. Da der Proxy-ARP auf der Ethernet-Schnittstelle von R1 standardmäßig aktiviert ist und eine Standardroute auf R3 verweist, antwortet er mit einer Proxy-ARP-Antwort mit einer eigenen MAC-Adresse. Somit sendet R2 den gesamten Datenverkehr an R1, und R1 leitet den gesamten Datenverkehr mithilfe der Standardroute (0.0.0.0/0) an AS 12 und somit über das Internet an 10.10.34.4 weiter.

Wenn R2 die Proxy-ARP-Antwort von R1 empfängt, wird eine /32 gültige Cisco Express Forwarding-Adjacency erstellt, die auf die Schnittstelle Ethernet 0/0 verweist. Dieser Eintrag für die Cisco Express-Weiterleitung wird erst ausgefallen, wenn der Proxy-ARP-Router R1 im Ethernet-Segment vorhanden ist. Daher wird der /32 Cisco Express Forwarding-Eintrag weiterhin für den Cisco Express Forwarding-Switch für die Pakete verwendet, auch nachdem die serielle Verbindung zwischen R2 und R4 gesichert ist und die Standardroute der Routing-Tabelle auf Serial 8/0 zu AS 10 verweist. Das Ergebnis ist eine Routing-Schleife.

Überprüfen Sie abschließend die Protokolle, und prüfen Sie, ob die serielle Verbindung (s8/0) flattert ist. Dies führt dazu, dass in der Routing-Tabelle eine Floating-statische Route installiert wird, die dann zum Proxy-ARP führt und zur Installation eines Cisco Express Forwarding-Eintrags von 10.10.34.4/32 in der FIB für Cisco Express Forwarding führt. 

R2#show log | beg Ethernet0/0
[..]
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to down
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Down Interface flap
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to up
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Up

Die Protokolle bestätigen die Ursache. Zusammenfassend lässt sich sagen, dass diese Schritte die Abfolge der Ereignisse zeigen:

  1. Serial 8/0 auf R2 fällt aus.

  2. R2 hat ein Paket, das für 10.10.34.4 bestimmt ist.

  3. R2 folgt der Backup-Standardroute, die direkt auf Ethernet 0/0 zeigt.

  4. R2 sendet eine ARP-Anfrage für 10.10.34.4.

  5. R1 (Proxy) antwortet auf die ARP-Anfrage mit einer eigenen MAC-Adresse für R2.

  6. R2 hat jetzt einen ARP-Eintrag für 10.10.34.4 mit der MAC-Adresse R1.

  7. R2 erstellt eine Cisco Express Forwarding-Adjacency für 10.10.34.4 und ein 10.10.34.4/32-Eintrag wird in der Cisco Express Forwarding-Tabelle (FIB) für dieses Ziel über Ethernet 0/0 installiert. Dieser Cisco Express Forwarding-Eintrag wird so lange beibehalten, wie der ARP-Eintrag gültig ist oder bis R1 im Ethernet-Segment vorhanden ist.

  8. Serial 8/0 auf R2 wird aktiviert.

  9. R2 bezieht die eBGP-Route 10.10.34.0/24 von R4 mit dem nächsten Hop 10.10.24.4 und installiert die Route in der IP-Routing-Tabelle.

  10. R1 erhält das Präfix 10.10.34.0/24 via iBGP von R2 und installiert es in der IP-Routing-Tabelle.

  11. R1 hat ein Paket, das für 10.10.34.4 bestimmt ist.

  12. R1 überprüft die Routing-Tabelle, vergleicht die iBGP-Präfixrouten mit R2 und leitet Routen zu R2 weiter.

  13. R2 empfängt ein Paket, das für 10.10.34.4 bestimmt ist. Da bereits ein Cisco Express Forwarding-Eintrag für 10.10.34.4/32 vorhanden ist, der auf Ethernet 0/0 in der FIB-Tabelle mit der MAC-Adresse von R1 verweist, wird das Paket ohne die Routing-Tabelle zurück an R1 gesendet. Dadurch wird eine Schleife erstellt.

Lösung

Ersetzen Sie die fließende statische Route, die direkt auf Ethernet 0/0 zeigt, durch eine Route, die auf eine Next-Hop-Adresse zeigt. 

R2(config)#no ip route 0.0.0.0 0.0.0.0 ethernet 0/0 10
R2(config)# ip route 0.0.0.0 0.0.0.0 192.168.12.1 10

Wenn Sie eine statische Route haben, die auf die nächste Hop-IP-Adresse verweist, statt auf eine Multi-Access-Schnittstelle Ethernet 0/0, verhindert sie, dass R2 ARP-Anfragen für alle Ziele sendet. Die Pakete werden basierend auf dem nächsten Hop 192.168.12.1 geroutet und geswitcht. Daher werden alle ARP Cisco Express Forwarding-Einträge und -Schleifen vermieden.

Beachten Sie den Cisco Express Forwarding-Eintrag auf R2, der auf die richtige Schnittstelle Serial 8/0 zeigt. 

R2#show ip cef 10.10.34.4
10.10.34.0/24, version 32, cached adjacency to Serial8/0
0 packets, 0 bytes
  via 10.10.24.4, 0 dependencies, recursive
    next hop 10.10.24.4, Serial8/0 via 10.10.24.0/24
    valid cached adjacency

Zugehörige Informationen

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren