Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Welche IP-Routing-Regeln gelten für Acano/CMS-Server?

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

Überprüfen und Ändern der Standardschnittstelle

Überprüfen

Fehlerbehebung

Zugehörige Informationen

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.

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

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

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

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"

}

}

Hinweis: In der Datei live.json werden die Schnittstellen A-D (vom MMP) zu eth4-eth1 zugeordnet, sodass Schnittstelle A eth4 zugeordnet und Schnittstelle D eth1 zugeordnet wird. Der andere Ausschnitt ist ein Ausschnitt eines Servers der X-Serie, auf dem die ADMIN-Schnittstelle im Abschnitt von mmp unter ipv4 angezeigt wird, anstatt module wie für die anderen Schnittstellen gezeigt.

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

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

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.

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

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

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 auf Schnittstelle B. Stellen Sie außerdem sicher, dass das Gateway auf Schnittstelle B es natürlich zur 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 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.

Zugehörige Informationen

- Technischer Support und Dokumentation - Cisco Systems

- Collaboration Solutions Analyzer-Tool

- CMS-Dokumentation