Inledning

Virtual Connect är ett ytterligare tilläggsalternativ för molnanslutning till dedikerad instans för Webex Calling (dedikerad instans). Med Virtual Connect kan kunder på ett säkert sätt utöka sitt privata nätverk över internet med hjälp av IP VPN-tunneler från punkt till punkt. Det här anslutningsalternativet visar att privat nätverksanslutning snabbt används med hjälp av cpe (Customer Premise Equipment) och internetanslutning.

Cisco är värdar, hanterar och säkerställer redundanta IP VPN-tunneler och nödvändig Internetåtkomst i den(a) datacenterregion (Dedikerade instanser) i Cisco där tjänsten krävs. På samma sätt ansvarar administratören för motsvarande CPE- och Internet-tjänster som krävs för Virtual Connect.

Varje virtual Connect-beställning i en viss dedikerad instans-region skulle inkludera två generisk dirigerings encapsulering (GRE) tunneler som skyddas av IPSec-kryptering (GRE over IPSec), en till varje Ciscos datacenter i den valda regionen.

Virtuell Connect har en bandbreddsgräns på 250 Mbit/s per tunnel och rekommenderas för mindre distribuering. Eftersom vpn-tunneler med två punkt-till-punkt används all trafik till molnet måste gå genom kundens huvudpunkt CPE, och det kanske inte är lämpligt där det finns många fjärrwebbplatser. För andra alternativa peering-alternativ, se Molnanslutning.

Innan du skickar peering-begäran för Virtual Connect, se till att den dedikerade instanstjänsten är aktiverad i respektive region.

Förutsättningar

För att upprätta virtual Connect krävs bland annat:

  • Kunden tillhandahåller

    • Internetanslutning med tillräckligt med bandbredd för att stödja distribueringen

    • Offentlig(a) IP-adress(er) för två IPSec-tunnel

    • KUNDsidans GRE-transport-IP-adresser för de två GRE-tunnelerna

  • Partner och kund

    • Samarbeta för att utvärdera bandbreddskraven

    • Säkerställ att nätverksenheten har stöd för Border Gateway Protocol (BGP) dirigering och en GRE over IPSec-tunneldesign

  • Partner eller kund tillhandahåller

    • Nätverk med kunskaper om VPN-tunneltekniker på plats-till-plats

    • Nätverk med kunskaper om BGP, eBGP och allmänna dirigeringsprinciper

  • Cisco

    • Cisco tilldelade privata autonoumous systemnummer (ASN:er) och tillfällig IP-adressering för GRE-tunnelgränssnitt

    • Cisco har tilldelat ett allmänt men inte internet dirigerbart C-nätverk (/24) för dedikerade instans cloud-adressering

Om en kund bara har 1 CPE-enhet kommer de 2 tunnelerna mot Ciscos datacenter (DC1 och DC2) i varje region att från den CPE-enheten. Kunden har också ett alternativ för 2 CPE-enheter. Sedan ska varje CPE-enhet ansluta till 1 tunnel endast mot Ciscos datacenter (DC1 och DC2) i varje region. Ytterligare redundans kan avbrytas genom att avsluta varje tunnel på en separat fysisk plats/plats i kundens infrastruktur.

Teknisk information

Implementeringsmodell

Virtual Connect använder en arkitektur med dubbla nivåer där dirigerings- och GRE-kontrollplan tillhandahålls av en enhet och IPSec-kontrollplan tillhandahålls av en annan.

När virtual Connect-anslutningen är klar kommer två GRE över IPSec-tunneler att skapas mellan kundens företagsnätverk och Dedikerade Instans Ciscos datacenter. En till varje redundant 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 Virtual Connect-kontrollhubb.

Figuren nedan visar ett exempel på distributionsmodellen för virtuell anslutning för alternativet med 2 koncentratorer på kundsidan.

Virtuell anslutning – 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 One Hub-webbplatser med två tunneler är också en distributionsmodell som stöds.

Bandbredden per tunnel är begränsad till 250 Mbit/s. För att säkerställa effektiv redundansväxling får den kombinerade trafiken över båda tunnlarna inte överstiga 250 Mbps, eftersom all trafik kommer att dirigeras genom en tunnel vid ett fel.

Kundens fjärrwebbplatser inom samma region måste ansluta tillbaka till Hub-webbplatsen/-webbplatserna via kundens WAN och det är inte Ciscos ansvar för anslutningen.

Partners förväntas arbeta nära kunderna och säkerställa att den mest optimala vägen väljs för serviceregionen Virtual Connect.

Figuren nedan visar peering-regionerna för dedikerad instans av molnanslutning.

Virtuella anslutningsområden

Dirigering

Dirigering för tillägget Virtual Connect implementeras med hjälp av extern BGP (eBGP) mellan dedikerad instans och CPE (Customer Premise Equipment). Cisco annonserar om sitt respektive nätverk för varje redundant DC inom en region till kundens CPE och CPE krävs för att annonsera en standardväg till Cisco.

  • Cisco underhåller och tilldelar

    • IP-adressering av tunnelgränssnitt (övergående länk för dirigering) tilldelar Cisco från ett anvisat delat adressutrymme (icke-offentligt dirigerbart)

    • Adressen för tunneltransporten (Ciscos sida)

    • Privata autonoma systemnummer för kundens BGP-dirigeringskonfiguration

      • Cisco tilldelar från det avsedda privata användningsintervallet: 64512 till 65534

  • eBGP som används för utbyte av vägar mellan dedikerad instans och CPE

    • Cisco kommer att dela det tilldelade/24-nätverket till 2/25 ett för varje dc i respektive region

    • I Virtual Connect annonseras varje /25-nätverk tillbaka till CPE av Cisco under respektive VPN-tunnel (tillfällig länk)

    • CPE måste konfigureras med lämpliga eBGP-grann. Om du använder en CPE kommer två eBGP-angränsande personer att användas, en pekar på varje fjärr tunnel. Om du använder två CPE kommer varje CPE att ha en eBGP-angränsande person som leder till den enda fjärr tunneln för CPE.

    • Cisco-sidan för varje GRE-tunnel (TUNNEL-gränssnitts-IP) är konfigurerad som BGP-grannen på CPE

    • CPE krävs för att annonsera om en standardväg över var och en av tunnelerna

    • CPE kan omdestribueras vid behov via de nyrädda vägar inom företagsnätverket.

  • Om länken inte felar kommer en CPE att ha två aktiva/aktiva tunnel. För två CPE-noder kommer varje CPE att ha en aktiv tunnel och båda CPE-noderna bör vara aktiva och skicka trafik. Om inte fel uppstår måste trafiken delas i två tunneler som går till rätt /25 destinationer om en av tunneln går ner kan den återstående tunneln leda trafiken för båda. Under ett sådant felscenario används nätverket som reservväg när /25-nätverket är nere. Cisco kommer att skicka kundtrafik via sin interna WAN till DC som förlorade anslutningen.

Virtuellt anslutningstrafikflöde

Trafikflödet när båda tunnlarna är uppe

Dedikerad instans - Virtuell anslutning

Den här bilden illustrerar en Virtual Connect nätverksarkitektur, som i detalj beskriver trafikflödet när både primära och sekundära tunnlar är i drift.

Den representerar en aktiv anslutningsmodell för en kund att få åtkomst till UC-applikationer som finns i Ciscos datacenter, och utnyttjar dubbla GRE/IPSEC tunnlar över internet med BGP för ruttutbyte.

Definitioner:

  • Kundens lokaler:
    • Detta representerar kundens nätverk på plats, där användare och deras enheter (t.ex. IP-telefoner, datorer som kör UC-klienter) finns.
    • Trafik som kommer härifrån måste nå UC-applikationerna som finns i Ciscos datacenter.
  • Cisco Webex Calling dedikerad instans (dedikerad instans) datacenter (WxC-DI DC-A och WxC-DI DC-B):
    • Det här är Ciscos datacenter som är värd för UC-applikationerna.
    • DC-A och DC-B är geografiskt åtskilda, vilket ger redundans.
    • Varje datacenter har sitt eget delnät för UC-applikationer:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Tunnlar (Tunnel 1 och Tunnel 2):
    • Det här är de säkra, krypterade anslutningarna mellan kundens lokaler och Ciscos datacenter över det publika internet.
    • GRE (generisk routinginkapsling): Detta protokoll används för att inkapsla olika nätverkslagerprotokoll inuti virtuella punkt-till-punkt-länkar. Det tillåter routingprotokoll som BGP att fungera över tunneln.
    • IPsec (Internetprotokollsäkerhet): Denna uppsättning protokoll tillhandahåller kryptografiska säkerhetstjänster (autentisering, integritet, konfidentialitet) för IP-kommunikation. Den krypterar den GRE-inkapslade trafiken, vilket säkerställer säker dataöverföring över internet.
  • Border Gateway-protokollet (BGP):
    • BGP är routingprotokollet som används för att utbyta routinginformation mellan kundens lokaler och Ciscos datacenter.

Som visas i diagrammet ovan måste enheter som distribueras hos kunden upprätta två GRE/IPSEC tunnlar.

Namngivningskonventionerna som används nedan med XX / YY, DC-A DC-B är generiska för alla regioner där dedikerad instans erbjuds. Dessa värden kommer att vara unika för varje region och de faktiska värdena för varje region. De specifika värdena anges under aktiveringen av den virtuella anslutningen.

På Ciscos sida kommer IPSec- och GRE-tunnlarna att avslutas på olika enheter. Så kunden måste se till att konfigurera IPSec-destinations- och GRE-destinations-IP:er på enheterna i enlighet därmed. Kunder kan använda samma IP-adress för GRE och IPSEC om det stöds på deras enheter. Se diagrammet ovan. De IP-relaterade värdena anges under aktivering av den virtuella anslutningen på portalen.

  • Tunnel 1: Ansluter kundens lokaler till "Dedicated Instance DC-A" (Data Center A) via internet. Den här tunneln använder BGP AS:64XX1 på kundsidan och BGP AS:64XX2 på den dedikerade instansens DC-A-sida. IPSEC- och GRE-tunnelkällkonfigurationer är uppdelade mellan kundlevererade och Cisco-levererade detaljer.
  • Tunnel 2: Ansluter kundens lokaler till "Dedicated Instance DC-B" (Data Center B) via internet. Den här tunneln använder BGP AS:64YY1 på kundsidan och BGP AS:64YY2 på den dedikerade instansens DC-B-sida. Precis som Tunnel 1 delas IPSEC- och GRE-tunnelkällkonfigurationer mellan kunden och Cisco.

I BGP AS:64XX och BGP AS:64YY, XX och YY är specifika för en viss region.

När GRE/IPSEC Om tunnlar upprättas till Webex Calling Dedicated Instance-datacenter (A och B), bör kunden få följande rutter som annonseras från Cisco under motsvarande BGP-sessioner.

  • För DC-A: Rutter som annonseras från Cisco kommer att vara X.X.X.0/25 och X.X.x.0/24. Valfritt om IaaS begärs och konfigureras för kundens rutter Y.Y.Y.0/25 och Y.Y.Y.0/24 kommer att annonseras från Cisco.
  • För DC-B: Rutter som annonseras från Cisco kommer att vara X.X.X.128/25 och X.X.x.0/24. Valfritt om IaaS begärs och konfigureras för kundens rutter Y.Y.Y.128/25 och Y.Y.Y.0/24 kommer att annonseras från Cisco.
  • Kunden behöver annonsera 0.0.0./0 väg till Cisco genom båda anslutningarna (tunnlarna)
  • Kunden måste följa det längsta prefixet (/25) rutter för att skicka trafik till Cisco genom respektive tunnlar när båda tunnlarna är uppe.
  • Cisco kommer att returnera trafiken genom samma tunnlar för att hålla trafiken symmetrisk.

Trafikflöde:

  • Trafik avsedd för "DC-A UC-appar" (X.X.X.0/25) från kundens lokaler flyter genom tunnel 1.
  • Trafik avsedd för "DC-B UC Apps" (X.X.X.128/25) från kundens lokaler flyter genom tunnel 2.

Redundansscenario : trafikflödet när en av tunnlarna är nere

Dedikerad instans - Virtuell anslutning

Som visas i diagrammet ovan, när tunneln till DC-A är nere, kommer bgp:n som etablerats genom tunneln till DC-A att gå ner.

Påverkan på BGP: När tunnel 1 går ner, kommer även BGP-sessionen över den tunneln att gå ner. Följaktligen kommer DC-A inte längre att kunna annonsera sina rutter (specifikt X.X.X.0/25) till kunden via denna väg. Därför kommer kundens router att upptäcka vägen som oåtkomlig.

Eftersom Tunnel 1 är nere kommer kundens router hos kunden automatiskt att ta bort de rutter som lärts in via Tunnel 1 från sin routingtabell eller markera dem som oåtkomliga.

  • Trafik avsedd för UC App Network (X.X.X.0/24) eller DC-A-subnätet (X.X.X.0/25) kommer sedan att omdirigeras genom arbetstunneln mot DC-B som fortsätter att annonsera X.X.X.0/24 som inkluderar X.X.X.0/25 nätverk.
  • Liknande beteende kommer att ses om tunneln till DC-B är nere medan tunneln till DC-A fortfarande är uppe.

Anslutningsprocess

Följande steg på hög nivå beskriver hur du etablerar anslutning med virtuell Connect för dedikerad instans.
1

Gör en beställning i Cisco CCW

2

Aktivera virtuell Connect från Control Hub

3

Cisco utför nätverkskonfiguration

4

Kunden utför nätverkskonfiguration

Steg 1: CCW-beställning

Virtual Connect är ett tillägg för dedikerad instans i CCW.

1

Gå till ccw-beställningssidan och klicka sedan på Logga in för att logga in på webbplatsen:

https://apps.cisco.com/Commerce/guest.
2

Skapa uppskattning.

3

Lägg till "A-FLEX-3" SKU.

4

Välj Redigera alternativ.

5

Välj Alternativ och Tillägg på fliken prenumeration som visas.

6

Under Ytterligare tillägg markerar du kryssrutan bredvid "Virtuell anslutning för dedikerad instans". SKU-namnet är "A-FLEX-DI-VC".

7

Ange antalet och antalet regioner som virtuell connect krävs i.

Antalet virtuella Connect-enheter får inte överskrida det totala antalet regioner som köpts för dedikerad instans. Dessutom tillåts endast en beställning av Virtual Connect per region.
8

När du är nöjd med dina val klickar du på Verifiera och Spara i den övre högra delen av sidan.

9

Klicka på Spara och fortsätt för att slutföra beställningen. Din slutliga ordning är nu appers i ordningens rutnät.

Steg 2: Aktivering av virtuell Connect i Control Hub

1

Logga in på Control Hub https://admin.webex.com/login.

2

Gå till avsnittet Tjänster och gå till > Dedikerad instacnce > molnanslutning.

3

På kortet Virtual Connect listas det köpta antalet virtuella Connect. Administratören kan nu klicka på Aktivera för att initiera aktiveringen av Virtual Connect.

Aktiveringsprocessen kan endast utlösas av administratörer med rollen "Fullständig kundadministratör". En administratör med rollen "Kund skrivskyddad administratör" kan endast se statusen.
4

När administratören klickar på aktiveringsknappen visas formuläret Aktivera virtuell anslutning för att ge den tekniska information som krävs för Virtual Connect för peering-konfigurationer på Ciscos sida.

Formuläret tillhandahåller också statisk information på Ciscos sida baserat på vilken region som har valts. Den här informationen är användbar för kundadministratörer för att konfigurera CPE på deras sida för att etablera anslutningen.

  1. GRE Tunnel Transport IP-adress: Kunden måste tillhandahålla kundens ip-adresser för tunneltransport och Cisco kommer att tilldela IP-adresserna dynamiskt när aktiveringen är slutförd. IPSec ACL för spännande trafik ska tillåta lokal tunneltransport IP/32 till fjärrtransportENS IP/32. ACL:en ska också ange endast GRE IP-protokollet.

    IP-adressen som tillhandahålls av kunden kan vara privat eller offentlig.

  2. IPSec-peer: Kunden måste tillhandahålla IPSec Tunnels käll-IP-adresser och Cisco allokerar IP-adressen för ip-adressen för IP-adressen för IP-adressen. Utförande av NAT-översättning av en intern IPSEC-tunneladress till en offentlig adress stöds också vid behov.

    IP-adressen som tillhandahålls av kunden ska vara offentlig.

    All annan statisk information som tillhandahålls på aktiveringsskärmen är säkerhets- och krypteringsstandarder för Cisco följt av Ciscos sida. Denna statiska konfiguration är inte anpassningsbar eller anpassningsbar. För ytterligare hjälp med statiska konfigurationer på Ciscos sida bör kunden kontakta TAC.
5

Klicka på knappen Aktivera när alla obligatoriska fält är ifyllda.

6

När aktiveringsformuläret för virtuell anslutning är klart för en deltagarregion kan kunden exportera aktiveringsformuläret från Control Hub, samtal > dedikerad instans > molnanslutningsfliken och klicka på Exportera inställningar.

Av säkerhetsskäl kommer autentisering och BGP-lösenord inte att vara tillgängliga i det exporterade dokumentet, men administratören kan se dem i Control Hub genom att klicka på Visa inställningar under Control Hub, Anrop. > Dedikerad instans > Fliken Molnanslutning.

Steg 3: Cisco utför nätverkskonfiguration

1

När aktiveringsformuläret för virtuell anslutning är slutfört kommer status att uppdateras till aktivering av pågående samtal > dedikerad instans > för molnanslutning med virtuellt Connect-kort .

2

Cisco kommer att slutföra de nödvändiga konfigurationerna på Ciscos sidoutrustning inom 5 arbetsdagar. När slutförandet är slutförd kommer statusen att uppdateras till "Aktiverad" för den specifika regionen i Control Hub.

Steg 4: Kunden utför nätverkskonfiguration

Statusen ändras till "Aktiverad" för att meddela kundadministratören att Ciscos sida av konfigurationer för IP VPN-anslutningen har slutförts baserat på kundens inmatningar. Men kundadministratören förväntas slutföra sin sida av konfigurationerna på CP:erna och testa anslutningsvägarna för den virtuella Connect-tunneln för att vara online. Om problem är aktuella då konfiguration eller anslutning är över kan kunden kontakta Cisco TAC (teknisk support) för hjälp.

Felsökning

Felsökning och validering av IPsec första fasen (IKEv2-förhandling)

IPsec-tunnelförhandlingen omfattar två faser, IKEv2-fasen och IPsec-fasen. Om IKEv2-fasförhandlingen inte slutförs, initieras ingen andra IPsec-fas. Utför först kommandot "show crypto ikev2 sa" (på Cisco-utrustning) eller ett liknande kommando på tredjepartsutrustningen för att verifiera om IKEv2-sessionen är aktiv. Om IKEv2-sessionen inte är aktiv kan de möjliga orsakerna vara:

  • Intressant trafik utlöser inte IPsec-tunneln.

  • IPsec-tunnelns åtkomstlista är felkonfigurerad.

  • Det finns ingen anslutning mellan kunden och den dedikerade instansens IPsec-tunnelslutpunkts-IP.

  • IKEv2-sessionsparametrarna matchar inte på sidan för den dedikerade instansen och kundsidan.

  • En brandvägg blockerar IKEv2 UDP-paketen.

Kontrollera först IPsec-loggarna för meddelanden som visar förloppet för IKEv2-tunnelförhandlingen. Loggarna kan indikera var det finns ett problem med IKEv2-förhandlingen. Avsaknad av loggmeddelanden kan också tyda på att IKEv2-sessionen inte aktiveras.

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

  • Inställningarna för IKEv2 på CPE-sidan matchar inte Ciscos, kontrollera de nämnda inställningarna igen:

    • Kontrollera att IKE-versionen är version 2.

    • Kontrollera att parametrarna kryptering och autentisering matchar den förväntade krypteringen på den dedikerade instanssidan.

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

    • Verifiera livstidsinställningen.

    • Verifiera Diffie-Hellman-modulgruppen.

    • Verifiera inställningarna för pseudoslumpfunktionen.

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

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

      Åtkomstlistan måste vara specifikt för "GRE"-protokollet, annars fungerar inte "IP"-protokollet.

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

Den dedikerade instanssidan startar inte alltid IKEv2-utbytet och kan ibland förvänta sig att kundens CPE-sida är initiativtagare.

Kontrollera CPE-sidans konfiguration för följande förutsättningar för initiering av IKEv2-session:

  • Sök efter en IPsec-kryptoåtkomstlista för GRE-trafik (protokoll 50) från CPE-tunnelns transport-IP till den dedikerade instansens tunneltransport-IP.

  • Se till att GRE-tunnelgränssnittet är aktiverat för GRE-keepalives. Om utrustningen inte stöder GRE-keepalives meddelas Cisco eftersom GRE-keepalives som standard aktiveras på den dedikerade instanssidan.

  • Se till att BGP är aktiverat och konfigurerat med grannadressen för den dedikerade instansens tunnel-IP.

När den är korrekt konfigurerad startar följande IPsec-tunneln och den första fasen av IKEv2-förhandlingen:

  • GRE-keepalives från CPE-sidans GRE-tunnelgränssnitt till det dedikerade instanssidans GRE-tunnelgränssnitt.

  • BGP-grannens TCP-session från BGP-grannen på CPE-sidan till BGP-grannen på dedikerad instanssidan.

  • Ping från CPE-sidtunnelns IP-adress till den dedikerade instansens sidtunnel-IP-adress.

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

Om ett paketspår behövs för IKEv2-trafiken, ställ in filtret för UDP och antingen port 500 (när ingen NAT-enhet finns mitt mellan IPsec-slutpunkterna) eller port 4500 (när en NAT-enhet är insatt mitt mellan IPsec-slutpunkterna).

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

Det dedikerade instansdatacentret startar inte alltid det första IKEv2-paketet. Kravet är att CPE-enheten kan initiera det första IKEv2-paketet mot den dedikerade instanssidan.

Om den lokala brandväggen tillåter det, försök även att pinga till den fjärranslutna IPsec-adressen. Om pingen inte lyckas från lokal till fjärr-IPsec-adress, utför då en spårningsrutt för att avgöra var paketet släpps.

Vissa brandväggar och internetutrustning tillåter eventuellt inte spårningsvägar.

Felsökning och validering av IPsec andra fasen (IPsec-förhandling)

Kontrollera att den första IPsec-fasen (det vill säga IKEv2-säkerhetsassociationen) är aktiv innan du felsöker den andra IPsec-fasen. Kör ett "show crypto ikev2 sa" eller motsvarande kommando för att verifiera IKEv2-sessionen. I utdata, verifiera att IKEv2-sessionen har varit igång i mer än några sekunder och att den inte studsar. Sessionens drifttid visas som sessionens "aktiv tid" eller motsvarande i utdata.

När IKEv2-sessionen verifierats som aktiv, undersök IPsec-sessionen. Precis som med IKEv2-sessionen, kör ett "show 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 IPsec-sessionen inte visas som aktiv, kontrollera IPsec-loggarna för felmeddelanden eller förhandlingsfel.

Några av de vanligaste problemen som kan uppstå under IPsec-förhandlingar är:

Inställningarna på CPE-sidan matchar inte sidan för dedikerad instans, kontrollera inställningarna igen:

  • Kontrollera att parametrarna kryptering och autentisering matchar inställningarna på sidan dedikerad instans.

  • Verifiera inställningarna för Perfect Forward Secrecy och att de matchar inställningarna på sidan Dedicated Instance.

  • Verifiera livstidsinställningarna.

  • Kontrollera att IPsec har konfigurerats i tunnelläge.

  • Verifiera käll- och destinations-IPsec-adresserna.

Felsökning och validering av tunnelgränssnitt

När IPsec- och IKEv2-sessionerna verifieras som aktiva kan GRE-tunnelns keepalive-paket flöda mellan den dedikerade instansen och CPE-tunnelns slutpunkter. Om tunnelgränssnittet inte visar status är några vanliga problem:

  • Tunnelgränssnittets transport-VRF matchar inte loopback-gränssnittets VRF (om VRF-konfiguration används på tunnelgränssnittet).

    Om VRF-konfigurationen inte används på tunnelgränssnittet kan denna kontroll ignoreras.

  • Keepalives är inte aktiverade på CPE-sidans tunnelgränssnitt

    Om keepalive-inställningar inte stöds på CPE-utrustningen måste Cisco meddelas så att standardkeepaliven på den dedikerade instanssidan också inaktiveras.

    Om keepalives stöds, kontrollera att keepalives är aktiverade.

  • Masken eller IP-adressen för tunnelgränssnittet är felaktig och matchar inte de förväntade värdena för den dedikerade instansen.

  • Käll- eller destinationstunnelns transportadress är felaktig och matchar inte de förväntade värdena för den dedikerade instansen.

  • En brandvägg blockerar GRE-paket från att skickas in i IPsec-tunneln eller tas emot från IPsec-tunneln (GRE-tunneln transporteras över IPsec-tunneln)

Ett pingtest bör verifiera att det lokala tunnelgränssnittet är aktivt och att anslutningen till det fjärranslutna tunnelgränssnittet är god. Utför ping-kontrollen från tunnelns IP-adress (inte transport-IP-adressen) till den fjärranslutna tunnelns IP-adress.

Kryptoåtkomstlistan för IPsec-tunneln som transporterar GRE-tunneltrafiken tillåter endast GRE-paket att korsa. Som ett resultat 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älltunnelns transport-IP till destinationstunnelns transport-IP, medan nyttolasten för GRE-paketet (den inre IP-adressen) kommer att vara käll- och destinationstunnelns IP.

Om pingtestet inte lyckas och föregående punkter verifieras kan en paketinsamling krävas för att säkerställa att icmp-pingen resulterar i ett GRE-paket som sedan inkapslas i ett IPsec-paket och skickas från käll-IPsec-adressen till destinations-IPsec-adressen. Räknare på GRE-tunnelgränssnittet och IPsec-sessionsräknarna kan också hjälpa till att visa om antalet skickade och mottagna paket ökar.

Förutom ping-trafiken bör avbildningen även visa keepalive GRE-paket även under inaktiv trafik. Slutligen, om BGP är konfigurerat, bör BGP keepalive-paket också skickas som GRE-paket inkapslade i IPSEC-paket över VPN.

BGP-felsökning och validering

BGP-sessioner

BGP krävs som routingprotokoll över VPN IPsec-tunneln. Den lokala BGP-grannen bör upprätta en eBGP-session med den dedikerade instansens BGP-grannen. eBGP-grann-IP-adresserna är desamma som de lokala och fjärranslutna tunnel-IP-adresserna. Se först till att BGP-sessionen är igång och verifiera sedan att rätt vägar tas emot från den dedikerade instansen och att rätt standardväg skickas till den dedikerade instansen.

Om GRE-tunneln är aktiv, kontrollera att en ping lyckas mellan den lokala och fjärranslutna GRE-tunnelns IP-adress. Om pingen lyckas men BGP-sessionen inte uppstår, undersök BGP-loggen för BGP-etableringsfel.

Några av de vanligaste BGP-förhandlingsproblemen är:

  • Fjärr-AS-numret matchar inte AS-numret som är konfigurerat på sidan Dedicated Instance. Kontrollera konfigurationen av grann-AS igen.

  • Det lokala AS-numret matchar inte vad den dedicerade instanssidan förväntar sig. Kontrollera att det lokala AS-numret matchar de förväntade parametrarna för den dedicerade instansen.

  • En brandvägg blockerar BGP TCP-paket inkapslade i GRE-paket från att skickas in i IPsec-tunneln eller tas emot från IPSEC-tunneln.

  • Den fjärranslutna BGP-grannens IP-adress matchar inte den fjärranslutna GRE-tunnelns IP-adress.

BGP-ruttbyte

När BGP-sessionen har verifierats för båda tunnlarna, se till att rätt vägar skickas och tas emot från den dedikerade instanssidan.

VPN-lösningen för dedikerade instanser förväntar sig att två tunnlar ska etableras från customer/partner sida. Den första tunneln pekar mot datacenter A för dedikerad instans och den andra tunneln pekar mot datacenter B för dedikerad instans. Båda tunnlarna måste vara i aktivt tillstånd och lösningen kräver en active/active spridning. Varje dedikerad instansdatacenter kommer att annonsera sina lokala /25 rutt såväl som en /24 reservväg. När du kontrollerar inkommande BGP-vägar från Dedicated Instance, se till att BGP-sessionen som är associerad med tunneln som pekar mot Dedicated Instance-datacenter A tar emot Dedicated Instance-datacenter A. /25 lokal rutt såväl som /24 reservväg. Se dessutom till att tunneln som pekar mot dedikerad instansdatacenter B tar emot dedikerad instansdatacenter B. /25 lokal rutt såväl som /24 reservväg. Observera att /24 Säkerhetskopieringsvägen kommer att vara samma rutt som annonseras från dedikerad instans datacenter A och dedikerad instans datacenter B.

Redundans tillhandahålls till ett dedikerat instansdatacenter om tunnelgränssnittet till det datacentret går ner. Om anslutningen till dedikerad instansdatacenter A bryts, kommer trafiken att vidarebefordras från dedikerad instansdatacenter B till datacenter A. I det här scenariot kommer tunneln till datacenter B att använda datacenter B. /25 rutten för att skicka trafik till datacenter B och tunneln till datacenter B kommer att använda säkerhetskopian /24 rutt för att skicka trafik till datacenter A via datacenter B.

Det är viktigt att när båda tunnlarna är aktiva så används inte datacenter A-tunneln för att skicka trafik till datacenter B och vice versa. I det här scenariot, om trafik skickas till datacenter A med destinationen datacenter B, kommer datacenter A att vidarebefordra trafiken till datacenter B och sedan försöker datacenter B skicka trafik tillbaka till källan via tunneln för datacenter B. Detta kommer att resultera i suboptimal routing och kan också bryta trafik som passerar brandväggar. Därför är det viktigt att båda tunnlarna är i en active/active konfiguration under normal drift.

De 0.0.0.0/0 Rutten måste annonseras från kundsidan till den dedikerade instansens datacentersida. Mer specifika rutter kommer inte att accepteras av den dedikerade instanssidan. Se till att 0.0.0.0/0 Rutten annonseras från både den dedikerade instansens datacentertunnel A och den dedikerade instansens datacentertunnel B.

MTU-konfiguration

På sidan Dedikerad instans är två funktioner aktiverade för att dynamiskt justera MTU för stora paketstorlekar. GRE-tunneln lägger till fler rubriker till IP-paketen som flödar genom VPN-sessionen. IPsec-tunneln lägger till de extra rubrikerna ovanpå GRE-rubrikerna vilket ytterligare minskar den största MTU som tillåts över tunneln.

GRE-tunneln justerar MSS-funktionen och GRE-tunnelns sökväg i MTU-identifieringsfunktionen är aktiverad på den dedikerade instanssidan. 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 den dynamiska justeringen av MTU för trafik genom VPN-tunneln.