Règles de routage IP sur Acano et Cisco Meeting Server (CMS)

Introduction

Ce document décrit les règles de routage IP sur les serveurs Acano ou Cisco Meeting Server (CMS). Les serveurs Acano ou CMS peuvent avoir plusieurs interfaces configurées, chacune avec sa propre passerelle par défaut.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Composants CMS : 
  • WebBridge (Web)
  • Traversée utilisant des relais autour du serveur NAT (TURN)
  • CallBridge (CB)
• Routage IP de base

Composants utilisés

Les informations contenues dans ce document sont basées sur Cisco Meeting Server version 2.3.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

La seule limitation ici est que les différentes interfaces sur le commutateur 4 ports doivent être dans différents sous-réseaux, sinon vous pouvez finir avec des problèmes de routage sur votre configuration. Par exception, les serveurs X matériels qui ont une interface ADMIN sont autorisés à avoir cette interface ADMIN dans le même sous-réseau que l'une des autres interfaces (A/B/C/D) comme décrit dans le guide d'installation de CMS et montré sur cette note.

Remarque : deux interfaces du serveur Cisco Meeting ne doivent pas être placées dans le même sous-réseau. La seule exception est que l'interface ADMIN d'un serveur physique Acano X-Series peut être sur le même sous-réseau que l'une des autres interfaces (A à D) et est probablement un déploiement commun.

Vous pouvez vous retrouver dans une situation où vous devez connaître la logique de routage quand vous recevriez des requêtes de liaison sur votre composant serveur TURN par exemple pour vérifier à partir de quelle interface la réponse est envoyée.

Quelles règles de routage IP s’appliquent-elles aux serveurs Acano/CMS ?

La logique de routage IP dépend de la nature de la connexion : UDP (User Datagram Protocol) ou TCP (Transmission Control Protocol).
Dans le cas du protocole TCP, qu'il s'agisse d'une nouvelle connexion ou d'une réponse à une connexion entrante, vous pouvez déterminer quelle logique de routage IP est applicable à votre cas à l'aide de l'organigramme de l'image.

Réponse de connexion TCP entrante

Le serveur Acano/CMS répond pour une connexion TCP entrante sur l'interface sur laquelle la requête est reçue (car il existe déjà une connexion TCP).

Connexion TCP sortante ou tout paquet UDP sortant

Pour les deux scénarios, ces règles de routage IP sont suivies conformément à cet organigramme (ainsi que la première étape pour les réponses de connexion TCP entrante).

Remarque : la logique s'applique à la création de nouveaux paquets UDP sortants ou à ceux envoyés en réponse aux paquets reçus.

Comment afficher toutes les tables de routage IP (par interface) ?

À l’aide de la commande ipv4 <interface> sur le processeur de gestion de la carte mère (MMP).

Avec ceci, vous pouvez voir l'adresse IP configurée et la longueur de préfixe ainsi que toutes les routes statiques qui sont configurées pour cette interface comme montré dans cette image.

Par exemple, ici, les routes vers 8.8.8.8/32 et 8.8.4.4/32 sont configurées pour aller explicitement sur cette interface particulière (a) :

Vous pouvez également voir les routes ajoutées dans le fichier live.json pour l'interface respective (A) qui mappe à eth4.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"
                        }
                    }

Remarque : dans le fichier live.json, les interfaces A-D (du MMP) sont mappées à eth4-eth1 de sorte que l'interface A est mappée à eth4 et l'interface D est mappée à eth1. L'autre extrait est un extrait d'un serveur de la série X où vous pouvez voir l'interface ADMIN est dans la section de mmp sous ipv4 au lieu de module comme montré pour les autres interfaces.

    "ipv4": {
        "mmp": {
            "interfaces": {
                "eth0": {
                    "macaddress": "44:4A:65:00:13:00",
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "address": "10.48.79.72",
                    "prefixlen": "24",
                    "gateway": "10.48.79.200"
                }

Afin d'ajouter ou de supprimer des routes statiques vers une interface spécifique, vous pouvez utiliser la commande ipv4 <interface> route (add | del) <adresse>/<longueur du préfixe>.

Comment vérifier et modifier l'interface par défaut ?

Par défaut, l'interface A est celle par défaut si vous commencez avec une configuration vide.

Vous pouvez vérifier ceci sur l'interface par le paramètre par défaut comme mis en surbrillance sur cette image :

Voici le résultat de la commande ipv4 <interface> sur MMP.

Remarque : si cette valeur est définie sur true, il s'agit de l'interface par défaut comme dans l'image.

Vous pouvez également voir à partir de live.json si l'interface A (qui correspond à eth4), est configurée comme interface par défaut.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"

Afin de modifier l'interface par défaut, vous pouvez utiliser la commande ipv4 <interface> default, mais assurez-vous que vous avez la ou les routes statiques appropriées en place pour accueillir cette modification sinon le routage est affecté.

Exemple :

L'image représente un exemple de configuration d'un serveur partagé unique avec un serveur Core et un serveur Edge avec ces exigences :

• Le serveur principal peut uniquement se connecter à l'interface DMZ (A) et non aux interfaces publiques (C et D).
• Le composant serveur TURN doit écouter sur 443 tout comme le WebBridge (et donc différentes interfaces sont nécessaires pour éviter un conflit de port).

Dans cet exemple, aucun routage spécial n'a été configuré et aucune autre interface par défaut n'a été spécifiée. Elle utilise donc par défaut l'interface A sur le serveur Edge.

Situation :

• Les clients WebRTC peuvent se connecter mais les appels échouent
• Les requêtes de liaison et d'allocation de CB au serveur TURN obtiennent des réponses Success
• Les requêtes de liaison et d'allocation des clients WebRTC externes au serveur TURN arrivent mais n'obtiennent pas de réponses Success

Explication:

• Étant donné que le WB et l'équilibreur de charge ne répondent qu'aux connexions TCP entrantes et ne lancent pas de connexions sortantes elles-mêmes, ce routage ne pose pas de problème.

Remarque : les deux services étant sur le même serveur, WB peut toujours établir une connexion sortante avec l'LB, mais cela se produit en interne.

• En outre, les requêtes Binding et Allocate de la CB à l'IP DMZ du serveur TURN reçoivent une réponse soit parce qu'elles sont dans le même sous-réseau (interface Edge A et interface Core A), soit parce qu'il n'y a pas de route statique configurée et qu'elle l'envoie juste sur l'interface par défaut (interface A dans ce cas).
• Pour les requêtes de liaison et d'allocation externes, il n'a pas de routes statiques et utilise donc l'interface par défaut A pour acheminer le trafic (ce qui a pour résultat de ne pas atteindre le client externe).

Solution :

• Ajoutez l'interface B sur les serveurs Edge et utilisez l'interface A pour la connexion WB interne (ainsi que l'interface LB) et l'interface B pour la connexion du serveur TURN interne (pour éviter l'interférence de port sur 443 est utilisé pour TURN et WB). Configurez ceci avec les commandes suivantes sur le MMP (et corrigez la configuration TURN sur vos ponts d'appels en conséquence pour le nouveau serveurAdresse de l'interface B).

ipv4 b add <adresse IP>/<longueur du préfixe> <passerelle par défaut>
ipv4 b enable

désactivation de spire
tourner écouter d b
activer en virage

• Ajoutez des routes statiques pour acheminer le trafic des serveurs Edge vers le serveur Core interne à l'aide de la commande suivante :
    
    ipv4 b route add <adresse>/<longueur du préfixe>

Remarque : comme les interfaces LB et WB ne réagissent que sur les connexions TCP entrantes, il vous suffit de configurer le routage pour les paquets UDP pour TURN et donc vous effectuez cette opération sur l'interface B. Assurez-vous également que la passerelle sur l'interface B peut l'acheminer vers la carte CB, bien sûr.

Par exemple, si le serveur principal a l'adresse IP 192.168.0.100/24, la commande doit être ipv4 b route add 192.168.0.100/24 ou ipv4 b route add 192.168.0.100/32.

• Définissez votre interface de serveur TURN externe (D) comme interface par défaut pour le trafic.

ipv4 d default

Vérifier 

Aucune procédure de vérification n'est disponible pour cette configuration.

Dépannage 

Aucune information de dépannage spécifique n’est actuellement disponible pour cette configuration.

Informations connexes 

• Assistance et documentation techniques - Cisco Systems
• Outil Collaboration Solutions Analyzer 
• documentation CMS