Virtual Connect maakt gebruik van een dual-tier headendarchitectuur, waarbij het omleidings- en GRE-besturingsvliegtuig door één apparaat wordt geleverd en het IPSec-besturingsvliegtuig door een ander apparaat wordt geleverd.

Na voltooiing van de Virtual Connect-verbinding worden twee GRE via IPSec-tunnels gemaakt tussen het bedrijfsnetwerk van de klant en de datacenters van Dedicated Instance Cisco. Eén naar elk redundant datacenter in de respectieve regio. Aanvullende netwerkelementen die vereist zijn voor de peering worden door de partner of klant uitgewisseld met Cisco via het Control Hub Virtual Connect-activeringsformulier.

Afbeelding 1 toont een voorbeeld van het Virtual Connect-implementatiemodel voor de 2-concentratoroptie aan de kant van de klant.

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

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

De bandbreedte per tunnel is beperkt tot 250 Mbps.

De externe sites van de klant binnen dezelfde regio moeten via het WAN van de klant opnieuw verbinding maken met de Hub-site(s) en Cisco is niet verantwoordelijk voor die verbinding.

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

Afbeelding 2 toont de Dedicated Instance Cloud Connectivity-peering-regio's.

Routering voor de Virtual Connect-invoegtoepassing wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen het toegewezen exemplaar en de apparatuur op locatie van de klant (CPE). Cisco adverteert zijn of haar netwerk voor elke redundante DC binnen een regio met de CPE van de klant en de CPE is vereist om een standaardroute naar Cisco te adverteren.

• Cisco onderhoudt en wijst deze toe

  • Tunnelinterface IP-adressering (tijdelijke koppeling voor routering) Cisco wijst een toegewezen gedeelde adresruimte toe (niet openbaar routeerbaar)

  • Desitinatieadres voor tunneltransport (kant van Cisco)

  • Private autonome systeemnummers (ASN's) voor BGP-routeringsconfiguratie van klanten

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

• eBGP wordt gebruikt om routes uit te wisselen tussen toegewezen exemplaar en CPE

  • Cisco splitst het toegewezen/24-netwerk op in 2/25 voor elke DC in de betreffende regio

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

  • CPE moet worden geconfigureerd met de juiste eBGP-buren. Bij gebruik van één CPE worden twee eBGP-buren gebruikt, waarvan één naar elke externe tunnel wijst. Als u twee CPE gebruikt, heeft elke CPE één eBGP-buurman die ponteert op de enkele externe tunnel voor de CPE.

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

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

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

• Bij een niet-defecte koppeling heeft één CPE twee actieve/actieve tunnels. Voor twee CPE-knooppunten heeft elke CPE één actieve tunnel en moeten beide CPE-knooppunten actief zijn en verkeer passeren. Bij niet-uitval moet het verkeer worden opgesplitst in twee tunnels die naar de juiste /25 bestemmingen gaan. Als een van de tunnels omlaag gaat, kan de resterende tunnel het verkeer voor beide tunnels vervoeren. Wanneer het /25-netwerk uitvalt, wordt het /24-netwerk in een dergelijk storingsscenario gebruikt als back-uproute. Cisco stuurt klantverkeer via zijn interne WAN naar de DC die de verbinding heeft verloren.

De IPsec-tunnelonderhandeling bestaat uit twee fasen: de IKEv2-fase en de IPsec-fase. Als de onderhandeling van de IKEv2-fase niet voltooid is, wordt er geen tweede IPsec-fase gestart. Geef eerst de opdracht 'show crypto ikev2 sa' (op Cisco-apparatuur) of een soortgelijke opdracht op de apparatuur van derden om te controleren 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 IPsec-tunneltoegangslijst is onjuist geconfigureerd.

• Er is geen verbinding tussen de klant en het eindpunt-IP voor de Dedicated Instance IPsec-tunnel.

• De IKEv2-sessieparameters 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 op 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 er ook op wijzen 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 GCM-code wordt gebruikt, verwerkt het GCM-protocol de verificatie en wordt de verificatieparameter ingesteld op NULL.

  • Controleer de instelling voor de levensduur.

  • Controleer de modulusgroep Diffie Hellman.

  • Controleer de Pseudo Random-functie-instellingen.

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

De kant van het toegewezen exemplaar begint mogelijk niet altijd met de IKEv2-uitwisseling en kan soms verwachten dat de CPE-kant van de klant de initiator is. Controleer de CPE-zijconfiguratie voor de volgende vereisten voor het starten van een IKEv2-sessie: Controleer op een IPsec crypto toegangslijst voor GRE verkeer (protocol 50) van de CPE tunnel transport IP naar de Dedicated Instance tunnel transport IP. Zorg ervoor dat de GRE-tunnelinterface is ingeschakeld voor GRE-keepalives. Als de apparatuur geen GRE-keepalives ondersteunt, wordt Cisco hiervan op de hoogte gesteld omdat GRE-keepalives standaard worden ingeschakeld aan de kant van het toegewezen exemplaar. Zorg ervoor dat BGP is ingeschakeld en geconfigureerd met het naburige adres van de tunnel-IP van het toegewezen exemplaar.

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

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

• BGP-buurman TCP-sessie van de CPE-kant BGP-buurman naar de kant BGP-buurman van het toegewezen exemplaar.

• Ping van het IP-adres van de CPE-zijtunnel naar het IP-adres van de zijtunnel van het toegewezen exemplaar.

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

Als er een pakkettracering nodig is voor het IKEv2-verkeer, stelt u het filter in voor UDP en ofwel 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).

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

Het datacenter van het toegewezen exemplaar begint mogelijk niet altijd het eerste IKEv2-pakket. De vereiste is dat het CPE-apparaat het eerste IKEv2-pakket kan initiëren naar de kant van het toegewezen exemplaar. Als de lokale firewall dit toestaat, probeert u ook te pingen naar het externe IPsec-adres. Als het pingen niet lukt van het lokale naar het externe IPsec-adres, voert u een traceringsroute uit om te helpen en bepaalt u waar het pakket wordt verwijderd. Sommige firewalls en internetapparatuur staan mogelijk geen traceringsroute toe.

Controleer of de eerste fase van IPsec (d.w.z. de IKEv2-beveiligingskoppeling) actief is voordat u problemen met de tweede fase van IPsec oplost. Voer een opdracht 'toon 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 geweest en dat deze niet springt. De uptime van de sessie wordt weergegeven als de sessie 'Actieve tijd' of equivalent in de uitvoer.

Zodra de IKEv2-sessie is geverifieerd als actief, Onderzoekt u de IPsec-sessie. Voer, net als bij de IKEv2-sessie, een opdracht 'toon 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 meest voorkomende problemen die zich tijdens de IPsec-onderhandelingen kunnen voordoen zijn:

De instellingen aan de kant van de CPE 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 en controleer of de overeenkomende instellingen aan de kant van het toegewezen exemplaar staan.

• Controleer de instellingen voor levensduur.

• Controleer of de IPsec is geconfigureerd in tunnelmodus.

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

Wanneer de IPsec- en IKEv2-sessies zijn geverifieerd als up en actief, kunnen de GRE-tunnelkeepalive-pakketten stromen tussen de eindpunten van het toegewezen exemplaar en de CPE-tunnel. Als de status van de tunnelinterface niet wordt weergegeven, zijn enkele veelvoorkomende problemen:

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

  Als de VRF-configuratie niet wordt gebruikt in 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 een melding ontvangen zodat ook de standaard keepalives aan de kant van het toegewezen exemplaar zijn uitgeschakeld. Als keepalives worden ondersteund, controleert u 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 het toegewezen exemplaar.

• Het bron- of bestemmingspunnel-transportadres is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.

• Een firewall blokkeert het verzenden van GRE-pakketten naar de IPsec-tunnel of ontvangen van de IPsec-tunnel (de GRE-tunnel wordt over de IPsec-tunnel vervoerd)

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

Met de crypto-toegangslijst voor de IPsec-tunnel die het GRE-tunnelverkeer vervoert, kunnen alleen GRE-pakketten worden gekruist. Hierdoor zullen pings niet werken van tunnel transport IP naar remote tunnel transport IP.

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

Als de pingtest niet succesvol is 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 ingekapseld 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 of de pakketten verzenden en ontvangen worden verhoogd.

Naast het pingverkeer moet de opname ook keepalive GRE-pakketten tonen, zelfs bij inactief verkeer. Als ten slotte BGP is geconfigureerd, moeten BGP keepalive-pakketten ook worden verzonden als GRE-pakketten die zijn ingekapseld 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 pakketformaten. De GRE-tunnel voegt meer kopteksten toe aan de IP-pakketten die door de VPN-sessie stromen. De IPsec-tunnel voegt de extra kopteksten toe boven op de GRE-kopteksten om de grootste toegestane MTU over de tunnel verder te verminderen.

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 vergelijkbare opdracht en 'tunnel path\u0002mtu-discovery' of een vergelijkbare opdracht aan de kant van de klant om te helpen bij het dynamisch aanpassen van de MTU van verkeer door de VPN-tunnel.