Utilización de una Ruta Estática a la Interfaz Null0 para la Prevención de Loops

Introducción

Este documento describe cómo una ruta estática a la interfaz Null puede evitar loops de ruteo.

Prerequisites

Requirements

No hay requisitos previos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las versiones de software y hardware.

• ‘Versión de software 12.3 del IOS® de Cisco.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Antecedentes

La interfaz nula se utiliza normalmente para evitar los loops de ruteo. Enhanced Interior Gateway Routing Protocol (EIGRP), por ejemplo, crea siempre una ruta a la interfaz Null0 cuando resume un grupo de rutas. Cada vez que se resume un protocolo de ruteo, significa que el router puede recibir tráfico para cualquier dirección IP dentro de ese resumen. Debido a que no todas las direcciones IP están siempre en uso, existe el riesgo de que los paquetes entren en loop en caso de que se utilicen rutas predeterminadas en el router que recibe el tráfico del resumen.

Sintaxis del comando

Una ruta estática a Null0 es una ruta estática normal, excepto que apunta a la interfaz Null0, que es una interfaz virtual de Cisco IOS. Refiérase a la sección ip route del Capítulo: Comandos Independientes del Protocolo de Ruteo IP de la A a la R para obtener más información sobre el comando ip route . La siguiente sección presenta un ejemplo de cómo utilizar el comando ip route para crear una ruta estática a Null0.

Ejemplo:

Un escenario común donde puede necesitar agregar una ruta estática a Null0 es el de un servidor de acceso que tiene muchos clientes marcando. Este escenario hace que las rutas de host se instalen en la tabla de ruteo del servidor de acceso. Para garantizar la accesibilidad a estos clientes, sin que la red se vea inundada de rutas de host, otros routers de la red suelen tener una ruta de resumen que apunta al servidor de acceso. En este tipo de configuración, el servidor de acceso debe tener la misma ruta de resumen que apunta a la interfaz Null0 del servidor de acceso. Si no es así, los loops de ruteo pueden ocurrir cuando los hosts externos intentan alcanzar direcciones IP que actualmente no están asignadas a un cliente marcado pero son parte de la ruta de resumen. Esto se debe a que el servidor de acceso rebotaría los paquetes sobre la ruta predeterminada del servidor de acceso a la red principal, porque el servidor de acceso carece de una ruta de host específica para el destino.

Tenga en cuenta este ejemplo:

Topología de red

Un ISP pequeño (ISP-R1) proporciona a uno de los usuarios un bloque de red de 192.168.0.0/16. En este ejemplo, el usuario dividió 192.168.0.0/16 en redes /24 y sólo utiliza 192.168.1.0/24 y 192.168.2.0/24 en este momento. En el router ISP-R1, el ISP configura una ruta estática para 192.168.0.0/16 hacia el router del usuario (cust-R2). A continuación, el ISP se conecta a un ISP de red troncal, representado por el router BB-R3. El router BB-R3 envía una ruta predeterminada a ISP-R1 y recibe la red 192.168.0.0/16 vía BGP desde ISP-R1.

Ahora se garantiza la disponibilidad desde Internet (router ISP de red troncal BB-R3) hasta el router de usuario cust-R2 porque cust-R2 tiene una ruta predeterminada configurada para señalar a ISP-R1. Sin embargo, si los paquetes están destinados a bloques de red que no están en uso fuera del rango 192.168.0.0/16, el router cust-R2 utiliza la ruta predeterminada a ISP-R1 para reenviar esos paquetes. A continuación, los paquetes realizan un bucle entre ISP-R1 y cust-R2 hasta que caduca el TTL. Esto puede tener un gran impacto en la utilización de la CPU del router y de los enlaces. Un ejemplo de dónde puede provenir este tráfico a direcciones IP no utilizadas podría ser ataques de denegación de servicio, escaneo de bloques IP para encontrar hosts vulnerables, etc.

Configuraciones relevantes:

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

Flujo de paquetes

Nota: Algunos comandos debug se habilitaron en los routers para ilustrar mejor el flujo de paquetes, especialmente debug ip packet y debug ip icmp. No habilite estos comandos en un entorno de producción a menos que comprenda completamente las consecuencias.

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 envía una única solicitud ICMP a una dirección IP dentro del bloque 192.168.0.0/16 que no está en uso en cust-R2. BB-R3 recibe un tiempo de ICMP excedido de vuelta de ISP-R1.

En 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

El paquete inicial se recibe en serial1/0 en ISP-R1 desde BB-R3 y se reenvía a cust-R2 en serial0/0 como se esperaba. El mismo paquete llega de vuelta a ISP-R1 en serial0/0 y se envía inmediatamente por la misma interfaz, a cust-R2, debido a esta ruta:

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

¿Qué sucede en el cliente R2 que hace que envíe este tráfico de vuelta al ISP-R1?

En 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

Puede ver que cust-R2 envía estos paquetes nuevamente a ISP-R1, debido a esta ruta:

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#

El router cust-R2 no tiene una ruta a 192.168.20.1 porque esta red no está en uso en la red del usuario, por lo que la mejor ruta a 192.168.20.1 es la ruta predeterminada que apunta a ISP-R1.

El resultado es que los paquetes realizan un loop entre ISP-R1 y cust-R2 hasta que caduca el TTL.

Si la solicitud ICMP hubiera ido a una dirección IP dentro de una red que está en uso, este resultado no se produciría. Por ejemplo, si la solicitud ICMP fuera para 192.168.1.x, que está conectado directamente en cust-R2, no se habría producido ningún 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

La solución a este problema es configurar una ruta estática a Null0 para 192.168.0.0/16 en 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

Si ahora vuelve a enviar la solicitud ICMP de BB-R3 a 192.168.20.1, cust-R2 envía este tráfico a Null0, que activa un ICMP inalcanzable para ser generado.

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

Puede haber situaciones en las que el uso de una ruta estática de resumen a Null0 no sea factible. Por ejemplo, si en el ejemplo anterior:

• El bloque 192.168.1.0/24 está conectado a otro router que marca en cust-R2 a través de ISDN

• ISP-R1 no asigna 192.168.0.0/16 sino sólo 192.168.1.0/24

• Se produce una desconexión del link ISDN

Nota: El resultado sería que los paquetes en tránsito o las aplicaciones que intentan alcanzar este bloque de direcciones IP crean el mismo loop de ruteo descrito anteriormente.

Nota: Para corregir este loop de ruteo, debe utilizar el comando ip route 192.168.1.0 255.255.255.0 Null0 200 para configurar una ruta estática flotante a Null0 para 192.168.1.0/24. El 200 en el comando es la distancia administrativa. Consulte ¿Qué es la distancia administrativa? para obtener más información.

Nota: Debido a que utilizamos una distancia administrativa más alta que cualquier protocolo de ruteo, si la ruta a 192.168.1.0/24 a través del link ISDN se vuelve inactiva, cust-R2 instala una ruta estática flotante. Los paquetes se envían a Null0 hasta que el link ISDN se activa.

Información Relacionada

• Soporte técnico y descargas de Cisco