Usa route statica all'interfaccia Null0 per la prevenzione dei loop

Introduzione

In questo documento viene descritto come una route statica all'interfaccia Null possa impedire loop di routing.

Prerequisiti

Requisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano sulle versioni software e hardware:

• Software Cisco IOS^® versione 12.3.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

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

Premesse

L'interfaccia Null viene in genere utilizzata per impedire loop di routing. Il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol), ad esempio, crea sempre una route all'interfaccia Null0 quando riepiloga un gruppo di route. Il riassunto di un protocollo di routing indica che il router può ricevere traffico per qualsiasi indirizzo IP contenuto in tale riepilogo. Poiché non tutti gli indirizzi IP sono sempre in uso, esiste il rischio di loop dei pacchetti nel caso in cui vengano utilizzati i percorsi predefiniti sul router che riceve il traffico per il riepilogo.

Sintassi dei comandi

Una route statica verso Null0 è una normale route statica, ad eccezione del fatto che punta all'interfaccia Null0, che è un'interfaccia Cisco IOS virtuale. Per ulteriori informazioni sul comando ip route, consultare la sezione ip route del capitolo: IP Routing Protocol-Independent Commands dalla A alla R. Nella sezione seguente viene illustrato un esempio di come utilizzare il comando ip route per creare una route statica a Null0.

Esempio

Uno scenario comune in cui può essere necessario aggiungere una route statica a Null0 è quello di un server di accesso che dispone di più client che si connettono. In questo scenario vengono installate le route host nella tabella di routing del server di accesso. Per garantire la raggiungibilità di questi client, senza sovraccaricare l'intera rete con percorsi host, gli altri router della rete in genere dispongono di un percorso di riepilogo che punta al server di accesso. In questo tipo di configurazione, il server di accesso deve avere la stessa route di riepilogo che punta all'interfaccia Null0 del server di accesso. In caso contrario, si possono verificare loop di routing quando gli host esterni tentano di raggiungere indirizzi IP non attualmente assegnati a un client chiamato ma che fanno parte della route di riepilogo. Infatti, il server di accesso rinvierebbe i pacchetti sulla route predefinita del server di accesso alla rete principale, in quanto il server di accesso non dispone di una route host specifica per la destinazione.

Considerate questo esempio:

Topologia della rete

Un piccolo ISP (ISP-R1) dà a uno degli utenti un blocco di rete di 192.168.0.0/16. In questo esempio, l'utente ha diviso 192.168.0.0/16 nelle reti /24 e attualmente utilizza solo 192.168.1.0/24 e 192.168.2.0/24. Sul router ISP-R1, l'ISP configura un percorso statico per 192.168.0.0/16 verso il router utente (cust-R2). L'ISP si connette quindi a un ISP backbone, rappresentato dal router B-R3. Il router B-R3 invia un percorso predefinito all'ISP-R1 e riceve la rete 192.168.0.0/16 tramite BGP dall'ISP-R1.

La raggiungibilità è ora garantita da Internet (router ISP backbone BB-R3) al router utente cust-R2 perché cust-R2 ha un percorso predefinito configurato per puntare a ISP-R1. Tuttavia, se i pacchetti sono destinati a blocchi di rete che non sono in uso all'interno dell'intervallo 192.168.0.0/16, il router cust-R2 utilizzerà il percorso predefinito all'ISP-R1 per inoltrare i pacchetti. I pacchetti quindi eseguono un loop tra ISP-R1 e cust-R2 fino alla scadenza del TTL. Questo può avere un impatto enorme sull'utilizzo della CPU e del collegamento del router. Un esempio di da dove può provenire questo traffico verso indirizzi IP inutilizzati potrebbe essere costituito dagli attacchi Denial of Service, dalla scansione dei blocchi IP per trovare host vulnerabili e così via.

Configurazioni rilevanti:

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

Flusso dei pacchetti

Nota: alcuni comandi di debug sono stati abilitati sui router per illustrare meglio il flusso del pacchetto, in particolare debug ip packet e debug ip icmp. Non abilitare questi comandi in un ambiente di produzione a meno che non se ne comprendano appieno le conseguenze.

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 invia una singola richiesta ICMP a un indirizzo IP all'interno del blocco 192.168.0.0/16 che non è in uso su cust-R2. BB-R3 riceve un tempo ICMP scaduto dall'ISP-R1.

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

Il pacchetto iniziale viene ricevuto su serial1/0 su ISP-R1 da BB-R3 e inoltrato a cust-R2 su serial0/0 come previsto. Lo stesso pacchetto torna all'ISP-R1 su serial0/0 e viene inviato immediatamente alla cust-R2 attraverso la stessa interfaccia, a causa di questo percorso:

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

Cosa succede a cust-R2 che provoca il rinvio del traffico all'ISP-R1?

Su 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

È possibile notare che cust-R2 invia questi pacchetti all'ISP-R1, a causa di questo percorso:

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#

Il router cust-R2 non ha un percorso verso 192.168.20.1 perché questa rete non è in uso nella rete degli utenti, quindi il percorso migliore per 192.168.20.1 è il percorso predefinito che punta a ISP-R1.

Di conseguenza, i pacchetti vengono trasmessi tra ISP-R1 e cust-R2 finché non scade il valore TTL.

Se la richiesta ICMP fosse stata inviata a un indirizzo IP all'interno di una rete in uso, il risultato non sarebbe stato possibile. Ad esempio, se la richiesta ICMP era per 192.168.1.x, collegato direttamente a cust-R2, non si sarebbe verificato alcun loop:

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

Per risolvere questo problema, configurare una route statica a Null0 per 192.168.0.0/16 su 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

Se si invia nuovamente la richiesta ICMP da BB-R3 a 192.168.20.1, cust-R2 invia il traffico a Null0, che attiva la generazione di un messaggio ICMP "destinazione irraggiungibile".

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

In alcuni casi non è possibile utilizzare una route statica di riepilogo a Null0. Ad esempio, se nell'esempio precedente:

• Il blocco 192.168.1.0/24 è collegato a un altro router che esegue la chiamata a cust-R2 tramite ISDN

• ISP-R1 non alloca 192.168.0.0/16 ma solo 192.168.1.0/24

• Il collegamento ISDN viene disconnesso

Nota: di conseguenza, i pacchetti in transito o le applicazioni che tentano di raggiungere questo blocco di indirizzi IP creano lo stesso loop di routing descritto in precedenza.

Nota: per correggere il loop di routing, usare il comando ip route 192.168.1.0 255.255.255.0 Null0 200 per configurare una route statica mobile per Null0 per 192.168.1.0/24. Il valore 200 nel comando è la distanza amministrativa. Per ulteriori informazioni, vedere Che cos'è la distanza amministrativa? (What Is Administrative Distance?).

Nota: poiché la distanza amministrativa è maggiore rispetto a qualsiasi protocollo di routing, se il percorso verso 192.168.1.0/24 tramite il collegamento ISDN diventa inattivo, cust-R2 installa un percorso statico mobile. I pacchetti vengono quindi inviati a Null0 finché il collegamento ISDN non diventa attivo.

Informazioni correlate

• Supporto tecnico Cisco e download