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 het voorbeeld van het Virtual Connect-implementatiemodel voor de optie 2-concentrator aan de klantzijde.

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 ze nauw samenwerken met de klanten en ervoor zorgen dat het meest optimale pad wordt gekozen voor de Virtual Connect -serviceregio.

De onderstaande afbeelding toont de peering-regio's voor cloudconnectiviteit van het toegewezen exemplaar.

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 onderhandelingen over de IKEv2-fase niet voltooid zijn, 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 uit om te verifiëren of de IKEv2-sessie actief is. Als de IKEv2-sessie niet actief is, kunnen de mogelijke redenen zijn:

• Interessant verkeer activeert de IPsec-tunnel niet.

• De toegangslijst voor IPsec-tunnel is onjuist geconfigureerd.

• Er is geen verbinding tussen de klant en het eindpunt van de IPsec-tunnel van het toegewezen exemplaar.

• De parameters van de IKEv2-sessie komen niet overeen tussen de kant van het toegewezen exemplaar en de kant van de klant.

• Een firewall blokkeert de IKEv2 UDP-pakketten.

Controleer eerst de IPsec-logboeken voor berichten die de voortgang van de IKEv2-tunnelonderhandeling weergeven. De logboeken kunnen aangeven waar er een probleem is met de IKEv2-onderhandeling. Een gebrek aan logboekberichten kan ook aangeven dat de IKEv2-sessie niet wordt geactiveerd.

Enkele veelvoorkomende fouten bij de IKEv2-onderhandeling zijn:

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

  • Controleer of de IKE-versie versie 2 is.

  • Controleer of de coderings- en verificatieparameters overeenkomen met de verwachte codering aan de kant van het toegewezen exemplaar.

    Wanneer de code "GCM" wordt gebruikt, verwerkt het GCM-protocol de verificatie en stelt het de verificatieparameter in op NULL.

  • Verifieer de instelling voor de levensduur.

  • Verifieer de Diffie Hellman-modulusgroep.

  • Verifieer de instellingen voor de pseudo-willekeurige functie.

• De toegangslijst voor de crypto-toewijzing is niet ingesteld op:

  • GRE toestaan (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255' (of gelijkwaardige opdracht)

    De toegangslijst moet specifiek voor het 'GRE'-protocol zijn en het 'IP'-protocol werkt niet.

Als de logboekberichten geen onderhandelingsactiviteit voor de IKEv2-fase weergeven, is mogelijk een pakketopname nodig.

Indien correct geconfigureerd, begint het volgende de IPsec-tunnel en de IKEv2-onderhandeling in de eerste fase:

• GRE-keepalives van de GRE-tunnelinterface aan de CPE-kant naar de GRE-tunnelinterface aan de kant van het toegewezen exemplaar.

• BGP neighbor TCP-sessie van de BGP-neighbor van CPE-kant naar de BGP-neighbor van kant Dedicated Instance.

• Ping vanaf het IP-adres van de CPE-zijtunnel naar het IP-adres van de tunnel aan de zijkant van het toegewezen exemplaar.

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

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

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

Controleer of de eerste IPsec-fase (dat wil zeggen, IKEv2-beveiligingsassociatie) actief is voordat u problemen met de tweede fase van IPsec 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 al meer dan een paar seconden actief is en niet bouncen. De uptime van de sessie wordt weergegeven als de sessie 'Actieve tijd' of gelijkwaardig in uitvoer.

Zodra de IKEv2-sessie wordt gecontroleerd als actief en actief, 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, controleert u de IPsec-logboeken op foutberichten of onderhandelingsfouten.

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

De instellingen aan de CPE-kant komen niet overeen met de kant van het toegewezen exemplaar. Controleer de instellingen opnieuw:

• Controleer of de coderings- en verificatieparameters overeenkomen met de instellingen aan de kant van het toegewezen exemplaar.

• Controleer de instellingen voor Perfect Forward Secrecy (Perfect doorschakelen van geheimhouding) en of de instellingen overeenkomen aan de kant van het toegewezen exemplaar.

• Verifieer de instellingen voor de levensduur.

• Controleer of de IPsec is geconfigureerd in de tunnelmodus.

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

Wanneer de IPsec- en IKEv2-sessies worden geverifieerd als actief en actief, kunnen keepalive-pakketten voor de GRE-tunnel worden uitgevoerd tussen de eindpunten van het toegewezen exemplaar en de CPE-tunnel. Als de tunnelinterface de status niet weergeeft, zijn enkele veelvoorkomende problemen:

• Het transport-VRF van de tunnelinterface komt niet overeen met de VRF van de loopback-interface (als VRF-configuratie op de tunnelinterface wordt gebruikt).

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

• Keepalives zijn niet ingeschakeld op de CPE-tunnelinterface aan de zijkant

  Als keepalives niet worden ondersteund op de CPE-apparatuur, moet Cisco hiervan op de hoogte worden gesteld zodat de standaard keepalives aan de kant van het toegewezen exemplaar ook worden uitgeschakeld.

  Als keepalives worden ondersteund, controleert u of de keepalives zijn ingeschakeld.

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

• Het bron- of doeltunneltransportadres is onjuist en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.

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

Een ping-test moet controleren of de lokale tunnelinterface werkt en of de verbinding met de externe tunnelinterface goed is. Voer de pingcontrole uit van de tunnel-IP (niet het transport-IP) naar de externe tunnel-IP.

De ping-controle resulteert in een GRE-pakket dat wordt gegenereerd vanaf het IP van de brontunnel naar het IP van de bestemmingstunnel, terwijl de payload van het GRE-pakket (het binnenste IP) de bron- en bestemmingstunnel-IP wordt.

Als de ping-test niet slaagt en de voorgaande items zijn geverifieerd, kan een pakketopname nodig zijn om ervoor te zorgen dat de icmp ping resulteert in een GRE-pakket dat vervolgens wordt ingesloten in een IPsec-pakket en vervolgens wordt verzonden van het bron-IPsec-adres naar het bestemmings-IPsec-adres. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om weer te geven als de pakketten voor verzenden en ontvangen toenemen.

Naast het ping-verkeer moet de opname ook keepalive GRE-pakketten tonen, zelfs tijdens inactief verkeer. Tot slot, als BGP is geconfigureerd, moeten BGP keepalive-pakketten ook worden verzonden als GRE-pakketten die zijn ingesloten in IPSEC-pakketten en via de VPN.

Aan de kant van het toegewezen exemplaar zijn twee functies ingeschakeld om de MTU dynamisch aan te passen voor grote pakketgroottes. De GRE-tunnel voegt meer kopteksten toe aan de IP-pakketten die door de VPN-sessie stromen. De IPsec-tunnel voegt de extra headers toe bovenop de GRE-headers, waardoor de grootste MTU die over de tunnel is toegestaan, verder wordt verkleind.

De GRE-tunnel past de MSS-functie aan en het GRE-tunnelpad in de MTU-detectiefunctie is ingeschakeld aan de kant van het toegewezen exemplaar. Configureer "ip tcp adjust-mss 1350" of een gelijkwaardige opdracht en "tunnelpad\u0002mtu-discovery" of een gelijkwaardige opdracht aan de klantzijde om te helpen met de dynamische aanpassing van MTU van het verkeer via de VPN-tunnel.