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.

É 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.

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.

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.

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.

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.

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 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.