Multicast-en français!
Un spécial en français pour mes collègues chéris
Troubleshooting de multicast 101
Nous avons eu récemment certains soucis avec le multicast. Comme c’est une bibitte un peu bizare qui donne des boutons à la majorité des tech, admins, analystes et architectes réseau, je laisse le tout ici pour aider un troubleshoot ultérieur.
Le multicast est basé sur deux choses: des adresses ip de classe D (L3) dans un range réservé et des Mac address sous le format 0100.5fXX.XXXX pour IGMP.
À la base, quand un poste émet un flux multicast, il y a création du groupe et la source doit s’enregistrer.
Le groupe, dans le cas qui nous concerne, est crée en premier en IGMP. C’est pour cette raison que l’on peut voir des entrées IGMP sur les ports de 4506 en faisant la commande
“show mac address-table”.
Il existe un mapping de groupe pour traduire la mac-address IGMP vers l’adresse ip du groupe. Comme le mapping est un peu tannant à faire, voici un outil pour le calculer:
http://www.dqnetworks.ie/toolsinfo.d/multicastaddressing.html
Donc…
Le poste manifeste le désir d’émettre un flux multicast ou de s’abonner à un flux multicast.
Il va émettre et ça se rends à son routeur (ou sa SVI) multicast local.
Tout ce qu’il fait, c’est de dire qu’il veut avoir le flux.
En IGMP v2, il peut aussi envoyer un message qu’il quitte le groupe multicast. Sinon c’est via le routeur qu’il y a une vérification à savoir qui veut être abonné et quels groupes sont utilisés à quel endroit.
IGMP snooping lui c’est un mécanisme qui permet aux switch niveau 2 de garder une “conscience” de ce qui se passe au niveau 3. Il permet donc aux switch MLS de se garder une table des mappings l2-l3, des groupes et des membres.
Si tnotre paquet multicast doit poursuit sa route vers le RP et son groupe, il y a un check RPF pour vérifier l’origine et la destination du traffic.
Pendant le check RPF, le routeur va regarder la mac source dans la GRT (unicast). Si le paquet a été reçu sur l’interface qui est sur le chemin de retour vers la source, le check RPF passe. Si le check RPF ne passe pas, c’est que le paquet est arrivé sur la mauvaise interface.
Après, c’est PIM qui embarque. Le rôle de PIM, c’est de construire un arbre pour remonter à un point de rendez-vous (RP). Il y a deux modes à PIM: sparse et dense. En ce qui nous concerne, c’est sparse qui est en utilisation. Ce dernier permet de créer une arborescence basée sur le besoin des receveurs multicasts actifs.
C’est important de se souvenir que PIM est dépendant du routage. Donc ce qu’il y a dans la GRT comme routes unicast vont être utilisées pour construire l’arbre PIM.
C’est pour cette raison par exemple qu’une mauvaise route pourrait faire en sorte que certaines nodes ne peuvent s’abonner à un groupe par elles-mêmes
Comme l’arbre peut avoir plusieur niveau, le multicast utilise un TTL ou nombre de saut qu’il peut franchir afin de ne pas garder des “arbres” multicast trop grands. C’est souvent une source de problème parce que lorsque le TTL est expiré, la node ne pourra pas s’enregistrer. Pour le routeur moyen, chaque “routeur” représente un ttl de -1.
Donc le paquet multicast a remonté jusqu’au point de Rendez-Vous. C’est à cet endroit que convergent tous les groupes de multicast.
Sur le RP, vous retrouverez tous les groupes de multicast qui sont enregistré, ainsi que les sources multicast qui sont enregistrées.
Les enregistrements sont (*. Groupes) et (Source, Groupe).
Les outils de troubleshooting du multicast
ping: pour générer du traffic multicast si on a l’ip d’un groupe. Notez qu’on voit le ip des nodes qui répondent!
mtrace: cette commande permet de voir le chemin de la source vers le recipiendaire du trafic multicast. Il fait la démonstration du TTL qui se décrémente de saut en saut.
mrinfo: montre les information des neighbors, leur capacité, les informations sur leur interfaces, le TTL, les metrics, le protocole ainsi que le statut. Très utile pour valider les adjacences
mstat: une de mes favorites….Ça montre en format graphique le chemin entre deux points avec les drops, les duplicats, le TTL…super pour identifier les endroits où il pourrait y avoir de la congestion.
show mac address-table: la bonne vieille commande…pour voir si on a des adresses 0100.5e
show ip igmp groups: pour vérifier qu’une source ou destination a joint le groupe sur une interface L3.
show ip pim neighbor: pour vois les voisins PIM
show ip pim interface: pour voir le statut d’une interface et sa configuration PIM
show ip mroute: pour voir les routes multicast. On peut utiliser le pipe pour aller chercher juste ce qu’on veut.
show ip rpf: pour valider le reverse path et voir si on est capable de remonter l’arbre correctement.
Multicast dans ACI
Le traffic multicast dans ACI est encapsulé dans les VXLAN au travers le Fabric.
Le traffic multicast des tennants est aussi encapsulé dans un paquet multicast VXLAN.
Dans les paquets (analyse de protocole) on parle de deux champs pour les entêtes:
GIPi: Group IP Inner address. C’est une adresse multicast dans le paquet interne VXLAN. Le traffic des tenants multicast dans le VRF tenant.
GIPo: Group IP Outer address. C’est une adresse multicast dans le paquet externe VXLAN. C’est l’adresse multicast utilisée pour la distribution dans tout le fabric.
Les APIC assignent un GIPo à tous les bridge domains et toutes les vrf pour lesquelles le multicast est configuré.
Le control plane utilise la plage 225.0.0.0/15 pour l’underlay lors de la mise en production.
PIM n’est pas utilisé dans l’underlay.
Les GIPo groups utilisent l’IS-IS GM-LSP pour annoncer les groupes.
À ne pas oublier:
Si PIM est activé, le multicast L2 a une approche routée en premier. Tout le multicast est donc routé.
Le TTL est décrémenté 2 fois: à l’ingress d’une interface et à l’egress.
La mac source sera réécrite comme étant la mac du bridge domain.
Pour plus d’information consultez les liens suivants:
https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13726-57.html#mrinfo
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKACI-2608.pdf