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 1 mostra um exemplo do modelo de implantação do Virtual Connect para a opção de 2-concentradores do 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.

É preciso que os parceiros trabalhem de perto com os clientes, garantindo que o caminho mais ideal seja escolhido para a região de serviço "Virtual Connect".

A Figura 2 mostra as Regiões dedicadas de conectividade de nuvem de instância.

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.

Devido a motivos de segurança, a autenticação e a senha BGP não estarão disponíveis no documento exportado, mas o administrador poderá visualizar o mesmo no Control Hub clicando em Configurações de exibição 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 em 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

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

A negociação do túnel IPsec envolve duas fases, a fase IKEv2 e a fase IPsec. Se a negociação de fase IKEv2 não for concluída, não haverá iniciação de uma segunda fase IPsec. Primeiro, emita o comando "show crypto ikev2 sa" (on Cisco equipment) 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 motivos potenciais podem ser:

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

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

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

  • Os parâmetros de sessão IKEv2 não correspondem 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 de 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 IKEv2 são:

  • As configurações do IKEv2 no lado do CPE não correspondem ao lado da Cisco, verifique novamente 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 trata a autenticação e define o parâmetro de autenticação como NULL.

    • Verifique a configuração de vida útil.

    • Verifique o grupo de módulos Diffie Hellman.

    • Verifique as configurações de Função Aleatória do Pseudo.

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

    • 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 poderá ser necessária.

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

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

  • Verifique se há uma lista de acesso criptografado 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 GRE keepalives, se o equipamento não suportar GRE keepalives, a Cisco será notificada porque GRE keepalives será habilitada 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 de ocorrência dedicada.

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

  • GRE keepalives 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 de TCP de vizinho BGP do lado do CPE vizinho de BGP ao lado da ocorrência dedicada vizinho de BGP.

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

    Ping não pode ser o IP de transporte de túnel para o IP de transporte de túnel, deve ser o IP de túnel para o IP de túnel.

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

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

O centro de dados da Ocorrência dedicada nem sempre pode iniciar o primeiro pacote IKEv2. O requisito é que o dispositivo CPE seja capaz de iniciar o primeiro pacote IKEv2 em direção ao lado da Ocorrência dedicada.

Se o firewall local permitir, tente também um ping para o 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 é 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 (ou seja, 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 há mais de um segundo e se ela não está pulando. O tempo de atividade da sessão mostra como a sessão "Tempo Ativo" ou equivalente na saída.

Uma vez que a sessão IKEv2 verifica 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. Tanto a sessão IKEv2 quanto a sessão IPsec devem estar ativas antes que o túnel GRE seja estabelecido. Se a sessão IPsec não aparecer como ativa, verifique os registros IPsec quanto a mensagens de erro ou erros de negociação.

Alguns dos problemas mais comuns que podem ser encontrados durante as negociações IPsec são:

As configurações do lado do CPE não correspondem ao lado da Ocorrência dedicada, verifique novamente 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 de Perfect Forward Secrecy e se as configurações de correspondência 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, os pacotes Keepalive do túnel GRE são capazes de fluir entre os terminais do túnel Instância dedicada e CPE. Se a interface do túnel não estiver aparecendo status, alguns problemas comuns são:

  • O VRF de transporte de interface de túnel não corresponde ao VRF da interface de loopback (se a configuração de 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.

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

    Se o keepalives não for suportado no equipamento CPE, a Cisco deverá ser notificada de modo que o keepalives padrão no lado da Ocorrência dedicada também seja desativado.

    Se o keepalives for suportado, verifique se o keepalives está ativado.

  • 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 de enviados para o túnel IPsec ou recebidos do túnel IPsec (o túnel GRE é transportado sobre o túnel IPsec)

Um teste de ping deve verificar se a interface do túnel local está ativa e se a conectividade é 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 cripto para o túnel IPsec que está carregando o tráfego de túnel GRE permite que apenas pacotes GRE cruzem. 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 a partir 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 de destino.

Se o teste de ping não for bem-sucedido e os itens anteriores forem verificados, uma captura de pacotes poderá ser necessária para garantir que o ping de icmp esteja resultando em um pacote GRE que é então encapsulado em um pacote IPsec e, em seguida, 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ões IPsec também podem ajudar a mostrar. se os pacotes de envio e recebimento estão sendo incrementados.

Além do tráfego 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 do BGP também devem ser enviados como pacotes GRE encapsulados em pacotes IPSEC também através do VPN.

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

Sessões BGP

O BGP é necessário como o protocolo de roteamento sobre o túnel IPsec de VPN. O vizinho BGP local deve estabelecer uma sessão eBGP com o vizinho BGP de ocorrência dedicada. Os endereços IP vizinhos do eBGP são os mesmos que os endereços IP locais e remotos do túnel. Primeiro, verifique se a sessão BGP está ativa e, em seguida, verifique se as rotas corretas estão sendo recebidas da Ocorrência dedicada e se o caminho padrão correto é enviado à 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 para erros de estabelecimento de BGP.

Alguns dos problemas mais comuns de negociação de BGP 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 vizinho COMO.

  • O número do AS local não corresponde ao que o lado da Ocorrência Dedicada está esperando, verifique se o número do AS local corresponde aos parâmetros esperados da Ocorrência dedicada.

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

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

Troca de rota BGP

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

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

É importante que, quando ambos os túneis estão ativos que o centro de dados Um túnel não é 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 de 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 fonte através do túnel do centro de dados B. Isso resultará em roteamento abaixo do ideal e também poderá quebrar o tráfego que atravessa 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 datacenter 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 A do centro de dados da Instância Dedicada e do túnel B do centro de dados da Instância Dedicada.

Configuração MTU

No lado da Ocorrência dedicada, dois recursos estão habilitados para ajustar dinamicamente o MTU para tamanhos de pacotes grandes. 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 em cima dos cabeçalhos GRE reduzirão ainda mais o maior MTU permitido sobre o túnel.

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