Virtual Connect använder en dubbel nivå-värmearkitektur, där routnings- och GRE-kontrollplanen tillhandahålls av en enhet och IPSEC-kontrollplanet tillhandahålls av en annan.

När anslutningen för virtuell anslutning har slutförts skapas två GRE över IPS ec-tunnlar mellan kundens företagsnätverk och Ciscos datacenter för dedikerad instans. Ett till varje överflödigt datacenter inom respektive region. Ytterligare nätverkselement som krävs för peering utbyts av partnern eller kunden till Cisco via aktiveringsformuläret för virtuell anslutning i Control Hub.

Figur 1 visar ett exempel på distributionsmodellen för virtuell anslutning för alternativet 2-koncentrerad på kundsidan.

Virtual Connect – VPN är en hubbdesign där kundens hubbwebbplatser är anslutna till DC1 och DC2 av dedikerade instansens datacenter inom en viss region.

Två Hub-webbplatser rekommenderas för bättre redundans, men en Hub-webbplats med två tunnlar är också en distributionsmodell som stöds.

Bandbredden per tunnel är begränsad till 250 Mbit/s.

Kundens fjärrplatser inom samma region måste ansluta tillbaka till Hub-webbplatsen(erna) över kundens WAN och det är inte Ciscos ansvar för den anslutningen.

Partner förväntas arbeta nära med kunderna och se till att den mest optimala sökvägen väljs för serviceregionen ”Virtual Connect”.

Figur 2 visar peering-regioner för anslutning till dedikerad instans.

Dirigering för tillägget Virtual Connect implementeras med extern BGP (eBGP) mellan dedikerad instans och kundplatsutrustning (CPE). Cisco kommer att annonsera sitt respektive nätverk för varje överflödig DC i en region till kundens CPE och CPE måste annonsera en standardrutt till Cisco.

• Cisco underhåller och tilldelar

  • Tunnel Interface IP-adress (tillfällig länk för dirigering) Cisco tilldelar från ett utsett delat adressutrymme (inte offentligt routningsbart)

  • Adress för tunneltransport (Ciscos sida)

  • Privata autonoma systemnummer (ASN) för konfiguration av kunds BGP-routning

    • Cisco tilldelar från det angivna privata användningsområdet: 64512 till 65534

• eBGP som används för att växla rutter mellan dedikerad instans och CPE

  • Cisco delar det tilldelade /24-nätverket i 2 /25 ett för varje DC i respektive region

  • I virtuell anslutning annonseras varje /25-nätverk tillbaka till CPE av Cisco via respektive punkt-till-punkt-VPN-tunnlar (övergångslänk)

  • CPE måste konfigureras med lämpliga eBGP-grannar. Om du använder en CPE kommer två eBGP grannar att användas, en pekar mot varje fjärrtunnel. Om två CPE används kommer varje CPE att ha en eBGP granne som ansluter till den enda fjärrtunneln för CPE.

  • Cisco-sidan av varje GRE-tunnel (tunnelgränssnitt IP) är konfigurerad som BGP-granne på CPE

  • CPE krävs för att annonsera en standardrutt över varje tunnel

  • CPE kan reagera för att omdistribuera inlärda rutter inom kundtjänstrepresentantens företagsnätverk efter behov.

• Ett enda CPE kommer att ha två aktiva/aktiva tunnlar under icke-misslyckade länkförhållanden. För två CPE-noder har varje CPE en aktiv tunnel och båda CPE-noderna ska vara aktiva och passera trafik. I händelse av misslyckande måste trafiken delas upp i två tunnlar som går till rätt /25 destinationer, om en av tunneln går ner kan den återstående tunneln bära trafiken för båda. Under ett sådant felscenario används nätverket /24 som en säkerhetskopieringsväg när nätverket /25 är nere. Cisco skickar kundtrafik via sin interna WAN till DC som förlorade anslutningen.

Förhandlingarna om IP-sec-tunneln omfattar två faser, IKEv2-fasen och IPsec-fasen. Om IKEv2-fasförhandlingen inte slutförs kommer det inte att inledas någon andra IP-sektorfas. Först utfärdar du kommandot ”visa crypto ikev2 sa” (på Cisco-utrustning) eller liknande kommando på tredjepartsutrustningen för att kontrollera om IKEv2-sessionen är aktiv. Om IKEv2-sessionen inte är aktiv kan de potentiella orsakerna vara:

• Intressant trafik utlöser inte IP-sec-tunneln.

• Åtkomstlistan för IP-sec-tunnel är felkonfigurerad.

• Det finns ingen anslutning mellan kunden och slutpunktens IP-adress för dedikerad instans IP.

• IKEv2-sessionsparametrarna matchar inte mellan sidan dedikerad instans och kundsidan.

• En brandvägg blockerar IKEv2 UDP-paketen.

Kontrollera först IP-sektorloggarna för alla meddelanden som visar förloppet i IKEv2-tunneln. Loggarna kan ange var det finns ett problem med IKEv2-förhandlingarna. Avsaknad av loggningsmeddelanden kan också indikera att IKEv2-sessionen inte aktiveras.

Några vanliga fel med IKEv2-förhandlingarna är:

• Inställningarna för IKEv2 på CPE-sidan matchar inte Cisco-sidan. Kontrollera om de inställningar som anges:

  • Kontrollera att IKE-versionen är version 2.

  • Kontrollera att parametrarna för kryptering och autentisering överensstämmer med den förväntade krypteringen på sidan Dedikerad instans.

    När ”GCM”-kryptern används hanterar GCM-protokollet autentiseringen och ställer in autentiseringsparametern till NULL.

  • Verifiera livstidsinställningen.

  • Verifiera modulusgruppen Diffie Hellman.

  • Verifiera inställningarna för pseudoslumpmässig funktion.

• Åtkomstlistan för kryptokartan är inte inställd på:

  • Tillåta GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (eller motsvarande kommando)

    Åtkomstlistan måste vara specifik för ”GRE”-protokollet och ”IP”-protokollet fungerar inte.

Om loggmeddelandena inte visar någon förhandlingsaktivitet för IKEv2-fasen kan en paketinspelning behövas.

Sidan för dedikerad instans kanske inte alltid startar IKEv2-utbytet och kan ibland förvänta sig att kundens CPE-sida ska vara initiatorn. Kontrollera konfigurationen av CPE-sidan för följande förutsättningar för initiering av IKEv2-sessionen: Kontrollera om du har en IP-sec kryptoåtkomstlista för GRE-trafik (protokoll 50) från CPE-tunneltransport-IP till den dedikerade instans-tunneltransport-IP. Se till att gränssnittet för GRE-tunneln är aktiverat för GRE-keepalives. Om utrustningen inte har stöd för GRE-keepalives meddelas Cisco eftersom GRE-keepalives kommer att aktiveras på sidan Dedikerad instans som standard. Kontrollera att BGP är aktiverat och konfigurerat med grannadressen till den dedikerade instans-IP-tunneln.

När den har konfigurerats korrekt startar följande IPsec-tunneln och IKE v2-förhandling i första fasen:

• GRE-keepalives från CPE sida GRE-tunnellgränssnittet till GRE-tunnellgränssnittet för dedikerad instans.

• TCP-session för BGP-granne från CPE-sidan för BGP till BGP-grannen för dedikerad instans.

• Ping från CPE-sidan av tunneln till IP-adressen för dedikerad instans.

  Ping kan inte vara tunneltransport IP till tunnel transport IP, det måste vara tunnel IP till tunnel IP.

Om det behövs en paketspårning för IKEv2-trafiken ställer du in filtret för UDP och antingen port 500 (när ingen NAT-enhet finns mitt i IPsec-slutpunkterna) eller port 4500 (när en NAT-enhet sätts in mitt i IPsec-slutpunkterna).

Kontrollera att IKEv2 UDP-paket med port 500 eller 4500 skickas och tas emot till och från DI IPsec-IP-adress.

Datacenter för dedikerad instans kanske inte alltid startar det första IKE v2-paketet. Kravet är att CPE-enheten kan initiera det första IKEv2-paketet mot sidan Dedikerad instans. Om den lokala brandväggen tillåter det kan du också försöka en ping till fjärradressen IP-sek. Om ping inte lyckas från lokal till fjärransluten IP-sek-adress utför du en spårningsväg för att hjälpa till och bestämma var paketet tappas. Vissa brandväggar och Internet-utrustning tillåter eventuellt inte spårningsväg.

Kontrollera att IP-sektorns första fas (dvs. IKEv2 säkerhetsassociation) är aktiv innan du felsöker IP-sektorns andra fas. Utför ett ”visa crypto ikev2 sa” eller motsvarande kommando för att verifiera IKE v2-sessionen. Kontrollera i utgången att IKEv2-sessionen har pågått i mer än några sekunder och att den inte hoppar. Sessionsuptiden visas som sessionen ”Aktiv tid” eller motsvarande i output.

När IKEv2-sessionen har verifierats som aktiv och aktiv undersöker du IP-sessionen. Som med IKE v2-sessionen utför du ett ”visa crypto ipsec sa” eller motsvarande kommando för att verifiera IPsec-sessionen. Både IKEv2-sessionen och IPsec-sessionen måste vara aktiva innan GRE-tunneln upprättas. Om IP-sektorsessionen inte visas som aktiv kontrollerar du IP-sektorloggarna för felmeddelanden eller förhandlingsfel.

Några av de vanligaste frågorna som kan stöta på under förhandlingarna om IP-sec är:

Inställningarna på CPE-sidan matchar inte sidan Dedikerad instans. Kontrollera inställningarna igen:

• Kontrollera att parametrarna för kryptering och autentisering överensstämmer med inställningarna på sidan Dedikerad instans.

• Kontrollera inställningarna för Perfekt vidarebefordra sekretess och att matchningsinställningarna på sidan Dedikerad instans.

• Verifiera livstidsinställningarna.

• Kontrollera att IP-sek har konfigurerats i tunnelläge.

• Verifiera källa- och destinationens IP-sektoradresser.

När IPsec- och IKEv2-sessioner verifieras som upp och aktiva kan GRE-tunneln keepalive-paket flöda mellan slutpunkterna för dedikerad instans och CPE-tunneln. Om tunnelgränssnittet inte visar status är några vanliga problem:

• VRF för transport av tunnelgränssnittet matchar inte VRF för loopback-gränssnittet (om VRF-konfigurationen används i tunnelgränssnittet).

  Om VRF-konfigurationen inte används i tunnelgränssnittet kan den här kontrollen ignoreras.

• Keepalives är inte aktiverade i CPE-gränssnittet i sidotunneln

  Om keepalives inte stöds på CPE-utrustningen måste Cisco meddelas så att standardkeepalives på sidan Dedikerad instans också är inaktiverade. Om keepalives stöds kontrollerar du att keepalives är aktiverade.

• Masken eller IP-adressen för tunnelgränssnittet är inte korrekt och överensstämmer inte med förväntade värden för dedikerad instans.

• Transportadressen till källan eller destinationstunneln är inte korrekt och matchar inte de förväntade värdena för den dedikerade instansen.

• En brandvägg blockerar GRE-paket från skickade in i IPsec-tunneln eller mottagna från IPsec-tunneln (GRE-tunneln transporteras över IPsec-tunneln)

Ett ping-test bör kontrollera att det lokala tunnelgränssnittet är igång och anslutningen är bra till fjärrtunnelgränssnittet. Utför ping-kontrollen från tunnel-IP (inte transport-IP) till fjärrtunnel-IP.

Kryptoåtkomstlistan för IPsec-tunneln som bär GRE-tunneln tillåter endast GRE-paket att korsa. Som ett resultat av detta kommer pings inte att fungera från tunneltransport-IP till fjärrtunneltransport-IP.

Ping-kontrollen resulterar i ett GRE-paket som genereras från källtunnelltransport-IP till destinationstunnelltransport-IP medan nyttobelastningen på GRE-paketet (den inre IP) kommer att vara källa- och destinationstunnellens IP.

Om ping-testet inte lyckas och föregående objekt verifieras kan det krävas en paketinspelning för att säkerställa att icmp-ping resulterar i ett GRE-paket som sedan är inkapslat i ett IPsec-paket och sedan skickas från källans IPsec-adress till destinationens IP-sec-adress. Räknare i GRE-tunnelgränssnittet och IPsec-sessionsräknaren kan också hjälpa till att visa. om sändningen och mottagningen av paket ökar.

Förutom pingtrafiken bör fångsten också visa keepalive GRE-paket även under passiv trafik. Slutligen, om BGP är konfigurerad, ska BGP keepalive-paket också skickas som GRE-paket inkapslat i IPSEC-paket samt via VPN.

På sidan Dedikerad instans aktiveras två funktioner för att dynamiskt justera MTU för stora paketstorlekar. GRE-tunneln lägger till fler rubriker i IP-paket som flödar genom VPN-sessionen. IPsec-tunneln lägger till de extra rubrikerna ovanför GRE-rubrikerna kommer ytterligare att minska det största MTU som tillåts över tunneln.

GRE-tunneln justerar MSS-funktionen och GRE-tunnelsökvägen i MTU-identifieringsfunktionen är aktiverad på sidan Dedikerad instans. Konfigurera ”ip tcp adjust-mss 1350” eller motsvarande kommando samt ”tunnel path\u0002mtu-discovery” eller motsvarande kommando på kundsidan för att hjälpa till med dynamisk justering av MTU av trafik genom VPN-tunneln.