[Acercándose a NE (9)] Aventuras de los paquetes en los routers de Huawei - El viaje del protocolo

59 0 0 0

 

 

La mayoría de los paquetes recibidos por los routers son paquetes de servicio. Estos paquetes son procesados por tarjetas de servicio y SFU’s. Los routers también reciben una pequeña cantidad de paquetes especiales, como paquetes de protocolo de enrutamiento, paquetes de inicio y cierre de sesión de usuario y paquetes de excepción o error. Estos paquetes especiales son enviados por las tarjetas de servicio a la CPU de la placa de control maestra para su procesamiento. Este capítulo describe cómo se reenvían los paquetes de protocolo.

 

Viaje de paquetes de protocolo entrantes

El procesamiento de los paquetes de protocolo que deben enviarse a la CPU es similar al de los paquetes de servicio. La siguiente figura muestra cómo se procesan los paquetes de protocolo.

 

063036tuzj55cywquj0cyu.png

 

Las cinco diferencias son las siguientes:

• Diferencia 1: El sistema no busca en la tabla de reenvío si los paquetes se identifican como paquetes de protocolo.

• Diferencia 2: Los paquetes con la dirección IP 127.0.0.1 del siguiente salto se envían a la CPU.

• Diferencia 3: La velocidad de acceso confirmada (CAR) de los paquetes de protocolo no está limitada.

• Diferencia 4: La clasificación de tráfico no se realiza en paquetes de protocolo.

• Diferencia 5: El plano de control (CP) -CAR se realiza en paquetes de protocolo antes de que se envíen a la CPU para su procesamiento.

 

Diferencia 1: El sistema no busca en la tabla de reenvío si los paquetes se identifican como paquetes de protocolo

El PFE (NP o chip ASIC) analiza los paquetes. Si del campo de protocolo en el encabezado de trama de la Capa 2, el PFE identifica un paquete como un paquete de protocolo que debe enviarse a la CPU para su procesamiento, como un control de paquete ARP, RARP, IS-IS, LLDP, LACP o PPP. Si la dirección IP de destino del paquete de protocolo es una dirección IP de multicast reservada (que va desde 224.0.0.1 a 224.0.0.255), el LPU de enlace de subida no busca en la tabla de reenvío el reenvío de paquetes.

 

Como se mencionó en el capítulo anterior, el LPU de enlace de subida busca en la tabla de reenvío el LPU de destino y la información de la interfaz de salida. La SFU cambia los paquetes a una LPU de enlace de bajada en función de la LPU de destino. Finalmente, la LPU de enlace de bajada reenvía los paquetes basándose en la información de la interfaz de salida. Si una LPU de enlace de subida identifica un paquete como un paquete de protocolo que debe enviarse a la CPU para su procesamiento, la placa no busca en la tabla de reenvío. En su lugar, llena el campo LPU de destino con su ranura y llena el campo de la interfaz de salida con la CPU.

Diferencia 2: los paquetes con la dirección IP 127.0.0.1 del siguiente salto se envían a la CPU

Las rutas de los siguientes tipos llevan una dirección IP fija para el siguiente salto (127.0.0.1), y los paquetes con tal dirección de siguiente salto deben enviarse a la CPU para su procesamiento.

• Interfaz de rutas de host y rutas de subred directas con una dirección de broadcast

Si las interfaces conectadas directamente están configuradas con direcciones IP y el protocolo de la capa de enlace y el protocolo de la capa IP están activados, se generan tres rutas. Por ejemplo,

Tabla de ruteo:

Destino/Márcara

Protocolo

Pre

Costo

Indicador

Sig Salto

Interface

10.2.5.0/24      

Directo

0

0

D

10.2.5.5      

GigabitEthernet      1/ 0/0

10.2.5.5/32      

Directo

0

0

D

127.0.0.1      

GigabitEthernet1      / 0/0

10.2.5.255/32      

Directo

0

0

D

127.0.0.1      

GigabitEthernet1      / 0/0

 

Tabla de reenvío:

Destino/Márcara

Sig salto

Indicador

TimeStamp

Interface

Tunel ID

10.2.5.0/24

10.2.5.5

U

t[5847]

GigabitEthernet      1/ 0/0

0x0

10.2.5.5/32

127.0.0.1

HU

t[5847]

InLoop0

0x0

10.2.5.255/32

127.0.0.1

HU

t[5847]

InLoop0

0x0

 

La primera ruta es una ruta de segmento de red, que indica que el GE1/0/0 del enrutador está conectado directamente al segmento de red 10.2.5.0 y que la interfaz de salida al segmento de red es GE1/0/0.

La segunda ruta es una ruta principal y la dirección IP de destino 10.2.5.5 es la dirección IP de GE1/0/0. Cuando un enrutador recibe un paquete destinado a la dirección IP de una interfaz local, envía el paquete a la pila de protocolos de aplicación. En los router de Huawei, la interfaz de salida de las rutas del host mostradas en la tabla de reenvío es InLoopBack0, lo que indica que los paquetes correspondientes deben enviarse a la CPU para su procesamiento.

La tercera ruta lleva una dirección de transmisión de 10.2.5.255/32 (una subred de 10.2.5.0/24). Según los estándares IP, todas las interfaces de Capa 3 en el segmento de red 10.2.5.0/24 deben aceptar los paquetes con esta dirección. La interfaz de salida de dichas rutas también es InLoopBack0. Al recibir dichos paquetes, los routers los envían a la CPU para su procesamiento.

Además, las interfaces de Loopback y de Virtual Template (VT) son lógicas, y las direcciones IP con una máscara de 32 bits generalmente se configuran para dichas interfaces. Cada interfaz de este tipo tiene una ruta de host, por ejemplo,

Tabla de ruteo:

Destino/Márcara

Protocolo

Pre

Costo

Indicador

Sig Salto

Interface

10.0.0.5/32

Directo

0

0

D

127.0.0.1

LoopBack1

10.2.3.9/32

Directo

0

0

D

127.0.0.1

Virtual-Template5

 

 

 

Tabla de reenvío:

Destino/Márcara

Sig Salto

Indicador

TimeStamp

Interface

TunnelID

10.0.0.5/32

127.0.0.1

HU

t[142]

InLoop0

0x0

10.2.3.9/32

127.0.0.1

HU

t[28733]

InLoop0

0x0

 

La dirección IP del siguiente salto de dichas rutas de host es 127.0.0.1, y la interfaz de salida en la tabla de reenvío es InLoopBack0, lo que indica que los paquetes correspondientes deben enviarse a la CPU para su procesamiento.

• Rutas con una dirección de transmisión en toda la red

La dirección IP 255.255.255.255/32 es una dirección de transmisión en toda la red y se utiliza para configurar la información de inicio del host. Durante el inicio, un host puede no conocer su máscara de red o incluso su dirección IP. En este caso, el host envía un mensaje de solicitud DHCP con la dirección IP 255.255.255.255/32 para obtener una dirección IP del servidor DHCP o BOOTP. Tales mensajes existen solamente en la red local. Al recibir dichos mensajes, los routers los envían a la CPU para su procesamiento en lugar de reenviarlos.

Tabla de ruteo:

Destino/Márcara

Protocolo

Pre

Costo

Indicador

Sig Salto

Interface

255.255.255.255/32

Directo

0

0

D

127.0.0.1

InLoopBack0

 

Tabla de reenvío:

Destino/Márcara

Sig Salto

Indicador

TimeStamp

Interface

TunnelID

255.255.255.255/32

127.0.0.1

HU

t[128]

InLoop0

0x0

 

• Rutas UNR

Cuando un usuario llama a un servidor de acceso remoto de banda ancha (BRAS) o pasarela de red de banda ancha (BNG) utilizando PPPoE, el BRAS o BNG solicita una dirección IP del servidor RADIUS y asigna la dirección al usuario. Si la dirección IP asignada al usuario es 10.111.111.1/32, el BRAS o BNG genera la ruta 10.111.111.1/32. Después de recibir un paquete de red a usuario, el BRAS o BNG lo envía a la CPU para su procesamiento para que se pueda implementar la contabilidad. La dirección IP del siguiente salto de esta ruta también es 127.0.0.1.

 

Destino/Márcara

Protocolo

Pre

Costo

Indicador

Sig Salto

Interface

10.111.111.1/32

Unr

61

0

D

127.0.0.1

InLoopBack0

 

Esta ruta no se aprende a través de ningún protocolo de enrutamiento, ni es una ruta directa o estática. Es una UNR.

El BRAS o BNG necesita anunciar esta ruta para que el usuario pueda recibir paquetes de la red. Sin embargo, si el BRAS o BNG tiene un gran número de usuarios de acceso, necesita anunciar el mismo número de UNR. Para evitar este problema, el BRAS o BNG genera un UNR basado en el conjunto de direcciones, con 127.0.0.1 como la dirección IP del siguiente salto, y Null0 como la interfaz de salida.

 

Destino/Márcara

Protocolo

Pre

Costo

Indicador

Sig Salto

Interface

10.111.111.0/24

Unr

61

0

D

127.0.0.1

NULL0

 

 

Diferencia 3: La velocidad de acceso confirmada (CAR) de los paquetes de protocolo no está limitada

El CAR de los paquetes de protocolo que se envían a la CPU no está limitado, lo que evita la pérdida de paquetes en el caso de ráfagas de tráfico.

Diferencia 4: La clasificación de tráfico no se realiza en paquetes de protocolo

Los paquetes de protocolo se envían a la CPU en la LPU de enlace de bajada. Por lo tanto, las funciones relacionadas con la política de tráfico, como la clasificación y el marcado del tráfico, no tienen sentido para los paquetes.

Diferencia 5: El plano de control (CP)-CAR se realiza en paquetes de protocolo antes de que se envíen a la CPU para su procesamiento

Si se envía una gran cantidad de paquetes a la CPU para su procesamiento, la CPU se sobrecargará. Para evitar este problema, CP-CAR se realiza en los paquetes antes de enviarlos a la CPU. El mecanismo de CP-CAR es similar al de CAR basado en flujo. Para obtener más información, consulte el Capítulo 4. Los paquetes se separan en diferentes canales según el tipo de protocolo, VLAN o usuario. Cada canal usa una muestra para limitar la velocidad de paquetes. Si el ancho de banda de los paquetes que se envían a la CPU excede una velocidad especificada, los paquetes se descartarán aleatoriamente.

 

Viaje de paquetes de protocolo salientes

Los paquetes de protocolo enviados por la CPU se entregan directamente a la PFE, sin ser procesados por la PIC. Debido a que la mayoría de los paquetes de protocolo enviados por la CPU llevan la LPU de destino y la información de la interfaz de salida, el plano de reenvío no necesita buscar en la tabla de reenvío. Los paquetes entran directamente en una fila. En cuanto a un pequeño número de paquetes especiales, como los paquetes de ping con una interfaz de origen específica (activada por el comando ping destination-ip -si interface-name), el plano de reenvío debe buscar en la tabla de reenvío debido a que la dirección IP de la fuente La interfaz es desconocida. Luego, los paquetes especiales se envían a la TM, sin pasar por la limitación de CAR.

El procesamiento posterior de los paquetes de protocolo es similar al de los paquetes de servicio, excepto que la limitación de CAR y la clasificación de tráfico no se realizan en los paquetes de protocolo en la LPU de enlace de bajada.

 

 

063039f8tfqqutrtww7rxw.png

 

Los paquetes de respuesta rápida no se envían a la CPU

Los paquetes de ping (solicitud ICMP) se usan generalmente para verificar la conectividad del enlace a una puerta de enlace o dirección IP del lado de la red. Antes de que los paquetes de solicitud ICMP se envíen a la CPU para su análisis, se implementa CP-CAR.

Al recibir los paquetes, la CPU construye paquetes de respuesta ICMP y los envía al final del origen. Si se envía una gran cantidad de paquetes de solicitud ICMP a la CPU, la CPU se sobrecargará, lo que aumentará la demora de ping. Para resolver este problema, los routers de gama alta de Huawei son compatibles con la función de respuesta rápida ICMP. Con esta función, los paquetes de solicitud ICMP recibidos no se envían a la CPU para su procesamiento. En cambio, el PFE de la LPU responde al final del origen con paquetes de respuesta ICMP, lo que acorta considerablemente el retardo del ping.

El proceso de reenvío utilizando la respuesta rápida ICMP es el siguiente:

 

063041bfcfc5fj8tjfa9c5.png

 

Como se muestra en la figura anterior, los paquetes de ping no se envían a la CPU en la LPU de enlace descendente. En su lugar, el PFE intercambia las direcciones IP de origen y destino de los paquetes y vuelve a colocar los paquetes en la LPU de enlace de subida.

 

Sin embargo, si el tamaño de los paquetes de respuesta rápida es mayor que el MTU, los paquetes se fragmentan y los paquetes fragmentados se consideran como paquetes de ping comunes para un procesamiento adicional de la CPU.

 

De forma predeterminada, la respuesta rápida de ICMP está habilitada en la mayoría de las versiones. Si los paquetes de ping se simulan como paquetes de servicio durante la resolución de problemas, la respuesta rápida de ICMP debe desactivarse. Para deshabilitarlo, ejecute el comando undo icmp-reply fast en la vista del slot o en la vista del sistema.

Al igual que en la respuesta rápida ICMP, hay mensajes de respuesta rápida ARP y mensajes de respuesta rápida web. No se envían a la CPU, y son generados por tableros de línea.

 

This post was last edited by j84088811 at 2019-01-08 16:33.
  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesi | Registrarse

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje
Respuesta rápida Desplácese hasta arriba