Regras de roteamento IP no Acano e no Cisco Meeting Server (CMS)

Introduction

Este documento descreve as regras de roteamento IP nos servidores Acano ou Cisco Meeting Server (CMS). Os servidores Acano ou CMS podem ter várias interfaces configuradas, cada uma com seu próprio gateway padrão.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Componentes CMS: 
  • WebBridge (WB)
  • Traversal usando relés em torno do servidor NAT (TURN)
  • CallBridge (CB)
• Roteamento IP básico

Componentes Utilizados

As informações neste documento são baseadas no Cisco Meeting Server na versão 2.3.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A única limitação aqui é que as diferentes interfaces no switch de 4 portas precisam estar em sub-redes diferentes, caso contrário você pode acabar com problemas de roteamento na configuração. Como exceção, os servidores de hardware X que têm uma interface ADMIN podem ter essa interface ADMIN na mesma sub-rede de uma das outras interfaces (A/B/C/D) conforme descrito no guia de instalação do CMS e mostrado nesta observação.

Note: As duas interfaces do Cisco Meeting Server não devem ser colocadas na mesma sub-rede. A única exceção é que a interface ADMIN de um servidor Acano X-Series físico pode estar na mesma sub-rede de uma das outras interfaces (A a D) e é provavelmente uma implantação comum.

Você pode se deparar com uma situação em que precisa saber a lógica de roteamento quando receberia Solicitações de vinculação no componente do servidor TURN, por exemplo, para verificar a partir de qual interface a resposta é enviada.

Quais regras de roteamento IP se aplicam aos servidores Acano/CMS?

A lógica de roteamento IP depende se a conexão é UDP (User Datagram Protocol) ou TCP (Transmission Control Protocol) por natureza.
No caso do TCP, seja uma nova conexão ou uma resposta para uma entrada, você pode descobrir qual lógica de roteamento IP é aplicável ao seu caso com o uso do fluxograma na imagem.

Resposta de conexão TCP de entrada

O servidor Acano/CMS responde por uma conexão TCP de entrada na própria interface na qual a solicitação é recebida (pois já existe uma conexão TCP).

Conexão TCP de saída ou qualquer pacote UDP de saída

Para ambos os cenários, essas regras de roteamento IP são seguidas de acordo com este fluxograma (assim como a primeira etapa para respostas de conexão TCP de entrada).

Note: A lógica se aplica à criação de novos pacotes UDP de saída ou àqueles enviados em resposta aos pacotes recebidos.

Como mostrar todas as tabelas de roteamento IP (por interface)?

Usando o comando ipv4 <interface> no MMP (Mainboard Management Processor).

Com isso, você pode ver o endereço IP configurado e o comprimento do prefixo, bem como todas as rotas estáticas configuradas para essa interface, como mostrado nesta imagem.

Por exemplo, aqui, as rotas para 8.8.8.8/32 e 8.8.4.4/32 são configuradas para sair explicitamente nesta interface específica (a):

Você também pode ver as rotas adicionadas no arquivo live.json para a respectiva interface (A) que mapeia para 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"
                        }
                    }

Note: No arquivo live.json, as interfaces A-D (do MMP) mapeiam para eth4-eth1, portanto a interface A mapeia para eth4 e a interface D mapeia para eth1. O outro snippet é um snippet de um servidor da série X onde você pode ver que a interface ADMIN está na seção de mmp em ipv4 em vez de módulo como mostrado para as outras 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"
                }

Para adicionar ou excluir rotas estáticas para uma interface específica, você pode usar o comando ipv4 <interface> route (adicionar | del) <address>/<prefix length>.

Como verificar e alterar a interface padrão?

Por padrão, a interface A é a padrão se você iniciar com uma configuração em branco.

Você pode verificar isso na interface pelo parâmetro padrão, como destacado nesta imagem:

Esta é a saída do comando ipv4 <interface> no MMP.

Note: Se esse valor for definido como verdadeiro, então essa é a interface padrão como na imagem.

Você também pode ver pelo live.json se a interface A (que mapeia para eth4) está configurada como a interface padrão.

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

Para alterar a interface padrão, você pode usar o comando ipv4 <interface> default, mas certifique-se de que você tenha as rotas estáticas corretas em vigor para acomodar essa alteração, caso contrário, o roteamento será afetado.

Exemplo:

A imagem representa um exemplo de uma única configuração de servidor dividido com um núcleo e um servidor de borda com estes requisitos:

• O servidor central só pode se conectar à interface DMZ (A) e não às públicas (C e D).
• O componente de servidor TURN precisa ouvir no 443 da mesma forma que o WebBridge (portanto, são necessárias diferentes interfaces para evitar um conflito de portas).

Neste exemplo, nenhum roteamento especial foi configurado e nenhuma interface padrão diferente foi especificada, portanto, o padrão é a interface A no servidor Edge.

Situação:

• Os clientes WebRTC podem fazer logon, mas as chamadas falham
• Vinculando e Alocando Solicitações do CB para o servidor TURN obtêm respostas Bem-sucedidas
• Vinculando e Alocando Solicitações de clientes WebRTC externos ao servidor TURN chegam, mas não obtêm respostas de Êxito

Explicação:

• Como o WB e o Balanceador de carga (LB) respondem somente às conexões TCP de entrada e não iniciam as próprias conexões de saída, esse roteamento não representa um problema.

Note: Como ambos os serviços estão no mesmo servidor, o WB ainda pode fazer uma conexão de saída com o LB, mas isso acontece internamente.

• Além disso, as Solicitações de Vinculação e Alocação do CB para o servidor TURN DMZ IP são respondidas, pois estão na mesma sub-rede (Interface de Borda A e Interface de Núcleo A) ou porque não há nenhuma configuração de rota estática e ela apenas a envia para a interface padrão (neste caso, a interface A).
• Para as Solicitações de Vinculação e Alocação externas, ele não tem rotas estáticas e, portanto, usa a interface padrão A para rotear o tráfego (o que resulta em não alcançar o cliente externo).

Solução:

• Adicione a interface B nos servidores Edge e use a interface A para a conexão WB interna (assim como o LB) e a interface B para a conexão interna do servidor TURN (para evitar que o conflito de portas no 443 seja usado para TURN e WB). Configure-o com os próximos comandos no MMP (e corrija a configuração TURN em seus callbridges de acordo com o novo serverAddress da interface B).

ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 b enable

desativar vez
girar ouvir d b
ativar vez

• Adicione rotas estáticas para rotear o tráfego dos servidores Edge para o servidor Core interno com o comando:
    
    ipv4 b route add <address>/<prefix length>

Note: Como o LB e o WB reagem somente em conexões TCP de entrada, você só precisa configurar o roteamento para os pacotes UDP para TURN e, portanto, você faz isso na interface B. Também certifique-se de que o gateway na interface B possa roteá-lo para o CB, é claro.

Por exemplo, se o servidor Core tiver o endereço IP 192.168.0.100/24, o comando deve ser ipv4 b route add 192.168.0.100/24 ou ipv4 b route add 192.168.0.100/32.

• Torne sua interface de servidor TURN externa (D) como a interface padrão para o tráfego.

ipv4 d default

Verificar 

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot 

Atualmente, não há informações específicas de solução de problemas disponíveis para esta configuração.

Informações Relacionadas 

• Suporte Técnico e Documentação - Cisco Systems
• Ferramenta Collaboration Solutions Analyzer 
• documentação CMS