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-componenten: 
  • WebBridge (WB)
  • Traversal met behulp van relais rond NAT (TURNSERVER)
  • 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 live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

De enige beperking hier is dat de verschillende interfaces op de 4-poorts switch in verschillende subnetten moeten zijn omdat u anders kunt eindigen met routeringsproblemen op uw setup. Bij wijze van uitzondering mogen hardware-X-servers met een ADMIN-interface deze ADMIN-interface in hetzelfde subsysteem hebben als een van de andere interfaces (A/B/C/D), zoals beschreven in de installatiehandleiding van het CMS en weergegeven in deze opmerking.

Opmerking: twee interfaces van Cisco Meeting Server mogen niet in hetzelfde subnetmenu worden geplaatst. De enige uitzondering is dat de ADMIN-interface van een fysieke Acano X-Series-server op hetzelfde subsysteem kan staan als een van de andere interfaces (A tot D) en waarschijnlijk een veel voorkomende implementatie is.

U kunt in een situatie lopen waar u de routeringslogica moet kennen wanneer u Bindende Verzoeken op uw de servercomponent van de DRAAI zou ontvangen bijvoorbeeld om te verifiëren waarvan de interface de reactie wordt verzonden.

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

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

Inkomend 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-routeringsregels gevolgd volgens dit stroomschema (evenals de eerste stap voor inkomende TCP-verbindingsantwoorden).

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

Hoe alle IP-routingtabellen (per interface) te tonen?

Door gebruik te maken van de opdracht ipv4 <interface> op de Mainboard Management Processor (MMP).

Hiermee kunt u het ingestelde IP-adres en de lengte van het prefix zien, evenals alle statische routes die zijn ingesteld voor deze interface zoals in deze afbeelding.

Hier zijn bijvoorbeeld routes naar 8.8.8.8/32 en 8.8.4.4/32 ingesteld om expliciet uit te gaan op deze specifieke interface (a):

U kunt ook de routes zien die worden toegevoegd aan het bestand live.json voor de betreffende interface (A) die wordt toegewezen aan 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"
                        }
                    }

Opmerking: In het bestand live.json worden de interfaces A-D (van het MMP) toegewezen aan eth4-eth1, dus de A-kaarten aan eth4 en de D-kaarten aan eth1. Het andere fragment is een fragment van een X-Series server waar u kunt zien dat de ADMIN interface in de sectie van mmp onder ipv4 is 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 verwijderen, kunt u de opdracht ipv4 <interface> route gebruiken (add | del) <adres>/<prefixlengte>.

Hoe de standaardinterface controleren en wijzigen?

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

U kunt dit op de interface verifiëren door de standaardparameter zoals die op dit beeld wordt benadrukt:

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

Opmerking: als deze waarde op true is ingesteld, is dit de standaardinterface zoals in het beeld.

U kunt ook van live.json zien of de interface A (die kaarten naar eth4), is ingesteld als de standaardinterface.

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

Als u de standaardinterface wilt wijzigen, kunt u de opdracht ipv4 <interface> standaard gebruiken, maar u moet ervoor zorgen dat u de juiste statische route(s) hebt om deze wijziging aan te passen, omdat de routing anders wordt beïnvloed.

Voorbeeld:

De Image representeert een voorbeeld van een enkele gesplitste server setup met één Core en één Edge server met deze vereisten:

• De server van de kern kan slechts met de interface DMZ (A) en niet met openbare degenen verbinden (C & D).
• De servercomponent van DE DRAAI moet op 443 enkel zoals WebBridge (en daarom worden verschillende interfaces vereist om een havenconflict te vermijden) luisteren.

In dit voorbeeld is geen speciale routing ingesteld en is geen andere standaardinterface opgegeven, zodat deze standaard wordt gebruikt voor interface A op de Edge-server.

Situatie:

• WebRTC-clients kunnen inloggen maar oproepen mislukken
• Binden en Toewijzen Verzoeken van CB aan de TURNserver krijgen geen Success response
• Binden en toewijzen Verzoeken van externe WebRTC-clients aan de TURNserver arriveren maar krijgen geen Success reacties

Uitleg:

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

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

• Ook de Binding en Wijs Verzoeken van de CB toe aan de TURNserver DMZ IP wordt wel beantwoord als ze in hetzelfde subnetnummer zijn (Edge-interface A en Core-interface A) of omdat er geen statische route is ingesteld en het stuurt het gewoon uit op de standaardinterface (interface A in dit geval).
• Voor de externe Binding en Wijs Verzoeken toe, heeft het geen statische routes en gebruikt zo de standaardinterface A om het verkeer uit te leiden (dat in het niet bereiken van de externe cliënt resulteert).

Oplossing:

• Voeg interface B toe op de Edge-servers en gebruik interface A voor de interne WB-verbinding (evenals de LB) en interface B voor de interne turn-serververbinding (om te voorkomen dat de poortconflict op 443 wordt gebruikt voor zowel turn als WB). Configureer dit met de volgende commando's op de MMP (en corrigeer de turn configuratie op uw callbridges dienovereenkomstig voor de nieuwe serverAddress van interface B).

IPv4 b <IP-adres>/<prefix length> <default-gateway>
IPv4 b inschakelen

uitschakelen
luister naar d b
inschakelen

• Voeg statische routes toe aan het routeverkeer van de Edge-servers naar de interne Core-server met de opdracht:
    
    ipv4 b route add <address>/<prefix length>

Opmerking: omdat de LB en de 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 natuurlijk naar de CB kan leiden.

Als de Core-server bijvoorbeeld het IP-adres 192.168.0.100/24 heeft, moet de opdracht ipv4 b route add 192.168.0.100/24 of ipv4 b route add 192.168.0.100/32 zijn.

• Maak van uw externe turn server interface (D) als de standaard interface 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
• Collaboration Solution Analyzer-tool 
• CMS-documentatie