IP-Routingregeln für Acano und Cisco Meeting Server (CMS)

Einleitung

In diesem Dokument werden die IP-Routing-Regeln für Acano- oder Cisco Meeting Server (CMS)-Server beschrieben. Für Acano- oder CMS-Server können mehrere Schnittstellen konfiguriert werden, von denen jede ein eigenes Standard-Gateway aufweist.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• CMS-Komponenten: 
  • WebBridge (WB)
  • Traversal mithilfe von Relays um den NAT-Server (TURN)
  • CallBridge (CB)
• Einfaches IP-Routing

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco Meeting Server 2.3.x.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Die einzige Einschränkung besteht darin, dass sich die verschiedenen Schnittstellen auf dem Switch mit 4 Ports in unterschiedlichen Subnetzen befinden müssen, da andernfalls Routing-Probleme bei der Einrichtung auftreten können. Als Ausnahme hiervon ist es Hardware-X-Servern mit einer ADMIN-Schnittstelle gestattet, diese ADMIN-Schnittstelle im gleichen Subnetz wie eine der anderen Schnittstellen (A/B/C/D) zu verwenden, wie im CMS-Installationsleitfaden beschrieben und in diesem Hinweis dargestellt.

Hinweis: Zwei Schnittstellen von Cisco Meeting Server dürfen nicht im gleichen Subnetz angeordnet sein. Die einzige Ausnahme besteht darin, dass sich die ADMIN-Schnittstelle eines physischen Servers der Acano X-Serie im gleichen Subnetz wie eine der anderen Schnittstellen (A bis D) befinden kann und wahrscheinlich eine gemeinsame Bereitstellung ist.

Sie können in eine Situation geraten, in der Sie die Routing-Logik kennen müssen, wenn Sie beispielsweise Binding Requests für Ihre TURN-Serverkomponente empfangen, um zu überprüfen, von welcher Schnittstelle die Response 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 das User Datagram Protocol (UDP) oder das Transmission Control Protocol (TCP) handelt.
Im Falle von TCP, ob es sich um eine neue Verbindung oder um eine Antwort auf eine eingehende Verbindung handelt, können Sie mithilfe des Flussdiagramms im Bild herausfinden, welche IP-Routing-Logik für Ihren Fall anwendbar ist.

Antwort auf eingehende TCP-Verbindung

Der Acano/CMS-Server antwortet auf eine eingehende TCP-Verbindung auf der Schnittstelle selbst, auf der die Anforderung empfangen wird (da bereits eine TCP-Verbindung besteht).

Ausgehende TCP-Verbindung oder ausgehende UDP-Pakete

Für beide Szenarien werden die IP-Routing-Regeln gemäß diesem Flussdiagramm befolgt (sowie der erste Schritt für eingehende TCP-Verbindungsantworten).

Hinweis: Die Logik gilt für die Erstellung neuer ausgehender UDP-Pakete oder für Pakete, die als Antwort auf empfangene Pakete gesendet werden.

Wie werden alle IP-Routing-Tabellen (pro Schnittstelle) angezeigt?

Mit dem Befehl ipv4 <interface> auf dem Mainboard Management Processor (MMP).

Damit sehen Sie die konfigurierte IP-Adresse und Präfixlänge sowie alle statischen Routen, die für diese Schnittstelle wie in diesem Bild dargestellt eingerichtet wurden.

Hier sind beispielsweise Routen zu 8.8.8.8/32 und 8.8.4.4/32 so konfiguriert, dass sie explizit über diese Schnittstelle ausgeführt werden (a):

Sie können auch die in der Datei live.json hinzugefügten Routen für die jeweilige Schnittstelle (A) sehen, die eth4 zugeordnet 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"
                        }
                    }

Hinweis: In der Datei live.json ordnen sich die Schnittstellen A-D (aus dem MMP) eth4-eth1 zu, sodass Schnittstelle A eth4 und Schnittstelle D eth1 zugeordnet ist. Das andere Snippet ist ein Snippet eines X-Series-Servers, auf dem Sie sehen können, dass sich die ADMIN-Schnittstelle im Abschnitt von mmp unter ipv4 befindet, anstatt wie für die anderen Schnittstellen gezeigt, das Modul.

    "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 statische Routen zu einer bestimmten Schnittstelle hinzuzufügen oder zu löschen, können Sie den Befehl ipv4 <interface> route (add | del) <Adresse>/<Präfixlänge>.

So überprüfen und ändern Sie die Standardschnittstelle

Die Standardschnittstelle A ist die Standardschnittstelle, wenn Sie mit einer leeren Konfiguration beginnen.

Sie können dies an der Schnittstelle mit dem Standardparameter überprüfen, wie in diesem Bild hervorgehoben:

Dies ist die Ausgabe des Befehls ipv4 <interface> auf MMP.

Hinweis: Wenn dieser Wert auf true gesetzt ist, ist dies die Standardschnittstelle wie im Bild.

Aus der Datei live.json können Sie auch erkennen, 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. Stellen Sie jedoch sicher, dass Sie über die richtige(n) statische(n) Route(n) verfügen, um dieser Änderung Rechnung zu tragen, da andernfalls das Routing beeinträchtigt wird.

Beispiel:

Das Image stellt ein Beispiel für eine Single-Split-Server-Konfiguration mit einem Core- und einem Edge-Server mit folgenden Anforderungen dar:

• Der Core-Server kann nur mit der DMZ-Schnittstelle (A) und nicht mit den öffentlichen (C & D) verbunden werden.
• TURN-Server-Komponente muss auf 443 genau wie die WebBridge hören (und daher verschiedene Schnittstellen erforderlich sind, um einen Port-Konflikt zu vermeiden).

In diesem Beispiel wurde kein spezielles Routing eingerichtet, und es wurde keine andere Standardschnittstelle festgelegt. Daher wird standardmäßig Schnittstelle A auf dem Edge-Server verwendet.

Situation:

• WebRTC-Clients können sich anmelden, aber Anrufe schlagen fehl
• Verbindungs- und Zuweisungsanforderungen von der CB an den TURN-Server erhalten Erfolgsantworten
• Binding and Allocate Requests von externen WebRTC Clients an den TURN Server kommen an, erhalten aber keine Success Responses

Erläuterung:

• Da WB und Load Balancer (LB) nur auf eingehende TCP-Verbindungen reagieren und selbst keine ausgehenden Verbindungen initiieren, stellt dieses Routing kein Problem dar.

Hinweis: Da sich beide Dienste auf demselben Server befinden, kann der WB weiterhin eine ausgehende Verbindung zum LB herstellen, was intern jedoch geschieht.

• Auch die Binding and Allocate Requests von der CB an den TURN-Server DMZ IP werden als entweder im gleichen Subnetz (Edge-Schnittstelle A und Core-Schnittstelle A) oder weil keine statische Route eingerichtet ist, sondern diese einfach an die Standard-Schnittstelle (in diesem Fall Schnittstelle A) versendet.
• Für die externen Binding- und Allocate-Anforderungen verfügt er ü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 die Schnittstelle A für die interne WB-Verbindung (sowie den LB) und die Schnittstelle B für die interne TURN-Serververbindung (um zu vermeiden, dass der Port-Konflikt auf 443 sowohl für TURN als auch WB verwendet wird). Konfigurieren Sie dies mit den nächsten Befehlen auf der MMP (und korrigieren Sie die TURN-Konfiguration auf Ihren Callbridges entsprechend für die neue serverAddress der Schnittstelle B).

ipv4 b add <IP-Adresse>/<Präfixlänge> <Standard-Gateway>
IPv4 b aktivieren

Deaktivierung
Turn listen d b
Drehfreigabe

• Fügen Sie statische Routen hinzu, um Datenverkehr von den Edge-Servern mit dem folgenden Befehl an den internen Core-Server weiterzuleiten:
    
    ipv4 b route add <Adresse>/<Präfixlänge>

Hinweis: Da LB und WB nur auf eingehende TCP-Verbindungen reagieren, müssen Sie nur das Routing für die UDP-Pakete für TURN einrichten. Dies geschieht an Schnittstelle B. Stellen Sie außerdem sicher, dass das Gateway an Schnittstelle B diese natürlich an die CB weiterleiten kann.

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 lauten.

• Legen Sie die externe TURN-Serverschnittstelle (D) als Standardschnittstelle für den Datenverkehr fest.

ipv4 d Standard

Überprüfung 

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.

Zugehörige Informationen 

• Technischer Support und Dokumentation für Cisco Systeme
• Analysetool für Collaboration-Lösungen 
• CMS-Dokumentation