Risoluzione dei problemi dei loop di routing di inoltro Cisco Express

Introduzione

Questo documento aiuta a risolvere i problemi dei loop di routing di Cisco Express Forwarding (CEF) e del routing non ottimale causati da una adiacenza di inoltro Cisco Express memorizzata nella cache valida che indica un'interfaccia errata. La creazione di un'adiacenza con un'interfaccia non corretta è dovuta ai seguenti motivi:

• Un percorso statico punta direttamente a un'interfaccia ad accesso multiplo.

• Come risultato delle risposte ARP (Proxy Address Resolution Protocol) è stata creata una adiacenza di inoltro Express Cisco valida.

Prerequisiti

Requisiti

Utilizzare queste risorse per comprendere meglio alcuni dei concetti utilizzati nel presente documento:

• Panoramica di Cisco Express Forwarding

• Selezione route in router Cisco

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Esempio di rete

Il router R1 si connette a R3 tramite Serial 8/0, il router R2 si connette a R4 tramite Serial 8/0. R1 e R2 sono connessi tramite Ethernet 0/0, come mostrato nella figura.

• R2 riceve gli aggiornamenti del prefisso eBGP (Border Gateway Protocol) esterno per 10.10.34.0/24 da R4. R2 propaga questo prefisso a R1 tramite BGP (iBGP) interno.

• R2 dispone di una route statica predefinita (0.0.0.0/0) che punta all'indirizzo IP seriale 8/0 di R4 10.10.24.4.

• R2 dispone anche di un percorso predefinito flottante di backup (percorso IP 0.0.0.0.0.0 Ethernet0/0 10) che punta all'interfaccia Ethernet 0/0 per indirizzare i pacchetti se la connessione seriale tra R2 e R4 non riesce.

• R1 dispone di un percorso predefinito che punta a R3 Serial 8/0 con l'indirizzo IP 10.10.13.3.

Problema

Il traffico IP destinato a 10.10.34.0/24 viene indirizzato tra R1 e R2. Osservare l'output del comando traceroute su 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 ...

Notare che il traffico è destinato a hop 10.10.34.4 tra l'interfaccia Ethernet 0/0 di R1 (indirizzo IP 192.168.12.1) e l'interfaccia Ethernet 0/0 di R2 (indirizzo IP 192.168.12.2). In teoria, il traffico proveniente da R1 e destinato a 10.10.34.0/24 deve andare su R2 a causa del prefisso appreso da iBGP 10.10.34.0/24. Quindi, da R2, il traffico deve essere indirizzato su R4. Tuttavia, l'output del comando traceroute conferma un loop di routing tra R1 e R2.

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

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 
!

Risoluzione dei problemi

Poiché i pacchetti destinati alla versione 10.10.34.4 vengono trasmessi tra R1 e R2, iniziare la risoluzione dei problemi. Controllare anzitutto il routing IP su R1. L'output del comando show ip route 10.10.34.0 conferma l'hop successivo di 192.168.12.2 per i pacchetti destinati a 10.10.34.0/24. Questa condizione corrisponde al primo hop del comando traceroute, dove i pacchetti vengono inviati all'hop successivo di 192.168.12.2, che conferma che i pacchetti sono commutati correttamente su R1.

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

Il passaggio successivo è controllare la tabella di routing IP di R2. Come mostrato nel comando show ip route 10.10.34.0, i pacchetti destinati alla versione 10.10.34.0 devono essere indirizzati all'hop successivo 10.10.24.4 sulla versione 8/0. Tuttavia, il comando traceroute mostra i pacchetti restituiti alla versione 192.168.12.1. È necessario studiare ulteriormente il motivo per cui i pacchetti destinati alla versione 10.10.10 4.0 vengono commutati su R2 all'hop successivo 192.168.12.1 (come nell'output del comando traceroute) anziché su 10.10.24.4.

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

A questo punto è importante capire che in una rete a commutazione di inoltro Cisco Express, una decisione di inoltro di pacchetto consiste in:

• Ricerca nella tabella di routing del prefisso più lungo.

• Ricerca FIB.

Poiché la tabella di routing è stata verificata, esaminare il file FIB di inoltro di Cisco Express. Nei risultati del comando show ip cef 10.10.34.4 detail, notare che gli switch Cisco Express Forwarding 10.10.34.4 out Ethernet 0/0 anziché l'hop successivo 10.10.24.4 out Serial 8/0 (come mostrato nell'output del comando show ip route 10.10.34.0). Questa discrepanza crea loop nella rete.

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

Il passaggio successivo è quello di esaminare la tabella delle adiacenze di Cisco Express Forwarding e vedere come Cisco Express Forwarding apprende a scambiare i pacchetti in uscita da Ethernet 0/0. Si noti che le adiacenze sono costruite a causa di ARP.

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

L'output del comando show ip arp è una conferma.

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

Quindi, scoprire perché questa voce ARP è stata creata quando c'è una route IP nella tabella di routing. Riesaminare la tabella di routing.

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

Se la connessione seriale non riesce tra R2 e R4, tutto il traffico viene instradato con l'uso di un router statico mobile verso Ethernet 0/0 perché R2 ha un percorso statico mobile che punta all'interfaccia a più accessi Ethernet 0/0 e non all'indirizzo IP Ethernet 192.168.12.1 di R1. Pertanto, per tutte le destinazioni sconosciute, il router R2 invia una richiesta ARP tramite l'interfaccia Ethernet 0/0. In questo caso, R2 ha perso il percorso più specifico verso la rete 10.10.34.0. Pertanto, quando il pacchetto dati arriva per gli host su questa rete, genera una richiesta ARP tramite l'interfaccia Ethernet. Poiché il proxy ARP è abilitato per impostazione predefinita sull'interfaccia Ethernet di R1 e dispone di un percorso predefinito che punta a R3, risponde con una risposta ARP proxy con il proprio indirizzo MAC. Di conseguenza, R2 invia tutto il traffico a R1, e R1 inoltra tutto il traffico con l'uso della sua route predefinita (0.0.0.0/0) in AS 12, e di conseguenza a 10.10.34.4 via Internet.

Quando R2 riceve la risposta ARP proxy da R1, crea un'adiacenza /32 valida di Cisco Express Forwarding che indica l'interfaccia Ethernet 0/0. Questa voce di Cisco Express Forwarding non scade finché il router R1 proxy ARP non è presente sul segmento Ethernet. Pertanto, la voce /32 di Cisco Express Forwarding continua a essere utilizzata per Cisco Express Forwarding-switch sui pacchetti, anche dopo il backup della connessione seriale tra R2 e R4 e dopo che il percorso predefinito della tabella di routing ha indicato Serial 8/0 verso AS 10. Il risultato è un loop di routing.

Infine, esaminare i log e verificare se il collegamento seriale (s8/0) è lampeggiato. In questo modo, viene installato un percorso statico mobile nella tabella di routing che a sua volta porta al proxy ARP e determina l'installazione di una voce Cisco Express Forwarding 10.10.34.4/32 nel FIB Cisco Express Forwarding.

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

I registri confermano la causa. In sintesi, questi passaggi mostrano la sequenza degli eventi:

1. Serial 8/0 su R2 non funziona.

2. R2 ha un pacchetto destinato a 10.10.34.4.

3. R2 segue il percorso predefinito di backup puntato direttamente a Ethernet 0/0.

4. R2 invia una richiesta ARP per 10.10.34.4.

5. R1 (Proxy) risponde alla richiesta ARP con il proprio indirizzo MAC a R2.

6. R2 ora ha una voce ARP per 10.10.34.4 con l'indirizzo MAC di R1.

7. R2 crea una adiacenza di Cisco Express Forwarding per 10.10.34.4 e una voce 10.10.34.4/32 viene installata nella FIB (Cisco Express Forwarding Table) per questa destinazione tramite Ethernet 0/0. Questa voce di Cisco Express Forwarding viene mantenuta per tutto il tempo in cui la voce ARP è valida o finché R1 non è presente sul segmento Ethernet.

8. Viene visualizzato Serial 8/0 su R2.

9. R2 apprende la route eBGP 10.10.34.0/24 da R4 con l'hop successivo 10.10.24.4 e installa la route nella tabella di routing IP.

10. R1 apprende il prefisso 10.10.34.0/24 tramite iBGP da R2 e lo installa nella tabella di routing IP.

11. R1 ha un pacchetto destinato a 10.10.34.4.

12. R1 esamina la tabella di routing, associa le route del prefisso iBGP a R2 e le route a R2.

13. R2 riceve un pacchetto destinato alla versione 10.10.34.4. Poiché ha già una voce Cisco Express Forwarding per la versione 10.10.34.4/32 che punta a Ethernet 0/0 nella sua tabella FIB con l'indirizzo MAC di R1, invia il pacchetto a R1 senza esaminare la tabella di routing. Questo si ripete ciclicamente.

Soluzione

Sostituire il percorso statico mobile che punta direttamente a Ethernet 0/0 con uno che punta a un indirizzo di hop successivo.

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

Quando si dispone di un percorso statico che punta all'indirizzo IP dell'hop successivo anziché a un'interfaccia ad accesso multiplo Ethernet 0/0, R2 non invia richieste ARP per tutte le destinazioni. I pacchetti vengono indirizzati e commutati in base all'hop successivo 192.168.12.1. Pertanto, vengono evitate le voci e i loop di inoltro ARP Cisco Express.

Osservare la voce Cisco Express Forwarding su R2 che punta all'interfaccia corretta Serial 8/0.

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

Informazioni correlate

• Risoluzione Dei Problemi Di Bilanciamento Del Carico Su Collegamenti Paralleli Tramite Cisco Express Forwarding
• Come verificare lo switching di inoltro Cisco Express
• Risoluzione dei problemi di incoerenza dei prefissi con Cisco Express Forwarding
• Risoluzione dei problemi relativi alle adiacenze incomplete con Cisco Express Forwarding
• Pagina di supporto per Cisco Express Forwarding
• Pagine di supporto per i protocolli di routing IP
• Documentazione e supporto tecnico – Cisco Systems