Introdução

A Conexão Virtual é uma opção adicional para conectividade de nuvem para instância dedicada para Webex Calling (Instância dedicada). A Conexão Virtual permite que os Clientes ampliem com segurança sua Rede Privada pela Internet usando Túnel VPN IP de ponto a ponto. Essa opção de conectividade proporciona uma rápida criação de conexão de rede privada usando os Equipamentos locais do cliente (CPE) existentes e a conectividade com a internet.

A Cisco organiza, gerencia e garante túneles IP VPN redundantes e o acesso necessário à Internet na(s) região(s) do centro de dados Instância Dedicada da Cisco onde o serviço é necessário. Da mesma forma, o Administrador é responsável pelo correspondente serviço CPE e Internet, que é necessário para o estabelecimento do Virtual Connect.

Cada ordem do Virtual Connect em uma região de Instância Dedicada específica inclui dois túneles de roteamento genéricos (GRE) protegidos pela criptografia IPSec (GRE sobre IPSec), um para cada centro de dados da Cisco na Região selecionada.

A Conexão Virtual tem um limite de largura de banda de 250 Mbps por túnel e é recomendada para implantações menores. Como dois túnels VPN ponto a ponto são usados, todo o tráfego na nuvem precisa passar pelo cpe do cliente e, portanto, pode não ser adequado onde há muitos sites remotos. Para outras opções alternativas de peering, consulte Conectividade em nuvem.

Antes de enviar a solicitação de emparelhamento do Virtual Connect, certifique-se de que o serviço de Ocorrência dedicada esteja ativado nessa respectiva região.

Pré-requisitos

Os pré-requisitos para estabelecer a Conexão Virtual incluem:

  • O cliente fornece

    • Conexão de Internet com largura de banda suficiente disponível para suportar a implantação

    • Endereço(es) de IP público para dois túneles IPSec

    • Endereços de IP de transporte GRE do lado do cliente para os dois túneles GRE

  • Parceiro e cliente

    • Trabalhe em conjunto para avaliar os requisitos de largura de banda

    • Certifique-se de que os dispositivos de rede Border Gateway Protocol ou Protocolo BGP com roteamento (BGP) e um design de túnel GRE sobre IPSec

  • O parceiro ou o cliente fornece

    • Equipe de rede com conhecimento de tecnologias de túnel VPN site a site

    • Equipe de rede com conhecimento de BGP, eBGP e princípios gerais de roteamento

  • Cisco

    • O Cisco atribuiu números de sistema autonómático (ASNs) e endereçamento IP transitório para interfaces de túnel DE GRE

    • A Cisco atribuiu à rede pública, mas não à Internet, classe C (/24) para endereçamento da Nuvem de Instância Dedicada

Se um cliente tem apenas 1 dispositivo CPE, então os 2 túnels para os centros de dados da Cisco (DC1 e DC2) em cada região serão desse dispositivo CPE. O cliente também tem uma opção para 2 dispositivos CPE, então cada dispositivo CPE deve se conectar a 1 túnel apenas para os centros de dados da Cisco (DC1 e DC2) em cada região. Redundância adicional pode ser alcançada terminando cada túnel em um local físico separado, dentro da infraestrutura do Cliente.

Detalhes técnicos

Modelo de implantação

O Virtual Connect usa uma arquitetura de encaminhamento de camada dupla, onde o controle de roteamento e o controle DE GRE são fornecidos por um dispositivo e o avião de controle IPSec é fornecido por outro.

Após a conclusão da conectividade do Virtual Connect , dois GRE sobre túneles IPSec serão criados entre a rede corporativa do Cliente e os centros de dados da Instância Dedicada da Cisco. Um para cada centro de dados redundante dentro da respectiva Região. Os elementos de rede adicionais necessários para o peering são trocados pelo parceiro ou cliente à Cisco através do formulário de ativação da Conexão virtual do Control Hub.

A figura abaixo mostra o exemplo do modelo de implantação do virtual connect para a opção de 2 concentradores no lado do cliente.

Conexão virtual - O VPN é um design Hub, onde os sites do Hub do cliente estão conectados ao DC1 e DC2 dos centros de dados de instâncias dedicadas em uma região específica.

Dois sites Hub são recomendados para uma melhor redundância, mas site One Hub com dois túneles também é um modelo de implantação suportado.

A largura de banda por túnel é limitada a 250 Mbps.

Os sites remotos do Cliente dentro da mesma região, precisariam se conectar novamente ao(s) site(s) Hub na WAN do cliente e não é responsabilidade da Cisco por essa conectividade.

Espera-se que os parceiros trabalhem em estreita colaboração com os Clientes, garantindo que o caminho mais ideal seja escolhido para a região de serviços do Virtual Connect .

A figura abaixo mostra as regiões de emparelhamento da conectividade em nuvem da Ocorrência dedicada.

Regiões de conexão virtual

Roteamento

O roteamento para o complemento da Conexão Virtual é implementado usando BGP externo (eBGP) entre Instância Dedicada e o Equipamento da Instalações do Cliente (CPE). A Cisco anunciará sua respectiva rede para cada DC redundante dentro de uma região para o CPE do cliente e o CPE é necessário para anunciar uma rota padrão para a Cisco.

  • A Cisco mantém e atribui

    • Endereçamento de IP da Interface de Túnel (link transitório para roteamento) A Cisco atribui a partir de um Espaço de endereço compartilhado designado (não roteável ao público)

    • Endereço de desitinação de transporte tunnel (lado do Cisco)

    • Números do sistema autônomo privado (ASNs) para a configuração de roteamento BGP do cliente

      • A Cisco atribui a partir do intervalo de uso privado designado: 64512 até 65534

  • eBGP usado para trocar rotas entre a Ocorrência Dedicada e o CPE

    • A Cisco dividirá a rede atribuída/24 em 2/25 uma para cada DC na respectiva região

    • Em Conexão Virtual, cada rede /25 é anunciada de volta ao CPE pela Cisco sobre os respectivos túneles VPN ponto a ponto (link transitório)

    • O CPE deve ser configurado com a confirmação do eBGP apropriado. Se utilizar um CPE, dois eBGP serão usados, um apontando para cada túnel remoto. Se usar dois CPE, então cada CPE terá um túnel vizinho eBGP para o único túnel remoto para o CPE.

    • O lado da Cisco de cada túnel GRE (IP da interface de túnel) é configurado como o vizinho BGP no CPE

    • O CPE é necessário para anunciar uma rota padrão por cada um dos túnels

    • O CPE éponível para redistribuição, conforme necessário, os caminhos aprendidos dentro da rede corporativa do cutomer.

  • Sob a condição de falha do link sem falha, um único CPE terá dois túneles ativos/ativos. Para dois nós CPE, cada CPE terá um túnel ativo e ambos os nós CPE devem estar ativos e passar o tráfego. Em um cenário sem falha, o tráfego deve dividir em dois túnel indo para os destinos corretos /25, se um dos túnel cair, o túnel restante pode carregar o tráfego para ambos. Sob tal cenário de falha, quando a rede /25 está inocessada, então a rede /24 é usada como uma rota de backup. A Cisco enviará o tráfego do cliente através de sua WAN interna para o DC, que perdeu a conectividade.

Processo de conectividade

As seguintes etapas de alto nível descrevem como estabelecer conectividade com a Conexão virtual para Instância Dedicada.
1

Fazer um pedido no Cisco CCW

2

Ativar a conexão virtual a partir do Control Hub

3

A Cisco executa a Configuração de Rede

4

O cliente executa a configuração de rede

Passo 1: Pedido CCW

A Conexão Virtual é um complemento para Instância Dedicada no CCW.

1

Navegue até o site de solicitação CCW e clique em Logon para se inscrever no site:

https://apps.cisco.com/Commerce/guest.
2

Crie estimativa.

3

Adicione SKU "A-FLEX-3".

4

Selecione Editar opções.

5

Na guia de assinatura que aparece, Selecione Opções e Complementos.

6

Em Complementos Adicionais, selecione a caixa de seleção ao lado de "Conexão Virtual para Instância Dedicada". O nome SKU é "A-FLEX-DI-VC".

7

Insira a quantidade e o número de regiões nas quais é necessário o Virtual Connect.

A quantidade de Conexão Virtual não deve exceder o número total de regiões compradas para Instância Dedicada. Além disso, apenas um pedido de Conexão Virtual é permitido por região.
8

Quando estiver satisfeito com as seleções, clique em Verificar e Salvar na parte superior direita da página.

9

Clique em Salvar e Continuar para finalizar seu pedido. Seu pedido finalizado agora é appers na grade de ordem.

Passo 2: Ativação da conexão virtual no Control Hub

1

Faça login no Control Hub https://admin.webex.com/login.

2

Na seção Serviços , navegue até Chamar > de Instacnce dedicada > nuvem.

3

No cartão De Conexão Virtual, a quantidade adquirida de Conexão Virtual está listada. O administrador pode agora clicar em Ativar para iniciar a ativação da Conexão Virtual.

O processo de ativação pode ser acionado apenas pelos administradores com a função "Administrador completo do cliente". Enquanto isso, um administrador com a função de "Administrador de somente leitura do cliente" pode apenas visualizar o status.
4

Ao clicar no botão Ativar, o formulário ativar conexão virtual é exibido para o administrador fornecer os detalhes técnicos do Virtual Connect necessários para as configurações de peering no lado da Cisco.

O formulário também fornece informações estáticas do lado da Cisco, com base na Região selecionada. Essas informações serão úteis para os administradores do cliente configurarem o CPE do lado deles para estabelecer a Conectividade.

  1. Endereço IP de transporte do túnel GRE: O cliente é necessário para fornecer o endereço de IP Tunnel Transport do lado do cliente e a Cisco alocará dinamicamente os endereços de IP assim que a ativação for concluída. O IPSec ACL para tráfego interessante deve permitir o IP/32 de transporte local Tunnel para o IP/32 de transporte remoto Tunnel. A ACL também deve especificar apenas o protocolo DE IP GRE.

    O endereço IP fornecido pelo cliente pode ser privado ou público.

  2. Pares IPSec: O cliente é necessário para fornecer os endereços ip de origem do IPSec e a Cisco aloca o endereço de IP de destino IPSec. Realizar a tradução NAT de um endereço de túnel IPSEC interno para um endereço público também é suportada, se necessário.

    O endereço IP fornecido pelo cliente deve ser público.

    Todas as outras informações estáticas fornecidas na tela de ativação são os padrões de segurança e criptografia do lado da Cisco seguidos. Essa configuração estática não é personalizável ou modificável. Para qualquer assistência em relação às configurações estáticas do lado da Cisco, o cliente precisará falar com o TAC.
5

Clique no botão Ativar uma vez que todos os campos obrigatórios sejam preenchidos.

6

Depois que o formulário de Ativação do Virtual Connect for concluído para uma região participantes, o cliente poderá Exportar o formulário de ativação do Control Hub, da > de Instância dedicada > Cloud Connectivity e clicar nas configurações de Exportação.

Por motivos de segurança, a Autenticação e a senha BGP não estarão disponíveis no documento Exportado, mas o administrador pode visualizar o mesmo no Control Hub clicando em Exibir configurações no Control Hub, Chamadas > Ocorrência dedicada > guia Conectividade em nuvem.

Passo 2: A Cisco executa a Configuração de Rede

1

Quando o formulário de Ativação do Virtual Connect for concluído, o status será atualizado para Ativação em andamento no > de instância > Cloud Connect.

2

A Cisco concluirá as configurações necessárias no equipamento lateral da Cisco dentro de 5 dias úteis. Após a conclusão bem-sucedida, o status será atualizado para "Ativado" para essa região específica no Control Hub.

Passo 4: O cliente executa a configuração de rede

O status é alterado para "Ativado" para notificar o administrador do Cliente que o lado das configurações da Cisco para a conectividade VPN IP foi concluído com base nas entradas fornecidas pelo Cliente. Mas é preciso que o administrador do cliente complete o lado das configurações nas CPEs e teste as rotas de conectividade para que o túnel Virtual Connect seja On-line. No caso de quaisquer problemas enfrentados no momento da configuração ou da conectividade, o cliente pode entrar em contato com o TAC da Cisco para assistência.

Solução de problemas

Solução de problemas e validação da primeira fase do IPsec (negociação IKEv2)

A negociação do túnel IPsec envolve duas fases, a fase IKEv2 e a fase IPsec. Se a negociação da fase IKEv2 não for concluída, então não haverá início de uma segunda fase IPsec. Primeiro, emita o comando "show crypto ikev2 sa" (no equipamento da Cisco) ou comando semelhante no equipamento de terceiros para verificar se a sessão IKEv2 está ativa. Se a sessão IKEv2 não estiver ativa, os possíveis motivos podem ser:

  • O tráfego interessante não aciona o túnel IPsec.

  • A lista de acesso do túnel IPsec está configurada incorretamente.

  • Não há conectividade entre o cliente e o IP do terminal do túnel IPsec de ocorrência dedicada.

  • Os parâmetros da sessão IKEv2 não estão correspondendo entre o lado da Ocorrência dedicada e o lado do cliente.

  • Um firewall está bloqueando os pacotes UDP IKEv2.

Primeiro, verifique os registros IPsec para quaisquer mensagens que mostram o progresso da negociação do túnel IKEv2. Os registros podem indicar onde há um problema com a negociação IKEv2. A falta de mensagens de registro também pode indicar que a sessão IKEv2 não está sendo ativada.

Alguns erros comuns com a negociação do IKEv2 são:

  • As configurações para o IKEv2 no lado CPE não correspondem ao lado da Cisco. Volte a verificar as configurações mencionadas:

    • Verifique se a versão IKE é a versão 2.

    • Verifique se os parâmetros de Criptografia e Autenticação correspondem à criptografia esperada no lado da Ocorrência dedicada.

      Quando a cifra "GCM" está em uso, o protocolo GCM lida com a autenticação e define o parâmetro de autenticação como NULO.

    • Verifique a configuração do tempo de vida.

    • Verifique o grupo do módulo Diffie Hellman.

    • Verifique as configurações de Função pseudo-aleatória.

  • A lista de acesso para o mapa de criptografia não está definida como:

    • Permitir GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (ou comando equivalente)

      A lista de acesso deve ser especificamente para o protocolo "GRE" e o protocolo "IP" não funcionará.

Se as mensagens de registro não estiverem mostrando nenhuma atividade de negociação para a fase IKEv2, uma captura de pacotes pode ser necessária.

O lado da Ocorrência dedicada pode nem sempre iniciar a troca IKEv2 e às vezes pode esperar que o lado CPE do cliente seja o iniciador.

Verifique a configuração do lado do CPE para os seguintes pré-requisitos para o início da sessão IKEv2:

  • Verifique se há uma lista de acesso à criptografia IPsec para tráfego GRE (protocolo 50) do IP de transporte do túnel CPE para o IP de transporte do túnel da ocorrência dedicada.

  • Certifique-se de que a interface do túnel GRE esteja habilitada para keepalives do GRE; se o equipamento não suportar keepalives do GRE, a Cisco será notificada porque o keepalives do GRE será habilitado no lado da Ocorrência dedicada no padrão.

  • Certifique-se de que o BGP esteja ativado e configurado com o endereço vizinho do IP do túnel da ocorrência dedicada.

Quando configurado corretamente, o seguinte inicia o túnel IPsec e a primeira fase da negociação do IKEv2:

  • Os keepalives do GRE da interface do túnel GRE do lado do CPE para a interface do túnel GRE do lado da ocorrência dedicada.

  • Sessão TCP de vizinho BGP do lado CPE do vizinho BGP do lado BGP da ocorrência dedicada.

  • Ping do endereço IP do túnel lateral CPE para o endereço IP do túnel lateral da Ocorrência dedicada.

    O ping não pode ser o IP de transporte do túnel para o IP de transporte do túnel, deve ser IP do túnel para IP do túnel.

Se um rastreamento de pacotes for necessário para o tráfego IKEv2, defina o filtro para o UDP e a porta 500 (quando nenhum dispositivo NAT estiver no meio dos terminais IPsec) ou a porta 4500 (quando um dispositivo NAT for inserido no meio dos terminais IPsec).

Verifique se os pacotes UDP IKEv2 com a porta 500 ou 4500 são enviados e recebidos de e para o endereço IPsec DI.

O data center da Ocorrência dedicada pode nem sempre iniciar o primeiro pacote IKEv2. O requisito é que o dispositivo CPE seja capaz de iniciar o primeiro pacote IKEv2 no lado da Ocorrência dedicada.

Se o firewall local permitir, tente também fazer um ping no endereço IPsec remoto. Se o ping não for bem-sucedido do endereço IPsec local para remoto, execute uma rota de rastreamento para ajudar e determine onde o pacote foi descartado.

Alguns firewalls e equipamentos de Internet podem não permitir rota de rastreamento.

Solução de problemas e validação da segunda fase do IPsec (negociação do IPsec)

Verifique se a primeira fase do IPsec (isto é, associação de segurança IKEv2) está ativa antes de solucionar problemas da segunda fase do IPsec. Execute um comando "show crypto ikev2 sa" ou equivalente para verificar a sessão IKEv2. Na saída, verifique se a sessão IKEv2 está ativa por mais de alguns segundos e se não está saltando. O tempo de atividade da sessão é mostrado como a sessão de "Tempo ativo" ou equivalente na saída.

Depois que a sessão IKEv2 verificar como ativa e ativa, investigue a sessão IPsec. Assim como na sessão IKEv2, execute um comando "show crypto ipsec sa" ou equivalente para verificar a sessão IPsec. As sessões IKEv2 e IPsec devem estar ativas antes que o túnel GRE seja estabelecido. Se a sessão IPsec não for exibida como ativa, verifique os logs IPsec para mensagens de erro ou erros de negociação.

Algumas das questões mais comuns que podem ser encontradas durante as negociações do IPsec são:

As configurações no lado CPE não correspondem ao lado da Ocorrência dedicada. Volte a verificar as configurações:

  • Verifique se os parâmetros de Criptografia e Autenticação correspondem às configurações no lado da Ocorrência dedicada.

  • Verifique as configurações do Perfect Forward Secrecy e se as configurações correspondem no lado da Ocorrência dedicada.

  • Verifique as configurações de vida útil.

  • Verifique se o IPsec foi configurado no modo de túnel.

  • Verifique os endereços IPsec de origem e destino.

Solução de problemas e validação da interface do túnel

Quando as sessões IPsec e IKEv2 são verificadas como ativas e ativas, os pacotes keepalive do túnel GRE são capazes de fluir entre a ocorrência dedicada e os terminais do túnel CPE. Se a interface do túnel não estiver exibindo o status, alguns problemas comuns são:

  • O VRF de transporte da interface do túnel não corresponde ao VRF da interface de loopback (se a configuração do VRF for usada na interface do túnel).

    Se a configuração do VRF não for usada na interface do túnel, essa verificação poderá ser ignorada.

  • Os Keepalives não estão ativados na interface do túnel lateral do CPE

    Se os keepalives não forem compatíveis com o equipamento CPE, a Cisco deverá ser notificada para que os keepalives padrão no lado da Ocorrência dedicada também sejam desativados.

    Se keepalives forem suportados, verifique se os keepalives estão ativados.

  • A máscara ou o endereço IP da interface do túnel não está correto e não corresponde aos valores esperados da Ocorrência dedicada.

  • O endereço de transporte do túnel de origem ou destino não está correto e não corresponde aos valores esperados da Ocorrência dedicada.

  • Um firewall está bloqueando pacotes GRE enviados para o túnel IPsec ou recebidos do túnel IPsec (o túnel GRE é transportado pelo túnel IPsec)

Um teste de ping deve verificar se a interface do túnel local está ativa e se a conectividade está boa para a interface do túnel remoto. Execute a verificação de ping do IP do túnel (não o IP de transporte) para o IP do túnel remoto.

A lista de acesso de criptografia para o túnel IPsec que está carregando o tráfego do túnel GRE permite que apenas os pacotes GRE sejam cruzados. Como resultado, os pings não funcionarão do IP de transporte de túnel para o IP de transporte de túnel remoto.

A verificação de ping resulta em um pacote GRE que é gerado do IP de transporte do túnel de origem para o IP de transporte do túnel de destino, enquanto a carga útil do pacote GRE (o IP interno) será o IP do túnel de origem e destino.

Se o teste de ping não for bem-sucedido e os itens anteriores forem verificados, uma captura de pacotes pode ser necessária para garantir que o ping do icmp resulte em um pacote GRE que é então encapsulado em um pacote IPsec e enviado do endereço IPsec de origem para o endereço IPsec de destino. Os contadores na interface do túnel GRE e os contadores de sessão IPsec também podem ajudar a mostrar. se os pacotes de envio e recebimento estão aumentando.

Além do tráfego de ping, a captura também deve mostrar pacotes GRE keepalive, mesmo durante o tráfego ocioso. Finalmente, se o BGP estiver configurado, os pacotes keepalive BGP também devem ser enviados como pacotes GRE encapsulados em pacotes IPSEC, bem como através da VPN.

Solução de problemas e validação BGP

Sessões BGP

O BGP é necessário como o protocolo de roteamento pelo túnel IPsec VPN. O vizinho BGP local deve estabelecer uma sessão eBGP com o vizinho BGP da ocorrência dedicada. Os endereços IP de vizinhos do eBGP são os mesmos que os endereços IP do túnel local e remoto. Primeiro, certifique-se de que a sessão BGP esteja ativa e, em seguida, verifique se as rotas corretas estão sendo recebidas da Ocorrência dedicada e se a rota padrão correta está sendo enviada à Ocorrência dedicada.

Se o túnel GRE estiver ativado, verifique se um ping foi bem-sucedido entre o IP do túnel GRE local e o remoto. Se o ping for bem-sucedido, mas a sessão BGP não estiver chegando, investigue o registro BGP em busca de erros de estabelecimento de BGP.

Alguns dos problemas de negociação BGP mais comuns são:

  • O número do AS remoto não corresponde ao número do AS configurado no lado da Ocorrência dedicada. Verifique novamente a configuração do AS vizinho.

  • O número AS local não corresponde ao que o lado da Ocorrência dedicada espera. Verifique se o número AS local corresponde aos parâmetros esperados da Ocorrência dedicada.

  • Um firewall está bloqueando que pacotes BGP TCP encapsulados em pacotes GRE sejam enviados para o túnel IPsec ou recebidos do túnel IPSEC

  • O IP de vizinho BGP remoto não corresponde ao IP do túnel GRE remoto.

Troca de rotas BGP

Depois que a sessão BGP for verificada em ambos os túneis, certifique-se de que as rotas corretas estejam sendo enviadas e recebidas do lado da Ocorrência dedicada.

A solução VPN de ocorrência dedicada espera que dois túneis sejam estabelecidos do lado do cliente/parceiro. O primeiro túnel aponta para o datacenter de Ocorrência dedicada A e o segundo túnel aponta para o datacenter de Ocorrência dedicada B. Ambos os túneis devem estar em estado ativo e a solução requer uma implantação ativa/ativa. Cada data center da Ocorrência dedicada anunciará sua rota local /25, bem como uma rota de backup /24. Ao verificar as rotas BGP de entrada da Ocorrência dedicada, certifique-se de que a sessão BGP associada ao túnel apontando para o centro de dados A da Ocorrência dedicada receba a rota local do centro de dados A /25, bem como a rota de backup /24. Além disso, certifique-se de que o túnel apontando para o centro de dados da Ocorrência dedicada B receba a rota local B /25 da Ocorrência dedicada, bem como a rota de backup /24. Observe que a rota de backup /24 será a mesma rota anunciada fora do datacenter A de ocorrência dedicada e do datacenter B de ocorrência dedicada.

A redundância será fornecida a um centro de dados de Ocorrência dedicada se a interface do túnel com esse centro de dados cair. Se a conectividade com o centro de dados da Ocorrência dedicada A for perdida, o tráfego será encaminhado do centro de dados B da Ocorrência dedicada para o centro de dados A. Nesse cenário, o túnel para o centro de dados B usará a rota do centro de dados B /25 para enviar tráfego ao centro de dados B e o túnel para o centro de dados B usará a rota de backup /24 para enviar tráfego ao centro de dados A via do centro de dados B.

É importante que, quando ambos os túneis estão ativos, o túnel do centro de dados A não seja usado para enviar tráfego para o centro de dados B e vice-versa. Neste cenário, se o tráfego for enviado para o centro de dados A com um destino do centro de dados B, o centro de dados A encaminhará o tráfego para o centro de dados B e, em seguida, o centro de dados B tentará enviar o tráfego de volta para a origem através do túnel do centro de dados B. Isso resultará em roteamento abaixo do ideal e também pode quebrar o tráfego que atravessa os firewalls. Portanto, é importante que ambos os túneis estejam em uma configuração ativa/ativa durante a operação normal.

A rota 0.0.0.0/0 deve ser anunciada do lado do cliente para o lado do data center da Ocorrência dedicada. Rotas mais específicas não serão aceitas pelo lado da Ocorrência dedicada. Certifique-se de que a rota 0.0.0.0/0 seja anunciada fora do túnel do centro de dados A da Ocorrência dedicada e do túnel do centro de dados B da Ocorrência dedicada.

Configuração MTU

No lado da Ocorrência dedicada, dois recursos são habilitados para ajustar dinamicamente o MTU de grandes tamanhos de pacotes. O túnel GRE adiciona mais cabeçalhos aos pacotes IP que fluem através da sessão VPN. O túnel IPsec adiciona os cabeçalhos adicionais sobre os cabeçalhos GRE reduzirá ainda mais o maior MTU permitido no túnel.

O túnel GRE ajusta o recurso MSS e o caminho do túnel GRE no recurso de descoberta do MTU estão habilitados no lado da Ocorrência dedicada. Configure "ip tcp adjust-mss 1350" ou comando equivalente, bem como "caminho do túnel\u0002mtu-discovery" ou comando equivalente no lado do cliente para ajudar no ajuste dinâmico do MTU de tráfego através do túnel VPN.