Preguntas y respuestas: cómo resolver el retraso en el tiempo de respuesta del failover para el tráfico multicast

95 0 0 0

Descripción del problema

 

Streaming Media Server----------->XG0/0/5(S6720)XG0/0/23 &XG0/0/24---------->XG0/0/1&XG0/0/2(S5720)--------EDGE QUAM(Receptor de alimentación multicast)

 

Hay uno de los ISP1 y ISP2 que proporcionan servicios de datos (Internet) y CATV. Recientemente hemos adquirido switches Huawei para que podamos transportar y entregar servicios de datos y multicast en varias partes. Mientras hacíamos la implementación observamos que si el enlace primario se cae, se tarda de 30 a 40 segundos para que se recupere el flujo Multicast, debido a que este flujo de videos se detiene durante 40 segundos y para datos (Unicast) sorprendentemente no se observa ningún retardo con una sola pérdida de paquetes. En segundo lugar, si el enlace primario se restaura, también tarda el mismo tiempo. <?xml:namespace prefix = "o" />

 

Información de alarma Ninguna

                                                Proceso de manejo1. La ruta principal y la ruta secundaria son independientes, no utilizan la unión de la interfaz eth-trunk;

2. El snooping de Vlan igmp está habilitado en los switches, y el tráfico multicast fluye a través de la ruta activa. Cuando la ruta primaria está caída, el puerto de ruta secundario se convertirá en un puerto miembro y el usuario se vuelve a unir al grupo multicast.

3. La topología de la red de capa 2 cambia en la red, la ruta de reenvío de los paquetes de multicast cambia y la consulta de multicast se regenera. La consulta ascendente envía mensajes de consulta dentro de un intervalo determinado (el intervalo predeterminado es de 60 segundos). Una vez completada la convergencia de red de capa 2, el dispositivo de salida no recibe el paquete de consulta inmediatamente. Por lo tanto, la ruta de reenvío de multicast no puede cambiarse rápidamente. El tiempo de conmutación multicast probado por el cliente puede ser de 30 a 40 segundos.

4. Este escenario se puede resolver configurando la función de reenvío rápido de la ruta de reenvío de multicast cuando cambia la topología STP. Cuando la topología STP cambia, esta función puede añadir rápidamente la interfaz en el estado de reenvío del dispositi****l puerto del enrutador, guiando así el flujo de datos multicast para cambiar rápidamente a la nueva ruta de reenvío.

Causa raíz. La configuración o el diseño de la red de multicast no es adecuada

                                                Solución

1. La primera manera:

Configuración del siguiente comando en S6720:

System-view

igmp-snooping fast-switch enable

2. La segunda manera:

Actualmente, se recomienda implementar la conmutación rápida del tráfico de multicast mediante la vinculación de eth-trunk.

Sugerencias La protección de SuggestionsLink se puede implementar mejor configurando el enlace eth-trunk


  • x
  • convención:

Comentar

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

Aviso 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!

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

Inicia sesión