Comprensión de los mensajes del Redireccionamiento de ICMP
Contenido
Introducción
Este documento discute el paquete reorienta las funciones proporcionadas por el Internet Control Message Protocol (ICMP). El documento explica qué presencia de mensajes del Redireccionamiento de ICMP en la red indica generalmente, y qué se puede hacer para minimizar los efectos secundarios negativos asociados a los estados de la red que causan la generación de mensajes del Redireccionamiento de ICMP.
Prerrequisitos
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Arquitectura de la plataforma del nexo 7000
- Configuración del software NX-OS
- Protocolo Protocolo de control de mensajes de Internet (ICMP) como se documenta en la Solicitud de comentarios (RFC) 792
Componentes Utilizados
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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Mensajes de Redireccionamiento de ICMP
Las funciones de la redirección ICMP se explican en el RFC 792 “protocolo Protocolo de control de mensajes de Internet (ICMP)” con el siguiente ejemplo
El gateway envía un mensaje de la reorientación a un host en la situación siguiente.
Un gateway, G1, recibe un datagrama de Internet de un host en una red a la cual se asocie el gateway. El gateway, G1, marca su tabla de ruteo y obtiene el direccionamiento del gateway siguiente, G2, en la ruta a la red de destino de Internet del datagrama, X.
Si el G2 y el host identificado por el direccionamiento de fuente de Internet del datagrama están en la misma red, un mensaje de la reorientación se envía al host. El mensaje de la reorientación aconseja al host enviar su tráfico para la red X directamente al gateway G2 pues esto es una trayectoria más corta al destino.
Los datos el gateway adelante del datagrama original a su destino de Internet.
Este escenario se muestra en el host de la imagen 1. y dos Routers, G1 y G2, está conectado con el segmento de los Ethernet compartida y tiene IP Addresses en la misma red 10.0.0.0/24
El host tiene la dirección IP 10.0.0.100. La tabla de ruteo del host tiene una entrada de la ruta predeterminado que señala a la dirección IP 10.0.0.1 del router G1 como el default gateway. El router G1 utiliza a la dirección IP 10.0.0.2 del router G2 como su salto siguiente cuando tráfico de reenvío a la red de destino X.
Cuando el host envía un paquete a la red de destino X, lo que sigue sucede
1. El gateway G1 con la dirección IP 10.0.0.1 recibe el paquete de datos del host 10.0.0.100 en una red a la cual se asocie.
2. El gateway, G1, marca su tabla de ruteo y obtiene a la dirección IP 10.0.0.2 del gateway siguiente, G2, en la ruta a la red de destino del paquete de datos, X.
3. Si el G2 y el host identificado por la dirección de origen del paquete del IP están en la misma red, el mensaje del Redireccionamiento de ICMP se envía al host. El mensaje del Redireccionamiento de ICMP aconseja al host enviar su tráfico para la red X directamente al gateway G2 pues esto es una trayectoria más corta al destino.
4. El gateway G1 adelante el paquete de datos original a su destino.
Dependiendo de la configuración del host, puede eligió ignorar los mensajes del Redireccionamiento de ICMP que el G1 le envía. Sin embargo, si el host utiliza los mensajes del Redireccionamiento de ICMP para ajustar su caché de ruteo y comienza a enviar los paquetes de datos subsiguientes directamente al G2, las siguientes ventajas se alcanzan en este escenario
- optimización de la trayectoria del reenvío de datos a través de la red; el tráfico alcanza su destino más rápidamente
- reducción de la utilización de los recursos de red, tal como ancho de banda y CPU del router carga
Tal y como se muestra en de la imagen 2, después de que el host creara la entrada de memoria caché de Route para la red X con el G2 como su salto siguiente, estas ventajas se consideran en la red:
- el uso del ancho de banda en el link entre el Switch y el router G1 disminuye en las ambas direcciones
- La utilización de la CPU en el router G1 reduce, porque el flujo de tráfico del host a la red X no atraviesa este nodo más
- el retardo de la red de extremo a extremo entre el host y la red X mejora.
Para entender la importancia del mecanismo del Redireccionamiento de ICMP, recuerde que las implementaciones del router tempranas de Internet confiaron sobre todo en los recursos de la CPU para procesar el tráfico de datos. Por lo tanto, la reducción del volumen de tráfico que tuvo que ser manejado cualquier único router y minimizando el número de saltos del router que un flujo del tráfico determinado tuvo que atravesar en su manera al destino era muy deseable. Al mismo tiempo, acode 2 que remiten (también conocidos como transferencia) fue implementado principalmente en los circuitos específicos de la aplicación personalizados (ASIC), y del rendimiento de reenvío la perspectiva era relativamente “barata” comparada para acodar 3 que remitían (también llamados encaminamiento), eso, fue hecha otra vez en los procesadores de fines generales.
Más nuevas generaciones de ASIC pueden hacer el reenvío de paquete de la capa 2 y de la capa 3. Teniendo búsquedas en la tabla de la capa 3 realizadas en las ayudas del hardware reduzca el funcionamiento costado asociado al paquete que dirige por el Routers. Además, las funciones de envío de integración de la capa 3 en los 2 Switch de la capa (que ahora se llaman los switches de la capa 3) hicieron la operación del reenvío de paquete más eficiente, eliminando la necesidad de las opciones del diseño del “router de un brazo” (también conocido como “router en un palillo”) y evitando las limitaciones asociadas a tales configuraciones de red.
Emplear de la imagen 3 el escenario en la imagen 1. Las funciones ahora de la capa 2 y de la capa 3, proporcionadas originalmente por dos Nodos separados, el Switch y el router G1, se consolidan en un 3 Switch de una sola capa, tal como plataforma de las 7000 Series del nexo.
Cuando el host envía el paquete a la red de destino X, lo que sigue sucede en la red
1. El Switch del gateway L3 con la dirección IP 10.0.0.1 recibe el paquete de datos de un host 10.0.0.100 en una red a la cual se asocie.
2. El gateway, el Switch L3, marca su tabla de ruteo y obtiene el direccionamiento 10.0.0.2 del gateway siguiente, G2, en la ruta a la red de destino del paquete de datos, X.
3. Si el G2 y el host identificado por la dirección de origen del paquete del IP están en la misma red, el mensaje del Redireccionamiento de ICMP se envía al host. El mensaje del Redireccionamiento de ICMP aconseja al host enviar su tráfico para la red X directamente al gateway G2 pues esto es una trayectoria más corta al destino.
4. El gateway adelante el paquete de datos original a su destino.
Con los switches de la capa 3 ahora pudiendo realizar el reenvío de paquete de la capa 2 y de la capa 3 en ASIC llano, puede ser concluido que ambas ventajas de las funciones del Redireccionamiento de ICMP, (a) de la mejora del retardo a través de la red y (b) de la reducción de la utilización de los recursos de red, están alcanzadas, y no hay necesidad de tener mucha atención a las técnicas de optimización de la trayectoria en los segmentos Ethernet de múltiples puntos.
Sin embargo, con las funciones del Redireccionamiento de ICMP habilitadas en las interfaces de la capa 3, la expedición subóptima a través de los segmentos Ethernet de múltiples puntos continúa presentando los embotellamientos del rendimiento potencial, aunque por una diversa razón, como se explica en las consideraciones de la plataforma del nexo seccionan más adelante en este documento.
Trayectos por debajo del nivel óptimo a través de las redes Ethernet
Los protocolos Interior Gateway Protocols (IGP), por ejemplo el trayecto más corto abierto primero (OSFP) y el Enhanced Interior Gateway Routing Protocol (EIGRP) de Cisco, se diseñan para sincronizar la información de ruteo entre el Routers, y para proporcionar el comportamiento constante y fiable del reenvío de paquete en todos los nodos de red que honren tal información. Tomar las redes Ethernet de múltiples puntos como un ejemplo, si todo acoda 3 Nodos en un segmento utiliza la misma información de ruteo y está de acuerdo con el mismo punto de salida al destino, expedición subóptima a través de tales redes es raramente el caso.
Para entender qué trayectos de reenvío subóptimos de las causas, recuerdan que los Nodos de la capa 3 hacen a la independiente de las decisiones de reenvío de paquetes de uno a. Es decir, la decisión de reenvío de paquetes tomada por el router B no depende de la decisión de reenvío de paquetes que fue tomada por el router A. Éste es uno de los principios dominantes a recordar al resolver problemas el reenvío de paquete a través de las redes del IP, y es importante a tener presente al investigar el trayecto de reenvío subóptimo en las redes Ethernet de múltiples puntos.
Según lo mencionado anterior, en las redes donde todo el Routers confía en un solo Dynamic Routing Protocol para entregar el tráfico entre los puntos extremos, la expedición subóptima a través de los segmentos Ethernet de múltiples puntos no debe suceder. Sin embargo, en las redes del mundo real es muy común encontrar la combinación de diversos ruteo de paquetes y mecanismos de reenvío. Los ejemplos de tales mecanismos son diversos IGP, Static Routing y encaminamiento basada directiva. Estas características se utilizan típicamente juntas para alcanzar la expedición del tráfico deseado a través de la red.
Mientras que el uso combinado de estos mecanismos puede ayudar a ajustar los requisitos del flujo de tráfico y de la reunión de un diseño de red particular, los efectos secundarios de desatención que estas herramientas juntos pueden causar en las redes Ethernet de múltiples puntos pueden dar lugar al rendimiento de la red total pobre.
Static Routing
Para ilustrar esto, considere el escenario en el router de la imagen 4. que A tiene Static ruta a la red X con el router B como su Next-Hop. Al mismo tiempo el router B utiliza el C del router como su Next-Hop en la Static ruta a la red X.
Mientras que el tráfico ingresa esta red en el router A, la deja con el C del router, y consigue eventual entregado a la red de destino X, los paquetes tienen que cruzar esta red del IP dos veces en su manera al destino. Éste no es uso effiencient de los recursos de red. En lugar, el envío de los paquetes del router A directamente al C del router alcanzaría los mismos resultados, mientras que consumía a menos recursos de red.
Ruteo basado en políticas
El Routing basado en políticas (PBR) es otro mecanismo que puede causar el trayecto por debajo del nivel óptimo a través de las redes Ethernet. Sin embargo, a diferencia del Static o Dynamic Routing, el PBR no actúa en el nivel de la tabla de ruteo. En lugar, programa el tráfico reorienta la lista de control de acceso (ACL) directamente en hardware del Switch. Como consecuencia, para los flujos de tráfico selectos, las operaciones de búsqueda del reenvío de paquete en el linecard del ingreso desvían la información de ruteo que se obtiene vía el Static o Dynamic Routing.
En la imagen 5, el Routers A y B intercambian la información de ruteo sobre la red de destino X usando uno de los Dynamic Routing Protocol. Ambos están de acuerdo con el router B que es el mejor Next-Hop a esta red.
Sin embargo, con la configuración PBR en el router B que reemplaza la información de ruteo recibió del Routing Protocol y fija el C del router como Next-Hop a la red X, la condición para accionar la función del Redireccionamiento de ICMP se cumple y el paquete consigue enviado al CPU del router B para el procesamiento adicional.
Redirecciones ICMP en los enlaces punto a punto
Este documento refirió hasta ahora a las redes Ethernet que tienen tres (o más) Nodos de la capa 3 asociados, por lo tanto las redes Ethernet de múltiples puntos del nombre. Sin embargo sea consciente que los mensajes del Redireccionamiento de ICMP se pueden generar en los links Ethernet de punto a punto también.
Considere el escenario en la Static Default ruta de las aplicaciones del router A de la imagen 6. enviar el tráfico al router B, mientras que el router B tiene una Static ruta a la red X que señala al router A.
Esta opción del diseño, también conocida como conexión escoja dirigida, es una opción popular al conectar los pequeños entornos del cliente con las redes del proveedor de servicios. Aquí el router B es un dispositivo del borde del proveedor (PE), y el router A es un dispositivo de la frontera del cliente (CE).
Observe que la configuración típica CE incluye la Static ruta global a los bloques de la dirección IP del cliente que señalan a la interfaz del null0. Esta configuración es una mejor práctica recomendada para la opción de conectividad escoja dirigida CE-PE con el Static Routing. Sin embargo, con el propósito de este ejemplo asuma que no hay tal configuración presente.
Asuma que el router A pierde la Conectividad a la red X tal y como se muestra en de la imagen. Cuando los paquetes de la red del cliente Y o del intento de la red remota Z para alcanzar la red X, el Routers A y B despedirán el tráfico entre uno a, decrementing el campo del Tiempo para vivir IP en cada paquete hasta que su valor alcance 1, la encaminamiento adicional del momento en el cual del paquete no es posible.
Ahora, mientras que el tráfico a la red X despide hacia adelante y hacia atrás entre el Routers PE y CE, dramáticamente (e innecesariamente) la utilización cada vez mayor del ancho de banda de link CE-PE, el problema llega a ser peor si las redirecciones ICMP se habilitan en una o los ambos lados de la conexión de punto a punto PE-CE. En este caso cada paquete en el flujo destinado a la red X será procesado en el CPU del tiempo múltiple correspondiente de los routers para ayudar a generar los mensajes del Redireccionamiento de ICMP.
Consideraciones de la plataforma del nexo
Cuando las redirecciones ICMP se habilitan en la interfaz de la capa 3 y paquete de datos entrantes utilizan esta interfaz al Switch del ingreso y de la salida Layer3, se genera el mensaje del Redireccionamiento de ICMP. Mientras que el reenvío de paquete de la capa 3 se hace en hardware en la plataforma del nexo 7000 de Cisco, sigue siendo la responsabilidad del CPU del Switch construir los mensajes del Redireccionamiento de ICMP. Para hacer esto, el CPU en el módulo de Supervisor del nexo 7000 necesita obtener la información de la dirección IP del flujo cuya trayectoria a través del segmento de red puede ser optimizada. Ésta es la razón detrás del paquete de datos que es enviado por el linecard del ingreso al módulo de Supervisor.
Si el beneficiario del mensaje del Redireccionamiento de ICMP la ignora y continúa el tráfico de reenvíos de datos para acodar la interfaz 3 del Switch del nexo en la cual se habilitan las redirecciones ICMP, el proceso de generación del Redireccionamiento de ICMP se acciona para cada paquete de datos.
En el nivel del linecard el proceso comienza bajo la forma de excepción del hardware que reenvía. Las excepciones se aumentan en Asics cuando la operación del reenvío de paquete no se puede completar con éxito por el módulo del linecard. En este caso, el paquete de datos necesita ser enviado al módulo de Supervisor para la dirección correcta del paquete.
Después de que el CPU en el módulo de Supervisor enviara el mensaje del Redireccionamiento de ICMP a la fuente, completa la administración de excepción por el paquete de reenvíos de datos al salto siguiente a través del módulo del linecard de la salida.
Mientras que los nexos 7000 módulos de Supervisor utilizan CPU potente los procesadores que son capaces de procesar los volúmenes de tráfico grandes, la plataforma se diseña para manejar la mayor parte del tráfico de datos en el linecard llano sin el procesador de la CPU del supervisor de acoplamiento en el proceso del reenvío de paquete. Esto permite que el CPU se centre en sus tareas de la base, dejando la operación del reenvío de paquete a los motores del hardware dedicado en el linecards.
En las redes estables, se espera que las excepciones del reenvío de paquete, ocurren, sucedan en las tarifas razonablemente bajas. Con esta suposición, pueden ser manejadas por el Supervisor CPU sin el impacto significativo en su funcionamiento. Por otra parte, tener trato CPU con las excepciones del reenvío de paquete que ocurren mismo a una alta velocidad puede tener un efecto negativo en la estabilidad de general del sistema y el responsivness.
El diseño de la plataforma del nexo 7000 proporciona varios mecanismos para proteger el Switch CPU contra ser abrumado por la cantidad significativa de tráfico. Estos mecanismos se implementan en diversas puntas en el sistema. En el linecard llano, hay limitadores de la tarifa del hardware y característica de las Políticas del plano de control (CoPP). Ambos fijaron los umbrales de las relaciones del tráfico, controlando con eficacia la cantidad de tráfico que se remitirán al supervisor de cada módulo del linecard.
Estos mecanismos protectores dan la preferencia al tráfico de los diversos protocolos del control que son críticos para la estabilidad de la red y conmutan la manejabilidad, tal como OSPF, BGP o SSH, mientras que los tipos de tráfico agresivamente de filtración que no son críticos controlar las funciones planas del Switch. La mayor parte del tráfico de datos, si está remitido al CPU como resultado de las excepciones del reenvío de paquete, es limpiado pesadamente por tales mecanismos.
Mientras que los limitadores de la tarifa del hardware y los mecanismos del policing de CoPP proporcionan la estabilidad del avión del control del Switch y se recomiendan fuertemente ser habilitados siempre, pueden ser una de las razones principales de los descensos del paquete de datos, de los retardos de la transferencia, y del rendimiento de la aplicación pobre total a través de la red. Esta es la razón por la cual la comprensión de las trayectorias que los flujos de tráfico toman a través de la red y de las herramientas el tener para monitorear el equipo de red que puede y/o se espera que utilice las funciones del Redireccionamiento de ICMP es importante.
Supervisión y herramientas de diagnóstico
muestre el tráfico del IP
Ambo Software Cisco IOS y NX-OS proporciona una manera de marcar las estadísticas del tráfico que es manejado por el CPU. Esto se hace con el comando show ip traffic. Este comando se puede utilizar para marcar el recibo y/o la generación de mensajes del Redireccionamiento de ICMP por el switch de la capa 3 o el router
Nexus7000# show ip traffic | begin ICMP
ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
Nexus7000#
Funcione con el comando show ip traffic algunas veces y control si los contadores del Redireccionamiento de ICMP incrementan.
Ethanalyzer
El Software Cisco NX-OS tiene una herramienta incorporada para capturar el flujo de tráfico a y desde el CPU del Switch, conocido como Ethanalyzer.
Represente el escenario de 7 demostraciones similar al que está en la imagen 3. Aquí la red X es substituida por la red 192.168.0.0/24.
El host 10.0.0.100 envía la secuencia continua de pedidos de eco ICMP al IP Address de destino 192.168.0.1. Las aplicaciones del host conmutan la interfaz virtual (SVI) 10 del 7000 Switch del nexo como su salto siguiente a la red remota 192.168.0.0/24. Como demostración, el host cofigured para ignorar los mensajes del Redireccionamiento de ICMP.
Utilice el siguiente comando de capturar el tráfico ICMP recibido y enviado por el nexo 7000 CPU
Nexus7000# ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000
Capturing on inband
2018-09-15 23:45:40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.136645 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
...
Los grupos fecha/hora adentro sobre la salida sugieren que tres paquetes resaltados en este ejemplo fueran capturados al mismo tiempo, 2018-09-15 23:45:40.128. Abajo está una ruptura por paquete de este grupo del paquete
- El primer paquete es el paquete de datos del ingreso, que en este ejemplo es un pedido de eco ICMP.
2018-09-15 23:45:40.128348 10.0.0.100 - > petición del eco ICMP de 192.168.0.1 (ping)
- El segundo paquete es un paquete del Redireccionamiento de ICMP, generado por el gateway. Este paquete se devuelve al host.
2018-09-15 23:45:40.128611 10.0.0.1 - > Redireccionamiento de ICMP de 10.0.0.100 (reoriente para el host)
- El tercer paquete es el paquete de datos capturado en la dirección de salida, después de que haya sido ruteado por el CPU. No mostrado sin embargo arriba, este paquete tiene su IP TTL decremented y suma de comprobación recalculada.
2018-09-15 23:45:40.128659 10.0.0.100 - > petición del eco ICMP de 192.168.0.1 (ping)
Mientras que navega con las capturas grandes de Ethanalyzer que tienen muchos paquetes de diversos tipos y flujos, puede no ser fácil correlacionar los mensajes del Redireccionamiento de ICMP con el tráfico de datos correspondientes.
En estas situaciones, foco en los mensajes del Redireccionamiento de ICMP para extraer la información sobre los flujos de tráfico subóptimo remitidos. Los mensajes del Redireccionamiento de ICMP incluyen la encabezado de Internet más los primeros 64 bits de los datos del datagrama original. Estos datos son utilizados por la fuente del datagrama para hacer juego el mensaje al proceso apropiado.
Utilice la herramienta de la captura de paquetes de Ethanalyzer con la palabra clave del detalle para visualizar el contenido de los mensajes del Redireccionamiento de ICMP y para encontrar la información de la dirección IP del flujo de datos que subóptimo se remite
Nexus7000# ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54:04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect, should be 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
Inhabilitación de Mensajes de Redirección ICMP
Si el diseño de red requiere el flujo de tráfico ser de los ruteado la misma interfaz de la capa 3 en la cual ingresó el Switch o al router, es posible evitar que el flujo sea ruteado con el CPU explícitamente inhabilitando las funciones del Redireccionamiento de ICMP en la interfaz de la capa correspondiente 3.
De hecho, porque la mayoría de las redes es una práctica adecuada dinámico inhabilitar las redirecciones ICMP en todas las interfaces de la capa 3, comprobación, como la interfaz de Ethernet, y virtual, como el canal del puerto y las interfaces SVI. Utilice el comando interface-level del no ip redirects NX-OS de inhabilitar las redirecciones ICMP en una interfaz de la capa 3. Siga los siguientes pasos para verificar que las funciones del Redireccionamiento de ICMP están inhabilitadas
- asegúrese que agreguen al comando no ip redirects a la configuración de la interfaz
Nexus7000# show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
Nexus7000#
- asegúrese de que el estatus de las redirecciones ICMP en la interfaz muestre que “inhabilitó”
Nexus7000# show ip interface vlan 10 | include redirects IP icmp redirects: disabled Nexus7000#
- asegúrese de que el permiso del Redireccionamiento de ICMP/el indicador de la neutralización esté fijado al “0" por el componente del software NX-OS que avanza la configuración de la interfaz del supervisor del Switch a uno de más linecards
Nexus7000# show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0 Nexus7000#
- asegúrese de que el permiso del Redireccionamiento de ICMP/el indicador de la neutralización para una interfaz determinada de la capa 3 esté fijado al “0" en uno o más linecards
Nexus7000# attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#
<optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs>
module-7# vdc 6
module-7# show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect : 0x0 ipv6_redirect : 0x1
module-7#
Resumen
El mecanismo del Redireccionamiento de ICMP, según lo descrito en el RFC 792, fue diseñado para optimizar el trayecto de reenvío a través de los segmentos de red de múltiples puntos. En los primeros días de Internet tal optimización ayudó a salvar a los recursos de red costosos, como el ancho de banda de link y los ciclos de la CPU del Routers.
Mientras que el ancho de banda de la red llegó a ser más asequible, y el ruteo de paquetes CPU-basado relativamente lento se desarrolló en un reenvío de paquete más rápido de la capa 3 en hardware dedicado ASIC, la importancia de los datos óptimos transita a través de los segmentos de red de múltiples puntos disminuidos, y no está consiguiendo tanta atención de los diseñadores de red hoy como utilizó a.
Por abandono, las funciones del Redireccionamiento de ICMP se habilitan en cada interfaz de la capa 3. Sin embargo, sus tentativas de notificar los nodos de red en los segmentos Ethernet de múltiples puntos sobre los trayectos de reenvío óptimos no son entendidas y son actuadas siempre sobre por el personal de redes.
En las redes con el uso combinado de los diversos mecanismos de reenvío, tales como Static Routing, el Dynamic Routing y el Policy-Based Routing, dejando las funciones del Redireccionamiento de ICMP habilitadas sin la supervisión apropiada pueden dar lugar al uso indeseable del nodo de tránsito CPU de manejar el tráfico de producción. Esto, a su vez, puede causar el impacto significativo en los flujos del tráfico de producción y en la estabilidad del avión del control de la infraestructura de red.
Para la mayoría de las redes se considera una práctica adecuada dinámico de inhabilitar las funciones del Redireccionamiento de ICMP en todas las interfaces de la capa 3 en la infraestructura de red. Esto ayuda a prevenir los escenarios del tráfico de datos de la producción que es dirigido en el CPU de los switches de la capa 3 y del Routers cuando hay un mejor trayecto de reenvío a través de los segmentos de red de la mutli-punta.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)