Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

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

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

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

Vérification

Dépannage

Informations connexes

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

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Composants CMS :

- WebBridge (WB)

- Traversée à l'aide de relais autour du serveur NAT (TURN)

- CallBridge (CB)

- Routage IP de base

Components Used

Les informations de 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 limite ici est que les différentes interfaces sur le commutateur à 4 ports doivent se trouver dans différents sous-réseaux, sinon vous pouvez rencontrer des problèmes de routage sur votre configuration. À titre d'exception, les serveurs X matériels disposant d'une interface ADMIN peuvent 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 illustré dans cette note.

Note: Les deux interfaces de Cisco Meeting Server 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 série X 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 rencontrer une situation dans laquelle vous devez connaître la logique de routage lorsque vous recevrez des requêtes de liaison sur votre composant de 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 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 s’applique à 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 demande est reçue (car il existe déjà une connexion TCP).

Connexion TCP sortante ou paquets UDP sortants

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

Note: 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 carte mère (MMP).

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

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

Vous pouvez également voir les routes ajoutées au fichier live.json pour l'interface respective (A) qui correspond à 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"

}

}

Note: Dans le fichier live.json, les interfaces A-D (de MMP) mappent à eth4-eth1, donc l'interface A mappe à eth4 et l'interface D mappe à eth1. L'autre fragment est un fragment d'un serveur de série X où vous pouvez voir que l'interface ADMIN se trouve dans la section de mmp sous ipv4 au lieu du module comme indiqué 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 à une interface spécifique, vous pouvez utiliser la commande ipv4 <interface> route (ajouter | del) <adresse>/<longueur du préfixe>.

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

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

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

Il s’agit de la sortie de la commande ipv4 <interface> sur MMP.

Note: 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 dans le 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 bonnes routes statiques en place pour prendre en charge cette modification sinon le routage est affecté.

Exemple :

L'image représente un exemple de configuration d'un serveur partagé unique avec un serveur principal et un serveur Edge avec les conditions suivantes :

- Le serveur principal ne peut se connecter qu'à l'interface DMZ (A) et non aux interfaces publiques (C & D).

- Le composant serveur TURN doit écouter sur 443 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 interface par défaut différente n'a été spécifiée. Par défaut, elle est définie sur l'interface A sur le serveur Edge.

Situation :

- Les clients WebRTC peuvent se connecter mais les appels échouent

- Liaison et allocation des demandes de CB au serveur TURN obtiennent des réponses Success

- Liaison et affectation des demandes des clients WebRTC externes au serveur TURN arrivent mais n'obtiennent pas de réponses Succès

Explication :

- Comme le WB et le répartiteur de charge (LB) répondent uniquement aux connexions TCP entrantes et ne lancent pas les connexions sortantes elles-mêmes, ce routage ne pose pas de problème.

Note: Étant donné que les deux services se trouvent sur le même serveur, le WB peut toujours établir une connexion sortante à l'équilibrage de charge, mais cela se produit en interne.

- De même, les requêtes de liaison et d'allocation de la CB au serveur TURN DMZ IP reçoivent une réponse car elles se trouvent dans le même sous-réseau (interface de périphérie A et interface principale A) ou parce qu'il n'y a pas de route statique configurée et qu'elle l'envoie simplement 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 empêche d'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'équilibrage de charge) et l'interface B pour la connexion interne du serveur TURN (afin d'éviter le choc des ports 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'appel 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ésactiver

activer écoute d b

activer

- Ajoutez des routes statiques pour acheminer le trafic des serveurs Edge vers le serveur principal interne à l’aide de la commande suivante :

ipv4 b route add <adresse>/<longueur du préfixe>

Note: Étant donné que la LB et le WB réagissent uniquement sur les connexions TCP entrantes, vous devez configurer le routage des paquets UDP pour TURN et donc le faire sur l'interface B. Assurez-vous également que la passerelle de l’interface B peut l’acheminer vers la CB, bien entendu.

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 par défaut

Vérification

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

- Support et documentation techniques - Cisco Systems

- Outil d'analyse des solutions de collaboration

- Documentation CMS