O Virtual Connect usa uma arquitetura de headend de camada dupla, na qual os planos de roteamento e controle GRE são fornecidos por um dispositivo e o plano de controle IPsec é fornecido por outro.

Após a conclusão da conectividade do Virtual Connect, dois túneis GRE sobre IPsec serão criados entre a rede corporativa do Cliente e os datacenters da Instância Dedicada da Cisco. Um para cada datacenter redundante na respectiva região. Elementos de rede adicionais necessários para o emparelhamento são trocados pelo parceiro ou cliente com a Cisco por meio do formulário de ativação do Control Hub Virtual Connect.

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 - VPN é um design de hub, em que os sites de hub do cliente são conectados aos datacenters DC1 e DC2 da Instância Dedicada em uma região específica.

Dois sites de hub são recomendados para uma melhor redundância, mas um site de hub com dois túneis também é um modelo de implantação compatível.

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

A figura abaixo mostra as regiões de emparelhamento de conectividade de nuvem da Instância Dedicada.

O complemento de roteamento para Virtual Connect é implementado usando BGP externo (eBGP) entre a Instância Dedicada e o Equipamento Local do Cliente (CPE). A Cisco anunciará sua respectiva rede para cada DC redundante em uma região para o CPE do Cliente e o CPE deverá anunciar uma rota padrão para a Cisco.

• A Cisco mantém e atribui

  • Endereçamento IP da interface de túnel (link transitório para roteamento) que a Cisco atribui a partir de um espaço de endereço compartilhado designado (não roteável publicamente)

  • Endereço de destino do transporte em túnel (lado da Cisco)

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

    • A Cisco atribui a partir da faixa de uso privado designada: 64512 a 65534

• O eBGP usado para trocar rotas entre a instância dedicada e o CPE

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

  • No Virtual Connect, cada rede /25 é anunciada de volta ao CPE pela Cisco nos respectivos túneis VPN ponto a ponto (link transitório)

  • O CPE deve ser configurado com os vizinhos eBGP apropriados. Se estiver usando um CPE, dois vizinhos eBGP serão usados, um apontando para cada túnel remoto. Se estiver usando dois CPE, cada CPE terá um vizinho eBGP apontando para o único túnel remoto do CPE.

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

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

  • O CPE é responsável por redistribuir, conforme necessário, as rotas aprendidas na rede corporativa do cliente.

• Em condições de falha de link sem falha, um único CPE terá dois túneis ativos/ativos. Para dois nós CPE, cada CPE terá um túnel ativo e os dois nós CPE devem estar ativos e transmitir tráfego. Em um cenário sem falha, o tráfego deve ser dividido em dois túneis indo para os destinos /25 corretos. Se um dos túneis cair, o túnel restante poderá transportar o tráfego para ambos. Nesse cenário de falha, quando a rede /25 está inativa, a rede /24 é usada como uma rota de backup. A Cisco enviará tráfego de clientes por meio de sua WAN interna para o DC, que perdeu a conectividade.

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” (no equipamento Cisco) ou um comando similar 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 ao túnel IPsec está configurada incorretamente.

• Não há conectividade entre o cliente e o IP do endpoint do túnel IPsec da Instância Dedicada.

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

• Um firewall está bloqueando os pacotes UDP IKEv2.

Primeiro, verifique os registros IPsec para ver se há mensagens que mostrem 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 na negociação do IKEv2 são:

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

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

  • Verifique se os parâmetros de criptografia e autenticação correspondem à criptografia esperada no lado da instância dedicada.

    Quando a cifra “GCM” está em uso, o protocolo GCM manipula 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 da função pseudo-aleatória.

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

  • Permissão 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, talvez seja necessária uma captura de pacote.

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

• O GRE se mantém ativo 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 vizinha do BGP do vizinho BGP do lado do CPE ao vizinho do BGP do lado da Instância Dedicada.

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

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

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

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

Verifique se a primeira fase do IPsec (ou seja, a associação de segurança IKEv2) está ativa antes de solucionar o problema 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 o “Tempo ativo” da sessão ou equivalente na saída.

Depois que a sessão IKEv2 for verificada 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 for exibida como ativa, verifique se há mensagens de erro ou erros de negociação nos registros IPsec.

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 coincidem com o lado da Instância Dedicada. Verifique novamente as configurações:

• Verifique se os parâmetros de criptografia e autenticação correspondem às configurações no lado da instância dedicada.

• Verifique as configurações do Perfect Forward Secrecy e se elas correspondem às configurações do lado da Instâ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.

Quando as sessões IPsec e IKEv2 são verificadas como ativas e ativas, os pacotes do túnel GRE mantêm ativos o fluxo entre os terminais da Instância Dedicada e 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 de túnel não corresponde ao VRF da interface de loopback (se a configuração VRF for usada na interface de túnel).

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

• Keepalives não estão habilitados na interface de túnel lateral 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 desativados.

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

• A máscara ou o endereço IP da interface do túnel não estão corretos e não correspondem 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á impedindo que pacotes GRE sejam 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 com 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 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, talvez seja necessária uma captura de pacote para garantir que o ping icmp esteja resultando em um pacote GRE que é 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 de manutenção de atividade, mesmo durante o tráfego ocioso. Finalmente, se o BGP estiver configurado, os pacotes BGP keepalive também devem ser enviados como pacotes GRE encapsulados em pacotes IPSEC, bem como pela VPN.

No lado da Instância Dedicada, dois recursos são habilitados para ajustar dinamicamente a MTU para pacotes grandes. 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 aos cabeçalhos GRE e 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 é ativado no lado da Instância Dedicada. Configure “ip tcp adjust-mss 1350" ou comando equivalente, bem como “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.