IP-Routing-Regeln für Acano und Cisco Meeting Server (CMS)
Inhalt
Einführung
Dieses Dokument beschreibt die IP-Routing-Regeln für Acano- oder Cisco Meeting Server (CMS)-Server. Für Acano- oder CMS-Server können mehrere Schnittstellen konfiguriert werden, von denen jede über ein eigenes Standard-Gateway verfügt.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
- CMS-Komponenten:
- WebBridge (WB)
- Traversal mittels Relays zum NAT (TURN)-Server
- CallBridge (CB)
- Grundlegendes IP-Routing
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf Cisco Meeting Server (Version 2.3.x).
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Hintergrundinformationen
Die einzige Einschränkung besteht darin, dass die verschiedenen Schnittstellen auf dem Switch mit 4 Ports in unterschiedlichen Subnetzen angeordnet sein müssen, da ansonsten Routingprobleme in Ihrer Konfiguration auftreten können. Ausgenommen hiervon ist, dass Hardware-X-Server, die über eine ADMIN-Schnittstelle verfügen, diese ADMIN-Schnittstelle im gleichen Subnetz wie eine der anderen Schnittstellen (A/B/C/D) haben dürfen, wie im CMS-Installationsleitfaden beschrieben und in diesem Hinweis dargestellt.
Sie können in eine Situation laufen, in der Sie die Routing-Logik kennen müssen, wenn Sie beispielsweise Binding Requests für Ihre TURN-Serverkomponente erhalten, um zu überprüfen, von welcher Schnittstelle die Antwort gesendet wird.
Welche IP-Routing-Regeln gelten für Acano/CMS-Server?
Die IP-Routing-Logik hängt davon ab, ob es sich bei der Verbindung um ein User Datagram Protocol (UDP) oder ein Transmission Control Protocol (TCP) handelt.
Im Fall von TCP, ob es sich um eine neue Verbindung oder eine Antwort auf eine eingehende Verbindung handelt, können Sie herausfinden, welche IP-Routing-Logik bei Verwendung des Flussdiagramms im Bild für Ihren Fall geeignet ist.
Antwort auf eingehende TCP-Verbindungen
Der Acano/CMS-Server antwortet auf eine eingehende TCP-Verbindung an der Schnittstelle selbst, an der die Anfrage empfangen wird (da bereits eine TCP-Verbindung besteht).
Ausgehende TCP-Verbindung oder ausgehende UDP-Pakete
Für beide Szenarien werden diese IP-Routing-Regeln gemäß diesem Flussdiagramm befolgt (sowie der erste Schritt für eingehende TCP-Verbindungsantworten).
Wie werden alle IP-Routing-Tabellen (pro Schnittstelle) angezeigt?
Mit dem Befehl ipv4 <interface> auf dem Mainboard Management Processor (MMP).
Auf diese Weise sehen Sie die konfigurierte IP-Adresse und Präfixlänge sowie alle statischen Routen, die für diese Schnittstelle eingerichtet sind, wie in diesem Bild gezeigt.
Hier sind beispielsweise Routen zu 8.8.8.8/32 und 8.8.4.4/32 so eingerichtet, dass sie explizit für diese Schnittstelle ausgeführt werden (a):
Sie können auch die Routen sehen, die in der Datei live.json für die entsprechende Schnittstelle (A), die eth4 zugeordnet ist, hinzugefügt wurden.
"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"
}
Um einer bestimmten Schnittstelle statische Routen hinzuzufügen oder zu löschen, können Sie den Befehl ipv4 <interface> route verwenden (Hinzufügen | del) <Adresse>/<Präfixlänge>.
Überprüfen und Ändern der Standardschnittstelle
Standardmäßig ist die Schnittstelle A die Standardschnittstelle, wenn Sie mit einer leeren Konfiguration beginnen.
Sie können dies auf der Schnittstelle mithilfe des Standardparameters überprüfen, der in diesem Bild hervorgehoben ist:
Dies ist die Ausgabe des Befehls ipv4 <interface> auf MMP.
Sie können auch von der live.json sehen, ob die Schnittstelle A (die eth4 zugeordnet ist) als Standardschnittstelle eingerichtet ist.
"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"
Um die Standardschnittstelle zu ändern, können Sie den Befehl ipv4 <interface> default verwenden, aber sicherstellen, dass Sie die richtigen statischen Routen eingerichtet haben, um diese Änderung zu bewältigen. Andernfalls wird das Routing beeinträchtigt.
Beispiel:
Das Image ist ein Beispiel für ein einzelnes Split-Server-Setup mit einem Core- und einem Edge-Server, der folgende Anforderungen erfüllt:
- Der Core-Server kann nur eine Verbindung zur DMZ-Schnittstelle (A) und nicht zu den öffentlichen (C & D) herstellen.
- Die TURN-Serverkomponente muss 443 genau wie die WebBridge überwachen (und daher sind verschiedene Schnittstellen erforderlich, um einen Portkonflikt zu vermeiden).
In diesem Beispiel wurde kein spezielles Routing eingerichtet, und es wurde keine andere Standardschnittstelle angegeben. Daher wird auf Schnittstelle A des Edge-Servers standardmäßig festgelegt.
Lage:
- WebRTC-Clients können sich anmelden, aber Anrufe schlagen fehl
- Die Bindung und Zuweisung von Anfragen von der CB an den TURN-Server führt zu Erfolgsreaktionen.
- Die Bindung und Zuweisung von Anfragen externer WebRTC-Clients zum TURN-Server erfolgt, ohne dass Erfolgsantworten vorliegen
Erläuterung:
- Da WB und Load Balancer (LB) nur auf eingehende TCP-Verbindungen reagieren und selbst keine ausgehenden TCP-Verbindungen initiieren, stellt dieses Routing kein Problem dar.
- Auch die Binding und Allocations Requests from the CB to the TURN server DMZ IP werden beantwortet, da sie sich entweder im gleichen Subnetz befinden (Edge-Schnittstelle A und Core-Schnittstelle A) oder weil keine statische Route eingerichtet ist und sie nur über die Standardschnittstelle (in diesem Fall Schnittstelle A) gesendet wird.
- Für die externen Binding- und Zuweisungsanforderungen verfügt sie über keine statischen Routen und verwendet daher die Standardschnittstelle A, um den Datenverkehr weiterzuleiten (was dazu führt, dass der externe Client nicht erreicht wird).
Lösung:
- Fügen Sie die Schnittstelle B auf den Edge-Servern hinzu, und verwenden Sie Schnittstelle A für die interne WB-Verbindung (sowie LB) und Schnittstelle B für die interne TURN-Serververbindung (um zu verhindern, dass der Port-Konflikt auf 443 sowohl für TURN als auch für WB verwendet wird). Konfigurieren Sie dies mit den nächsten Befehlen im MMP (und korrigieren Sie die TURN-Konfiguration der Anrufbrücken entsprechend für die neue Server-Adresse der Schnittstelle B).
ipv4 b add <IP-Adresse>/<präfix length> <default-gateway>
IPv4 aktivieren
Schwenk-Deaktivierung
Turn listen b
aktivieren
- Fügen Sie statische Routen hinzu, um den Datenverkehr von den Edge-Servern mit dem folgenden Befehl zum internen Core-Server zu leiten:
ipv4 b route add <address>/<prefix length>
Wenn der Core-Server beispielsweise die IP-Adresse 192.168.0.100/24 hat, muss der Befehl entweder ipv4 b route add 192.168.0.100/24 oder ipv4 b route add 192.168.0.100/32 sein.
- Legen Sie Ihre externe TURN-Serverschnittstelle (D) als Standardschnittstelle für den Datenverkehr fest.
IPv4-Standard
Überprüfen
Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.
Fehlerbehebung
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Feedback