Regole di routing IP su Acano e Cisco Meeting Server (CMS)

Introduzione

In questo documento vengono descritte le regole di routing IP sui server Acano o Cisco Meeting Server (CMS). I server Acano o CMS possono avere più interfacce configurate, ognuna con il proprio gateway predefinito.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Componenti CMS: 
  • WebBridge (WB)
  • Attraversamento tramite relè intorno al server NAT (TURN)
  • CallBridge (CB)
• Routing IP di base

Componenti usati

Le informazioni fornite in questo documento si basano su Cisco Meeting Server versione 2.3.x.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

L'unico limite qui è che le diverse interfacce sullo switch a 4 porte devono trovarsi in subnet diverse, altrimenti si potrebbero verificare problemi di routing nella configurazione. In via di eccezione, i server X hardware dotati di interfaccia ADMIN possono avere questa interfaccia ADMIN nella stessa subnet di una delle altre interfacce (A/B/C/D) come descritto nella guida all'installazione del CMS e mostrato in questa nota.

Nota: due interfacce di Cisco Meeting Server non devono essere inserite nella stessa subnet. L'unica eccezione è che l'interfaccia ADMIN di un server fisico Acano serie X può trovarsi sulla stessa subnet di una delle altre interfacce (da A a D) ed è probabilmente un'implementazione comune.

È possibile trovarsi in una situazione in cui è necessario conoscere la logica di routing quando si ricevono richieste di binding sul componente server TURN, ad esempio per verificare da quale interfaccia viene inviata la risposta.

Quali regole di routing IP si applicano ai server Acano/CMS?

La logica di routing IP dipende dal tipo di connessione, ovvero UDP (User Datagram Protocol) o TCP (Transmission Control Protocol).
Nel caso del protocollo TCP, sia che si tratti di una nuova connessione o di una risposta a una connessione in entrata, è possibile verificare la logica di routing IP applicabile al caso specifico utilizzando il diagramma di flusso nell'immagine.

Risposta connessione TCP in entrata

Il server Acano/CMS risponde per una connessione TCP in entrata sull'interfaccia stessa su cui viene ricevuta la richiesta (poiché esiste già una connessione TCP).

Connessione TCP in uscita o qualsiasi pacchetto UDP in uscita

In entrambi gli scenari, le regole di routing IP vengono seguite in questo diagramma di flusso (nonché nella prima fase per le risposte alle connessioni TCP in entrata).

Nota: la logica si applica alla creazione di nuovi pacchetti UDP in uscita o a quelli inviati in risposta ai pacchetti ricevuti.

Come visualizzare tutte le tabelle di routing IP (per interfaccia)?

Usare il comando ipv4 <interface> sul processore di gestione della scheda madre (MMP).

In questo modo è possibile visualizzare l'indirizzo IP configurato e la lunghezza del prefisso, nonché tutte le route statiche impostate per l'interfaccia, come mostrato nell'immagine.

Ad esempio, qui le route verso 8.8.8.8/32 e 8.8.4.4/32 sono configurate per andare esplicitamente su questa particolare interfaccia (a):

È inoltre possibile visualizzare le route aggiunte al file live.json per la rispettiva interfaccia (A) mappata a 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"
                        }
                    }

Nota: nel file live.json, le interfacce A-D (dal pannello MMP) sono mappate su eth4-eth1, quindi l'interfaccia A è mappata su eth4 e l'interfaccia D su eth1. L'altro frammento è un frammento di codice di un server serie X in cui l'interfaccia ADMIN si trova nella sezione di mmp in ipv4 anziché in module, come mostrato per le altre interfacce.

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

Per aggiungere o eliminare route statiche a un'interfaccia specifica, è possibile utilizzare il comando ipv4 <interface> route (add | del) <indirizzo>/<lunghezza prefisso>.

Come controllare e modificare l'interfaccia predefinita?

Per impostazione predefinita, l'interfaccia A è quella predefinita se si inizia con una configurazione vuota.

È possibile verificare questa condizione sull'interfaccia con il parametro predefinito evidenziato in questa immagine:

Questo è l'output del comando ipv4 <interface> su MMP.

Nota: se questo valore è impostato su true, si tratta dell'interfaccia predefinita dell'immagine.

Inoltre, è possibile verificare dal file live.json se l'interfaccia A (che mappa su eth4) è impostata come predefinita.

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

Per modificare l'interfaccia predefinita, è possibile usare il comando ipv4 <interface> default, ma assicurarsi di avere le route statiche appropriate per accettare la modifica, altrimenti il routing ne risente.

Esempio:

L'immagine rappresenta un esempio di configurazione di un singolo server diviso con un server Core e un server Edge con i seguenti requisiti:

• Il server di base può connettersi solo all'interfaccia DMZ (A) e non a quelle pubbliche (C & D).
• Il componente server TURN deve essere in ascolto su 443 proprio come il WebBridge (e quindi sono necessarie diverse interfacce per evitare un conflitto di porte).

In questo esempio non è stato impostato alcun routing speciale e non è stata specificata un'interfaccia predefinita diversa, quindi per impostazione predefinita viene utilizzata l'interfaccia A sul server Edge.

Situazione:

• I client WebRTC possono eseguire l'accesso ma le chiamate hanno esito negativo
• Le richieste di binding e allocazione da CB al server TURN non ricevono risposte riuscite
• Le richieste di binding e allocazione dai client WebRTC esterni al server TURN arrivano ma non ottengono risposte di esito positivo

Spiegazione:

• Poiché WB e Loadbalancer (LB) rispondono solo alle connessioni TCP in entrata e non avviano esse stesse quelle in uscita, questo routing non pone problemi.

Nota: poiché entrambi i servizi si trovano sullo stesso server, il bilanciamento carico di rete può ancora stabilire una connessione in uscita al bilanciamento carico, ma ciò avviene internamente.

• Anche le richieste Binding e Allocate dal CB al server TURN DMZ IP ricevono risposta in quanto si trovano nella stessa subnet (interfaccia Edge A e interfaccia Core A) o perché non è stata impostata una route statica, ma semplicemente la invia sull'interfaccia predefinita (in questo caso l'interfaccia A).
• Per le richieste Binding e Allocate esterne, non dispone di route statiche e pertanto utilizza l'interfaccia predefinita A per instradare il traffico (che non consente di raggiungere il client esterno).

Soluzione:

• Aggiungere l'interfaccia B sui server perimetrali e utilizzare l'interfaccia A per la connessione WB interna (oltre al bilanciamento del carico) e l'interfaccia B per la connessione del server TURN interno (per evitare l'interferenza della porta sul router 443 è utilizzata sia per il bilanciamento del carico che per il bilanciamento del carico). Configurarlo con i comandi successivi sul pannello di gestione (e correggere la configurazione TURN sui bridge di chiamate in modo corrispondente per il nuovo indirizzo del server dell'interfaccia B).

ipv4 b add <indirizzo-IP>/<lunghezza prefisso> <gateway-predefinito>
abilitazione ipv4 b

disattivare
attivare l'ascolto d b
attivare

• Aggiungere route statiche per indirizzare il traffico dai server perimetrali al server Core interno con il comando:
    
    ipv4 b route add <indirizzo>/<lunghezza prefisso>

Nota: poiché il bilanciamento del carico e il bilanciamento del carico reagiscono solo alle connessioni TCP in entrata, è necessario configurare il routing dei pacchetti UDP per TURN solo sull'interfaccia B. Accertarsi inoltre che il gateway sull'interfaccia B possa indirizzarlo alla BC, naturalmente.

Ad esempio, se l'indirizzo IP del server Core è 192.168.0.100/24, il comando deve essere ipv4 b route add 192.168.0.100/24 o ipv4 b route add 192.168.0.100/32.

• Imposta l'interfaccia del server TURN (D) esterno come interfaccia predefinita per il traffico.

ipv4 d predefinito

Verifica 

Attualmente non è disponibile una procedura di verifica per questa configurazione.

Risoluzione dei problemi 

Non sono attualmente disponibili informazioni specifiche sulla risoluzione dei problemi per questa configurazione.

Informazioni correlate 

• Documentazione e supporto tecnico – Cisco Systems
• strumento Collaboration Solutions Analyzer 
• Documentazione CMS