IP : Protocolos de routing de IP

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

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

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. Siempre que se resume un protocolo de ruteo, significa que el router podría recibir tráfico de 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.

prerrequisitos

Requisitos

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 indicadas a continuación.

  • Software Release 12.3 del � del Cisco IOS.

La información que se presenta en este documento se originó a partir de dispositivos dentro de 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

Sintaxis del comando

Una Static ruta al null0 es una Static ruta normal, salvo que señala a la interfaz del null0, que es una interfaz IOS virtual. Refiera a los comandos de los IP Routing Protocol: Secciono de la referencia del comando ip del Cisco IOS, el volumen 2 de 4: Routing Protocol, Release12.3 para más información sobre el comando ip route. La siguiente sección presenta un ejemplo de cómo utilizar el comando ip route de crear una Static ruta al null0.

Ejemplo:

Un escenario frecuente donde usted puede necesitar agregar una Static ruta al null0 es el de un Access Server que tenga muchos clientes que marcan adentro. Este escenario hace las rutas del host ser instalado en la tabla de ruteo del Access Server. Para asegurar el accesibilidad a estos clientes, mientras que el no inundar toda la red con las rutas del host, el otro Routers en la red tiene típicamente una ruta de resumen que señale al Access Server. En los este tipos de configuración, el Access Server debe tener que la misma ruta de resumen que señala a la interfaz del null0 del Access Server. Si no, rutear los loopes puede ocurrir cuando los host exteriores intentan alcanzar los IP Addresses asignados no no actualmente al marcado en el cliente pero es parte de la ruta de resumen. Esto es porque el Access Server despediría los paquetes detrás sobre la ruta predeterminado del Access Server en la red del núcleo, porque el Access Server falta una ruta específica del host para el destino.

Tenga en cuenta este ejemplo:

/image/gif/paws/14956/route_to_null_interface_01.gif

Un pequeño ISP (ISP-R1) da a uno de sus clientes un bloque de la red de 192.168.0.0/16. En este ejemplo, el cliente dividió 192.168.0.0/16 en las redes y solamente las aplicaciones 192.168.1.0/24 y 192.168.2.0/24 de /24 en el momento. En el router ISP-R1, el ISP configura una Static ruta para 192.168.0.0/16 hacia el router del cliente (cust-R2). El ISP entonces conecta con una estructura básica ISP, representada por el router BB-R3. El router BB-R3 envía una ruta predeterminado al ISP-R1 y recibe la red 192.168.0.0/16 vía el BGP del ISP-R1.

El accesibilidad ahora se garantiza de Internet (router ISP de estructura básica BB-R3) al router del cliente cust-R2 porque cust-R2 hace una ruta predeterminado configurar para señalar al ISP-R1. Sin embargo, si los paquetes se destinan a los bloques de la red que son rango parado de los 192.168.0.0/16, después cust-R2 el router utiliza la ruta predeterminado al ISP-R1 para remitir esos paquetes. Los paquetes entonces colocan entre el ISP-R1 y cust-R2 hasta que expire TTL. Esto puede tener un impacto enorme en CPU del router y la utilización del vínculo. Un ejemplo de donde este tráfico a los IP Addresses inusitados pudo venir del podría ser establecimientos de rechazo del servicio, el analizar de los bloques IP para encontrar los hosts vulnerables, etc

Configuraciones pertinentes:

cust-R2
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

ISP-R1
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

BB-R3
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: Habilitamos algunos comandos debug en el Routers de ilustrar mejor el flujo de paquetes, para hacer el debug de notablemente el paquete del IP y para hacer el debug del ICMP del IP. No habilite estos comandos en un entorno de producción a menos que usted entienda 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

El BB-R3 envía una sola petición ICMP a una dirección IP dentro del bloque 192.168.0.0/16 que está parado prendido cust-R2. El BB-R3 recibe un rato ICMP excedido detrás del ISP-R1.

En el 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 del BB-R3 y se remite a cust-R2 de serial0/0 como se esperaba. El mismo paquete llega detrás el ISP-R1 en serial0/0 y se envía inmediatamente hacia fuera 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 cust-R2 ése lo hace enviar este tráfico de nuevo 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

Vemos que cust-R2 envía estos paquetes de nuevo al 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 es parada en la red del cliente, así que la mejor ruta a 192.168.20.1 es la ruta predeterminado que señala al ISP-R1.

El resultado es que los paquetes colocan entre el ISP-R1 y cust-R2 hasta que expire TTL.

Observe que si la petición ICMP hubiera ido a una dirección IP dentro de una red que es funcionando, no ocurriría este resultado. Por ejemplo, si la petición ICMP estuviera para 192.168.1.x, que está conectado directamente encendido cust-R2, ninguna colocación habría ocurrido:

cust-R2# show ip rou 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 Static ruta al null0 para 192.168.0.0/16 encendido cust-R2.

cust-R2# conf t
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 volvemos a enviar la petición ICMP del BB-R3 a 192.168.20.1, cust-R2 envía este tráfico al null0, que acciona un ICMP fuera de alcance que se generará.

BB-R3# p 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

Nota: Puede haber situaciones donde no está posible el uso de una Static ruta sumaria al null0. Por ejemplo, si en el ejemplo anterior:

  • El bloque 192.168.1.0/24 está conectado con otro router que marque en cust-R2 vía el ISDN

  • El ISP-R1 no afecta un aparato 192.168.0.0/16 sino solamente 192.168.1.0/24

  • Una desconexión del link ISDN ocurre

Nota: El resultado sería que los paquetes adentro transitan o las aplicaciones que intentan alcanzar este bloque de los IP Addresses cree el mismo Routing Loop descrito anterior.

Nota: Para reparar este Routing Loop, usted debe utilizar el comando 200 del null0 de 192.168.1.0 255.255.255.0 de la ruta de IP de configurar las Rutas estáticas flotantes al null0 para 192.168.1.0/24. Los 200 en el comando es la distancia administrativa. ¿Refiérase a cuál es distancia administrativa? para más información.

Nota: Porque utilizamos una distancia administrativa más alta que cualquier Routing Protocol, si la ruta a 192.168.1.0/24 vía el link ISDN llega a estar inactiva, cust-R2 instala las Rutas estáticas flotantes. Los paquetes entonces se envían al null0 hasta que el link ISDN llegue a ser activo.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 14956