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

Introdução

Este documento descreve as regras de roteamento IP em 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.

Pré-requisitos

Requisitos

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

• Componentes do CMS: 
  • WebBridge (WB)
  • Atravessar usando retransmissões 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.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 sua configuração. Como exceção a isso, os servidores X de hardware que têm uma interface ADMIN podem ter essa interface ADMIN na mesma sub-rede que uma das outras interfaces (A/B/C/D), conforme descrito no guia de instalação do CMS e mostrado nesta nota.

Observação: 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 físico Acano X-Series pode estar na mesma sub-rede que 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 você receberia Solicitações de vinculação no seu componente do servidor TURN, por exemplo, para verificar de que interface a resposta é enviada.

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

A lógica de roteamento IP depende da natureza da conexão: User Datagram Protocol (UDP) ou Transmission Control Protocol (TCP).
No caso do TCP, seja uma nova conexão ou uma resposta a uma de 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 (já que 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 esse fluxograma (assim como a primeira etapa para respostas de conexão TCP de entrada).

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

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

Pelo uso do comando ipv4 <interface> no Processador de Gerenciamento da Placa Principal (MMP).

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

Observação: no arquivo live.json, as interfaces A-D (do MMP) são mapeadas para eth4-eth1, de modo que a interface A é mapeada para eth4 e a interface D é mapeada para eth1. O outro snippet é um snippet de um servidor X-series onde você pode ver que a interface ADMIN está na seção de mmp em ipv4 em vez de module 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 (add | 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 default, conforme destacado nesta imagem:

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

Observação: se esse valor for definido como verdadeiro, essa será a interface padrão da imagem.

Você também pode ver no 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 ter as rotas estáticas corretas estabelecidas para acomodar essa alteração, caso contrário o roteamento será afetado.

Exemplo:

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

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

Neste exemplo, nenhum roteamento especial foi configurado e nenhuma interface padrão diferente foi especificada, portanto, ele assume como padrão a interface A no servidor de borda.

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 Success
• Vinculando e alocando solicitações de clientes WebRTC externos para o servidor TURN chegam, mas não obtêm respostas Success

Explicação:

• Como o WB e o Balanceador de Carga (LB) respondem apenas a conexões TCP de entrada e não iniciam elas mesmas as de saída, esse roteamento não representa um problema.

Observação: como os dois 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 Binding e Allocate do CB para o servidor TURN DMZ IP são respondidas como estão na mesma sub-rede (interface de borda A e interface de núcleo A) ou porque não há nenhuma rota estática configurada e ela apenas a envia para a interface padrão (interface A, neste caso).
• Para as Associações externas e Alocar Solicitações, ele não tem nenhuma rota estática 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 de borda e use a interface A para conexão WB interna (assim como o LB) e a interface B para conexão interna do servidor TURN (para evitar o conflito de porta em 443 é usado para TURN e WB). Configure-o com os próximos comandos no MMP (e corrija a configuração TURN em suas callbridges de acordo com o novo serverAddress da interface B).

ipv4 b add <endereço-IP>/<comprimento do prefixo> <gateway-padrão>
ipv4 b enable

turn disable
turn listen d b
turn enable

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

Observação: como o LB e o WB só reagem em conexões TCP de entrada, você só precisa configurar o roteamento dos pacotes UDP para TURN e, assim, fazer isso na interface B. Certifique-se também de que o gateway na interface B possa roteá-lo para o CB, é claro.

Por exemplo, se o servidor núcleo tiver o endereço IP 192.168.0.100/24, o comando deverá ser ipv4 b route add 192.168.0.100/24 ou ipv4 b route add 192.168.0.100/32.

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

ipv4 d padrão

Verificar 

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

Troubleshooting 

No momento, 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 de CMS