Regole di routing IP su Acano e Cisco Meeting Server (CMS)
Sommario
Introduzione
Questo documento descrive 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.
È 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 (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 delle risposte alle connessioni TCP in entrata).
Come visualizzare tutte le tabelle di routing IP (per interfaccia)?
Usare il comando ipv4 <interface> sul processore di gestione della scheda madre (MMP).
In questa immagine è possibile visualizzare l'indirizzo IP configurato e la lunghezza del prefisso, nonché tutte le route statiche impostate per l'interfaccia.
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"
}
}
"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.
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 ricevono 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.
- 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>
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
Feedback