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 peering para o Virtual Connect, certifique-se de que o serviço Instância Dedicada esteja ativado na 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 de conexão virtual 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. Para garantir um failover eficaz, o tráfego combinado em ambos os túneis não deve exceder 250 Mbps, pois todo o tráfego será roteado por meio de um túnel em caso de falha.

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 adequado seja escolhido para a região de serviço do Virtual Connect.

A figura abaixo mostra as regiões de peering de conectividade de nuvem da Instâ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.

Fluxo de tráfego de conexão virtual

Fluxo de tráfego quando ambos os túneis estão ativos

Instância dedicada - Conexão virtual

Esta imagem ilustra uma arquitetura de rede Virtual Connect, detalhando o fluxo de tráfego quando os túneis primário e secundário estão operacionais.

Representa um modelo de conectividade ativa para um cliente acessar aplicativos UC hospedados nos datacenters da Cisco, aproveitando a conectividade dupla GRE/IPSEC túneis pela internet com BGP para troca de rotas.

Definições:

  • Premissa do Cliente:
    • Isso representa a rede local do cliente, onde os usuários e seus dispositivos (por exemplo, telefones IP, computadores executando clientes UC) estão localizados.
    • O tráfego originado daqui precisa chegar aos aplicativos UC hospedados nos datacenters da Cisco.
  • Datacenters de instância dedicada do Cisco Webex Calling (Instância dedicada) (WxC-DI DC-A e WxC-DI DC-B):
    • Esses são os datacenters da Cisco que hospedam os aplicativos UC.
    • DC-A e DC-B são geograficamente distintos, fornecendo redundância.
    • Cada datacenter tem sua própria sub-rede para aplicativos UC:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Túneis (Túnel 1 e Túnel 2):
    • Essas são as conexões seguras e criptografadas entre as instalações do cliente e o datacenter da Cisco pela Internet pública.
    • GRE (Encapsulamento de Roteamento Genérico): Este protocolo é usado para encapsular vários protocolos da camada de rede dentro de links virtuais ponto a ponto. Ele permite que protocolos de roteamento como BGP operem no túnel.
    • IPsec (Segurança do Protocolo de Internet): Este conjunto de protocolos fornece serviços de segurança criptográfica (autenticação, integridade, confidencialidade) para comunicações IP. Ele criptografa o tráfego encapsulado em GRE, garantindo a transmissão segura de dados pela Internet.
  • Protocolo de Gateway de Borda (BGP):
    • BGP é o protocolo de roteamento usado para trocar informações de roteamento entre as instalações do cliente e os datacenters da Cisco.

Conforme mostrado no diagrama acima, os dispositivos implantados nas instalações do cliente precisam estabelecer dois GRE/IPSEC túneis.

As convenções de nomenclatura usadas abaixo com XX / YY, DC-A e DC-B são genéricos para todas as regiões onde a Instância Dedicada é oferecida. Esses valores serão exclusivos para cada região e os valores reais para cada região. Os valores específicos são fornecidos durante a ativação da conexão virtual.

Do lado da Cisco, os túneis IPSec e GRE serão encerrados em dispositivos diferentes. Portanto, o cliente precisa configurar os IPs de destino IPSec e GRE nos dispositivos adequadamente. Os clientes podem usar o mesmo IP para GRE e IPSEC se ele for suportado em seus dispositivos. Consulte o diagrama acima. Os valores relacionados ao IP são fornecidos durante a ativação da conexão virtual no portal.

  • Túnel 1: Conecta as instalações do cliente à "Instância Dedicada DC-A" (Data Center A) via Internet. Este túnel usa BGP AS:64XX1 do lado do cliente e BGP AS:64XX2 no lado DC-A da Instância Dedicada. As configurações de origem do túnel IPSEC e GRE são divididas entre detalhes fornecidos pelo cliente e pela Cisco.
  • Túnel 2: Conecta as instalações do cliente à "Instância Dedicada DC-B" (Data Center B) via Internet. Este túnel usa BGP AS:64YY1 do lado do cliente e BGP AS:64YY2 no lado DC-B da Instância Dedicada. Assim como o Túnel 1, as configurações de origem do túnel IPSEC e GRE são compartilhadas entre o cliente e a Cisco.

Em BGP AS:64XX e BGP AS:64YY, XX e YY são específicos de uma região particular.

Uma vez que o GRE/IPSEC túneis são estabelecidos para datacenters de instância dedicada do Webex Calling (A e B), o cliente deve receber as seguintes rotas anunciadas pela Cisco nas sessões BGP correspondentes.

  • Para DC-A: As rotas anunciadas pela Cisco serão X.X.X.0/25 e X.X.x.0/24. Opcionalmente, se o IaaS for solicitado e configurado para as rotas do cliente Y.Y.Y.0/25 e Y.Y.Y.0/24 será anunciado pela Cisco.
  • Para DC-B: As rotas anunciadas pela Cisco serão X.X.X.128/25 e X.X.x.0/24. Opcionalmente, se o IaaS for solicitado e configurado para as rotas do cliente Y.Y.Y.128/25 e Y.Y.Y.0/24 será anunciado pela Cisco.
  • O cliente precisa anunciar o 0.0.0./0 rota para a Cisco através de ambas as conexões (túneis)
  • O cliente deve seguir o prefixo mais longo (/25) rotas para enviar tráfego para a Cisco através dos respectivos túneis quando ambos os túneis estiverem ativos.
  • A Cisco retornará o tráfego pelos mesmos túneis para manter o tráfego simétrico.

Fluxo de tráfego:

  • Tráfego destinado a "DC-A UC Apps" (X.X.X.0/25) das instalações do cliente flui através do Túnel 1.
  • Tráfego destinado a "DC-B UC Apps" (X.X.X.128/25) das instalações do cliente flui através do Túnel 2.

Cenário de failover : fluxo de tráfego quando um dos túneis está inoperante

Instância dedicada - Conexão virtual

Conforme mostrado no diagrama acima, quando o túnel para DC-A estiver inativo, o BGP estabelecido através do túnel para DC-A ficará inativo.

Impacto no BGP: Quando o Túnel 1 cair, a sessão BGP sobre esse túnel também cairá. Consequentemente, a DC-A não poderá mais anunciar suas rotas (especificamente X.X.X.0/25) para o cliente por esse caminho. Portanto, o roteador do cliente detectará o caminho como inacessível.

Agora que o Túnel 1 está inativo, o roteador do cliente nas instalações do cliente removerá automaticamente as rotas aprendidas pelo Túnel 1 de sua tabela de roteamento ou as marcará como inacessíveis.

  • Tráfego destinado à UC App Network (X.X.X.0/24) ou a sub-rede DC-A (X.X.X.0/25) será então redirecionado através do túnel de trabalho em direção a DC-B, que continua a anunciar o X.X.X.0/24 que inclui o X.X.X.0/25 rede.
  • Comportamento semelhante será observado se o túnel para DC-B estiver inativo enquanto o túnel para DC-A ainda estiver ativo.

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 de 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 visualizá-las no Control Hub clicando em Exibir configurações em Control Hub, Chamadas > Instâ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 do lado 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, não haverá início de uma segunda fase IPsec. Primeiro, emita o comando "show crypto ikev2 sa" (em equipamentos Cisco) ou comando similar em equipamentos 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:

  • 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 ponto de extremidade do túnel IPsec da instância dedicada.

  • Os parâmetros da sessão IKEv2 não correspondem entre o lado da Instância Dedicada e o lado do cliente.

  • Um firewall está bloqueando os pacotes UDP IKEv2.

Primeiro, verifique os logs do IPsec em busca de mensagens que mostrem o progresso da negociação do túnel IKEv2. Os logs 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 na negociação IKEv2 são:

  • As configurações do IKEv2 no lado do CPE não correspondem às do lado da Cisco, verifique novamente as configurações mencionadas:

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

    • Verifique se os parâmetros Criptografia e Autenticação correspondem à criptografia esperada no lado da Instâ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 NULL.

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

    • Verifique o grupo de módulos de Diffie Hellman.

    • Verifique as configurações da função pseudoaleatória.

  • 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 específica para o protocolo "GRE" e o protocolo "IP" não funcionará.

Se as mensagens de log não mostrarem nenhuma atividade de negociação para a fase IKEv2, poderá ser necessária uma captura de pacotes.

O lado da Instância Dedicada nem sempre inicia 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 iniciação de sessão IKEv2:

  • Verifique se há uma lista de acesso criptográfico IPsec para tráfego GRE (protocolo 50) do IP de transporte do túnel CPE para o IP de transporte do túnel da instância dedicada.

  • Certifique-se de que a interface do túnel GRE esteja habilitada para keepalives GRE. Se o equipamento não oferecer suporte a keepalives GRE, a Cisco será notificada, pois os keepalives GRE serão habilitados no lado da Instância Dedicada por padrão.

  • Certifique-se de que o BGP esteja habilitado e configurado com o endereço vizinho do IP do túnel da Instância Dedicada.

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

  • Keepalives GRE da interface do túnel GRE do lado do CPE para a interface do túnel GRE do lado da instância dedicada.

  • Sessão TCP do vizinho BGP do vizinho BGP do lado do CPE para o vizinho BGP do lado da Instância Dedicada.

  • Faça ping do endereço IP do túnel do lado do CPE para o endereço IP do túnel do lado da instância dedicada.

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

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

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

O datacenter da instância dedicada nem sempre inicia o primeiro pacote IKEv2. O requisito é que o dispositivo CPE seja capaz de iniciar o primeiro pacote IKEv2 em direção ao lado da Instância Dedicada.

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

Alguns firewalls e equipamentos de internet podem não permitir o rastreamento de rotas.

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

Verifique se a primeira fase do IPsec (ou seja, a 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 alguns segundos e se não está saltando. O tempo de atividade da sessão é exibido como "Tempo ativo" da sessão ou equivalente na saída.

Depois que a sessão IKEv2 for verificada como 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 logs do IPsec em busca de mensagens de erro ou erros de negociação.

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

As configurações no lado do CPE não correspondem ao lado da Instância Dedicada, verifique novamente as configurações:

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

  • Verifique as configurações do Perfect Forward Secrecy e se as configurações correspondem no lado da Instância Dedicada.

  • Verifique as configurações de tempo de vida.

  • Verifique se o IPsec foi configurado no modo 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 conseguem fluir entre os pontos finais da instância dedicada e do túnel CPE. Se a interface do túnel não estiver mostrando o status, alguns problemas comuns são:

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

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

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

    Se os keepalives não forem suportados no equipamento CPE, a Cisco deverá ser notificada para que os keepalives padrão no lado da Instância Dedicada também sejam desabilitados.

    Se keepalives forem suportados, verifique se eles estão habilitados.

  • A máscara ou endereço IP da interface do túnel não está correto e não corresponde aos valores esperados da Instâ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 Instâ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 com a interface do túnel remoto está boa. 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 criptográfico para o túnel IPsec que transporta o tráfego do túnel GRE permite que somente pacotes GRE passem. Como resultado, os pings não funcionarão do IP de transporte do túnel para o IP de transporte do 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 pacote pode ser necessária para garantir que o ping ICMP esteja resultando 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 sendo incrementados.

Além do tráfego de ping, a captura também deve mostrar pacotes GRE keepalive mesmo durante tráfego ocioso. Por fim, se o BGP estiver configurado, os pacotes keepalive do BGP também deverão ser enviados como pacotes GRE encapsulados em pacotes IPSEC pela VPN.

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

Sessões BGP

O BGP é necessário como protocolo de roteamento no túnel VPN IPsec. O vizinho BGP local deve estabelecer uma sessão eBGP com o vizinho BGP da instância dedicada. Os endereços IP 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 Instância Dedicada e se a rota padrão correta está sendo enviada para a Instância Dedicada.

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

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

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

  • O número do AS local não corresponde ao que o lado da Instância Dedicada está esperando. Verifique se o número do AS local corresponde aos parâmetros esperados da Instância Dedicada.

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

  • O IP do 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 Instância Dedicada.

A solução VPN de instância dedicada espera que dois túneis sejam estabelecidos a partir do customer/partner lado. O primeiro túnel aponta para o datacenter da instância dedicada A e o segundo túnel aponta para o datacenter da instância dedicada B. Ambos os túneis devem estar em estado ativo e a solução requer um active/active Implantação. Cada datacenter de instância dedicada anunciará seu local /25 rota, bem como uma /24 rota de backup. Ao verificar as rotas BGP de entrada da Instância Dedicada, certifique-se de que a sessão BGP associada ao túnel que aponta para o datacenter A da Instância Dedicada receba o datacenter A da Instância Dedicada. /25 rota local, bem como a /24 rota de backup. Além disso, certifique-se de que o túnel que aponta para o datacenter da instância dedicada B receba o datacenter da instância dedicada B /25 rota local, bem como a /24 rota de backup. Observe que o /24 a rota de backup será a mesma rota anunciada a partir do datacenter da instância dedicada A e do datacenter da instância dedicada B.

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

É importante que, quando ambos os túneis estiverem ativos, o túnel do datacenter A não seja usado para enviar tráfego para o datacenter B e vice-versa. Neste cenário, se o tráfego for enviado para o datacenter A com destino ao datacenter B, o datacenter A encaminhará o tráfego para o datacenter B e, então, o datacenter B tentará enviar o tráfego de volta para a origem por meio do túnel do datacenter B. Isso resultará em roteamento abaixo do ideal e também poderá interromper o tráfego que passa pelos firewalls. Portanto, é importante que ambos os túneis estejam em um active/active configuração durante a operação normal.

O 0.0.0.0/0 a rota deve ser anunciada do lado do cliente para o lado do datacenter da instância dedicada. Rotas mais específicas não serão aceitas pelo lado da Instância Dedicada. Assegurar que o 0.0.0.0/0 a rota é anunciada tanto no túnel do datacenter A da instância dedicada quanto no túnel do datacenter B da instância dedicada.

Configuração de MTU

No lado da Instância Dedicada, dois recursos são habilitados para ajustar dinamicamente a MTU para tamanhos grandes de pacotes. O túnel GRE adiciona mais cabeçalhos aos pacotes IP que fluem pela sessão VPN. O túnel IPsec adiciona cabeçalhos adicionais sobre os cabeçalhos GRE, o que reduzirá ainda mais a maior MTU permitida no túnel.

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