Règles de Routage IP sur Acano et Cisco rencontrant le serveur (CMS)
Contenu
Introduction
Ce document décrit les règles de Routage IP sur Acano ou Cisco rencontrant des serveurs du serveur (CMS). Acano ou serveurs CMS peut avoir des plusieurs interfaces configurées, chacun avec leur propre passerelle par défaut.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Composants CMS :
- WebBridge (WB)
- Traversée utilisant des relais autour de serveur NAT (de TOUR)
- CallBridge (CB)
- Routage IP de base
Composants utilisés
Les informations dans ce document sont basées sur le serveur de téléconférence de Cisco sur la version 2.3.x.
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 en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
L'information générale
La seule limite ici est que les différentes interfaces sur la nécessité du commutateur 4-port d'être dans les différents sous-réseaux en tant qu'autrement vous peuvent finir par avec des questions de routage sur votre installation. Comme exception au ce, on permet aux des serveurs du matériel X qui ont une interface d'ADMIN pour avoir cette interface d'ADMIN dans le même sous-réseau qu'une des autres interfaces (A/B/C/D) comme décrit sur le CMS installez le guide et affichez sur cette note.
Vous pouvez s'exécuter dans une situation où vous devez connaître la logique de routage quand vous recevriez des demandes d'obligatoire sur votre composant de serveur de TOUR par exemple de vérifier de quelle interface la réponse est envoyé.
Quel Routage IP ordonne s'appliquent sur des serveurs Acano/CMS ?
La logique de Routage IP dépend de si la connexion est Protocole UDP (User Datagram Protocol) ou Protocole TCP (Transmission Control Protocol) en nature.
Dans le cas du TCP, si c'est une nouvelle connexion ou une réponse à d'arrivée, vous pouvez découvrir qui la logique de Routage IP s'applique dans votre cas avec l'utilisation de l'organigramme dans l'image.
Réponse d'arrivée de connexion TCP
Le serveur Acano/CMS répond pour une connexion TCP d'arrivée sur l'interface elle-même sur laquelle la demande est reçue (car il y a déjà une connexion TCP).
Connexion TCP sortante ou tous paquets UDP sortants
Pour les deux scénarios, ces règles de Routage IP sont suivies selon cet organigramme (aussi bien que la première étape pour des réponses d'arrivée de connexion TCP).
Comment afficher tous les Tableaux de Routage IP (par interface) ?
En employant le <interface> d'ipv4 de commande sur le processeur de Gestion de carte mère (MMP).
Avec ceci vous pouvez voir l'adresse IP et la longueur de préfixe configurée aussi bien que toutes les artères de charge statique qui sont installées pour cette interface suivant les indications de cette image.
Par exemple ici, des artères à 8.8.8.8/32 et à 8.8.4.4/32 sont installées pour sortir explicitement sur cette interface spécifique (a) :
Vous pouvez également voir les artères ajoutées sur le live.json pour classer pour l'interface respective (a) qui trace à 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"
}
}
"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 supprimer les artères statiques à une interface spécifique, vous pouvez utiliser l'artère de <interface> d'ipv4 de commande (ajoutez | length> du del) <address>/<prefix.
Comment vérifier et changer l'interface par défaut ?
Par l'interface par défaut A est le par défaut si vous commencez par une configuration vide.
Vous pouvez vérifier ceci sur l'interface par le paramètre par défaut comme mis en valeur sur cette image :
C'est la sortie du <interface> d'ipv4 de commande sur MMP.
Vous pouvez également voir du live.json si l'interface A (qui trace à eth4), est installé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 changer l'interface par défaut, vous pouvez utiliser le par défaut de <interface> d'ipv4 de commande, mais vous assurez que vous avez les artères statiques droites pour faciliter cette modification autrement que le routage est affecté.
Exemple :
L'image représente un exemple d'une configuration du serveur fendue simple avec un noyau et d'un serveur de périphérie avec ces conditions requises :
- Le serveur principal peut seulement se connecter à l'interface DMZ (a) et pas au public (C et D).
- Le serveur de TOUR composant doit écouter sur 443 juste comme le WebBridge (et différentes interfaces sont exigées ainsi pour éviter un désaccord de port).
Dans cet exemple aucun routage spécial n'a été installé et aucune interface par défaut différente ne lui a été spécifiée ainsi se transfère pour relier A sur le serveur de périphérie.
Situation :
- Les clients de WebRTC peuvent ouvrir une session mais échouer d'appels
- En liant et allouez les demandes des CB au serveur de TOUR obtiennent des réponses d'un succès
- En liant et allouez les demandes des clients externes de WebRTC au serveur de TOUR arrivent mais n'obtiennent pas des réponses de succès
Explication :
- Pendant que le WB et le Loadbalancer (livre) répondent seulement aux connexions TCP d'arrivée et n'initient pas les sortants elles-mêmes, ce routage ne pose pas une question.
- Également l'attache et allouent des demandes des CB au serveur de TOUR que L'IP DMZ obtiennent répondu pendant que l'un ou l'autre elles est dans le même sous-réseau (l'interface A de périphérie et la principale interface A) ou parce qu'il n'y a aucune artère statique installée et lui l'envoie juste sur l'interface par défaut (reliez A dans ce cas).
- Pour l'attache externe et allouez les demandes, elle n'a aucune artère statique et emploie ainsi l'interface par défaut A pour conduire le trafic (qui a en n'atteignant pas le client externe).
Solution :
- Ajoutez l'interface B sur les serveurs de périphérie et utilisez l'interface A pour la connexion interne WB (aussi bien que livre) et l'interface B pour la connexion au serveur interne de TOUR (pour éviter le désaccord de port sur 443 est utilisé pour le TOUR et le WB). Configurez ceci avec les prochaines commandes sur le MMP (et corrigez la configuration de TOUR sur vos callbridges en conséquence pour les nouveaux serverAddress de l'interface B).
l'ipv4 b ajoutent le <default-gateway> de length> <IP-address>/<prefix
enable de l'ipv4 b
tournez le débronchement
le tour écoutent d b
tournez l'enable
- Ajoutez les artères statiques pour conduire le trafic des serveurs de périphérie au serveur principal interne avec la commande :
l'artère de l'ipv4 b ajoutent le length> <address>/<prefix
Par exemple si le serveur principal a l'adresse IP 192.168.0.100/24, la commande doit ou être artère de l'ipv4 b additionnent 192.168.0.100/24 ou l'artère de l'ipv4 b additionnent 192.168.0.100/32.
- Faites votre Interface serveur externe de TOUR (d) comme l'interface par défaut pour le trafic.
par défaut de l'ipv4 d
Vérifiez
Aucune procédure de vérification n'est disponible pour cette configuration.
Dépanner
Il n'y a actuellement aucun specifictroubleshootinginformation disponible pour cette configuration.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)