O Virtual Connect usa uma arquitetura de cabeçalho de camada dupla, onde os planos de controle de roteamento e GRE são fornecidos por um dispositivo e o plano de controle IPSec é fornecido por outro.

Após a conclusão da conectividade Virtual Connect , dois túneis GRE através de IPSec serão criados entre a rede corporativa do cliente e os datacenters da Cisco de ocorrência dedicada. Um para cada centro de dados redundante na respectiva Região. Os elementos de rede adicionais necessários para o emparelhamento são trocados pelo Parceiro ou Cliente pela Cisco por meio do formulário de ativação do Control Hub Virtual Connect.

A Figura 1 mostra um exemplo do modelo de implantação do Virtual Connect para a opção de 2 concentradores no lado do cliente.

Virtual Connect - VPN é um design de Hub, onde os sites do Hub do cliente estão conectados ao DC1 e DC2 dos datacenters da Ocorrência dedicada dentro de uma determinada região.

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

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

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

Espera-se 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 de emparelhamento de conectividade em nuvem da ocorrência dedicada.

O roteamento para o complemento do Virtual Connect é implementado usando BGP externo (eBGP) entre a Ocorrência dedicada e o equipamento local do cliente (CPE). A Cisco anunciará sua respectiva rede para cada CC redundante em 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ço IP da interface do túnel (link transitório para roteamento) que a Cisco atribui de um espaço de endereço compartilhado designado (não roteável publicamente)

  • Endereço de desitinação de transporte do túnel (lado da Cisco)

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

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

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

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

  • No Virtual Connect, cada rede /25 é anunciada de volta ao CPE pela Cisco sobre os 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, então cada CPE terá um vizinho eBGP ponderando para o único túnel remoto para o CPE.

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

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

  • O CPE é responsável pela redistribuição, conforme necessário, das rotas aprendidas na rede corporativa do cliente.

• Sob condição de falha de conexão de não falha, um único CPE terá dois túneis ativos/ativos. Para dois nós CPE, cada CPE terá um túnel ativo e ambos os nós CPE devem estar ativos e passando o tráfego. Sob o cenário de não falha, o tráfego deve dividir em dois túneis indo para os destinos corretos /25, se um dos túneis cair, o túnel restante pode transportar o tráfego para ambos. Em um cenário de falha, quando a rede /25 está inativa, a rede /24 é usada como uma rota de backup. A Cisco enviará o tráfego do cliente por meio de sua WAN interna para o DC, o 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 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.

Verifique se a primeira fase do IPsec (ou seja, associação de segurança IKEv2) está ativa antes de solucionar os 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.

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.

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.