Todo sobre switches Serie S Solución de problemas de pérdida de paquetes.

Publicado 2019-1-29 11:29:39 187 0 0 0

Contenido

1 Sobre este documento 1

2 Localización y manejo de problemas de pérdida de paquetes. 2


2.1 Comprobando si los paquetes se han perdido 5

2.2 Comprobando la PC donde Packet LossOccurs. 5

2.3 Comprobando si el estado físico de las interfaces está inactivo. 5

2.4 Comprobación de errores de CRC en la dirección de entrada de interfaces. 8

2.5 Comprobación del recuento de descartes en la dirección de salida. 9

2.6 Comprobación de bucles. 10

2.7 Revisando los ataques. 14

2.8 Comprobando si la tasa de paquetes enviados a la CPU excede el límite 17

2.9 Comprobación de las configuraciones relacionadas. 18

2.10 Determinación de la ubicación de la pérdida de paquetes según las estadísticas de tráfico. 23

2.10.1 Cargando el último parche que coincide con la versión del software del sistema. 25

2.10.2 Restablecimiento o reemplazo de las tarjetas problemáticas. 26

2.10.3 Comprobando los enlaces físicos. 26

2.11 Contacto con el personal de soporte técnico 28

3 Casos típicos. 29

3.1 A Pocos paquetes se eliminan 2 minutos después de que el servicio de multidifusión está habilitado. 29

3.2 El usuario de administración no puede hacer telnet a un conmutador. 31

3.3 Paquetes de ping del Servidor de Monitoreo a Servidores son eliminados. 32

3.4 Los paquetes de entrada se eliminan. 33

3.5 La pixelación aparece en la pantalla cuando el conmutador está conectado a dos receptores. 34

3.6 Los hosts de los usuarios se conectan lentamente y el retraso de la puerta de enlace. 36

3.7 Los paquetes se eliminan cuando un conmutador está conectado a un dispositivo de terceros. 40

3.8 Los paquetes se pierden cuando los usuarios acceden a un interruptor apilado. 41

3.9 Los usuarios conectados a un switch no pueden acceder a la red. 42

3.10 Los paquetes se pierden cuando los usuarios acceden a un servidor 43

3.11 Los artefactos ocurren cuando los usuarios ven videos. 43

3.12 La pixelación ocurre cuando los usuarios ven videos. 45

3.13 La pixelación ocurre cuando los usuarios ven televisión durante las horas pico. 47

3.14 Se producen pausas en la imagen cuando los usuarios ven videos. 49

4 Medidas de prevención de pérdida de paquetes. 51

5 Apéndice. 53

5.1 Configurar la recopilación de estadísticas de tráfico. 53

1 Sobre este documento.

Overview
When managing and maintaining a network, wemay encounter intermittent network disconnection caused by transmission delayor slow network access speed. Most of these symptoms are caused by packet loss.
Quickly isolating and rectifying thefailures are important.
This document analyzes the packet losssymptoms on the network, describes the fault locating and fixing methods, andprovides typical cases and reference for you to fix the packet loss problems.

The functions and commands supported on aswitch may vary depending on the product model and software version. This documentuses V200R008C00 as an example. For the functions and commands used on yourswitch, see the documentation of the specific version.
ChangeHistory

 

Visión general

Al administrar y mantener una red, es posible que se produzca una desconexión intermitente de la red causada por el retraso de la transmisión o la velocidad lenta de acceso a la red. La mayoría de estos síntomas son causados por la pérdida de paquetes.

Es importante aislar y rectificar rápidamente los fallos.

Este documento analiza los síntomas de pérdida de paquetes en la red, describe los métodos de localización y solución de fallas, y proporciona casos típicos y referencias para que pueda solucionar los problemas de pérdida de paquetes.

 

Las funciones y comandos admitidos en aswitch pueden variar según el modelo del producto y la versión del software. Este documento utiliza V200R008C00 como ejemplo. Para las funciones y comandos utilizados en su interruptor, consulte la documentación de la versión específica.

 

Historial de cambios

   Evento
     

   Fecha
     

   Descripción
     

  02
    

  2017-01-31
    

  Segundo   lanzamiento comercial.
    

  01
    

  2016-12-30
    

  Lanzamiento   oficial inicial
    

 

Localización y manejo de problemas de pérdida de paquetes

Cuando se produce una pérdida de paquete, determine la ubicación donde se eliminan los paquetes, analice la causa de la pérdida de paquete y, a continuación, corrija la falla en consecuencia. La Figura 2-1 muestra el proceso de localización de fallas.

Figura 2-1 Localización y manejo de problemas de pérdida de paquetes

 

Este documento utiliza una red de campus como ejemplo para describir los métodos de localización y manejo de problemas de pérdida de paquetes.

La figura 2-2 muestra el diagrama de la red del campus. Los usuarios A, B y C están conectados a accessSwitch_3 y Switch_2. El usuario D y el usuario E están conectados para acceder a Switch_4.Switch_3, Switch_2, y Switch_4 están conectados al Core Switch_1. Switch_1 está conectado a Internet a través del firewall.

Figura 2-2 Red de campus

 

El usuario A se queja de que la velocidad de acceso a la red es lenta y las páginas web no se pueden abrir a veces. Otros usuarios no se quejan de esto. Cuando la PC del usuario A hace ping a una dirección de red pública, el paquete de ping se cae.

 


2.1  Comprobando si los paquetes se han perdido
2.2  Comprobación de la PC donde se produce la pérdida de paquetes
2.3  Comprobación de si el estado físico de las interfaces está inactivo
2.4  Comprobación de errores de CRC en la dirección entrante de las interfaces
2.5  Comprobación del recuento de descartes en la dirección de salida
2.6  Comprobación de bucles
2.7  Comprobando Ataques
2.8  Comprobación de si la velocidad de los paquetes enviados a la CPU excede el límite
2.9  Comprobación de las configuraciones relacionadas
2.10  Determinación de la ubicación de pérdida de paquetes basada en estadísticas de tráfico
2.11  Contacto con el personal de soporte técnico
2.1 Comprobando si los paquetes se han perdido

 

Los síntomas de pérdida de paquetes son los siguientes:

·         Cuando los usuarios se conectan:

- La velocidad de conexión es inestable. Las páginas web se abren a baja velocidad, o algunas partes de las páginas web o la totalidad de las páginas web no se pueden mostrar.

- El video está congelado o aparecen artefactos en la pantalla.

- La herramienta de mensajería de instancia, como QQ, se desconecta con frecuencia o el inicio de sesión se agota.

- La descarga de archivos es lenta.

·         Cuando un interruptor está funcionando:

- La operación de ping en el interruptor se apaga.

- Un puerto no puede reenviar datos.

- El inicio de sesión de un administrador de tiempo fuera.

- El servicio es frecuentemente interrumpido.

Si aparecen uno o más síntomas, se produjo el paquete losshas.

 

2.2 Comprobación de la PC donde se produce la pérdida de paquetes

 

Compruebe la PC donde se produce la pérdida de paquetes.

Por ejemplo, verifique si las tarjetas de red funcionan normalmente y si el cable entre la PC y el dispositivo conectado es normal. Solución: Desconecte la PC de la red y escanee el virus en la PC, verifique el cable, vuelva a instalar el sistema operativo y verifique las tarjetas de red.

Si la PC es normal pero la falla persiste, vaya al siguiente paso.

 

2.3 Comprobación de si el estado físico de las interfaces está inactivo

 

Si el estado físico es Abajo, o el modo de dúplex o la velocidad negociada de la interfaz local es diferente a la del extremo remoto, el estado de la interfaz es anormal.

1. Ejecute el comando display interface interface-typeinterface-number para verificar el estado de ejecución de la interfaz.

Por ejemplo, la configuración de GE1 / 0/2 en el Switch_3 es la siguiente:

 

<HUAWEI> display interfacegigabitethernet 1/0/2  
GigabitEthernet1/0/2 current state : DOWN //Current physical status of the interface 
Line protocol current state : DOWN  
Description:  
Switch Port, Link-type : access(negotiated), 
PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216  
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is000b-0974-a475  
Last physical up time : 2016-08-10 07:09 Last physical down time :2016-08-10 07:09  
Current system time: 2016-08-10 07:09 
Port Mode: COMMON FIBER  //Interfaceworking mode. COMMON COPPER indicates an electrical interface, and COMMON FIBERindicates an optical interface. 
Speed : 1000, Loopback: NONE  //Therates, loopback interface, and link status on two ends must be consistent. 
Duplex: FULL, Negotiation: ENABLE  //Theduplex mode, negotiation status, and link status on two ends must beconsistent. 
---- More ----
          If the command output includes"current state : UP", the interface works normally. Then skip thissection.
          If the command output includes"current state : Administratively down", the interface has been shutdown.

 

Ejecute el comando interface interface-typeinterface-number  en la vista del sistema para ingresar a la vista de la interfaz, y luego ejecute el comando display this para verificar la configuración de la interfaz. Si la interfaz se ha cerrado con el comando shutdown, ejecute el comando undo shutdown en la vista de interfaz.

- Si la salida del comando incluye "estado actual: DOWN", verifique si el estado de negociación, las tasas, los modos dúplex y los modos de cable en dos extremos son consistentes.

Ejecute el comando display interface en los dos extremos del enlace. Se muestra la información mostrada en la Tabla 2-1.

Tabla 2-1 Verificación de los modos dúplex, tasas y modos de negociación en dos extremos

 

 

   Objeto
     

   Descripción
     

   Procedimiento   de seguimiento
     

  Negociación
    

  Estado de   negociación:
    
l   Habilidato: auto-negotiation
    
l   Deshabilitado: non-auto-negotiation
    

  Las dos   interfaces deben funcionar en el mismo modo de negociación (tanto en modo de   negociación automática como en modo de no negociación automática).

   1. Ejecute el   comando negotiation auto  en la vista de interfaz para habilitar   la negociación automática.

   2. Si el error   persiste, desactive la negociación automática y establezca a la fuerza la   misma velocidad y modo dúplex en las interfaces.
    

  Velocidad
    

  Current rate   (Tasa Actual)
    

  Si las tasas de   interfaz son inconsistentes en el modo de negociación automática, ejecute el   comando restart para reiniciar la interfaz, haciéndolos coherentes.

   l Si las tasas   de interfaz son inconsistentes en el modo de no negociación automática,   ejecute the speed 10 | 100 | 1000 }en   la vista de interfaz, haciéndolos coherentes.

   NOTA

   Si una interfaz   eléctrica funciona correctamente a 10 Mbit / s o 100 Mbit / s pero no   funciona correctamente a 1000 Mbit / s, verifique si el cable funciona   correctamente. Si no, reemplace el cable.
    

  Duplex
    

  Duplex mode en   la interfaz
    
l   FULL: full duplex
    
l   HALF: half duplex
    

  l   If the duplex modes on two  ends are   inconsistent in the auto-negotiation mode, run the restart command   to restart the  interface, so that they can negotiate the same   mode. Alternatively, run the auto duplex  full  command   in the interface view to enable full duplex mode.
    
l   If the duplex modes of the  interfaces are different in   non-auto-negotiation mode, run the duplex full command in   the interface  view to enable full duplex mode.
    

  Mdi
    

  Tipo de cable   Ethernet soportado por la interfaz:
    
l   across: cable cruzado

  l   auto: tipo de cable identificado automáticamente Es decir, la interfaz   se puede conectar a un cable de conexión directa o a un cable cruzado.

  l   normal: cable recto
    

  Ensure that the   cable modes and types on  two ends are consistent.
    By default, the cable mode is auto. If  the cable mode   is not auto, run the mdi  autocommand in the interface   view to change it to auto.
    

 

 

 

Si la salida del comando incluye "estado actual: ERROR ABAJO (causa descendente)", la interfaz se cerrará debido a un error. Averigüe la causa basada en el campo de causa descendente.

Para obtener más información, consulte la sesión de resolución de problemas sobre el estado físico de las interfaces Ethernet.

Si el estado de la interfaz aún está abajo, vaya al siguiente paso.

2. Conecte el cable a otra interfaz, y verifique si el estado de la interfaz es normal.

- Si el estado físico sigue siendo Inactivo, póngase en contacto con el personal de asistencia técnica.

- Si ambas interfaces están activadas, funcionan en modo dúplex completo y están habilitadas con negociación automática, pero persisten perdedores de paquetes, consulte la siguiente sección.

 

2.4 Comprobación de errores de CRC en la dirección entrante de las interfaces

 

Esta sección está separada de "Verificar el estado de la interfaz" porque la pérdida de paquetes causada por la congestión a menudo ocurre en redes en vivo.

Compruebe si se producen errores de comprobación de redundancia cíclica (CRC) en las interfaces físicas a lo largo de la ruta de transmisión de paquetes, y si la cantidad de errores de CRC aumenta continuamente.

Si el número de errores de CRC no es 0 y continúa aumentando, la interfaz está recibiendo paquetes de errores de CRC. Los paquetes de error se generan debido al estado incorrecto del enlace físico o problemas de problemas.

Rectifique el problema del enlace de acuerdo con 2.10.3 Comprobación de los enlaces físicos. Si el problema persiste, contacte a los ingenieros de soporte técnico.

 

<HUAWEI> display interface gigabitethernet 1/0/2 
GigabitEthernet1/0/2 current state : UP 
Line protocol current state : UP 
Description: 
Switch Port,PVID :    1,TPID :8100(Hex),The Maximum Frame Length is 1600 
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0025-9e80-2494
Current system time: 2016-08-10 07:09-05:13 
Port Mode: COMMON COPPER 
Speed : 1000,  Loopback: NONE 
Duplex: FULL,  Negotiation: ENABLE 
Mdi   : AUTO 
Last 300 seconds input rate 760 bits/sec, 0 packets/sec 
Last 300 seconds output rate 896 bits/sec, 0 packets/sec 
Input peak rate 12304 bits/sec,Record time: 2016-08-10 07:09 
Output peak rate 14568 bits/sec,Record time: 2016-08-10 07:09 
Input:  28643 packets, 2734204 bytes 
Unicast        :               20923,Multicast          :                7703 
Broadcast      :                  17,Jumbo              :                   0 
CRC            :                   0,Giants             :                   0 
Jabbers        :                   0,Fragments          :                   0 
Runts          :                   0,DropEvents         :                   0 
Alignments     :                   0,Symbols            :                   0 
Ignoreds       :                   0,Frames             :                   0 
Discard        :                 474,Total Error        :                   0 
Output:  68604 packets, 8057155 bytes 
Unicast        :               20429,Multicast          :               14054 
Broadcast      :               34121,Jumbo              :                   0 
Collisions     :                   0,Deferreds          :                   0 
Late Collisions:                  0,ExcessiveCollisions:                  0 
Buffers Purged :                   0 
Discard        :                   0,Total Error        :                   0 
Input bandwidth utilization threshold : 100.00% 
Output bandwidth utilization threshold: 100.00% 
Input bandwidth utilization  : 0.01% 
Output bandwidth utilization : 0.00%

 

2.5 Verificación del conteo de descartes en la dirección de salida

Esta sección está separada del "Estado de verificación del interfaz" porque la pérdida de paquetes causada por la congestión a menudo ocurre en las redes en vivo.

Cuando el recurso de la red es insuficiente y la velocidad de transmisión disminuye, se produce un retraso. Si una red tiene una ráfaga de tráfico de multidifusión o ejecuta múltiples servicios al mismo tiempo, puede producirse una congestión. La ráfaga de tráfico ocupa un ancho de banda excesivo, algunos paquetes se eliminan.

1. Compruebe si hay paquetes descartados en la interfaz.

 

Ejecute el comando display interface interface-typeinterface-number  en cualquier vista o display this interface en la vista de interfaz para ver las estadísticas de paquetes salientes en la interfaz del lado del usuario. Si el recuento de descartes no es 0, el puerto se ha iniciado. Compruebe si aumenta el número de paquetes descartados.

- Si no, el problema es irrelevante para la pérdida de paquetes. Luego salta esta sección.

- Si es así, el problema es causado por la pérdida de paquetes. Entonces ve al siguiente paso.

 

[HUAWEI]display interfaceGigabitEthernet 1/0/2 
GigabitEthernet1/0/2 current state : UP 
Line protocol current state : UP 
Description:link-to-OLT-LB 
Switch Port, PVID :1, TPID : 8100(Hex), The Maximum Frame Length is 1600 
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is4c1f-cc45-b1c0  
Current system time: 2016-08-10 07:09 
Port Mode: COMMON COPPER 
Speed : 1000,Loopback: NONE 
Duplex: FULL,Negotiation: ENABLE 
Mdi: AUTO,Flow-control: DISABLE 
Last 300 seconds input rate 99894144 bits/sec, 141895 packets/sec 
Last 300 seconds output rate 190939848 bits/sec, 271220 packets/sec 
Input peak rate 173002368 bits/sec, Record time: 2016-08-10 07:09 
Output peak rate 346005880 bits/sec, Record time: 2016-08-10 07:09 
Input:175946456 packets, 15483288128 bytes 
Unicast:0,Multicast:0 
Broadcast:175946456,Jumbo:0 
Discard:0, Pause:0 
Total Error:0 
CRC:0,Giants:0 
Jabbers:0,Fragments:0 
Runts:0,DropEvents:0 
Alignments:0,Symbols:0 
Ignoreds:0,Frames:0 
Output:348119287 packets, 30634557621 bytes 
Unicast:0,Multicast:773 
Broadcast:348118514,Jumbo:0 
Discard:3769937,Pause:0 
Total Error:0 
Collisions:0,ExcessiveCollisions:0 
Late Collisions:0,Deferreds:0 
Buffers Purged:0

 

. Establezca el modo de búfer en mejorado y verifique si aumenta el número de paquetes descartados.

Generalmente, el tamaño del búfer en una interfaz es pequeño. Cuando la tasa de tráfico en una interfaz alcanza el 50% al 60% del ancho de banda de la interfaz, los paquetes se pierden en la interfaz. Una vez que el modo de búfer en la interfaz se establece en mejorado, una interfaz puede adelantarse a un búfer más dinámico y la interfaz tiene una mayor capacidad para hacer frente a la ráfaga de tráfico. Esto puede aliviar la pérdida de paquetes causada por la congestión.

<HUAWEI> system-view 
[HUAWEI] interface gigabitethernet 1/0/2 
[HUAWEI-GigabitEthernet1/0/1] qos burst-mode enhanced

 

Las LPU de la serie X1E no admiten este comando.

Cuando el modo de búfer se configura en mejorado, el comando qos burst-mode (interface view) y el comando qos burst-mode(system view)  no se pueden usar juntos. Además, los comandos anteriores no pueden usarse junto con la longitud de qosqueue.

 

Compruebe el recuento de descartes en la interfaz.

- Si la cantidad de paquetes descartados no aumenta, se elimina la congestión. Compruebe si la pérdida de paquetes está corregida. Si no, salta esta sección y ve a la siguiente sección.

- Si la cantidad de paquetes descartados aumenta o el dispositivo no es compatible con el comando qos burst-mode, optimice la red.

 

3. Optimizar la red.

 

Considere los siguientes métodos:

- Configurar el limitador de velocidad de tráfico en la dirección de entrada.

La ráfaga de tráfico es el motivo principal de la pérdida inesperada de paquetes. Cuando el tamaño del paquete de ráfaga excede el interfacebuffer, los paquetes de servicio se pierden, afectando a los servicios del usuario. La configuración de la limitación o la configuración de la tasa de tráfico en el dispositi****scendente puede aliviar la ráfaga de tráfico o reducir el tamaño del paquete de ráfaga, y se reduce la posibilidad de que se produzca una congestión en los dispositivos descendentes.

- Proporcionar servicios diferenciados en puertos. Los servicios clave se colocan en colas de alta prioridad, que se pueden procesar primero en caso de congestión.

Si una interfaz ejecuta muchos servicios, incluidos servicios de alta prioridad (como voz y video) y servicios de baja prioridad (como acceso a la red). Puede especificar diferentes prioridades para los servicios de alta prioridad en el dispositivo en sentido ascendente o configurar la asignación de prioridad en el ingreso de un dispositivo, para garantizar que los servicios clave ingresen en las colas de prioridad alta. La configuración de la programación de PQ en la salida puede garantizar que los servicios de alta prioridad se programen primero.

- Si hay varios flujos de conflicto, aumente el ancho de banda del enlace entre los dispositivos o agregue más interfaces al Troncal para el equilibrio de la carga.

- Si el servicio de multidifusión está configurado, ajuste el modo de envío de paquetes en el servidor de origen de multidifusión para aliviar la congestión.

 

2.6 Comprobación de bucles

El bucle es una causa común de pérdida de paquetes y es difícil detectar los bucles. Por ejemplo, en una red de gran tamaño, si el administrador conecta incorrectamente las interfaces del conmutador para provocar un bucle, los paquetes se eliminarán.

1. Compruebe si aparecen los siguientes síntomas:

Además de la pérdida de paquetes, los bucles pueden causar los siguientes síntomas:

 

         Ejecutar el comando display interface brief | include up  para ver las estadísticas de tráfico en la interfaz Up. Si la interfaz tiene un bucle, los valores de InUti y Oututti aumentan, o incluso se aproximan al 100%. Los valores superan el volumen del tráfico de servicios.

Primera consulta:

 

<SwitchA> display interface brief | include up  
 ... 
Interface                   PHY   Protocol  InUti OutUti  inErrors  outErrors                                                       
GigabitEthernet0/0/2        up    up       0.56%  0.56%          0          0                                                       
 ...    
Last query:
<SwitchA> display interface brief | include up  
... 
Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors                                                      
GigabitEthernet0/0/2        up    up         76%    76%          0          0                                                      
...
          The display interface command output shows a large number of broadcastpackets received on an interface.
          Indicators of interfaces in theVLAN where a loop has occurred blink faster than usual.
          The CPU usage of a switchexceeds 80%.
<SwitchB> display cpu-usage  
CPU Usage Stat.
Cycle: 60 (Second)   
CPU Usage            : 95% Max: 97%    
CPU Usage Stat. Time : 2013-08-21 16:38:44   
CPU utilization for five seconds: 95%: one minute: 95%: five minutes: 95%   
Max CPU Usage Stat. Time : 2016-08-10 07:09.   
 ....

 

Ejecute el comando display cpu-usage  para verificar el uso de la CPU. Los bucles de red pueden llevar a un uso elevado y continuo de la CPU, y es posible que el conmutador no pueda procesar los paquetes y los descarte.

- Ocurre frecuentemente MAC flapping.

 

Ejecute el comando display trapbuffer para verificar si se reporta una alarma de fallas del MAC,

La alarma de aleteo de MAC es como sigue:

 

L2IFPPI/4/MFLPVLANALARM:OID1.3.6.1.4.1.2011.5.25.160.3.7 MAC move detected, VlanId = 22, MacAddress =0000-5e00-0116, Original-Port = Eth-Trunk1, Flapping port = Eth-Trunk11. Pleasecheck the network accessed to flapping port.

 

            Verifique si el aleteo de MAC se produce en el dispositivo con el paquete de ping perdido.

 

Ejecute el comando mac-address flappingdetection  para configurar la detección de flapping de la dirección MAC, y luego ejecute el comando display mac-address flapping record para verificar si se está produciendo el aleteo de la dirección MAC.

 

<HUAWEI> system-view 
[HUAWEI] mac-address flapping detection
<HUAWEI> display mac-addressflapping record 
 S : start time                                                                
 E : end time                                                                  
(Q) : quit VLAN  
(D) : error down  
------------------------------------------------------------------------------ 
Move-Time             VLAN  MAC-Address  Original-Port Move-Ports   MoveNum
-------------------------------------------------------------------------------
S:2016-08-10 07:09 300  0000-0000-0007Eth-Trunk1   Eth-Trunk2   81 
E:2016-08-10 07:09 
 
-------------------------------------------------------------------------------
Total items on slot 2: 1

 

Ejecute el comando display mac-address varias veces. Si la dirección MAC es aprendida por diferentes interfaces, existe el aleteo de MAC.

 

<HUAWEI> display mac-address 
-------------------------------------------------------------------------------  
MAC Address          VLAN/VSI                    Learned-From        Type        
-------------------------------------------------------------------------------
0022-0022-0033       100/-                       GE1/0/1             dynamic  
0000-0000-0001       -/HUAWEI                    GE1/0/2             static  
-------------------------------------------------------------------------------
Total items displayed = 2 
          Loop alarms are generated afterloop detection is enabled.

 

Tabla2-2 enumera las alarmas de bucle.

Tabla 2-2 Alarmas de bucle en el switch

 

   Id de alarma
     

   Mensaje de la   alarma
     

   Descripción
     

  1.3.6.1.4.1.2011.5.25.174.3.1
    

  LDT/4/DetectLoop:   OID [oid] The port  detected loop. (InterfaceIndex: [INTEGER]   InterfaceName: [OCTET] VlanListLow:  [OCTET] VlanListHigh: [OCTET])
    

  Si los paquetes   que envía un puerto se devuelven al puerto a través de la VLAN local, esto   indica que los paquetes están en bucle. Un bucle puede causar una tormenta de   difusión.

   Esta alarma se   genera cuando se detecta un bucle.
    

  1.3.6.1.4.1.2011.5.25.174.3.2
    

  LDT/4/LoopResume:   OID [oid] The detected  loop is removed. (InterfaceIndex: [INTEGER]   InterfaceName: [OCTET]  VlanListLow: [OCTET] VlanListHigh: [OCTET])
    

  Esta   notificación de recuperación se genera cuando se borra el bucle de paquetes   del puerto.
    

  1.3.6.1.4.1.2011.5.25.174.3.3
    

  LBDT/4/PORTTRAP:   OID [OID] Loopback  exists on interface([INTEGER1]) [OCTET1] ([OCTET2]),   loopback detection  status: [INTEGER2].(1:normal; 2:block;   3:shutdown; 4:trap; 5:nolearn;  6:quitvlan)
    

  Se detecta un   bucle en la red de Capa 2 conectada a la interfaz.  

  1.3.6.1.4.1.2011.5.25.174.3.4
    

  LBDT/4/PORTTRAP:   OID [OID] Loopback is  removed on interface([INTEGER1]) [OCTET],   loopback detection status:  [INTEGER2].(1:normal; 2:block;   3:shutdown; 4:trap; 5:nolearn; 6:quitvlan)
    

  The loop on the   interface is removed.
    

 

Seleccione un método apropiado basado en la información y la red de bucle.

1. Observe los indicadores de interfaz y recopile estadísticas de tráfico en las interfaces para ubicar las tormentas de transmisión en curso de las interfaces.

2. Verifique el salto de los dispositivos de acuerdo con la topología para ubicar los dispositivos que causan el bucle.

3. Localice la interfaz que causa el bucle y apáguela para eliminar el bucle.

GE0 / 0/2 puede tener un bucle, por lo que los paquetes ping en el conmutador B se eliminan. Para determinar si la pérdida de paquetes en el switch B está causada por un bucle, cierre GE0 / 0/2 del switch B y luego realice una prueba de ping.

# Shut down GE0/0/2 of switch B.
<SwitchB> system-view  
[SwitchB] interface gigabitethernet0/0/3  
[SwitchB-GigabitEthernet0/0/3] shutdown  
[SwitchB-GigabitEthernet0/0/3] quit
# Perform a ping test.
<SwitchB> ping -c 100 192.168.2.21  
 PING 192.168.2.21: 56  data bytes, press CTRL_C to break       
    Reply from 192.168.2.21: bytes=56Sequence=1 ttl=255 time=1 ms     
  ... 
    Reply from 192.168.2.21: bytes=56Sequence=100 ttl=255 time=2 ms                                                                  
                                                                                                                                      
  --- 192.168.2.21 ping statistics---                                                                                              
    100 packet(s) transmitted                                                                                                         
    100 packet(s) received                                                                                                            
    0.00% packet loss                                                                                                                 
    round-trip min/avg/max = 1/1/19ms  

 

Deshabilitar la interfaz no es la solución definitiva para la pérdida de paquetes de ping. Para resolver el problema, elimine el bucle de la red conectada. Configure el protocolo RRPP, SEP, Smart Link o STP / RSTP / MSTP para evitar bucles.

4. Si el error persiste después de realizar las operaciones anteriores, recopile información de la red (incluidas las conexiones de interfaz) y los registros (el archivo log.log o la salida del comando logbuffer de pantalla), y proporcione la información recopilada a los ingenieros de soporte técnico Huawei switchagentsHuawei.

 

Este capítulo describe solo el método de ubicación de los bucles de red y las sugerencias de manejo. Para obtener más información, consulte la guía de resolución de problemas del bucle del conmutador

 

2.7 Comprobando Ataques

 

Al sufrir un ataque, un conmutador está ocupado procesando las solicitudes de la fuente del ataque, y otros paquetes de servicio se eliminan.

Los ataques comunes a la red, como los ataques ARP, ARPMiss y DHCP, pueden causar un alto uso de la CPU en un conmutador. Todos estos ataques se inician enviando una gran cantidad de paquetes de protocolo; por lo tanto, las estadísticas de paquetes en el conmutador muestran una gran cantidad de paquetes enviados a la CPU.

l ARP y ARP-Miss ataques

l ataque de paquetes de protocolo DHCP

l otros ataques

- ataque ICMP

- Ataque DDoS

- ataque de difusión

- Ataque TTL-caducado

- Envío de paquetes IP cuya dirección de destino es la dirección IP del dispositivo de destino

- SSH / FTP / Telnet ataque

 

1. Ejecute el comando display cpu-defend statistics  para ver las estadísticas sobre los paquetes enviados a la CPU, determinando si se han descartado demasiados paquetes de protocolo debido al tiempo de espera.

 

a. Ejecute el comando reset cpu-defend statistics  para borrar las estadísticas sobre los paquetes enviados a la CPU.

segundo.

b. Después de varios segundos, ejecute el comando display cpu-defend statistics  para ver las estadísticas sobre los paquetes enviados a la CPU.

Si hay demasiados paquetes de protocolo, determine si es normal dependiendo de la red. Si no, hay una alta probabilidad de que el conmutador esté experimentando un paquete de protocolo de ataque.

 

<HUAWEI> reset cpu-defend statistics 
<HUAWEI> display cpu-defendstatistics all 
Statistics on slot 2: 
-----------------------------------------------------------------------------------------------------------
Packet Type         Pass(Bytes)  Drop(Bytes)  Pass(Packets)   Drop(Packets) 
-----------------------------------------------------------------------------------------------------------
arp-miss            0           0            0             0 
arp-request          40800       35768        600           52600 
bgp                0           0            0             0 
... 
-----------------------------------------------------------------------------------------------------------

 

La información anterior muestra que el conmutador ha descartado muchos paquetes de solicitud ARP. Si estos paquetes son anormales, el interruptor sufre un ataque ARP.

 

2.        Configure the attack sourcetracing function to find out the attack source.
If a CPU is busy with many valid orattack packets, services may be interrupted. The switch provides the localattack defense function to protect the CPU. Local attack defense policiesinclude attack source tracing, port attack defense, CPCAR, and blacklist.
For details about local attack defense,see S switch high CPU usage troubleshooting.
a.
        Create the local attack defensepolicy based on attack source tracing.
i.
         Create an ACL and add thegateway IP address to the whitelist of attack source tracing.

 

2. Configure la función de búsqueda de fuentes de ataque para averiguar la fuente del ataque.

Si una CPU está ocupada con muchos paquetes válidos o de ataque, los servicios pueden interrumpirse. El interruptor proporciona la función de defensa localattack para proteger la CPU. Las políticas locales de defensa contra ataques incluyen el rastreo de la fuente del ataque, la defensa contra ataques en el puerto, CPCAR y la lista negra.

Para obtener más información acerca de la defensa local contra ataques, consulte la resolución de problemas con el uso elevado de CPU del interruptor S

a. Cree la política de defensa de ataque local basada en el rastreo de la fuente de ataque.

yo. Cree una ACL y agregue la dirección IP de la puerta de enlace a la lista blanca de rastreo de origen de ataque.

 

<HUAWEI> system-view 
[HUAWEI] acl number 2000  
[HUAWEI-acl-basic-2000] rule 5 permitsource 10.1.1.1 0  //10.1.1.1 is thegateway IP address. 
[HUAWEI-acl-basic-2000] quit
ii.
       Create the local attack defensepolicy based on attack source tracing.
[HUAWEI] cpu-defend policy policy1 
[HUAWEI-cpu-defend-policy-policy1] auto-defendenable  //Enable attack sourcetracing. By default, this function is disabled. 
[HUAWEI-cpu-defend-policy-policy1] undoauto-defend trace-type source-portvlan //Set the attack tracing mode to MAC + IP based. By default, attacksource tracing is based on source MAC address, source IP address, sourceinterface, and VLAN ID. To delete unneeded mode, run the undo auto-defend trace-typecommand. 
[HUAWEI-cpu-defend-policy-policy1] undoauto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp  //Delete a packet type from attack sourcetracing. By default, the packet types for attack source tracing are 802.1x,ARP, DHCP, ICMP, IGMP, TCP, Telnet, TTL-expired, and UDP. 
[HUAWEI-cpu-defend-policy-policy1] auto-defendwhitelist 1 acl 2000  //Add thegateway IP address to whitelist. 
[HUAWEI-cpu-defend-policy-policy1] quit

 

b.        Aplicar la política de defensa de ataque local.

 

Modular Switches

 

.

 

Tanto las MPU como las LPU tienen sus propias CPU. Las políticas locales de defensa contra ataques se configuran de manera diferente para las MPU y las LPU.

Antes de crear y aplicar políticas de defensa de ataque, verifique la información de ataque en las MPU y las LPU. Si la información de ataque en las MPU y las LPU es coherente, aplique la misma política de defensa de ataques a las MPU y las LPU; De lo contrario, aplicarles diferentes políticas.

yo. Aplicar una política de defensa de ataque a MPU.

 

<HUAWEI> system-view 
[HUAWEI] cpu-defend-policy policy1  
[HUAWEI] quit

 

ii. Aplicar una política de defensa de ataque a una LPU.

 

Si una política de defensa de ataque se ha aplicado a todas las LPU, no se puede aplicar a la LPU especificada. De manera similar, si una política de defensa de ataques se ha aplicado a una LPU específica, no se puede aplicar a todas las LPU.

□ Si todas las LPU proce******rvicios similares, aplique una política de defensa de ataques a todas las LPU.

 

<HUAWEI> system-view 
[HUAWEI] cpu-defend-policy policy2global 
   If LPUs process different services, apply an attack defense policyto the specified LPU.
<HUAWEI> system-view 
[HUAWEI] slot 1 
[HUAWEI-slot-1] cpu-defend-policypolicy2

 

Fixed Switch

 

 Apply an attack defense policy to a stand-alone switch.

 

Aplicar una política de defensa de ataque a un interruptor independiente.

 

<HUAWEI> system-view 
[HUAWEI] cpu-defend-policy policy1global 

 

En una pila:

 

Aplicar una política de defensa de ataque al switch maestro.

 

<HUAWEI> system-view 
[HUAWEI] cpu-defend-policy policy1 

 

- Aplicar una política de defensa de ataque a todos los switches apilados.

<HUAWEI> system-view 
[HUAWEI] cpu-defend-policy policy1global 

 

c.         Ver información de la fuente de ataque.

 

Después de configurar la defensa de ataque local en función del seguimiento de la fuente de ataque, ejecute display auto-defend attack-source y display auto-defend attack-source slot slot-id  para ver la información de la fuente del ataque.

 

La dirección MAC de la puerta de enlace debe ser excluida de las fuentes de ataques sospechosos.

3. Seleccione un método apropiado basado en la información de origen del ataque y la red.

- Configurar la seguridad ARP para prevenir los ataques ARP.

El conmutador proporciona seguridad ARP para evitar los ataques de paquetes ARP y ARP Miss.

Para obtener detalles sobre la seguridad de ARP, consulte Soluciones de seguridad ARP en la sección Configuración de seguridad ARP en la Guía de configuración - Seguridad.

- Configure una acción de ataque de origen: descarte los paquetes de ataque dentro del período especificado.

 

# Discard attack packets within 300s.
<HUAWEI> system-view 
[HUAWEI] cpu-defend policy policy1 
[HUAWEI-cpu-defend-policy-policy1] auto-defendenable  //Enable attack sourcetracing. By default, this function is disabled. 
[HUAWEI-cpu-defend-policy-policy1] auto-defendaction deny timer 300  //By default,attack source tracing action is not enabled.

 

Configurar una lista negra para la defensa localattack. Los paquetes de los usuarios en la lista negra se descartan.

Si una fuente de ataque se considera un atacante (por ejemplo, la dirección de la fuente de ataque es 1.1.1.0/24), agregue los usuarios con las características especificadas a una lista negra.

# Configure ACL 2001 para que coincida con los paquetes con la dirección de origen 1.1.1.0/24 y descarte los paquetes que coincidan con la ACL.

 

[HUAWEI] acl number 2001 
[HUAWEI-acl-basic-2001] rule permitsource 1.1.1.0 0.0.0.255 
[HUAWEI-acl-basic-2001] quit 
[HUAWEI] cpu-defend policy policy1 
[HUAWEI-cpu-defend-policy-policy1] blacklist1 acl 2001

 

Configure el rastreo de la fuente de ataque: cierre la interfaz que recibe los paquetes de ataque.

Si los paquetes de ataque se envían desde una interfaz específica y el cierre de esta interfaz no afecta a los servicios, use este método.

 

 

 

Apagar una interfaz puede causar una interrupción del servicio y afectar a usuarios válidos. Utilice este método con precaución.

 

# Configurar el rastreo de la fuente de ataque: cierre la interfaz que recibe los paquetes de ataque.

 

<HUAWEI> system-view 
[HUAWEI] cpu-defend policy policy1 
[HUAWEI-cpu-defend-policy-policy1] auto-defendenable  //Enable attack sourcetracing. By default, this function is disabled. 
[HUAWEI-cpu-defend-policy-policy1] auto-defendaction error-down

 

Después de localizar la fuente de ataque y usar el método de manejo, verificar si se alivia la pérdida de paquetes. Si no, vea la sección siguiente.

 

2.8 Comprobación de si la tasa de paquetes enviados a la CPU excede el límite

 

El conmutador utiliza diferentes valores de CPCAR para diferentes tipos de paquetes de protocolo. En general, los valores CPCAR predeterminados pueden cumplir los requisitos del servicio. Es posible que los valores de CPCAR de algunos paquetes de protocolo deban cambiarse de acuerdo con la escala de servicio y el entorno de red del usuario.

 

1. Ejecute el comando display cpu-defend statistics all  para ver las estadísticas de los paquetes enviados a la CPU, determinando si los paquetes de servicio se pierden.

2. Ejecute display cpu-defend configuration [ packet-type packet-type ]{ all | slot slot-id | mcu } para ver los límites de velocidad para los paquetes enviados a la CPU.

3. Ejecute display cpu-defend rate [ packet-typepacket-type ] { all | mcu | slot slot-id } para ver la tasa de paquetes enviados a la CPU.

4. Determine si los valores de CPCAR cumplen con los requisitos de la red.

Por ejemplo, si una red tiene paquetes perdidos, verifique si la configuración de CPCAR coincide con la escala de la red.

# Compruebe si los paquetes ICMP enviados a la CPU han sido eliminados.

 

<HUAWEI> display cpu-defend statistics all                                           
 Statistics on mainboard:                                                       
--------------------------------------------------------------------------------
Packet Type         Pass(Packet/Byte)  Drop(Packet/Byte) Last-dropping-time   
--------------------------------------------------------------------------------
icmp                          880928            44380928  2016-08-10 07:09 
                               25301              693450 
...
A total of 44380928 ICMP packets on theMPU are dropped.
# Check the rate limit on the ICMPpackets sent to the CPU.
<HUAWEI> display cpu-defend configuration packet-type icmp all                       
Car configurations on mainboard.                                                
----------------------------------------------------------------------           
Packet Name         Status     Cir(Kbps)  Cbs(Byte)  Queue  Port-Type           
----------------------------------------------------------------------           
icmp                 Enabled         256       48128      3        NA           
----------------------------------------------------------------------           

 

La tasa de paquetes ICMP que se pueden enviar a la CPU es de 256 kbit / s = 256 * 1024 bit / s = 262144 bit / s.

# Compruebe la tasa de paquetes ICMP enviados a la CPU.

 

<HUAWEI> display cpu-defend rate packet-type icmp all                               
Info: Please wait for a moment....                                               
Cpu-defend rate on mainboard:                                                   
-------------------------------------------------------------------------------  
Packet Type           Pass(bps)    Drop(bps)       Pass(pps)       Drop(pps)     
-------------------------------------------------------------------------------  
icmp                      239211      3389532          5854            69585     
-------------------------------------------------------------------------------  
...

 

La tasa de paquetes ICMP enviados por la MPU a la CPU es de 239211 bit / s, que se aproxima al valor máximo 262144. Muchos paquetes se eliminan. Esto indica que el valor de CPCAR no coincide con la escala de la red.

5. La configuración incorrecta de CPCAR afectará los servicios de red. Por lo tanto, ajuste la configuración de CPCAR bajo la guía del personal de soporte técnico.

 

2.9 Comprobación de las configuraciones relacionadas

 

1. Compruebe si las configuraciones de las interfaces, VLAN, interfaces VLANIF o configuraciones globales causan la pérdida de paquetes.

Las configuraciones a verificar incluyen:

- Compruebe si el filtrado de tráfico, la supresión o la limitación de velocidad están configurados y si la configuración de la política de tráfico es adecuada. Por ejemplo, si la política de tráfico está configurada para eliminar un tipo de paquetes, estos paquetes se eliminarán.

n Compruebe la configuración de la política de tráfico. Compruebe si la política de tráfico se aplica correctamente y si el comportamiento del tráfico y el clasificador de tráfico en la política de tráfico tienen configuraciones que conducen a la pérdida de paquetes.

# Ejecute el comando display traffic policy user-defined para ver la configuración de la política de tráfico.

 

<HUAWEI> display traffic policy user-defined 
  User Defined Traffic PolicyInformation:                                       
  Policy: p1                                                                    
   Classifier: c1                                                               
    Operator: AND                                                               
     Behavior: b1                                                               
      Permit  
      Remark:                                                                   
        Remark 8021p 4                                                          
      Committed Access Rate:                                                    
        CIR 10000 (Kbps), PIR 10000(Kbps), CBS 1880000 (byte), PBS 3130000 (byte)                                                                              
        Color Mode: color Blind                                                 
        Conform Action: pass                                                    
        Yellow  Action: pass                                                    
        Exceed  Action: discard                                                  
                                                                                
Total policy number is 1

 

# Ejecute el comando display traffic behavior user-definedbehavior-name ] para verificar si el comportamiento del tráfico tiene configuraciones que lideran la pérdida de topacket.

 

<HUAWEI> display traffic behavior user-defined 
  User Defined Behavior Information:                                             
    Behavior: b1 
      permit 
      Remark:                                                                    
        Remark 8021p 4                                                          
      Redirect:                                                                 
        Redirect cpu                                                             
      Committed Access Rate:                                                    
        CIR 10000 (Kbps), PIR 10000(Kbps), CBS 1880000 (byte), PBS 3130000 (byte) 
        Color Mode: color Blind                                                  
        Conform Action: pass                                                    
        Yellow  Action: pass                                                    
        Exceed  Action: discard                                                  
                                                                                
Total behavior number is 1     

# Ejecute el comando display traffic classifier user-defined classifier-name ] para verificar la configuración del clasificador de tráfico.

 

<HUAWEI> display traffic classifier user-defined
  User Defined Classifier Information: 
   Classifier: c1 
    Precedence: 5 
    Operator: AND 
    Rule(s) : if-match acl 2046 
              
Total classifier number is 1 

 

# Ejecute el comando display acl {acl-number | all} para verificar si la ACL contiene la regla de denegación.

 

<HUAWEI> display acl all                                     
 Total nonempty ACL number is 1                                                 
                                                                                
Advanced ACL 2046, 1 rule                                                       
Acl's step is 5                                                                 
 rule 5 deny icmp                                             

 

Si las configuraciones son incorrectas, modifique las configuraciones.

n Compruebe la configuración de supresión de tráfico: cuando se produce un ataque de paquetes de difusión o si necesita suprimir paquetes de difusión por otras razones, ejecute el comando broadcast-suppression.

difusión-supresión: establece la tasa de tráfico máximo de paquetes de difusión que pueden pasar a través de una interfaz. Cuando la cantidad de paquetes de difusión que llegan a la interfaz supera el umbral, los paquetes de exceso se descartan. No se registra ningún registro para la pérdida de paquetes.

2. Compruebe si las funciones de seguridad están configuradas, como la seguridad del puerto, IPSG y URPF.

port-securityenable: después de habilitar la seguridad del puerto en una interfaz, las direcciones MAC aprendidas por la interfaz cambian para asegurar direcciones MAC dinámicas. Cuando el número máximo de direcciones MAC dinámicas seguras aprendidas en una interfaz alcanza el límite (el valor es 1 de manera predeterminada), la interfaz no aprende nuevas direcciones MAC. Descarta paquetes con nuevas direcciones MAC de origen.

ipsource check user-bind enable: habilita IP packetcheck, incluida la dirección IP, la dirección MAC, la VLAN y la información de la interfaz en los paquetes IP.

urpfstrict: habilita el control estricto de URPF en la interfaz. Los paquetes recibidos por las subinterfaces no pueden pasar el control estricto y se colocarán en suspensión.

Si la función BPDU está deshabilitada en la interfaz, las BPDU no se pueden transmitir de forma transparente y se descartarán.

En general, la dirección MAC de destino de las BPDU es 01: 80: C2: 00: 00: xx. De forma predeterminada, una interfaz entrante eliminará las BPDU. Para transmitir BPDU de forma transparente, ejecute el comando bpdu bridge enable en la vista de interfaz.

3. Si el conmutador realiza el reenvío de Capa 2, realice las siguientes comprobaciones:

a. Verifique que la configuración de VLAN en la interfaz sea correcta.

n La interfaz no se agrega a una VLAN especificada; por lo tanto, no permite que los paquetes de la VLAN pasen a través.

Ejecute el comando vlanvlan-id de la pantalla para verificar si la interfaz se agrega a cualquier VLAN en modo sin etiquetar sin etiquetar. Si el PVID está configurado en la interfaz, el PVID se agrega a los paquetes no etiquetados en la interfaz de entrada. Es necesario agregar la interfaz a la VLAN VID.

 

<HUAWEI> display vlan 10                                                       
--------------------------------------------------------------------------------
U: Up;         D: Down;         TG: Tagged;         UT: Untagged;                
MP: Vlan-mapping;               ST:Vlan-stacking;                              
#: ProtocolTransparent-vlan;    *:Management-vlan;                             
--------------------------------------------------------------------------------
                                                                                
VID  Type    Ports                                                              
--------------------------------------------------------------------------------
10   common  UT:GE2/9/0/1(D)    GE2/9/0/3(D)                                     
             TG:GE2/9/0/4(D)                                                    
                                                                                
VID  Status  Property     MAC-LRN Statistics Description                        
--------------------------------------------------------------------------------
10   enable  default      enable  disable    VLAN 0010 

 

Compruebe si las interfaces de entrada y salida pertenecen a la VLAN de servicio de nombres de usuario.

n La interfaz está configurada para dejar caer los paquetes etiquetados entrantes.

puerto descartar paquete etiquetado: configura la interfaz para eliminar los paquetes etiquetados entrantes. Si la pérdida de paquetes se debe a una configuración incorrecta, ejecute el comando undoport discard tagged-packet para modificar la configuración.

n La interfaz está configurada para eliminar los paquetes que no coinciden con ninguna entrada de asignación de VLAN o QinQ selectiva.

qinq vlan-translation miss-drop: configura la interfaz configurada con el mapeo selectivo de QinQ y VLAN para deshacer los paquetes recibidos que no coinciden con ningún tipo de mapeo selectivo de QinQ o VLAN. Si la pérdida del paquete se debe a una configuración incorrecta, ejecute el comando de deshacer qinq vlan-translation miss-drop para modificar la configuración.

Si la QinQ selectiva está configurada en la interfaz, agregue la interfaz a la VLAN especificada por la etiqueta VLAN externa que reemplaza la etiqueta VLAN externa original de los paquetes.

segundo. Compruebe que la dirección MAC de los paquetes de Capa 2 se aprende correctamente.

Ejecute el comando mac-address mac-address de la pantalla para verificar si los enlaces entre la dirección MAC, la VLAN y la interfaz son correctos.

 

<HUAWEI> display mac-address 
-------------------------------------------------------------------------------  
MAC Address          VLAN/VSI                    Learned-From        Type        
-------------------------------------------------------------------------------
0022-0022-0033       100/-                       GE1/0/1             dynamic  
0000-0000-0001       -/HUAWEI                    GE1/0/2             static  
-------------------------------------------------------------------------------
Total items displayed = 2

 

Si la dirección MAC de origen no se aprende, reconfigure los enlaces entre la dirección MAC, la ID de VLAN y el número de interfaz.

Si la QinQ selectiva está configurada en una interfaz, se aprenden las direcciones MAC de origen de las interfaces en la VLAN especificada por la etiqueta VLAN externa de los paquetes, colocada allí.

do. Compruebe si alguna configuración de la dirección MAC causa la pérdida de paquetes.

n El aprendizaje de la dirección MAC está deshabilitado en la interfaz y la interfaz está configurada para descartar paquetes con direcciones MAC de origen desconocido.

Verifique las configuraciones en la vista de la interfaz o VLAN. Si la salida del comando incluye el descarte de la acción de deshabilitar la dirección de mac, el conmutador no aprende las direcciones MAC en la interfaz. Si se encuentra una entrada coincidente en la tabla de direcciones MAC, los paquetes se reenvían según la tabla de direcciones MAC. De lo contrario, los paquetes se eliminan.

n Compruebe si las reglas de limitación de la dirección MAC están configuradas.

Verifique las configuraciones en la vista de la interfaz o VLAN. Si la salida del comando incluye mac-limit max-num máximo, los paquetes de los cuales las direcciones MAC de origen no están incluidas en la tabla de direcciones MAC se eliminan después de que el número de entradas de la dirección MAC alcance el límite.

n Compruebe si una dirección MAC estática está configurada.

Ejecute el comando de visualización de la dirección mac para ver las entradas de direcciones MAC estáticas.

Si una dirección MAC estática está configurada, solo la interfaz vinculada a la dirección MAC estática procesa los paquetes con esta dirección MAC. Otras interfaces eliminan los paquetes con esta dirección MAC.

n Compruebe si una dirección MAC de agujero negro está configurada.

Ejecute el comando display mac-address blackhole para ver las entradas de direcciones MAC de agujero negro.

Cuando se configura una dirección MAC de agujero negro, el sistema descarta un paquete si la dirección MAC de origen o destino del paquete es la dirección MAC de agujero negro.

4. Si el conmutador realiza el reenvío de Capa 3, realice las siguientes comprobaciones:

a. Compruebe si las entradas de ARP existen, el conflicto o el número de entradas de ARP excede el límite.

n Ejecute el comando arp all de la pantalla para verificar si el fin local ha aprendido la entrada ARP del final remoto.

n Ejecute el comando display arp learningstrict para verificar si el aprendizaje estricto de ARP está configurado globalmente o en una interfaz VLANIF.

 

<HUAWEI> display arp learning strict 
The global configuration:arp learning strict 
 Interface                           LearningStrictState 
------------------------------------------------------------ 
 Vlanif100                           force-disable 
 Vlanif200                           force-enable 
------------------------------------------------------------ 
 Total:2 
 Force-enable:1 
 Force-disable:1

 

Después de configurar esta función, el conmutador aprende solo los paquetes de respuesta ARP en respuesta a los paquetes ARPRequest enviados por sí mismo.

n Ejecute el comando logbuffer en un interruptor para ver los registros. Si se muestra la siguiente información, el conmutador recibió paquetes ARP con direcciones IP en conflicto.

ARP / 4 / ARP_DUPLICATE_IPADDR: Se recibió un paquete ARP con una dirección IP duplicada desde la interfaz. (IpAddress = [IPADDR], InterfaceName = [STRING], MacAddress = [STRING])

Método de manejo:

Ejecute el comando arp anti-attack gateway-duplicate enable en la vista del sistema para habilitar la función anticolisión de la puerta de enlace ARP. Después de recibir paquetes de colisión de direcciones, el conmutador entrega entradas de defensa de ataque y suelta los paquetes de la misma dirección MAC de origen dentro de un período determinado (la fuente de ataques no puede acceder a la red dentro de este período).

Si el cliente lo permite, puede configurar una lista negra de defensa de ataque local para filtrar paquetes y configurar una entrada de dirección MAC de agujero negro para evitar que el atacante acceda a la red.

Para obtener detalles sobre la configuración, consulte 2.7 Verificación de ataques.

segundo. Compruebe que exista una ruta accesible entre los extremos local y remoto.

Ejecute los comandos display ip routing-table y displayfib para verificar las rutas a lo largo de la ruta de reenvío. Compruebe si el extremo local tiene una ruta accesible al extremo remoto, y si el extremo remoto tiene una ruta de retorno al extremo local. Asegúrese de que el protocolo de enrutamiento esté configurado correctamente.

Ejecute el comando de visualización de tabla de enrutamiento ip para verificar si las entradas de enrutamiento excesivas causan un error en la entrega de las entradas de hardware.

do. Para una subinterfaz de Capa 3, verifique si la terminación de difusión ARP (habilitación de arpbroadcast) está configurada. Luego, la subinterfaz caerá los paquetes de difusión recibidos.

5. Compruebe si la interfaz local está bloqueada por STP, RRPP, LDT o Smart Link.

Generalmente, una interfaz no puede ejecutar múltiples protocolos de anillo. Si se configura un protocolo de anillo en la interfaz, verifique el tipo de protocolo y el estado de la interfaz. STP y RRPP se utilizan como ejemplos.

- Si se configura STP, verifique si la interfaz está bloqueada por STP.

Ejecute el comando display stp brief para ver el estado de la interfaz. En las situaciones normales, el valor del campo Estado de STP es FORWARDING.

 

<HUAWEI> display stp brief 
 MSTID  Port                        Role  STP State    Protection  
    0   GigabitEthernet1/0/1       DESI  FORWARDING      NONE     
    0   GigabitEthernet1/0/2       DESI  FORWARDING      NONE     
    0   GigabitEthernet1/0/4       ROOT  FORWARDING      NONE 

 

Si el valor del estado STP es DESCARGAR, la interfaz está bloqueada. Ejecute el comando de nivel de prioridad stp en la vista del sistema para establecer la prioridad STP. Asegúrese de que el puerto local esté seleccionado como el puente raíz y no se bloqueará. (El valor de los niveles de prioridad varía de 0 a 61440. Un valor pequeño indica una prioridad alta. Una prioridad baja puede hacer que un puerto se convierta en el puente raíz).

- Si se configura RRPP, verifique si la interfaz está bloqueada por RRPP.

Ejecute el comando rrpp verbary domain domain-index para ver el estado de la interfaz. En situaciones normales, el campo de estado del puerto está arriba.

 

<HUAWEI> display rrpp verbose domain 1 
Domain Index   : 1 
Control VLAN   : major 400    sub 401 
Protected VLAN : Reference Instance 30 
Hello Timer    : 1 sec(default is 1sec)  Fail Timer : 6 sec(default is 6sec) 
RRPP Ring      : 1 
Ring Level     : 0 
Node Mode      : Master 
Ring State     : Complete 
Is Enabled     : Enable                        Is Active : Yes 
Primary port   :GigabitEthernet1/0/1          Port status:UP 
Secondary port : GigabitEthernet1/0/2         Port status: BLOCKED
If the value is BLOCK, the port is blocked. A secondary interface is blocked byRRPP. You need to modify the configuration so that the interface is not thesecondary interface.

 

2.10 Determinación de la ubicación de pérdida de paquetes según las estadísticas de tráfico

1. Aplique una política de tráfico a la interfaz de entrada y la interfaz de salida del dispositivo donde ocurre la pérdida de paquetes. Recopile estadísticas sobre paquetes del tipo especificado en las interfaces de entrada y salida y compruebe si estos paquetes se descartan en el dispositivo local.

En este ejemplo, la política de tráfico se configura en switch_3, switch_2 y switch_1. Ver estadísticas de tráfico de puerto a puerto f.

Figura 2-3 Despliegue de la política de tráfico

 

Configuraciones estadísticas de configuración de la colección.

# Configure las estadísticas de tráfico en la dirección de entrada del puerto a en switch_3.

a. Configurar reglas de ACL.

 

<Switch_3> system-view 
[Switch_3 acl number 3000 
[Switch_3-acl-adv-3000] rule permit icmpsource 192.168.100.1 0 destination 202.10.1.1 0 
[Switch_3-acl-adv-3000] quit

 

b.         Configurar un clasificador de tráfico.

 

[Switch_3] traffic classifier 3000 
[Switch_3-classifier-3000] if-match acl3000 
[Switch_3-classifier-3000] quit

 

c. Configurar un comportamiento de tráfico.

 

[Switch_3] traffic behavior 3000 
[Switch_3-behavior-3000] statisticenable 
[Switch_3-behavior-3000] quit

 

d.        Configurar  traffic policy.

 

[Switch_3] traffic policy 3000 
[Switch_3-trafficpolicy-3000] classifier3000 behavior 3000 
[Switch_3-trafficpolicy-3000] quit

 

e.        Aplicar la política de tráfico a la interfaz.

 

[Switch_3] interface gigabitethernet 1/0/2   
[Switch_3-GigabitEthernet1/0/2] traffic-policy3000 inbound    
[Switch_3-GigabitEthernet1/0/2] quit

 

# Configure la recopilación de estadísticas de tráfico en la dirección de salida del puerto b en el conmutador 3.

 

a.        Configurar ACL rules.

 

[Switch_3] acl number 3001 
[Switch_3-acl-adv-3001] rule permit icmpsource 202.10.1.1 0 destination 192.168.100.1 0 
[Switch_3-acl-adv-3001] quit

 

b.        Configurar traffic classifier.

 

[Switch_3] traffic classifier 3001 
[Switch_3-classifier-3001] if-match acl3001 
[Switch_3-classifier-3001] quit

 

c.        Configurar  traffic behavior.

 

[Switch_3] traffic behavior 3001 
[Switch_3-behavior-3001] statisticenable 
[Switch_3-behavior-3001] quit

 

d.        Configurar traffic policy.

 

[Switch_3] traffic policy 3001 
[Switch_3-trafficpolicy-3001] classifier3001 behavior 3001 
[Switch_3-trafficpolicy-3001] quit

 

e.        Aplicar la política de tráfico a la interfaz.

 

[Switch_3] interface gigabitethernet 1/0/2   
[Switch_3-GigabitEthernet1/0/2] traffic-policy3001 outbound    
[Switch_3-GigabitEthernet1/0/2] quit

 

Configure la recopilación de estadísticas de tráfico en switch_2 y switch_1 de manera similar. Para conocer los conceptos y configuraciones de la colección de estadísticas de tráfico, consulte la sección 5.1 Configuración de la colección de estadísticas de tráfico.

Analiza las estadísticas.

a. Ejecute el comando de la base de reglas de la interfaz de estadísticas de la política de tráfico de visualización tipo interfaz número de interfaz entrante / saliente para ver las estadísticas de tráfico en la interfaz.

segundo. Compare los conteos Pasados en la dirección de entrada del puerto a y la dirección de salida del puerto b, la dirección de salida del puerto b y la dirección de entrada del puerto c, la dirección de entrada del puerto y la dirección de salida del puerto d, la dirección de salida del puerto d y la dirección de entrada del puerto e, y dirección de entrada del puerto e y dirección de salida del puerto f. Determine la ubicación de la pérdida de paquetes.

En este ejemplo, compare las Cuentas aprobadas en la dirección de entrada del puerto a y la dirección de salida del puerto b, y en la dirección de salida del puerto b y la dirección de entrada del puerto c.

n Si el conteo Aprobado en la dirección de entrada del puerto se aproxima al conteo Aprobado en la dirección de salida del puerto b, no se descarta ningún paquete.

n Si el conteo Pasado en la dirección de entrada del puerto a es mayor que el conteo Pasado en la dirección de salida del puerto b, los paquetes se eliminan en switch_3.

Localice el problema de acuerdo con 2.10.1 Cargar el último parche que coincida con la versión del software del sistema y 2.10.2 Restablecer o reemplazar las tarjetas problemáticas.

n Si el conteo Pasado en la dirección de salida del puerto b se aproxima al conteo Pasado en la dirección de entrada del puerto c, no se descarta ningún paquete.

n Si el conteo Pasado en la dirección de salida del puerto b es mayor que el conteo Pasado en la dirección de entrada del puerto c, los paquetes se descargan en el enlace entre switch_3 y switch_2. Localice el problema de acuerdo con 2.10.3 Comprobación de los enlaces físicos.

2.10.1 Carga del último parche que coincide con la versión del software del sistema

 

Cargue y active el último parche que coincida con la versión del software del sistema. A continuación, compruebe si el problema está solucionado.

 

Visite http://support.huawei.com/enterprise/http://support.huawei.com/ para obtener el archivo de parche y los documentos correspondientes (notas de la versión del parche y guía de instalación).

2.10.2 Restablecimiento o reemplazo de las tarjetas problemáticas

 

Reinicie o retire las tarjetas y verifique si se resuelve la pérdida del paquete. Asegúrese de que esta operación no afecte a los servicios. Póngase en contacto con los ingenieros de soporte técnico para reemplazar las tarjetas.

2.10.3 Comprobación de los enlaces físicos

 

En este ejemplo, vea las estadísticas de tráfico en el interruptor A y el interruptor B. Puede ver que la cantidad de paquetes entrantes en el interruptor B es menor que la cantidad de paquetes salientes en el interruptor A, pero el número de paquetes entrantes en el interruptor A es más pequeño que los paquetes salientes en el interruptor B, lo que indica que los paquetes de ping se han dejado caer en el enlace físico entre el interruptor A y el interruptor B.

Las fallas de enlace físico comunes son las siguientes:

l conectores de cable están conectados demasiado flojos.

l El módulo óptico de longitud de onda no satisface las necesidades reales.

l Las interfaces de comunicación están dañadas.

l cable es demasiado largo o dañado.

Localice las fallas del enlace físico de la siguiente manera:

1. Observe el estado del indicador.

Si el indicador está apagado, el puerto no está conectado. Reemplace el puerto o el cable de red e intente nuevamente.

2. Compruebe si los cables y los módulos de hardware están conectados correctamente.

Si los cables y los módulos de hardware están conectados correctamente pero el fallo persiste, vaya al siguiente paso.

3. Compruebe si los enlaces y los módulos de interfaz funcionan correctamente.

- Si los dos dispositivos están conectados por un par trenzado, verifique los elementos de acuerdo con la Tabla 2-3.

 

Tabla 2-3 Compruebe los dispositivos conectados por un par trenzado

 

 

   Objeto
     

   Resultado   Esperado
     

   Procedimiento   de seguimiento
     

  Estado de trabajo   de par trenzado
    

  El probador   muestra que el par trenzado funciona correctamente.  

  Si el par   trenzado está defectuoso, reemplácelo.
    

  Par trenzado de   longitud
    

  La longitud del   par trenzado no supera los 100 m.

   NOTA

   Las interfaces   eléctricas 10/100 / 1000M usan conectores RJ45 y pares trenzados de Categoría   5 o superior. La distancia máxima de transmisión de dichos cables es de 100   m.
    

  Si la longitud   del cable es superior a 100 m,

   l Acortar la   distancia entre los dos dispositivos.

   l Si la   distancia entre los dos dispositivos no se puede acortar, despliegue un   repetidor o cambie entre los dispositivos.  

  Tipo de par   trenzado
    

  Un cable directo   conecta las interfaces Ethernet entre los siguientes dispositivos:

   l enrutador y   hub

   l enrutador y   conmutador

   l PC y switch

   l PC y hub

   Un cable   cruzado conecta las interfaces Ethernet entre los siguientes dispositivos:

   l dos   enrutadores

   l router y PC

   l dos hubs

   l un hub y un   interruptor

   l dos interruptores

   l   PC  

  Si el tipo de   par trenzado es incorrecto, reemplace el par trenzado.  

  Módulos   eléctricos locales y remotos.  

  1. Compruebe si   las clavijas de metal del puerto están dobladas o desviadas.

   2. Compruebe si   el cable está suelto o dañado.  

  Si los módulos   eléctricos funcionan anormalmente, reemplácelos.
    

 

Si los dos dispositivos están conectados mediante fibras ópticas, verifique los elementos según la Tabla 2-4.

Tabla 2-4 Compruebe en los dispositivos conectados por una fibra

 

 

   Objeto

   Resultado   Esperado
     

   Procedimiento   de seguimiento
 
     

  Tipos de módulos   ópticos y fibras ópticas.  

  Verifique que el   tipo de fibra sea correcto.
    

  Si el tipo de   fibra óptica no coincide con el tipo de módulo óptico, reemplace el módulo   óptico o la fibra óptica.  

  Longitud de   fibra óptica y distancia de transmisión máxima de módulos ópticos
    

  La longitud de   la fibra óptica debe ser más corta que la distancia de transmisión máxima de   un módulo óptico.  

  Si la longitud   de la fibra óptica excede la distancia de transmisión máxima de los módulos   ópticos, acorte la distancia entre los dispositivos o utilice módulos ópticos   con una distancia de transmisión más larga.  

  Atenuación de la   señal óptica.
    

  El rango de   atenuación de la señal óptica depende del tipo de módulo óptico.  

  1. Si la   atenuación es demasiado grande, reemplace la fibra.

   2. Si la   atenuación sigue siendo grande, acorte la fibra.
    

  Optical fiber   working status
    

  l   El probador muestra que las señales ópticas se envían y se reciben   correctamente.

   l En una prueba   de bucle invertido, las dos interfaces están activadas.  

  El probador   muestra que las señales ópticas se envían y se cumplen correctamente.

En una prueba de bucle   invertido, las dos interfaces están activadas.
    

 

Consulte los parámetros del módulo óptico según la sección "Módulos conectables para interfaces" en la Descripción de hardware. Los parámetros incluyen la longitud de onda central, la distancia de transmisión, los tipos de fibra admitidos, la potencia óptica de recepción y la potencia óptica de transmisión.

Si la potencia óptica es anormal, se notifica una alarma. También puede ver la información de la alarma para saber si la potencia óptica es normal.

2.11 Contacto con el personal de soporte técnico

 

Si el error persiste, recopile información de red (incluidas las conexiones de puerto), dirección IP de origen problemática, dirección de SourceMAC, dirección IP de destino, dirección MAC de destino, puerto de entrada, puerto de salida y registros (lea el archivo log.log o ejecute el comando display logbuffer) .Proporcionar la información recopilada a los ingenieros de soporte técnico.

 

Casos Tipicos.

3.1  Se eliminan algunos paquetes 2 minutos Después, se habilita el servicio de multidifusión
3.2  El usuario de administración no puede hacer telnet a un conmutador
3.3  Paquetes de ping del Servidor de Monitoreo a Servidores son eliminados
3.4  Los paquetes entrantes son eliminados
3.5  La pixelación aparece en la pantalla cuando un interruptor está conectado a dos receptores
3.6  Los hosts de los usuarios se conectan lentamente y el Pinging theGateway tiene un retraso
3.7  Los paquetes se eliminan cuando un conmutador está conectado a un dispositivo de terceros
3.8  Los paquetes se pierden cuando los usuarios de acceso hacen ping a un interruptor apilado
3.9  Los usuarios conectados a un switch no pueden acceder a la red

3.10  Los paquetes se pierden cuando los usuarios acceden a un servidor
3.11  artefactos ocurren cuando los usuarios ven videos
3.12  La pixelización ocurre cuando los usuarios ven videos
3.13  La pixelización se produce cuando los usuarios ven IPTV en horas pico
3.14  Se producen pausas en la imagen cuando los usuarios ven videos

 

3.1 Algunos paquetes se eliminan 2 minutos después de que se haya habilitado el servicio de multidifusión

 

Productos y versiones aplicables

Switchs serie S de todas las versiones.

Descripción de red

Como se muestra en la figura, un conmutador se encuentra en una etapa posterior a un servidor de multidifusión y en una etapa posterior a los hosts de los usuarios. El interruptor tiene muchas entradas de multidifusión. Probar el rendimiento de reenvío de multidifusión en el interruptor.

 

Cuando la interfaz GE1 / 0/1 que recibe los paquetes de multidifusión y la interfaz GE1 / 0/2 que envía los paquetes de multidifusión están en la misma VLAN, algunos paquetes se eliminan 2 minutos después de que se crean las entradas de multidifusión, y luego los paquetes de los grupos de multidifusión son aleatorios caído.

Si las dos interfaces se agregan a diferentes VLAN, no se pierde ningún paquete.

Análisis de causa

Hay múltiples interlocutores IGMP en diferentes intervalos de consulta en la red. Los intervalos de consulta incoherentes pueden causar un envejecimiento incorrecto de las entradas de reenvío de multidifusión de Capa 2.

Resolución de problemasProcedimiento

 

1. Ejecute el display cpu-defend statistics all  para verificar las estadísticas del paquete enviado a la CPU. Las estadísticas muestran que no se ha eliminado ningún paquete ICMP.

 

2. Ejecute el comando display multicast forwarding-table para verificar las entradas de reenvío de capa 3 y catastro. En la salida del comando, el valor de tiempo de actividad de la entrada es de 39 minutos, lo que indica que la entrada ha caducado anteriormente.

 

3. Ejecute el comando display igmp-snooping port-info verbose  para verificar las entradas de reenvío de capa 2. Las interfaces de salida tienen diferentes valores de tiempo de actividad, algunos de los cuales son muy cortos. El tiempo de caducidad de la mayoría de las interfaces de salida se actualiza cuando el tiempo de actividad se aproxima a 5 minutos.

 

4. Ejecute el comando display igmp interface. El resultado del comando muestra que el interrogador de IGMP se encuentra en el comprobador, pero no en el conmutador. En el probador, el intervalo de consulta se establece en 125 segundos.

El valor predeterminado de la consulta de indagación IGMP del conmutador es de 60 segundos, por lo que el tiempo de caducidad de la entrada de multidifusión de Capa 2 es de 130 segundos. Esto significa que el interruptor tiene solo 5 segundos para actualizar las entradas. El conmutador no puede procesar todos los mensajes recibidos en tan poco tiempo, por lo que algunas entradas están desactualizadas, aunque no deberían estar desactualizadas. Como resultado, los paquetes de algunos grupos se eliminan.

Solución

Deshabilite la función de consulta en el probador.

Conclusión

La pérdida aleatoria de paquetes generalmente se debe a lo siguiente:

l Algunos paquetes de protocolo IGMP se han interrumpido debido a un exceso de CPCAR, por lo que algunas entradas de reenvío de multidifusión tienen una caducidad incorrecta.

l Hay varios consultantes con diferentes intervalos de consulta en el segmento de red compartido, por lo que algunas entradas de reenvío de multidifusión tienen una caducidad incorrecta.

l La tasa de tráfico de ráfagas en una interfaz excede la capacidad del búfer, por lo que los paquetes se eliminan aleatoriamente en la interfaz.

Cuando se produce la pérdida de paquetes de multidifusión, excluir las causas anteriores una por una para determinar la causa raíz. Después de eso, ajuste la implementación de la red para resolver el problema.

 

3.2 El usuario de administración no puede hacer telnet a un switch.

 

Productos aplicables y versiones

Conmutadores serie S de todas las versiones.

Descripción de la red

El terminal del administrador está conectado a un interruptor.

Síntoma de falla

Un conmutador tiene un alto uso de la CPU, los usuarios no pueden iniciar sesión en el conmutador a través de Telnet o el puerto de la consola, y el conmutador imprime una gran cantidad de registros de fallos de inicio de sesión de Telnet.

Análisis de causa

Cuando Telnet y los paquetes FTP atacan a un conmutador, el uso de la CPU es alto y los usuarios no pueden iniciar sesión en el conmutador.

Procedimiento de resolución de problemas

 

1. Borre las estadísticas de los paquetes Telnet enviados a la CPU.

<Quidway> reset cpu-defend statistics packet-type telnet all

2. Espere un minuto y vea las estadísticas sobre los paquetes de Telnet enviados a la CPU nuevamente.

Si se caen muchos paquetes de Telnet, puede ocurrir un ataque de Telnet.

[Quidway] display cpu-defend statistics packet-type telnet slot 2 

  Estadísticas en el slot 2:

---------------------------------------------------------------------- 
Packet Type         Pass(Bytes)  Drop(Bytes)  Pass(Packets)   Drop(Packets) 
---------------------------------------------------------------------- 
Telnet              40800      3576800      600           52600  //Many packets are discarded. 
----------------------------------------------------------------------

 

3. No se recomienda descartar paquetes de Telnet. Se recomienda:

- Verifique si la dirección IP que acepta muchos paquetes Telnet está autorizada.

Por ejemplo, si la dirección IP de la puerta de enlace conectada directamente envía muchos paquetes de Telnet, estos paquetes no se pueden bloquear.

Si la dirección de origen del ataque es una dirección no autorizada, configure la política de tráfico para eliminar los paquetes de un interruptor fijo o configure una lista negra o configure el seguimiento de la fuente de ataque para un interruptor modular.

 

# Configure el seguimiento de la fuente de ataque para identificar la fuente de ataque de Telnet y configurar la función de defensa automática.

cpu-defend policy 1 
 auto-defend enable 
 auto-defend attack-packet sample 5 
 auto-defend threshold 30  //Set the attack identification threshold to30 pps. 
 auto-defend trace-type source-macsource-ip 
 auto-defend protocol telnet 
 auto-defend action deny timer 30  //Set the punishment interval to 30s. 
#
<Quidway> display auto-defend attack-source slot 2detail 
    Attack Source IP Table (MPU):  
  -------------------------------------------------------- 
    IP address                     10.1.0.2  //Exclude the gateway's IP address. 
      TELNET:                    2873  
      Total                        2873  
 ---------------------------------------------------------- 
   Total: 1

 

To ensure security for theTelnet control layer, configure an ACL on the user-interface vty interface andconfigure AAA to control Telnet users' right. Only the specified IP addressesare allowed.
3.3 Los paquetes de ping del servidor de monitoreo a los servidores se eliminan

 

Para garantizar la seguridad de la capa de control de Telnet, configure una ACL en la interfaz vty de la interfaz de usuario y configure AAA para controlar los derechos de los usuarios de Telnet. Sólo se permiten las direcciones IP especificadas.

3.3 Los paquetes de ping del servidor de monitoreo a los servidores se eliminan

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

Descripción de Networking

Switch_1 y switch_2 funcionan como puertas de enlace para conectarse al servidor de monitoreo. Switch_3 es un dispositivo de acceso de Capa 2 que se conecta al servidor A y al servidor B.

 

Síntoma de Fault

Las pruebas de ping se realizan en el servidor de monitoreo para probar la interoperabilidad con el servidor A y el servidor B. Ocurre una severa pérdida de paquetes.

Análisis de causa

1. Cuando el servidor de supervisión accede a los servidores, Switch_1 y switch_2 no tienen entradas ARP de estos servidores. Esto dispara una gran cantidad de paquetes ARP Miss.

2. En switch_1 y switch_2, se establece el límite de ratificación de los mensajes ARP Miss del servidor de monitoreo 10.0.0.1.

 

arp-miss speed-limit source-ip 10.0.0.1 maximum 100  // Establezca el límite de velocidad para los mensajes ARPMiss desde la dirección de origen 10.0.0.1 a 100 pps.

 

3. Cuando un conmutador genera muchos mensajes de Miss ARP desde la misma dirección IP de origen, se eliminan los paquetes excesivos.

Resolución de problemasProcedimiento

1. Analice el ARP y la configuración de seguridad en el dispositivo.

2. Verifique la información ARP del dispositivo y ejecute el comando display arppacket statistics  para verificar si los paquetes ARP se descartan.

3. Ejecute el comando display arp anti-attack configuration all  para verificar la configuración de ARPanti-attack. Compruebe si se ha configurado el límite de tasa de Miss ARP y el límite de tasa ARP.

Solución

1. Deshabilite la limitación de velocidad para los mensajes ARPMiss.

2. Establezca el tiempo de antigüedad de ARPentries en 1200s (valor predeterminado).

Conclusión

Al localizar problemas de pérdida de paquetes de ping, verifique las configuraciones relacionadas con la seguridad. Los comandos de seguridad, que incluyen arp-miss speed-limit source-ip, arp anti-attack rate limit, y icmp rate-limit enable deben configurarse en función de las situaciones reales.

 

3.4 Los paquetes entrantes son eliminados

 

Productos aplicables y versiones

Conmutadores serie S de todas las versiones.

Descripción de la red

Switch_1 está en sentido descendente a un analiservidor de paquetes, y en sentido ascendente a un divisor, que está conectado a switch_2 y switch_3.

 

Síntoma de falla

Los paquetes de switch_2 y switch_3 se arrastran en GE0 / 0/1 de switch_1.

Análisis de causa

Entre el tráfico reenviado por el dispositivo de distribución ascendente:

l La dirección MAC de origen y el VLANID en el tráfico de switch_2 son los mismos que la dirección MAC de destino y el ID de VLAN en el tráfico de SwitchC.

l La dirección MAC de origen y el VLANID en el tráfico de switch_3 son los mismos que la dirección MAC de destino y el ID de VLAN en el tráfico de switch_2.

Los paquetes no se pueden reenviar porque el inboundport aprende las mismas direcciones MAC de origen y destino de los paquetes.

Procedimiento de resolución de problemas

 

1. Compruebe si el tráfico en dos direcciones (las direcciones MAC de origen y destino en dos direcciones son inversas) es reenviado por la misma interfaz basada en los servicios.

2. Obtenga paquetes y verifique si una interfaz ha aprendido las mismas direcciones MAC de origen y destino.

3. Desactive el aprendizaje de direcciones MAC en la interfaz de entrada o en una VLAN.

Conclusión

Los paquetes no se pueden reenviar porque una interfaz de entrada aprendió las mismas direcciones MAC de origen y destino de los paquetes.

 

3.5 La pixelación aparece en la pantalla cuando un conmutador está conectado a TwoReceivers

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

Descripción de Networking

Una fuente de multidifusión está directamente conectada al interruptor. El conmutador tiene configurado el servicio de multidifusión de Capa 3 y se conecta a un segmento de red del receptor a través de una interfaz VLANIF. Los dos receptores son terminales de monitoreo que monitorean la información del programa de multidifusión.

 

Síntoma de Fault

El cliente encuentra pixelación frecuente en los terminales de monitoreo.

Análisis de causa

Solo se configura la multidifusión de Capa 3 en el conmutador, por lo que la interfaz de salida en las entradas de reenvío de multidifusión es la interfaz VLANIF. Sin embargo, solo la multidifusión de Capa 3 en un switch no puede implementar el reenvío preciso. Es decir, el tráfico de multidifusión se reenviará a todas las interfaces físicas en la VLAN que coincidan con la interfaz VLANIF de salida.

Los dos terminales están conectados al conmutador a través de una VLAN, por lo que el segundo terminal puede recibir los programas (que no se desean) monitoreados por el primer terminal. Del mismo modo, el primer terminal puede recibir los programas supervisados por el segundo terminal.

Limitados por su capacidad de procesamiento de paquetes, los terminales no pueden procesar todos los paquetes recibidos de manera oportuna. En consecuencia, se produce la pixelación.

Resolución de problemas Procedimiento

 

Compruebe si igmp-snooping enable está configurado en la vista de la VLAN que coincide con la interfaz VLANIF donde está configurada la multidifusión de Capa 3.

 

Solución

l Reemplace la multidifusión de capa 3 por la multidifusión de capa 2 para implementar el reenvío preciso del tráfico de datos de multidifusión.

l Si el cliente requiere multidifusión de capa 3, configure la multidifusión de capa 2 y capa 3 en el conmutador.

Conclusión

La pixelación es a menudo causada por la pérdida de paquetes o paquetes duplicados.

Las causas comunes para la pérdida de paquetes incluyen:

l Los paquetes se eliminan debido a la señalización en la interfaz de salida.

Compruebe si hay recuentos de descarte.

- Instale el parche más reciente para la versión de software del sistema en uso, y verifique si el problema está resuelto. Obtenga la versión del software, el parche, el modelo del producto y la configuración de los interruptores para determinar si el problema se debe a un problema conocido.

- Ajuste el modo en el que el servidor de catastro envía paquetes para aliviar la congestión del tráfico.

- Si se transmiten múltiples flujos de tráfico en el mismo enlace, aumente el ancho de banda del enlace entre los dispositivos de red.

l La limitación de velocidad se configura en la interfaz de salida, y la velocidad de los paquetes entrantes excede el límite de velocidad en las horas pico.

Las causas comunes de paquetes duplicados incluyen:

l La función de multidifusión de Capa 3 no puede implementar el reenvío preciso del tráfico de multidifusión sin la función de inspección de IGMP.

l Múltiples fuentes de multidifusión enviadas al mismo flujo de datos de multidifusión. Cuando esto ocurre, modifique el despliegue de la red o requiera que los receptores especifiquen una fuente al solicitar programas.

 

3.6 Los hosts de los usuarios se conectan lentamente y el control de la puerta de enlace tiene un retraso

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

Descripción de Networking

Switch_1 y switch_2 son interruptores de acceso, que se encuentran en la parte superior del interruptor central y en la parte inferior de los hosts del usuario.

 

Síntoma de Fault

El host del usuario A está desconectado de thenetwork. Cuando el usuario aloja el comando ping en la puerta de enlace, la puerta de enlace responde después de adelay. Switch_1 está frecuentemente fuera de la administración. Los servicios en switch_2 no son normales y el usuario B host puede hacer ping a la puerta de enlace.

Análisis de causa

Switch_1 recibe paquetes ARP con dirección MAC de fuente fija. El host del usuario A no puede enviar o recibir paquetes ARP.

Resolución de problemas Procedimiento

Realice las siguientes operaciones onswitch_1:

1. Compruebe si el uso de la CPU es alto.

 

<HUAWEI>display cpu-usage 
CPU Usage Stat.
Cycle: 10 (Second) 
CPU Usage         : 82% Max: 99% 
CPU Usage Stat. Time : 2010-12-18 15:35:56 
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.
The CPU usage reaches 82%.

 

2. Ver las entradas temporales de ARP para verificar si el aprendizaje de ARP es normal.

 

<HUAWEI>display cpu-usage 
CPU Usage Stat.
Cycle: 10 (Second) 
CPU Usage         : 82% Max: 99% 
CPU Usage Stat. Time : 2010-12-18 15:35:56 
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.
The CPU usage reaches 82%.
2.
        View temporary ARP entries tocheck whether ARP learning is normal.
<HUAWEI>display arp 
IP ADDRESS  MAC ADDRESS EXPIRE(M) TYPEVPN-INSTANCE   INTERFACE 
VLAN/CEVLAN 
------------------------------------------------------------------------------------------------------
10.137.222.139  00e0-fc01-4422            I -         Eth0/0/0 
10.137.222.1    0025-9e36-e8c1  20       D-0         Eth0/0/0 
10.137.222.100  0025-9e80-b278  6         D-0         Eth0/0/0 
10.137.222.99   00e0-4c77-b0e1  9        D-0         Eth0/0/0 
10.137.222.173  000f-3d80-cba4  18       D-0         Eth0/0/0 
10.137.222.34   0025-9e36-e8c1  1        D-0         Eth0/0/0 
10.137.222.172  0016-ec71-ea8c  7         D-0         Eth0/0/0 
10.137.222.35   0025-9e36-e8c1  18       D-0         Eth0/0/0 
10.137.222.179  0014-2ae2-3128  20       D-0         Eth0/0/0 
10.137.222.38   0025-9e36-e8c1  17       D-0         Eth0/0/0 
10.137.222.175  0014-2261-2b22  1         D-0         Eth0/0/0 
50.1.1.3        Incomplete      1         D-0         GE5/0/0 
500/- 
50.1.1.2        Incomplete      1         D-0         GE5/0/0 
500/- 
6.1.1.2         00e0-fc01-4422            I -         Vlanif6 
10.0.0.139      00e0-fc01-4422            I -         Vlanif10 
192.0.0.4       00e0-fc01-4422            I -         Vlanif192 
20.1.1.1        00e0-fc01-4422            I -         Vlanif200 
192.168.2.2     00e0-fc01-4422            I -         Vlanif100 
------------------------------------------------------------------------------------------------------
Total:16        Dynamic:10      Static:0    Interface:6

 

Los campos MACADDRESS de dos entradas ARP están incompletos, lo que indica entradas temporales. Algunas entradas de ARP no se pueden aprender.

 

3. Compruebe si el switch emite un ataque ARP.

 

# Ver estadísticas sobre paquetes de solicitud ARP enviados a la CPU.

 

<HUAWEI>display cpu-defend arp-request statistics all 
Statistics on mainboard: 
------------------------------------------------------------------------------------------------------------------
Packet Type         Pass(Bytes)       Drop(Bytes)   Pass(Packets)     Drop(Packets) 
-----------------------------------------------------------------------------------------------------------------
arp-request            67908288            0         1061067               0 
------------------------------------------------------------------------------------------------------------------
Statistics on slot 4: 
------------------------------------------------------------------------------------------------------------------
Packet Type         Pass(Bytes)       Drop(Bytes)   Pass(Packets)     Drop(Packets) 
------------------------------------------------------------------------------------------------------------------
arp-request            80928            44380928          2301         693450
------------------------------------------------------------------------------------------------------------------
Statistics on slot 5: 
------------------------------------------------------------------------------------------------------------------
Packet Type         Pass(Bytes)       Drop(Bytes)   Pass(Packets)     Drop(Packets) 
------------------------------------------------------------------------------------------------------------------
arp-request                 N/A          N/A               0               0 
------------------------------------------------------------------------------------------------------------------
Statistics on slot 6: 
------------------------------------------------------------------------------------------------------------------
Packet Type         Pass(Bytes)       Drop(Bytes)   Pass(Packets)     Drop(Packets) 
------------------------------------------------------------------------------------------------------------------
arp-request                 N/A          N/A               0               0 
------------------------------------------------------------------------------------------------------------------

 

Hay una gran cantidad de paquetes de solicitudes ARP en la placa en la ranura 4.

# Configurar el seguimiento de la fuente de ataque para identificar la fuente del ataque.

 

<HUAWEI>system-view 
[HUAWEI]cpu-defend policy policy1 
[HUAWEI-cpu-defend-policy-policy1]auto-defendenable 
[HUAWEI-cpu-defend-policy-policy1]auto-defendattack-packet sample 5  //One packetis sampled when every five packets are sent. A small sampling rate will consumemany CPU resources. 
[HUAWEI-cpu-defend-policy-policy1]auto-defendthreshold 30  //The packets of whichthe rate reaches 30 pps are considered attack packets. If there are many attacksources, reduce this value. 
[HUAWEI-cpu-defend-policy-policy1]undoauto-defend trace-type source-ip source-portvlan  //Identify the attack source based on sourceMAC address. 
[HUAWEI-cpu-defend-policy-policy1]undoauto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp  //Identify the attack source of the ARPattack. 
[HUAWEI-cpu-defend-policy-policy1]quit
[HUAWEI]cpu-defend-policy policy1 
[HUAWEI]cpu-defend-policy policy1 global
# View attack source information.
[HUAWEI]display auto-defend attack-source 
Attack Source User Table (MPU): 
------------------------------------------------------------------------------------------------
MacAddress       InterfaceName      Vlan:Outer/Inner      TOTAL 
------------------------------------------------------------------------------------------------
0000-0000-00db  GigabitEthernet2/0/22        193           416 
------------------------------------------------------------------------------------------------

 

La dirección MAC de la fuente de ataque es 0000-0000-00db, que está conectada a GigabitEthernet2 / 0/22.

Si la dirección MAC tiene un ARPentry coincidente, ejecute la pantalla arp | comando include0000-0000-00db para comprobar su dirección IP.

 

# Choose one method to block the attacksource.
          Configure a blacklist.

acl number 4000 
 rule 10 permit type 0806 ffff source-mac0000-0000-00db ffff-ffff-ffff 

cpu-defend policy 1 
 blacklist 1 acl 4000  //Add the users with specifiedcharacteristics to the blacklist through an ACL. The switch discards thepackets from the users in blacklist. 

cpu-defend-policy 1  
cpu-defend-policy 1 global 
#
          Configure the attack sourcetracing action.

cpu-defend policy policy1  
 auto-defend enable  
 auto-defend threshold 30  
 undo auto-defend trace-type source-ipsource-portvlan  
 undo auto-defend protocol 8021x dhcpicmp igmp tcp telnet ttl-expired udp 
 auto-defend action deny  //Set the attack source tracing action. Theswitch drops all attack packets within the default interval, 300s. 

 cpu-defend-policy policy1 global  
 cpu-defend-policy policy1  

# If you cannot determine the attacksource, use either of the following methods:
          Traffic suppression
Set the maximum rate of broadcast andunknown unicast packets to 100 kbit/s and the maximum percentage of multicastpacket rate to 30%.

interface GigabitEthernet12/0/12 
 unicast-suppression cir 100 cbs 18800 
 multicast-suppression 30 
 broadcast-suppression cir 100 cbs 18800 
#
          Storm control
Perform storm control on broadcastpackets received on GigabitEthernet12/0/12. In the storm detection interval,the switch performs storm control on packets when the rate of receiving packetson an interface is higher than 8000 pps and forwards packets when the rate ofreceiving packets is lower than 5000 pps.

interface GigabitEthernet12/0/12 
 storm-control broadcast min-rate 5000max-rate 8000 
#
View the storm control effect:
<Quidway> display storm-control interfacegigabitethernet 12/0/12 
PortName     Type  Rate     Action    Punish-   Trap Log Interval Last- 
                   (Min/Max)           Status                      Punish-Time  
------------------------------------------------------------------------------ 
GE12/0/12 Broadcast    14881000  shutdown shutdown  off  off 180     2010-12-12  
                   /14881000                                       14:30:00

 

3.7 Los paquetes se eliminan cuando un switch está conectado a un dispositivo de terceros

 

Productos y versiones aplicables

Todos los productos y versiones.

NetworkingDescripción

Un interruptor está conectado a un dispositivo de terceros.

Síntoma de Fault

Si el espacio entre cuadros en el dispositivo de terceros es menor a 12 bytes, los paquetes se eliminan. Si el espacio entre tramas es de 12 bytes, no se descarta ningún paquete.

Análisis de causa

Si el IFG se establece en un valor pequeño en el dispositivo remoto, el dispositivo remoto reenvía los paquetes a una velocidad mayor, lo que provoca la pérdida de paquetes en el conmutador local.

La tasa de reenvío de paquetes, también llamada transferencia, se refiere a la capacidad de reenvío de datos en una interfaz y se mide en paquetes por segundo (pps). La tasa de reenvío de paquetes se calcula en función del número de paquetes de datos de 64 bytes transmitidos en un período. Las longitudes de preámbulo e IFG afectan la tasa de reenvío de paquetes.

Resolución de problemas Procedimiento

Obtenga paquetes para verificar si el IFG es de 12 bytes (96 bits). Cambie el IFG a 12 en el dispositivo remoto.

Conclusión

3.8 Los paquetes se pierden cuando los usuarios de acceso hacen ping a un switch apilado

 

ApplicableProducts and Versions
S series switches of all versions
NetworkingDescription
In the following figure, SwitchA_1 andSwitchA_2 set up a stack, SwitchA-stack, while SwitchB_1 and SwitchB_2 set up astack SwitchB-stack.
SwitchA_1 is connected to SwitchB_1 usingtwo uplinks, and SwitchA_2 is connected to SwitchB_2 using two uplinks. Thefour uplinks are bound to Eth-Trunk 100, and users are connected toSwitchA-stack.

FaultSymptom
When the shutdown or undo shutdowncommand is used on any link of the Eth-Trunk and a PC pings SwitchB-stack,packets are lost.
CauseAnalysis
l  A loop occurs on the network ofthe downstream device connected to SwitchB-stack, and packets sent bySwitchB-stack are looped back from the downstream device.
l  A loop is formed betweenSwitchB-stack and the downstream device.
TroubleshootingProcedure
1.
        Collect traffic statistics onthe Eth-Trunk of SwitchB-stack and Eth-Trunk of the remote device. If there arestatistics on received packets on the local interface and statistics on sentpackets on the remote interface, a loop occurs on the downstream deviceconnected to SwitchB-stack or a loop is formed between SwitchB-stack and thedownstream device.
2.        Check the network topology,find the loop, and adjust the configuration or change the physical link toeliminate the loop.
Conclusion
This problem is caused by the incorrectconfiguration. During network planning, determine the interfaces that need toexchange STP BPDUs with other devices and determine the devices where STP needsto be disabled.

 

3.9 Los usuarios conectados a un switch no pueden acceder a la red

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

NetworkingDescripción

Varios usuarios están conectados a un conmutador que realiza una transmisión transparente de Capa 2.

Síntoma de Fault

Algunos usuarios no pueden acceder a la red, y hay estadísticas sobre los paquetes ARP descartados en el conmutador.

Análisis de causa

El comando arpanti-attack gateway-duplicate enable está configurado en el switch, por lo que todos los paquetes ARP que pa****** envían a la CPU. Cuando se transmite una gran cantidad de paquetes ARP en la red, algunos paquetes ARP se descartan. Como resultado, algunos usuarios no pueden acceder a la red.

Resolución de problemasProcedimiento

1. Ejecute el comando display cpu-defend statistics all para verificar las estadísticas sobre los paquetes ARP enviados a la CPU. La salida del comando muestra que se descartan una gran cantidad de paquetes ARP.

2. Verifique la configuración del dispositivo, encontrando que el comando arp anti-attackgateway-duplicate enable se ha configurado en el switch.

Solución

Elimine la configuración del comando de activación de arp anti-attack gateway-duplicate y luego verifique si hay estadísticas sobre los paquetes ARP descartados que están presentes en la CPU.

 

3.10 Los paquetes se pierden cuando los usuarios acceden a un servidor

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

Descripción de Networking

En la siguiente figura, el conmutador de acceso Switchwitch_2 está conectado a un switch central Switch_1 y el enlace descendente está conectado a los usuarios, y Switch_1 está conectado a un servidor.

 

Síntoma de Fault

Cuando un usuario accede al servidor, se produce una pérdida grave de paquetes y se interrumpen los servicios.

Análisis de causa

El comando loopbackinternal está configurado en GE0 / 0/1 del Switch_2, por lo que GE1 / 0/2 de Switch_1 aprende la dirección MAC del servidor. Como resultado, el tráfico no puede ser reenviado.

Resolución de problemas

Procedimiento

1. Ejecute el comando display trapbuffer en Switch_1 para verificar si se produce un error en la dirección MAC. Si es así, ubique las interfaces en las que se produce la agudización de la dirección MAC.

2. Elimine la configuración del comando interno de bucle invertido en Switch_2.

Conclusión

El solapamiento de la dirección MAC es una de las causas más comunes de pérdida de paquetes durante el reenvío de Capa 2. Si se produce un problema de este tipo, compruebe si se produce un aleteo de la dirección MAC.

 

3.11 artefactos ocurren cuando los usuarios ven videos

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

NetworkingDescripción

En la siguiente figura, el Switch está conectado a un servidor de multidifusión y tiene GE1 / 0/0 y GE1 / 0/2 agregados a Eth-Trunk0 y Eth-Trunk 1 respectivamente. Los usuarios están conectados al Switch. El servicio Themulticast se implementa en el Switch para que los usuarios puedan reproducir videos.

 

Síntoma de Fault

Los artefactos ocurren cuando los usuarios ven videos.

Análisis de causa

Los artefactos a menudo son causados por la pérdida de paquetes, paquetes duplicados o la secuenciación incorrecta de paquetes. En general, los artefactos son causados por la pérdida de paquetes o paquetes duplicados, y la probabilidad de pérdida de paquetes es mayor. Cuando ocurren artefactos, verifique las estadísticas de tráfico en las interfaces ascendentes y descendentes del conmutador para determinar si ha ocurrido una pérdida de paquetes. También puede obtener paquetes para verificar la pérdida de paquetes o paquetes duplicados.

En este ejemplo, los artefactos son causados por la secuenciación errónea de paquetes. La causa de la secuenciación errónea de paquetes es: Los puertos Eth-Trunkmember en la fuente de multidifusión no comparten el tráfico por flujo, por lo que los paquetes del mismo flujo de multidifusión no llegan al Switch a través del mismo puerto miembro de Eth-Trunk. Debido a la secuencia incorrecta, el Switch no puede reenviar los paquetes de multidifusión en una secuencia correcta, causando artefactos en el terminal receptor.

Resolución de problemasProcedimiento

1. Configure las estadísticas de tráfico en el Switch. Las estadísticas muestran que no se descartan paquetes en el Switch.

2. Obtenga paquetes en el dispositivo corriente abajo del Switch, encontrando que se produce una secuencia incorrecta de paquetes. Como resultado, el terminal receptor no puede procesar paquetes normalmente.

3. Compruebe si cada puerto de Eth-Trunkmember recibe paquetes del mismo flujo.

- Configure la duplicación de puertos en todos los puertos de miembros del Eth-Trunk ascendente para obtener paquetes. Si cada miembro recibe paquetes, la secuencia de paquetes no se puede asegurar cuando los paquetes son enviados por el Switch.

- Si no se pueden obtener paquetes, intente cerrar los puertos miembros de este Eth-Trunk para retener un solo puerto Up. Si se resuelve el problema, este problema se produce porque varios puertos de Switch reciben paquetes del mismo flujo de multidifusión.

Solución

1. Cierre los puertos miembros de la Eth-Trunk ascendente y retenga un solo puerto Miembro arriba (si el ancho de banda del puerto es suficiente para el reenvío de tráfico).

2. Arregle el problema de la fuente upstreammulticast para garantizar que todos los paquetes de un flujo se envíen al Conmutador a través del mismo puerto físico.

Conclusión

Huawei cambia los paquetes de reenvío a través de hardware, por lo que rara vez se produce una secuenciación errónea de paquetes. Si ocurre en un conmutador, verifique si el conmutador ha recibido paquetes del mismo flujo de varios puertos.

 

3.12 La pixelización ocurre cuando los usuarios ven videos

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

NetworkingDescripción

En la siguiente figura, Switch_1 está conectado a un servidor de multidifusión y Switch_2, mientras que Switch_2 está conectado a los usuarios. La multidifusión de Capa 2 y la multidifusión de Capa 3 se configuran en GE1 / 0/2 de Switch_1, y la multidifusión de Capa 2 se configura en GE0 / 0/1 de Switch_2.

 

Síntoma de Fault

La pixelación se produce en los terminales de usuario.

Análisis de causa

Las ráfagas de tráfico de video ocurren con frecuencia en el servidor de multidifusión. Cuando los conmutadores reciben tráfico de multidifusión, envían múltiples copias del tráfico. Como resultado, el ancho de banda requerido para reenviar el tráfico excede el límite. Cuando se agota el búfer en los conmutadores, se producirá una pérdida de paquetes debido a la congestión, lo que provocará una pixelación en los terminales de usuario.

Resolución de problemasProcedimiento

1. Verifique las entradas de reenvío de multidifusión en Switch_1 y Switch_2, sin encontrar excepciones.

2. Configure una política de tráfico en Switch_2 para recopilar estadísticas sobre paquetes entrantes en GE0 / 0/1 y paquetes salientes en GE0 / 0/2. Las estadísticas muestran que algunos paquetes entrantes en GE0 / 0/1 están descartados.

3. Configure una política de tráfico en Switch_2 para recopilar estadísticas sobre paquetes entrantes en GE0 / 0/1 y paquetes salientes en GE0 / 0/2. Las estadísticas muestran que algunos paquetes entrantes en GE0 / 0/1 están descartados.

4. Ejecute el comando display interface interface-typeinterface-number en cualquier vista, o ejecute el comando display this interface en la vista de interfaz. Verifique el número de paquetes salientes en la interfaz conectada a los terminales de usuario. El comando muestra que se ha descartado una gran cantidad de paquetes y que los números siguen creciendo.

5. Configure la duplicación de puertos para copiar los paquetes entrantes en la interfaz conectada al servidor de multidifusión a un puerto de observación y use Wireshark para analizar el tráfico. Determine si la pérdida de paquetes se ha producido debido a ráfagas de tráfico.

Use Wireshark para analizar los paquetes entrantes en GE0 / 0/1 del Switch_1, y encuentre que ocurren ráfagas de tráfico con frecuencia.

En general, la tasa de tráfico es de aproximadamente 10 Mbit / s, pero alcanza aproximadamente 1 Gbit / s en un momento específico. Switch_1 necesita copiar el tráfico a diferentes VLAN, por lo que la tasa de tráfico saliente descendente excede instantáneamente el ancho de banda de 1 Gbit / s. Como resultado, la pérdida de paquetes debido a la congestión.

Si solo hay una pequeña cantidad de tráfico de ráfagas, aumente el ancho de banda de enlace entre los dispositivos de red.

- La tasa de tráfico de ráfagas ha alcanzado 1 Gbit / s. Como se muestra en la Figura 3-1, el servidor multiprofesional hiberna durante más de 1 segundo y luego envía un flujo de video a una velocidad de aproximadamente 1 Gbit / s. Varios milisegundos después, vuelve a entrar en hibernación. Aunque la tasa de tráfico saliente promedio es de aproximadamente 10 Mbit / s, la tasa de tráfico se aproxima a 1 Gbit / s si se mide en milisegundos.

Figura 3-1 Ráfaga de tráfico de video en el servidor de multidifusión

 

En este caso, ajuste el modo de transmisión de paquetes de multidifusión en el servidor de multidifusión para garantizar que los paquetes se presenten a tasas más uniformes. Luego verifique si las ráfagas de tráfico se mitigan, como se muestra en la Figura 3-2.

Si el switch ejecuta V200R001 o una versión posterior, ejecute el comando qos burst-modeenhanced en las interfaces relacionadas para aumentar la capacidad del búfer en las interfaces. Luego verifique si los paquetes se transmiten a velocidades uniformes, con un poco de ráfaga de tráfico, como se muestra en la Figura 3-2.

Figura 3-2 Estallidos de tráfico migrados

 

 

Solución

l Utilice tarjetas que ofrezcan una mayor tasa para ampliar la capacidad de los interruptores.

l Configurar un Eth-Trunk para enlazar a múltiples puertos físicos para aumentar la capacidad del puerto.

l Ajuste la fuente de multidifusión para asegurar que envíe paquetes de datos de multidifusión de manera más uniforme, lo que reduce las explosiones de tráfico.

 

3.13 La pixelización ocurre cuando los usuarios ven IPTV durante las horas pico

 

Productos y versiones aplicables

Conmutadores serie S de todas las versiones.

NetworkingDescripción

En la siguiente figura, el Switch está conectado a un servidor de multidifusión, tiene GE1 / 0/0 agregado a Eth-Trunk 0, y está conectado a los usuarios. El servicio de multidifusión se implementa en el Switch para que los usuarios puedan reproducir videos.

 

Síntoma de Fault

La pixelización se produce cuando los usuarios ven IPTV durante las horas pico.

Análisis de causa

La prioridad de la VLAN en los paquetes de multidifusión se cambia 5 a 4 en el puerto de entrada, mientras que la limitación de la velocidad se configura en el puerto de entrada para los paquetes con la prioridad 4 de la VLAN.

Durante las horas pico, la tasa de tráfico real excede la tasa de tráfico configurada. Como resultado, algunos paquetes se descartan y la pixelización se produce en los videos.

Resolución de problemasProcedimiento

1. Verifique el archivo de configuración, encontrando que la asignación de prioridad está configurada en GE1 / 0/0 para asignar la prioridad 5 de paquetes a la prioridad 4.

 


diffserv domain ds  //Create a DiffServdomain. 
 8021p-inbound 4 phb ef green  //Map the 802.1p priority 4 of incoming VLANpackets to the PHB EF and mark these packets green. 
 8021p-inbound5 phb af4 green  //Map the 802.1ppriority 5 of incoming VLAN packets to the PHB AF4 and mark these packetsgreen. 
 8021p-outboundaf4 green map 5  //Map the PHB AF4 ofoutgoing VLAN packets marked green to the 802.1p priority 5. 
 8021p-outbound af4 yellow map 5  //Map the PHB AF4 of outgoing VLAN packetsmarked yellow to the 802.1p priority 5. 
 8021p-outbound af4 red map 5  //Map the PHB AF4 of outgoing VLAN packetsmarked red to the 802.1p priority 5. 
 8021p-outbound ef green map 4  //Map the PHB EF of outgoing VLAN packetsmarked green to the 802.1p priority 4. 

interface GigabitEthernet1/0/0 
 eth-trunk 0 
 trustupstream ds  //Apply the DiffServdomain to the interface. 
#
2.
        Check the configuration file,finding that rate limiting is configured on Eth-Trunk 0 for packets with thepriority 4.

traffic policy sp-wrr  //Create a trafficpolicy sp-wrr
 classifier sp-wrr behavior sp-wrr  //Associate the traffic policy with thetraffic classifier sp-wrr andtraffic behavior sp-wrr
traffic behavior sp-wrr  //Create atraffic behavior sp-wrr
 carcir 102400 pir 102400 cbs 19251200 pbs 32051200 mode color-blind green passyellow pass red discard  //Configuretraffic policing: Set the CIR value to 102400 kbit/s, PIR value to 102400kbit/s, and PBS value to 32051200 bytes, permit green packets to be sent,permit yellow packets to pass through, and discard red packets. 
traffic classifier sp-wrr operator and precedence 20  //Create a traffic classifier sp-wrr
 if-matchvlan-8021p 4  //Match the packetswith the 802.1p priority 4. 

interface Eth-Trunk0 
 port link-type trunk 
 port trunk allow-pass vlan 2 to 35003900 to 4094 
 traffic-policysp-wrr inbound  //Apply the trafficpolicy sp-wrr in the inbounddirection of the Eth-Trunk. 
 
traffic-policy remark_cos outbound 
#

 

3. Modifique la configuración de limitación de velocidad en Eth-Trunk 0.

4. Modifique o elimine la configuración de confianza en sentido ascendente ds en GE1 / 0/0.

Conclusión

Un conmutador coloca paquetes de datos de multidifusión en una interfaz o envía dos copias del mismo flujo de multidifusión a los usuarios, lo que provoca una inflexión o artefactos en los hosts del receptor. Las posibles causas son las siguientes:

l La limitación de velocidad se configura en el conmutador y los paquetes de datos de multidifusión se eliminan debido a que se excede el límite de velocidad.

l La velocidad de paquetes instantánea excede el ancho de banda de la interfaz debido a ráfagas de tráfico. Como resultado, se eliminan los paquetes de datos de multidifusión.

l Las tasas de las interfaces de enlace ascendente y de enlace descendente son diferentes. Por ejemplo, la interfaz de enlace ascendente es un enlace externo que consta de varias interfaces de GE, mientras que la interfaz de enlace descendente es una interfaz de GE, o la interfaz de enlace ascendente es una interfaz de 10GE, mientras que la interfaz de enlace descendente es una interfaz de GE.

l El switch replica paquetes del mismo grupo repetidamente y envía copias duplicadas a los hosts posteriores.

Realice los siguientes pasos para localizar y corregir la falla:

1. Compruebe si la limitación de velocidad está configurada en las interfaces de enlace ascendente y de enlace descendente del conmutador.

2. Las ráfagas de tráfico generalmente duran poco tiempo, mientras que la tasa de tráfico en una interfaz es la tasa promedio de paquetes calculada en un período determinado. Por lo tanto, no se puede determinar si se ha producido una ráfaga de tráfico de acuerdo con el número de paquetes descartados. Puede obtener paquetes en la interfaz y usar el software de Wireshark para analizar la información de paquetes obtenida. También puede pedir a los ingenieros de I + D que verifiquen los registros de chips en el conmutador para determinar si se produjo una ráfaga de tráfico.

3. Compruebe si las tasas de las interfaces de enlace de enlace descendente y enlace coinciden.

4. Compruebe si la capa 3 multicastis está configurada en el switch. Si es así, el conmutador envía copias duplicadas de paquetes a los hosts posteriores.

 

3.14 Se producen pausas en la imagen cuando los usuarios ven videos

Productos y versiones aplicables

S2300 y S3300S2700 y S3700V100R005 / V100R006

NetworkingDescripción

En la siguiente figura, Switch_1 está conectado a varios switches fijos. Tanto Switch_1 como estos interruptores fijos pertenecen a VLAN 204 y tienen habilitado el servicio de multidifusión.

 

Síntoma de Fault

Las pausas de imagen ocurren con frecuencia cuando los usuarios solicitan videos. Una vez que los usuarios se conectan directamente a Switch_1, los usuarios pueden ver los videos normalmente.

Análisis de causa

Las pausas de imagen se producen en los hosts del receptor, lo que indica que los datos de multidifusión no se reenvían normalmente. La pérdida de paquetes puede haber ocurrido o los paquetes de multidifusión excesivos o los paquetes de multidifusión duplicados pueden remitirse a los hosts.

Esta falla ocurrió cuando los paquetes de multidifusión se perdieron debido al gran tráfico de transmisión.

Resolución de problemasProcedimiento

1. De acuerdo con la información devuelta por el cliente, determine que los interruptores fijos están defectuosos. Verifique el tráfico en los puertos de entrada de los conmutadores fijos, encontrando que el volumen de tráfico es alto, hay paquetes de transmisión excesivos y el uso de ancho de banda es más del 30%.

2. También hay estadísticas de paquetes descartados en los conmutadores fijos. Por lo tanto, determine que el gran tráfico de difusión provoca la pérdida de paquetes de multidifusión, lo que afecta la calidad del video.

Solución

Configure el aislamiento del puerto en Switch_1.

Conclusión

Si muchos conmutadores de acceso están conectados a un conmutador de agregación y pertenecen a la misma VLAN, se recomienda configurar el aislamiento de puertos en el conmutador de agregación para evitar que el tráfico de difusión ocupe ancho de banda.

 

medidas de prevención de pérdida de paquetes

 

En las secciones anteriores, puede localizar la causa de la pérdida de paquetes en los conmutadores de la serie S. Para reducir la pérdida de paquetes, se recomienda que tome las medidas en la Tabla 4-1 durante la implementación de la red.

Tabla 4-1 Medidas de prevención de pérdida de paquetes

 

 

   Causas
     

   Medicion
     

  La PC conectada   al dispositivo remoto está infectada por un virus.  

  Escanee virus en   las PC o servidores conectados al switch periódicamente.  

  The hardware is   faulty, for example,  physical link is faulty, card is loose, card   is faulty, and interface status  is abnormal.
    

  l   Check whether the physical  link and   cards are properly installed.
    
l   The cable connected to the  electrical interface must be a   standard cable. A non-standard cable may cause  link problems.
    
l   Electrical interfaces must  work in full duplex mode. Half   duplex mode will cause many problems.
    
l   The optical module used on  the switch must be a   Huawei-certified optical module.
    
The optical modules from  different   vendors use different implementation methods, and may   cause  unexpected problems, such as packet loss. Therefore, only   the  Huawei-certified optical modules can be used on Huawei   switches.
    

  El volumen de   tráfico de ráfagas supera el ancho de banda de la interfaz, lo que provoca   congestión.  

  l Optimizar la   transmisión de paquetes en el servidor para reducir la ráfaga de tráfico.

   l Configure un   Eth-Trunk y agregue interfaces miembro al Eth-Trunk para equilibrar la carga   del tráfico y reducir el tráfico en una sola interfaz.
    

  Configuración   inadecuada  

  /
    

  Bucle de red
    

  Plan the network   configurations,  configure loop prevent protocol, and enable loop   detection to prevent loops.
    
l   Run the loopback-detect untagged mac-address ffff-ffff-ffff command   in  the system view to broadcast BPDUs for loop detection and   prevent them from  being terminated by unexpected devices.
    
l   Run the loopback-detect enable command in the   interface view to enable  loop detection.
    
When the total number of VLANs  on   the interfaces with loopback detection enabled exceeds 1024 VLANs, run   the  loopback-detect action shutdown  command on   these interfaces to set the action for a detected loopback   to  shutdown. (The VLAN counter increases by 1 every time an   interface is added to  a VLAN, even when multiple interfaces are   added to the same VLAN.)
    

  Ataque 

  l   Configure ARP security to  protect the   device against ARP or ARP Miss attacks.
    
l   On the network prone to DHCP  and ARP attacks, such as   campus networks, configure local attack defense  policies for DHCP   and ARP protocol packets.
    

  The rate of packets sent to the CPU  exceeds the limit.
    

  The switch   provides CPCAR values for each  protocol. Generally, the default   CPCAR values can meet requirements. If  service traffic volume is   too high, contact Huawei switch agentsHuawei  technical support   engineers to adjust the CPCAR values.
    

  The product   specifications are limited  and network planning is improper.
    

  When inter-card   traffic volume is too  high, choose S9700S9300 and SRUB/SRUD as   MPUs, to obtain higher inter-card  bandwidth.
    

 

Apendice




5.1  Configuring Traffic Statistics Collection
5.1 Configuring Traffic Statistics Collection

5.1 Configuración de la recopilación de estadísticas de tráfico

5.1 Configuración de la recopilación de estadísticas de tráfico

 

Visión general

En la Figura 5-1, el conmutador de la serie S admite la recopilación de estadísticas globales y basadas en interfaz en las direcciones de entrada y salida. El conmutador utiliza una política de tráfico para recopilar estadísticas de tráfico. Cuando se aplica una política de tráfico a una interfaz, el conmutador recopila estadísticas solo sobre el tráfico entrante o saliente en esta interfaz; cuando una política de tráfico se aplica globalmente, el conmutador recopila estadísticas sobre el tráfico entrante o saliente en todas las interfaces.

La política de tráfico configurada en la vista de interfaz tiene prioridad sobre la política de tráfico configurada en la vista del sistema. Cuando el tráfico coincide con la política de tráfico en una interfaz, thetraffic no puede coincidir con la política de tráfico global. Por lo tanto, las estadísticas de tráfico no se muestran.

Figura 5-1 Recopilación de estadísticas de tráfico

 

 

Compruebe la siguiente información basada en estadísticas de tráfico:

1. Si el tráfico llega a la interfaz de entrada del conmutador y si los paquetes se pierden en el dispositivo de flujo ascendente.

2. Si el tráfico se reenvía a la interfaz de salida del conmutador y si los paquetes se pierden en el interruptor.

3. Si la información de la capa 2 y la capa 3 del tráfico en la interfaz de entrada del conmutador es correcta y si el dispositi****scendente ha encapsulado y reenviado correctamente los paquetes.

4. Si la información de la capa 2 y la capa 3 del tráfico en la interfaz de salida del conmutador es correcta y si el conmutador ha encapsulado y reenviado correctamente los paquetes.

5. Si el tráfico es inestable debido a un cambio de dirección MAC, cambio de ruta o conflicto de direcciones IP.

ConfiguraciónProcedimiento

Configure las reglas de ACL para que coincida con las estadísticas de tráfico.

Configure un clasificador de tráfico para clasificar las reglas de ACL que coinciden con el tráfico.

Configure el comportamiento del tráfico y configure la recopilación de estadísticas de tráfico en el comportamiento.

Configure la política de tráfico, vincule el clasificador y el comportamiento del tráfico a la política de tráfico y aplique la política de tráfico a la dirección de entrada del conmutador para implementar la recopilación de estadísticas de tráfico.

 

<HUAWEI> system-view 
[HUAWEI] acl 3999 
[HUAWEI-acl-adv-3999] rule permit icmp source 1.1.1.1 0 destination 2.2.2.20  //Configure ACL. 
[HUAWEI-acl-adv-3999] quit 
[HUAWEI] traffic classifier test operator or precedence 45  //Create a traffic classifier and referenceACL 3999 to the traffic classifier. 
[HUAWEI-classifier-test] if-match acl 3999 // 
[HUAWEI-classifier-test] quit 
[HUAWEI] traffic behavior test  //Createthe traffic behavior and enable traffic statistics collection. 
[HUAWEI-behavior-test] statistic enable 
[HUAWEI-behavior-test] quit 
[HUAWEI] traffic policy test  //Create atraffic policy and bind the traffic classifier and behavior to the trafficpolicy. 
[HUAWEI-classifier-test] classifier test behavior test 
[HUAWEI-classifier-test] quit 
[HUAWEI] interface GigabitEthernet1/0/1 
[HUAWEI-GigabitEthernet1/0/1] traffic-policy test inbound  //Apply the traffic policy to the inbounddirection of the interface, or run the traffic-policy test global inboundcommand in the system view to apply the traffic policy globally.
# View the overall traffic statistics.
<Quidway> display traffic policy statistics interface GigabitEthernet 1/0/1inbound 
 
Interface: GigabitEthernet1/0/1  
 Traffic policy inbound: test  
 Rule number: 1  
 Current status: OK!  
---------------------------------------------------------------------  
 Board : 1    
Item       Packets                      Bytes   
---------------------------------------------------------------------  
Matched      0                           0   
  +--Passed    0                          0   
  +--Dropped  0                           0   
    +--Filter   0                           0   
    +--CAR   0                           0   
# View traffic statistics based on rules.
<Quidway> display traffic policy statistics interface GigabitEthernet 1/0/1inbound verbose rule-base 
 
Interface: GigabitEthernet1/0/1  
 Traffic policy inbound: test  
 Rule number: 1  
 Current status: OK!  
---------------------------------------------------------------------   
 Classifier: test operator or   
 Behavior: test  
 Board : 1 
 rule 5 permit icmp source 192.168.1.3 0  
 Passed Packet  0,Passed Bytes  0  
 Dropped Packet  0,Dropped Bytes  0

 

Después de completar la recopilación de estadísticas de tráfico, desactive esta función para reducir la carga de la CPU.

Si el S3700 no admite la recopilación de estadísticas de tráfico en la interfaz de salida, realice los siguientes pasos para resolver una falla de pérdida de paquetes.

l Recopile estadísticas de tráfico en la interfaz de entrada del dispositivo remoto y compare las estadísticas de tráfico con las de la interfaz de entrada del S3700 para verificar si los paquetes se pierden en el S3700.

l Configure la redirección de paquetes en la interfaz de entrada para redirigir los paquetes a la interfaz de salida, y verifique si ocurre una pérdida de paquetes. Si se está produciendo una pérdida de paquetes, el S3700 reenvía los paquetes normalmente. Si no se produce la pérdida de paquetes, el S3700 descarta los paquetes.


  • 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