Virtual Connect maakt gebruik van een headend-architectuur met twee niveaus, waarbij de routerings- en GRE-besturingsvlakken worden verzorgd door het ene apparaat en het IPsec-controlevlak door een ander apparaat.

Na voltooiing van de Virtual Connect-connectiviteit worden twee GRE-over-IPsec-tunnels gecreëerd tussen het bedrijfsnetwerk van de klant en de datacenters van Dedicated Instance Cisco. Eén voor elk redundant datacenter in de betreffende regio. Aanvullende netwerkelementen die nodig zijn voor de peering worden door de partner of klant aan Cisco uitgewisseld via het Control Hub Virtual Connect-activeringsformulier.

De onderstaande afbeelding toont het voorbeeld van het virtual connect-implementatiemodel voor de optie met twee concentrators aan de kant van de klant.

Virtual Connect - VPN is een Hub-ontwerp waarbij de Hub-sites van de klant verbonden zijn met DC1 en DC2 van de datacenters van Dedicated Instance in een bepaalde regio.

Twee Hub-sites worden aanbevolen voor betere redundantie, maar één Hub-site met twee tunnels is ook een ondersteund implementatiemodel.

Van de partners wordt verwacht dat ze nauw samenwerken met de klanten om ervoor te zorgen dat het meest optimale pad wordt gekozen voor de Virtual Connect-serviceregio.

De onderstaande afbeelding toont de peering-regio's voor cloudconnectiviteit van Dedicated Instance.

De add-on Routing for Virtual Connect wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen Dedicated Instance en de Customer Premise Equipment (CPE). Cisco maakt voor elke redundante DC binnen een regio reclame voor hun respectieve netwerk bij de CPE van de klant en de CPE is verplicht om reclame te maken voor een standaardroute naar Cisco.

• Cisco onderhoudt en wijst toe

  • IP-adressering van de tunnelinterface (tijdelijke link voor routering) die Cisco toewijst vanuit een aangewezen gedeelde adresruimte (niet openbaar routeerbaar)

  • Adres van bestemming voor tunnelvervoer (aan de kant van Cisco)

  • Nummers van particuliere autonome systemen (ASN's) voor de configuratie van BGP-routering van klanten

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

• eBGP wordt gebruikt om routes uit te wisselen tussen Dedicated Instance en CPE

  • Cisco zal het toegewezen /24-netwerk opsplitsen in 2/25 netwerken voor elke DC in de betreffende regio

  • In Virtual Connect wordt elk /25-netwerk door Cisco teruggeadverteerd naar CPE via de respectieve point-to-point VPN-tunnels (tijdelijke link)

  • CPE moet worden geconfigureerd met de juiste eBGP-buren. Als u één CPE gebruikt, worden twee eBGP-buren gebruikt, waarvan één naar elke afgelegen tunnel wijst. Als u twee CPE gebruikt, dan heeft elke CPE één eBGP-buur die naar de enkele afgelegen tunnel voor de CPE wijst.

  • De Cisco-kant van elke GRE-tunnel (tunnelinterface-IP) is geconfigureerd als de BGP-buur op de CPE

  • CPE is vereist om reclame te maken voor een standaardroute over elk van de tunnels

  • CPE is verantwoordelijk voor de herverdeling, indien nodig, van de geleerde routes binnen het bedrijfsnetwerk van de klant.

• Als de verbinding niet uitvalt, heeft één CPE twee actieve/actieve tunnels. Voor twee CPE-knooppunten moet elke CPE één actieve tunnel hebben en moeten beide CPE-knooppunten actief zijn en verkeer passeren. Als er geen storing is, moet het verkeer zich in twee tunnels splitsen die naar de juiste /25 bestemmingen gaan. Als een van de tunnels naar beneden gaat, kan de overblijvende tunnel het verkeer voor beide bestemmingen vervoeren. In zo'n storingsscenario wordt, wanneer het /25-netwerk uitvalt, het /24-netwerk gebruikt als reserveroute. Cisco stuurt klantenverkeer via zijn interne WAN naar het DC, waardoor de verbinding is verbroken.

De IPsec-tunnelonderhandeling bestaat uit twee fasen, de IKEv2-fase en de IPsec-fase. Als de onderhandeling over de IKEv2-fase niet is voltooid, dan is er geen start van een tweede IPsec-fase. Voer eerst de opdracht „show crypto ikev2 sa” uit (op Cisco-apparatuur) of een soortgelijke opdracht op apparatuur van derden om te controleren of de IKEv2-sessie actief is. Als de IKEv2-sessie niet actief is, kunnen de volgende redenen zijn:

• Interessant verkeer activeert de IPsec-tunnel niet.

• De toegangslijst voor de IPsec-tunnel is verkeerd geconfigureerd.

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

• De IKEv2-sessieparameters komen niet overeen tussen de kant van de Dedicated Instance en de kant van de klant.

• Een firewall blokkeert de IKEv2 UDP-pakketten.

Controleer eerst in de IPsec-logboeken of er berichten zijn 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 er ook op wijzen dat de IKEv2-sessie niet wordt geactiveerd.

Enkele veelgemaakte fouten bij de IKEv2-onderhandelingen zijn:

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

  • Controleer of de IKE-versie versie 2 is.

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

    Wanneer het „GCM” -cijfer in gebruik is, zorgt het GCM-protocol voor de authenticatie en wordt de authenticatieparameter ingesteld op NULL.

  • Controleer de levensduurinstelling.

  • Controleer de Diffie Hellman-modulusgroep.

  • Controleer de instellingen van de Pseudo Random Function.

• De toegangslijst voor de cryptokaart is niet ingesteld op:

  • GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" toestaan (of een gelijkwaardige opdracht)

    De toegangslijst moet specifiek voor het „GRE” -protocol zijn en het „IP” -protocol zal niet werken.

Als in de logberichten geen onderhandelingsactiviteiten voor de IKEv2-fase worden weergegeven, dan is het mogelijk dat er pakketten moeten worden vastgelegd.

Als de configuratie correct is ingesteld, beginnen de IPsec-tunnel en de IKEv2-onderhandeling in de eerste fase:

• GRE blijft bestaan van de GRE-tunnelinterface aan de CPE-zijde naar de GRE-tunnelinterface aan de kant van de Dedicated Instance.

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

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

  Ping mag niet het IP-adres van tunneltransport naar het IP-adres voor tunneltransport zijn, het moet van tunnel-IP naar tunnel-IP zijn.

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

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

Controleer of de eerste fase van IPsec (dat wil zeggen de IKEv2-beveiligingsassociatie) actief is voordat u problemen oplost met de tweede fase van IPsec. Voer een opdracht „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 dat deze niet stuitert. De uptime van de sessie wordt weergegeven als „Active Time” van de sessie of een equivalent in de uitvoer.

Zodra de IKEv2-sessie is geverifieerd en actief is, moet u de IPsec-sessie onderzoeken. Voer, net als bij de IKEv2-sessie, een opdracht „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 kunnen optreden tijdens de IPsec-onderhandelingen zijn:

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

• Controleer of de parameters voor versleuteling en authenticatie overeenkomen met de instellingen aan de kant van de Dedicated Instance.

• Controleer of de instellingen van Perfect Forward Secrecy overeenkomen met de instellingen aan de kant van de Dedicated Instance.

• Controleer de instellingen voor de levensduur.

• Controleer of IPsec in tunnelmodus is geconfigureerd.

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

Wanneer wordt geverifieerd dat de IPsec- en IKEv2-sessies actief zijn, kunnen de keepalive-pakketten van de GRE-tunnel tussen de eindpunten van de Dedicated Instance en de CPE-tunnel stromen. Als de status van de tunnelinterface niet wordt weergegeven, zijn enkele veelvoorkomende problemen:

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

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

• Keepalives zijn niet ingeschakeld op de zijtunnelinterface van de CPE.

  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 de Dedicated Instance ook worden uitgeschakeld.

  Als keepalives worden ondersteund, controleer dan of de keepalives 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 transportadres van de bron- of bestemmingstunnel is niet correct en komt niet overeen met de verwachte waarden voor de Dedicated Instance.

• Een firewall voorkomt dat GRE-pakketten naar de IPsec-tunnel worden gestuurd of via de IPsec-tunnel worden ontvangen (de GRE-tunnel wordt via de IPsec-tunnel getransporteerd)

Een ping-test moet verifiëren dat de lokale tunnelinterface actief is en dat de verbinding met de externe tunnelinterface goed is. Voer de ping-controle uit van het IP-adres van de tunnel (niet het IP-adres voor transport) naar het IP-adres van de tunnel op afstand.

De ping-controle resulteert in een GRE-pakket dat wordt gegenereerd op basis van het IP-adres voor het transport van de brontunnel naar het IP-adres van het doeltunneltransport, terwijl de lading van het GRE-pakket (het interne IP-adres) het IP-adres van de bron- en doeltunnel is.

Als de ping-test niet succesvol is en de voorgaande items zijn geverifieerd, kan een pakketopname nodig zijn om er zeker van te zijn dat de icmp-ping resulteert in een GRE-pakket dat vervolgens wordt ingekapseld in een IPsec-pakket en vervolgens wordt verzonden van het IP-bron-adres naar het IPsec-adres van de bestemming. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om aan te geven of het aantal verzend- en ontvangstpakketten toeneemt.

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

Aan de kant van de Dedicated Instance zijn twee functies mogelijk om de MTU dynamisch aan te passen voor grote pakketgroottes. De GRE-tunnel voegt meer headers toe aan de IP-pakketten die door de VPN-sessie stromen. De IPsec-tunnel voegt extra headers toe aan de GRE-headers om de maximale MTU die over de tunnel is toegestaan nog verder te verlagen.

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