IP-routingregels voor Acano- en Cisco Meeting Server (CMS)

Inleiding

Dit document beschrijft de IP-routeringsregels op Acano- of Cisco Meeting Server (CMS)-servers. Acano- of CMS-servers kunnen meerdere interfaces geconfigureerd hebben, elk met hun eigen standaardgateway.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• CMS-onderdelen: 
  • Webebridge (WB)
  • Traversal met Relay rondom NAT-server (TURN)
  • CallBridge (CB)
• Basis IP-routing

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Meeting Server op versie 2.3.x.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

De enige beperking hier is dat de verschillende interfaces op de 4-poorts switch in verschillende subnetwerken moeten zijn, omdat anders u problemen kunt oplossen bij het routeren van uw instellingen. Als uitzondering daarop mogen hardware-X-servers die een ADMIN-interface hebben, deze ADMIN-interface hebben in hetzelfde subnetwerk als een van de andere interfaces (A/B/C/D) zoals beschreven in de CMS-installatiehandleiding en in deze noot.

Opmerking: Om het even welke twee interfaces van de Server van de Vergadering van Cisco moeten niet in zelfde slechts worden gezet. De enige uitzondering is dat de ADMIN-interface van een fysieke Acano X-Series server op dezelfde vorm kan zijn als een van de andere interfaces (A tot D) en waarschijnlijk een gemeenschappelijke toepassing is.

U kunt in een situatie lopen waar u de routing logica moet weten wanneer u Bindende Verzoeken op uw component van de server van het TURN bijvoorbeeld zou ontvangen om te verifiëren van welke interface de reactie wordt verzonden.

Welke IP-routingregels zijn van toepassing op Acano-/CMS-servers?

De IP-routeringslogica hangt af van de vraag of de verbinding User Datagram Protocol (UDP) of Transmission Control Protocol (TCP) in de natuur is.
In het geval van TCP, of het een nieuwe verbinding of een antwoord op een inkomende is, kunt u weten welke IP routeringslogica van toepassing is op uw case met het gebruik van het stroomschema in de afbeelding.

Ingaand TCP-verbindingsantwoord

De Acano/CMS server antwoordt voor een inkomende TCP verbinding op de interface zelf waarop het verzoek wordt ontvangen (aangezien er reeds een TCP verbinding is).

Uitgaande TCP-verbinding of enige uitgaande UDP-pakketten

Voor beide scenario's, worden deze IP routingregels gevolgd zoals in dit stroomschema (zowel als de eerste stap voor inkomende TCP verbinding antwoorden).

Opmerking: De logica is van toepassing op de creatie van nieuwe uitgaande UDP-pakketten of op die welke in antwoord op ontvangen pakketten worden verzonden.

Hoe worden alle IP-routingtabellen (per interface) weergegeven?

Met behulp van de opdrachtversie ipv4 <interface>op de ingebouwde beheerprocessor (MMP).

Hierin ziet u het geconfigureerde IP-adres en de prefix-lengte evenals alle statische routes die voor deze interface zijn ingesteld zoals in deze afbeelding.

Bijvoorbeeld hier, zijn de routes naar 8.8.8.8/32 en 8.8.4.4/32 ingesteld om uitdrukkelijk op deze specifieke interface (a) uit te gaan:

U kunt ook de routes zien die op het live.json bestand worden toegevoegd voor de respectieve interface (A) die aan eth4 landt.

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

Opmerking: In het live.json-bestand, de interface A-D (van de MMP)-kaart naar eth4-eth1, zodat A-kaarten naar eth4 en D-kaarten naar eth1 interface. Het andere fragment is een fragment van een X-Series server waarop je de ADMIN-interface kunt zien in het gedeelte van mmp onder ipv4 in plaats van module zoals getoond voor de andere 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"
                }

Om statische routes aan een specifieke interface toe te voegen of te wissen kunt u de opdracht ipv4 <interface> route gebruiken (add | del) <adres>/<prefixlengte>.

De standaardininterface controleren en wijzigen

Standaard is interface A de standaard als u met een lege configuratie start.

U kunt dit op de interface controleren door de standaard parameter zoals deze in dit beeld wordt gemarkeerd:

Dit is de uitvoer van de opdracht ipv4 <interface>op MMP.

Opmerking: Als deze waarde op waar is ingesteld, dan is dit de standaardinstelling van de interface zoals in de afbeelding.

Je kunt ook aan live.json zien of de interface A (die kaarten naar eth4 maakt) is ingesteld als de standaardininterface.

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

Om de standaardinterface te wijzigen, kunt u de standaard opdrachtversie ipv4 <interface> gebruiken, maar u dient er voor te zorgen dat u de juiste statische route(s) hebt om deze wijziging aan te passen anders wordt de routing gewijzigd.

Voorbeeld:

Het Afbeeldingsbestand is een voorbeeld van één gesplitste serverinstelling met één Core- en één Edge-server met deze vereisten:

• Core server kan alleen worden aangesloten op de DMZ interface (A) en niet op de openbare (C & D).
• De servercomponent van TURN moet op 443 enkel zoals de WebBridge luisteren (en dus zijn verschillende interfaces vereist om een poortconflict te voorkomen).

In dit voorbeeld is geen speciale routing ingesteld en is er geen verschillende standaardininterface gespecificeerd zodat de standaardinstelling is dat de standaardinstelling is om A op de Edge-server om te zetten.

Situatie:

• WebexRTC-clients kunnen inloggen maar oproepen falen
• Bij het binden en toewijzen van aanvragen van CB aan de TURN-server wordt Success reacties verkregen
• Bindend en toegewezen Verzoeken van externe cliënten van WebRTC aan de server TURN aankomen maar krijgen geen Success reacties

Uitleg:

• Aangezien WB en Loadbalances (LB) alleen reageren op inkomende TCP-verbindingen en geen uitgaande daarvan zelf initiëren, vormt deze routing geen probleem.

Opmerking: Aangezien beide diensten op dezelfde server staan, kan WB nog steeds een uitgaande verbinding met de LB maken, maar dat gebeurt intern.

• Ook de Bindende en toegewezen verzoeken van de CB aan de TURN server DMZ IP worden behandeld aangezien zij in hetzelfde net zijn (interface A van de Rand en interface A van de Kern) of omdat er geen statische route is ingesteld en het wordt gewoon verzonden op de standaardinterface (interface A in dit geval).
• Voor de externe Bindende en toegewezen aanvragen heeft het geen statische routes en gebruikt het dus de standaardinterface A om het verkeer weg te leiden (wat resulteert in het niet bereiken van de externe cliënt).

Oplossing:

• Voeg interface B toe op de Edge-servers en gebruik interface A voor interne WB-verbinding (evenals de LB) en interface B voor de interne TURN-serververbinding (om de poortconflict op 443 te vermijden wordt gebruikt voor zowel TURN als WB). Configureer dit met de volgende opdrachten in het MMP (en corrigeer de configuratie van het TURN op uw oproepen dienovereenkomstig voor het nieuwe serverAddress van interface B).

ipv4 b add <IP-adres>/<prefix length> <default gateway>
ipv4 b mogelijk

uitschakelen
afluisteren b
inschakelen

• Voeg statische routes toe aan routeverkeer van de servers van de Rand aan de interne server van de Kern met de opdracht:
    
    ipv4 b-route toevoegen <adres>/<prefixlengte>

Opmerking: Aangezien de LB en WB alleen reageren op inkomende TCP-verbindingen, hoeft u alleen de routing voor de UDP-pakketten voor TURN in te stellen en dus doet u dit op interface B. Zorg er ook voor dat de gateway op interface B deze naar de CB kan sturen.

Bijvoorbeeld als de Core Server het IP adres 192.168.0.100/24 heeft, moet de opdracht of ipv4 b route add 192.168.0.100/24 of ipv4 b route add 192.168.0.100/32 zijn.

• Maak uw externe interface (D) van de server als de standaardinterface voor het verkeer.

standaard ipv4 d

Verifiëren 

Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.

Problemen oplossen 

Er is momenteel geen specifieke informatie over probleemoplossing beschikbaar voor deze configuratie.

Gerelateerde informatie 

• Technische ondersteuning en documentatie – Cisco Systems
• Analyzer voor Collaboration-oplossingen 
• CMS-documentatie