Virtual Connect maakt gebruik van een headend-architectuur van een dubbele laag, waarbij de routering en GRE-besturing door het ene apparaat worden geleverd en het IPSec-besturingsmodel door een ander apparaat wordt geleverd.

Nadat de Virtual Connect-verbinding is voltooid, wordt twee GRE over IPSec-verbinding gemaakt tussen het bedrijfsnetwerk van de klant en de datacenters van Cisco. Een voor elk redundant datacenter binnen de respectievelijke regio. Aanvullende netwerkelementen die vereist zijn voor peering, worden door de partner of klant uitgewisseld aan Cisco via het Control Hub Virtual Connect-activeringsformulier.

De onderstaande afbeelding toont een voorbeeld van het implementatiemodel voor virtuele verbinding voor de optie met 2 concentratoren aan de kant van de klant.

Virtuele verbinding : VPN is een hub-ontwerp, waarbij de hub-sites van de klant zijn verbonden met DC1 en DC2 van de datacenters van een speciale instantie binnen een bepaalde regio.

Two Hub-sites worden aanbevolen voor een betere redundantie, maar One Hub-site met twee hub-sites is ook een ondersteund implementatiemodel.

Van partners wordt verwacht dat zij nauw samenwerken met de klanten en ervoor zorgen dat het meest optimale pad wordt gekozen voor de serviceregio van Virtual Connect.

De onderstaande afbeelding toont de cloudconnectiviteitspeeringregio's van de Dedicated Instance.

Routering voor de virtual Connect-invoegkoppeling wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen speciale instantie en de CPE (Customer Premise Equipment). Cisco zal hun respectievelijke netwerk voor elk redundante DC binnen een regio adverteren in de CPE van de klant en de CPE is vereist om een standaardroute naar Cisco te adverteren.

• Cisco onderhoudt en wijst

  • Tunnel Interface IP-adressering (tijdelijke koppeling voor routering) Die Cisco toewijst vanuit een toegewezen gedeelde adresruimte (niet-openbaar omleidingsbaar)

  • Tunnel transportdeitiatieadres (aan de kant van Cisco)

  • Privé zelfstandige systeemnummers (ASN's) voor BGP-routeringsconfiguratie klant

    • Cisco wijst toe vanuit het toegewezen bereik voor privégebruik: 64512 tot en met 65534

• eBGP gebruikt om routes uit te wisselen tussen speciale instantie en CPE

  • Cisco zal het toegewezen /24-netwerk opsplitsen in 2 /25 een voor elk DC in de respectievelijke regio

  • In Virtual Connect wordt elk /25-netwerk via de respectievelijk point-to-point VPN - (tijdelijke koppeling) geadverteerd naar CPE door Cisco

  • CPE moet worden geconfigureerd met de juiste eBGP-naburigen. Als u één CPE gebruikt, worden twee eBGP-naburigen gebruikt, een die naar elke externe tunnel wijst. Als u twee CPE gebruikt, heeft elke CPE één eBGP-naburige gebruikers die werken met de enkele externe tunnel voor de CPE.

  • Cisco-zijde van elke GRE-tunnel (tunnel interface IP) wordt geconfigureerd als de BGP-neighbor op de CPE

  • CPE is vereist om een standaardroute te adverteren over elk van de

  • CPE kan indien nodig opnieuw worden verdeeld over de geleerde routes binnen het bedrijfsnetwerk van de netwerkbeheerder.

• Als de koppeling niet mislukt, heeft één CPE twee actieve/actieve gebruikers. Voor twee CPE-knooppunten heeft elke CPE één actieve tunnel en moeten beide CPE-knooppunten actief zijn en doorgevend verkeer. Bij een niet-storingsscenario moet het verkeer in twee delen als deze naar de juiste /25-bestemmingen gaat. Als een van de tunnel uitgaat, kan de resterende tunnel het verkeer voor beide uitvoeren. Bij een dergelijk storingsscenario wordt het /25-netwerk gebruikt als back-uproute als het /25-netwerk defect is. Cisco zal klantverkeer via de interne WAN naar de DC sturen, waardoor de verbinding is verloren.

De IPsec-tunnelonderhandeling bestaat uit twee fasen: de IKEv2-fase en de IPsec-fase. Als de IKEv2-faseonderhandeling niet wordt voltooid, wordt er geen tweede IPsec-fase gestart. Geef eerst de opdracht "show crypto ikev2 sa" (op Cisco-apparatuur) of een vergelijkbare opdracht op de apparatuur van derden om te controleren of de IKEv2-sessie actief is. Als de IKEv2-sessie niet actief is, kunnen de volgende oorzaken optreden:

• Interessant verkeer activeert de IPsec-tunnel niet.

• De IPsec-tunneltoegangslijst is verkeerd geconfigureerd.

• Er is geen connectiviteit tussen de klant en het IPsec-tunneleindpunt van de Dedicated Instance.

• De IKEv2-sessieparameters komen niet overeen tussen de Dedicated Instance-zijde en de klantzijde.

• Een firewall blokkeert de IKEv2 UDP-pakketten.

Controleer eerst de IPsec-logboeken op berichten die de voortgang van de IKEv2-tunnelonderhandeling weergeven. De logboeken kunnen aangeven of er een probleem is met de IKEv2-onderhandeling. Als er geen logberichten worden weergegeven, kan dat er ook op duiden dat de IKEv2-sessie niet wordt geactiveerd.

Enkele veelvoorkomende fouten bij IKEv2-onderhandeling zijn:

• De instellingen voor IKEv2 aan de CPE-zijde komen niet overeen met de Cisco-zijde. Controleer de genoemde instellingen opnieuw:

  • Controleer of de IKE-versie versie 2 is.

  • Controleer of de parameters Versleuteling en Authenticatie overeenkomen met de verwachte versleuteling aan de kant van de Dedicated Instance.

    Wanneer de "GCM"-codering wordt gebruikt, verwerkt het GCM-protocol de authenticatie en wordt de authenticatieparameter ingesteld op NULL.

  • Controleer de levensduurinstelling.

  • Controleer de Diffie-Hellman-modulusgroep.

  • Controleer de instellingen van de pseudo-willekeurige functie.

• De toegangslijst voor de cryptokaart is niet ingesteld op:

  • Vergunning GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (of gelijkwaardig commando)

    De toegangslijst moet specifiek bedoeld zijn voor het "GRE"-protocol; het "IP"-protocol zal niet werken.

Als de logberichten geen onderhandelingsactiviteit voor de IKEv2-fase aangeven, is mogelijk een pakketregistratie nodig.

Als het goed is geconfigureerd, start het volgende de IPsec-tunnel en de eerste fase van de IKEv2-onderhandeling:

• GRE keepalives van de GRE-tunnelinterface aan de CPE-zijde naar de GRE-tunnelinterface aan de Dedicated Instance-zijde.

• BGP-buur TCP-sessie van de BGP-buur aan de CPE-zijde naar de BGP-buur aan de Dedicated Instance-zijde.

• Ping vanaf het IP-adres van de CPE-zijtunnel naar het IP-adres van de Dedicated Instance-zijtunnel.

  Ping kan niet van tunneltransport-IP naar tunneltransport-IP zijn, maar moet van tunnel-IP naar tunnel-IP zijn.

Als er een pakkettracering nodig is voor het IKEv2-verkeer, stelt u het filter in voor UDP en poort 500 (wanneer er zich geen NAT-apparaat in het midden van de IPsec-eindpunten bevindt) of poort 4500 (wanneer er zich een NAT-apparaat in het midden van de IPsec-eindpunten bevindt).

Controleer of IKEv2 UDP-pakketten met poort 500 of 4500 worden verzonden en ontvangen van en naar het DI IPsec IP-adres.

Controleer of de eerste IPsec-fase (dat wil zeggen de IKEv2-beveiligingskoppeling) actief is voordat u problemen met de tweede IPsec-fase oplost. Voer een "show crypto ikev2 sa" of een gelijkwaardige opdracht uit om de IKEv2-sessie te verifiëren. Controleer in de uitvoer of de IKEv2-sessie langer dan een paar seconden actief is en of deze niet bouncet. De sessie-uptime wordt in de uitvoer weergegeven als de 'Actieve tijd' van de sessie of een equivalent daarvan.

Zodra de IKEv2-sessie als actief wordt geverifieerd, onderzoekt u de IPsec-sessie. Voer, net als bij de IKEv2-sessie, een "show crypto ipsec sa" of een gelijkwaardige opdracht uit om de IPsec-sessie te verifiëren. Zowel de IKEv2-sessie als de IPsec-sessie moeten actief zijn voordat de GRE-tunnel tot stand wordt gebracht. Als de IPsec-sessie niet als actief wordt weergegeven, controleer dan de IPsec-logboeken op foutmeldingen of onderhandelingsfouten.

Enkele van de meest voorkomende problemen die zich tijdens IPsec-onderhandelingen kunnen voordoen, zijn:

De instellingen aan de CPE-zijde komen niet overeen met de Dedicated Instance-zijde. Controleer de instellingen opnieuw:

• Controleer of de parameters voor Versleuteling en Authenticatie overeenkomen met de instellingen op de Dedicated Instance-zijde.

• Controleer de Perfect Forward Secrecy-instellingen en of de instellingen op de Dedicated Instance-zijde overeenkomen.

• Controleer de levensduurinstellingen.

• Controleer of de IPsec in de tunnelmodus is geconfigureerd.

• Controleer de bron- en bestemmings-IPsec-adressen.

Zodra de IPsec- en IKEv2-sessies als actief worden geverifieerd, zorgt de GRE-tunnel ervoor dat pakketten tussen de Dedicated Instance en de CPE-tunnel-eindpunten kunnen worden uitgewisseld. Als de tunnelinterface de status niet weergeeft, kunnen de volgende problemen optreden:

• De VRF van het tunnelinterfacetransport komt niet overeen met de VRF van de loopbackinterface (als de VRF-configuratie op de tunnelinterface wordt gebruikt).

  Als de VRF-configuratie niet op de tunnelinterface wordt gebruikt, kan deze controle worden genegeerd.

• Keepalives zijn niet ingeschakeld op de CPE-zijtunnelinterface

  Als keepalives niet worden ondersteund op de CPE-apparatuur, moet Cisco hiervan op de hoogte worden gesteld, zodat de standaard keepalives aan de Dedicated Instance-zijde ook worden uitgeschakeld.

  Als keepalives worden ondersteund, controleer dan of deze zijn ingeschakeld.

• Het masker of IP-adres van de tunnelinterface is niet correct en komt niet overeen met de verwachte waarden van de Dedicated Instance.

• Het bron- of bestemmingstunneltransportadres is niet correct en komt niet overeen met de verwachte waarden van de Dedicated Instance.

• Een firewall blokkeert GRE-pakketten die naar de IPsec-tunnel worden verzonden of van de IPsec-tunnel worden ontvangen (de GRE-tunnel wordt via de IPsec-tunnel getransporteerd).

Met een pingtest kunt u controleren of de lokale tunnelinterface actief is en of de verbinding met de externe tunnelinterface goed is. Voer de pingcontrole uit van het tunnel-IP (niet het transport-IP) naar het externe tunnel-IP.

De pingcontrole resulteert in een GRE-pakket dat wordt gegenereerd van het bron-tunneltransport-IP naar het bestemmings-tunneltransport-IP, terwijl de payload van het GRE-pakket (het interne IP) het bron- en bestemmings-tunnel-IP zal zijn.

Als de pingtest niet succesvol is en de voorgaande items worden geverifieerd, kan een pakketvastlegging nodig zijn om te garanderen dat de ICMP-ping resulteert in een GRE-pakket. Dit pakket wordt vervolgens ingekapseld in een IPsec-pakket en vervolgens verzonden van het bron-IPsec-adres naar het bestemmings-IPsec-adres. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om aan te geven of de verzonden en ontvangen pakketten toenemen.

Naast het pingverkeer moeten in de vastlegging ook keepalive GRE-pakketten worden weergegeven, zelfs tijdens inactief verkeer. Als BGP is geconfigureerd, moeten BGP keepalive-pakketten ook als GRE-pakketten, ingekapseld in IPSEC-pakketten, via de VPN worden verzonden.

Aan de Dedicated Instance-zijde zijn twee functies ingeschakeld om de MTU dynamisch aan te passen voor grote pakketgroottes. De GRE-tunnel voegt meer headers toe aan de IP-pakketten die via de VPN-sessie stromen. De IPsec-tunnel voegt extra headers toe bovenop de GRE-headers en verlaagt zo de grootste MTU die via de tunnel is toegestaan.

De GRE-tunnel past de MSS-functie en het GRE-tunnelpad aan in de MTU-detectiefunctie is ingeschakeld aan de kant van de Dedicated Instance. Configureer "ip tcp adjust-mss 1350" of een gelijkwaardige opdracht, evenals "tunnel path\u0002mtu-discovery" of een gelijkwaardige opdracht aan de kant van de klant om te helpen bij het dynamisch aanpassen van de MTU van het verkeer via de VPN-tunnel.