Inleiding

Virtual Connect maakt gebruik van een dual-tier headend-architectuur, waarbij de routerings- en GRE-besturingsvlakken worden geleverd door het ene apparaat en het IPSec -besturingsvlak wordt geleverd door een ander apparaat.

Na voltooiing van de Virtuele verbinding connectiviteit, worden er twee GRE over IPSec -tunnels gemaakt tussen het bedrijfsnetwerk van de klant en de datacenters van Cisco voor toegewezen instanties. Eén voor elk redundant datacenter binnen de respectieve regio. Aanvullende netwerkelementen die nodig zijn voor de peering, worden door de partner of klant uitgewisseld met Cisco via het activeringsformulier van Control Hub Virtual Connect.

Afbeelding 1 toont een voorbeeld van het Virtual Connect implementatiemodel voor de optie met 2 concentrators aan de kant van de klant.

Virtuele verbinding - VPN is een hub-ontwerp, waarbij de hubsites van de klant zijn verbonden met DC1 en DC2 van de datacenters van een toegewezen exemplaar binnen een bepaalde regio.

Twee hubsites worden aanbevolen voor betere redundantie, maar één hubsite 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 opnieuw verbinding maken met de hubsite(s) via het WAN van de klant. 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'.

In afbeelding 2 ziet u de peeringregio's voor cloudconnectiviteit voor specifieke instanties.

Routering voor de add-on Virtual Connect wordt geïmplementeerd met behulp van externe BGP (eBGP) tussen een toegewezen exemplaar en de Customer Premise Equipment (CPE). Cisco adverteert hun respectieve netwerk voor elke redundante DC binnen een regio aan de CPE van de klant en de CPE moet een standaardroute naar Cisco adverteren.

• Cisco onderhoudt en wijst toe

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

  • Bestemmingsadres voor tunneltransport (zijde van Cisco)

  • Privé-autonome systeemnummers (ASN's) voor de BGP-routeringsconfiguratie van de klant

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

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

  • Cisco splitst het toegewezen /24-netwerk in 2/25 één voor elke DC in de respectieve regio

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

  • CPE moet worden geconfigureerd met de juiste eBGP-buren. Als u één CPE gebruikt, worden er twee eBGP-buren gebruikt, waarbij één naar elke externe tunnel wijst. Als u twee CPE's gebruikt, heeft elke CPE één eBGP-buur die naar de enkele externe tunnel voor de CPE verwijst.

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

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

  • CPE is verantwoordelijk voor het zo nodig herdistribueren van de geleerde routes binnen het bedrijfsnetwerk van de klant.

• Bij een niet-failure verbindingsfout heeft één CPE twee actieve/actieve tunnels. Voor twee CPE-knooppunten heeft elke CPE één actieve tunnel en beide CPE-knooppunten moeten actief zijn en verkeer doorgeven. In het scenario zonder storing moet het verkeer worden opgesplitst in twee tunnels die naar de juiste /25-bestemmingen gaan. Als een van de tunnels uitvalt, kan de resterende tunnel het verkeer voor beide vervoeren. In een dergelijk storingsscenario wordt het /24-netwerk gebruikt als een back-uproute wanneer het /25-netwerk niet beschikbaar is. Cisco stuurt klantverkeer via het interne WAN naar de DC die de verbinding heeft verbroken.

De IPsec-tunnelonderhandeling omvat twee fasen: de IKEv2-fase en de IPsec-fase. Als de onderhandeling van de IKEv2-fase 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 redenen zijn:

• Interessant verkeer activeert de IPsec-tunnel niet.

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

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

• 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. Als er geen logboekberichten zijn, kan dit er ook op wijzen dat de IKEv2-sessie niet wordt geactiveerd.

Als de logboekberichten geen onderhandelingsactiviteiten voor de IKEv2-fase weergeven, is mogelijk een pakketopname vereist.

De kant van de toegewezen instantie start mogelijk niet altijd de IKEv2-uitwisseling en kan soms verwachten dat de CPE-kant van de klant de initiator is. Controleer de configuratie aan de CPE-zijde voor de volgende vereisten voor het starten van een IKEv2-sessie: Controleer of er een IPsec- toegangslijst is voor GRE-verkeer (protocol 50) van het CPE-tunneltransport- IP naar het toegewezen tunneltransport- IP voor het toegewezen exemplaar . Zorg ervoor dat de GRE-tunnelinterface is ingeschakeld voor GRE-keealives. Als de apparatuur geen GRE-keealives ondersteunt, ontvangt Cisco een melding omdat GRE-keealives standaard worden ingeschakeld aan de kant van het toegewezen exemplaar. Zorg ervoor dat BGP is ingeschakeld en geconfigureerd met het buuradres van het toegewezen tunnel- IP-adres.

Als dit correct is geconfigureerd, wordt het volgende gestart met de IPsec-tunnel en de IKEv2-onderhandeling in de eerste fase:

• GRE houdt alives van de GRE-tunnelinterface aan de CPE-zijde naar de GRE-tunnelinterface aan de kant van de toegewezen instantie.

• BGP-buur- TCP -sessie van de BGP-buur aan de CPE-zijde naar de BGP-buur aan de kant van het toegewezen exemplaar.

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

  Ping kan niet het IP-adres van het tunneltransport naar het transport- IP van de tunnel zijn. Het moet het IP - IP IP .

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

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

Het datacenter van het toegewezen exemplaar begint mogelijk niet altijd met het eerste IKEv2-pakket. De vereiste is dat het CPE-apparaat het eerste IKEv2-pakket naar de kant van het toegewezen exemplaar kan starten. Als de lokale firewall dit toestaat, probeert u ook een ping uit te voeren naar het externe IPsec-adres. Als de ping van het lokale naar het externe IPsec-adres niet lukt, voert u een traceerroute uit om te helpen bepalen waar het pakket wordt neergezet. Sommige firewalls en internetapparatuur staan mogelijk geen traceerroute toe.

Controleer of de eerste fase van IPsec (dat wil zeggen de IKEv2-beveiligingskoppeling) actief is voordat u problemen met de tweede fase van IPsec oplost. Voer de opdracht 'show crypto ikev2 sa' of een vergelijkbare 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 stuitert. De uptime van de sessie wordt weergegeven als de sessie 'Actieve tijd' of een equivalent daarvan in de uitvoer.

Zodra de IKEv2-sessie is geverifieerd als actief en actief, onderzoekt u de IPsec-sessie. Voer, net als bij de IKEv2-sessie, de opdracht 'show crypto ipsec sa' of een vergelijkbare 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 kunnen optreden tijdens de IPsec-onderhandelingen 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 parameters voor versleuteling en verificatie overeenkomen met de instellingen aan de kant van het toegewezen exemplaar.

• Controleer of de instellingen voor Perfect Forward Secrecy overeenkomen met de instellingen aan de kant van de toegewezen instantie.

• Controleer de instellingen voor de levensduur.

• Controleer of de IPsec is geconfigureerd in de tunnelmodus.

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

Wanneer de IPsec- en IKEv2-sessies zijn geverifieerd als actief en actief, kunnen de keepalive-pakketten van de GRE-tunnel tussen het toegewezen exemplaar en de CPE-tunneleindpunten 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 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 CPE-zijtunnelinterface

  Als keepalives niet worden ondersteund op de CPE-apparatuur, moet Cisco hiervan op de hoogte worden gebracht, 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 transportadres van de bron- of bestemmingstunnel is niet correct en komt niet overeen met de verwachte waarden van het toegewezen exemplaar.

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

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

De toegangslijst voor de IPsec-tunnel die het GRE-tunnelverkeer vervoert, staat alleen GRE-pakketten toe. Als gevolg hiervan werken pings niet van het IP -adres voor tunneltransport naar het IP -adres voor extern tunneltransport.

De pingcontrole resulteert in een GRE-pakket dat wordt gegenereerd van het transport- IP van de brontunnel naar het transport- IP van de bestemmingstunnel, terwijl de payload van het GRE-pakket (het binnen- IP) het bron- en bestemmingstunnel- IP is.

Als de ping-test niet is gelukt en de voorgaande items zijn geverifieerd, is mogelijk een pakketopname vereist 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 vanaf het IPsec-bronadres naar het doel-IPsec-adres. Tellers op de GRE-tunnelinterface en de IPsec-sessietellers kunnen ook helpen om weer te geven. als de verzend- en ontvangstpakketten toenemen.

Naast het ping-verkeer moet de opname ook keepalive GRE-pakketten weergeven, zelfs tijdens inactief verkeer. Als BGP is geconfigureerd, moeten BGP-keeppakketten ook worden verzonden als GRE-pakketten die zijn ingekapseld in IPSEC-pakketten en via de VPN.

Aan de kant van de toegewezen instantie zijn twee functies ingeschakeld om 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 de extra headers toe aan de GRE-headers om de grootste MTU die via de tunnel is toegestaan verder te verkleinen.

De GRE-tunnel past de MSS-functie aan en het GRE-tunnelpad in de MTU-detectiefunctie is ingeschakeld aan de kant van de toegewezen instantie. Configureer de opdracht 'ip tcp adjust-mss 1350' of een vergelijkbare opdracht en de opdracht '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 via de VPN -tunnel.