Distribution de vidéo et de contenu : Logiciel Cisco Digital Content Manager (DCM)

Dépannez les questions d'inondation d'UDP sur le DCM

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment dépanner le Protocole UDP (User Datagram Protocol) inondant sur le gestionnaire de contenu numérique de Cisco (DCM).

Contribué par Sourav Jyoti DAS, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur Cisco DCM D9902. 

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème

On a observé des scénarios où le D9902 est connecté à un commutateur de la couche 2 (L2) et configuré pour recevoir des flux vidéos d'unicast. Cependant, après que le vidéo d'unicast soit coulé pendant approximativement cinq minutes, le même RÉSEAU LOCAL observe l'inondation sur le commutateur, qui entraîne une panne dans le réseau client. Dans ce scénario, on l'a déterminé que le port de commutateur connecté au DCM a vieilli la table d'adresse de Contrôle d'accès au support (MAC), qui a entraîné l'inondation parce que l'adresse MAC de destination était inconnue au commutateur.

L'inondation d'UDP est un problème courant dans les scénarios unidirectionnels. Le temporisateur de cache de Protocole ARP (Address Resolution Protocol) (avec un par défaut de quatre heures) dans le routeur/couche 3 des Commutateurs (L3) est toujours supérieur au délai d'attente d'âge d'adresse MAC (avec un par défaut de cinq minutes). Ceci signifie qu'il y a toujours une occasion que les informations d'adresse MAC peuvent être enlevées du commutateur s'il n'y a aucune réponse du périphérique de destination.

Remarque: Une augmentation en valeur du dépassement de durée d'âge de table de MAC n'est pas recommandée, car elle peut créer un chargement significatif sur le commutateur et le faire manquer de ressources.

Solution

Voici trois différentes méthodes que vous pouvez appliquer afin de résoudre ce problème :

  • La solution la plus fiable et la plus simple pour cette question est de créer une Multidiffusion factice s'associent au DCM. Dans ce cas, le DCM envoie un rapport d'adhésion de Protocole IGMP (Internet Group Management Protocol) au commutateur, et le commutateur commence à voter le DCM périodiquement. Afin de voter le DCM, le commutateur envoie une requête d'adhésion IGMP, qui régénère la table d'adresse MAC dans le commutateur.

  • Une autre solution pour cette question est de diminuer la valeur du temporisateur de cache d'ARP sur le commutateur de sorte qu'elle soit moins qu'ou près du temporisateur d'obsolescence de table de MAC. Ceci fait devenir les paquets d'ARP émission, et l'adresse MAC doit être réapprise avant les âges d'entrée L2.

  • Comme troisième option, vous pouvez configurer une entrée statique d'adresse MAC sur le commutateur, qui demeure même après une réinitialisation et élimine la question de délai d'attente.

Attention : Faites attention si vous décidez d'implémenter la troisième option, car il peut être dangereux quand vous changez le câblage.

Conseil : Des questions référez-vous du Catalyst à 6500/6000 de Commutateurs d'ARP ou de CAM Tableau dépannant le document Cisco pour plus d'informations sur l'inondation d'UDP.



Document ID: 118966