- Start
- /
- Artikel
Tack för din feedback.
Dedikerad instans-Virtual Connect
I den här artikeln
Har du feedback?Virtual Connect är ett extra tilläggsalternativ för molnanslutning till Webex Calling Dedikerad instans. Virtual Connect gör det möjligt för kunder att säkert utöka sitt privata nätverk över internet med hjälp av punkt-till-punkt IP VPN-tunnlar. Här diskuterar vi om beställning, aktivering och konfiguration för Virtual Connect.
Introduktion
Virtual Connect är ett extra tilläggsalternativ för molnanslutning till dedikerad instans för Webex Calling (Dedikerad instans). Virtual Connect gör det möjligt för kunder att säkert utöka sitt privata nätverk över internet med hjälp av punkt-till-punkt IP VPN-tunnlar. Det här anslutningsalternativet ger en snabb etablering av privat nätverksanslutning genom att använda befintlig CPE (Customer Premise Equipment) och internetanslutning.
Cisco är värd för, hanterar och säkerställer redundanta IP-VPN-tunnlar och nödvändig internetåtkomst i Ciscos datacenterregion (er) för dedikerade instanser där tjänsten krävs. På samma sätt är administratören ansvarig för deras motsvarande CPE- och internettjänster som krävs för etablering av Virtual Connect.
Varje Virtual Connect-order i en viss region för dedikerad instans skulle innehålla två generiska routingkapslingstunnlar (GRE) skyddade av IPsec-kryptering (GRE över IPsec), en till varje Ciscos datacenter i den valda regionen.
Virtual Connect har en bandbreddgräns på 250 Mbps per tunnel och rekommenderas för mindre driftsättningar. Eftersom två punkt-till-punkt-VPN-tunnlar används måste all trafik till molnet gå igenom kundens huvudänds CPE, och därför kanske det inte är lämpligt där det finns många avlägsna platser. För andra alternativa peering-alternativ, se Cloud Connectivity.
Innan du skickar peering-begäran för Virtual Connect, se till att tjänsten Dedikerad instans är aktiverad i respektive region.
Förutsättningar
Förutsättningarna för att etablera Virtual Connect inkluderar:
-
Kunden tillhandahåller
-
Internetanslutning med tillräckligt med tillgänglig bandbredd för att stödja distributionen
-
Offentlig IP-adress (er) för två IPsec-tunnlar
-
Kundens GRE-transport-IP-adresser för de två GRE-tunnlarna
-
-
Partner och kund
-
Arbeta tillsammans för att utvärdera bandbreddskrav
-
Se till att nätverksenheter stöder BGP-routing (Border Gateway Protocol) och en GRE över IPsec-tunneldesign
-
-
Partner eller kund tillhandahåller
-
Nätverksteam med kunskap om VPN-tunnelteknologier från plats till plats
-
Nätverksteam med kunskap om BGP, eBGP och allmänna routingprinciper
-
-
Cisco
-
Cisco tilldelade privata autonoma systemnummer (ASN) och övergående IP-adressering för GRE-tunnelgränssnitt
-
Cisco tilldelade publikt men inte internetroutbart klass C (/24) nätverk för dedikerad instans Molnadressering
-
Om en kund bara har en CPE-enhet kommer de två tunnlarna mot Ciscos datacenter (DC1 och DC2) i varje region att komma från den CPE-enheten. Kunden har också ett alternativ för 2 CPE-enheter, då ska varje CPE-enhet endast ansluta till en tunnel mot Ciscos datacenter (DC1 och DC2) i varje region. Ytterligare redundans kan uppnås genom att varje tunnel avslutas på en separat fysisk plats/plats inom kundens infrastruktur.
Tekniska detaljer
Distributionsmodell
Virtual Connect använder en headend-arkitektur med dubbla nivåer, där routing- och GRE-kontroll planen tillhandahålls av en enhet och IPsec-kontrollplanet tillhandahålls av en annan.
När Virtual Connec t-anslutningen är klar skapas två GRE över IPsec-tunnlar mellan kundens företagsnätverk och Ciscos datacenter för dedikerade instanser. Ett till varje redundant datacenter inom respektive region. Ytterligare nätverkselement som krävs för peering byts ut av partnern eller kunden till Cisco via aktiveringsformuläret Control Hub Virtual Connect.
Figuren nedan visar exemplet på distributionsmodellen för virtuell anslutning för alternativet 2-koncentrator på kundsidan.
Virtual Connect - VPN är en hub-design där kundens hubplatser är anslutna till DC1 och DC2 i Dedicated Instances datacenter inom en viss region.
Två hubplatser rekommenderas för bättre redundans, men One Hub-plats med två tunnlar är också en distributionsmodell som stöds.
Bandbredden per tunnel är begränsad till 250 Mbps. För att säkerställa effektiv failover får den kombinerade trafiken över båda tunnlarna inte överstiga 250 Mbps, eftersom all trafik kommer att diriger as genom en tunnel i händelse av ett fel.
Kundens fjärrplatser inom samma region skulle behöva ansluta tillbaka till hubplatsen/platserna via kundens WAN och det är inte Ciscos ansvar för den anslutningen.
Partners förväntas arbeta nära kunderna för att säkerställa att den mest optimala vägen väl js för Virtual Connect-tjänster egionen.
Figuren nedan visar peeringsområdena för molnanslutning för dedikerade instanser.
Routing
Routing for Virtual Connect-tillägget implementeras med hjälp av extern BGP (eBGP) mellan Dedicated Instance och Customer Premise Equipment (CPE). Cisco kommer att annonsera sitt respektive nätverk för varje redundant DC inom en region till kundens CPE och CPE måste annonsera en standardrutt till Cisco.
-
Cisco underhåller och tilldelar
-
Tunnelgränssnitt IP-adressering (övergående länk för routing) Cisco tilldelar från ett utsett delat adressutrymme (ej offentligt dirigerbart)
-
Adress för tunneltransport (Ciscos sida)
-
Privata autonoma systemnummer (ASN) för kundens BGP-routningskonfiguration
-
Cisco tilldelar från det angivna området för privat användning: 64512 till 65534
-
-
-
EBGP används för att utbyta rutter mellan Dedicated Instance och CPE
-
Cisco delar upp det tilldelade/24-nätverket i 2/25 för varje DC i respektive region
-
I Virtual Connect annonseras varten/25-nätverk tillbaka till CPE av Cisco via respektive punkt-till-punkt-VPN-tunnlar (övergående lä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 på varje fjärrtunnel. Om du använder två CPE kommer varje CPE att ha en eBgP-granne som ponerar 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 var och en av tunnlarna
-
CPE ansvarar för att omfördela, efter behov, de inlärda vägarna inom kundens företagsnätverk.
-
-
Om länkfel inte misslyckas kommer en enda CPE att ha två aktiva/aktiva tunnlar. För två CPE-noder kommer varje CPE att ha en aktiv tunnel och båda CPE-noderna ska vara aktiva och passera trafik. I scenariot utan fel måste trafiken delas upp i två tunnlar som går till rätt /25 destinationer, om en av tunnelerna går ner kan den återstående tunneln bära trafiken för båda. Under ett sådant felscenario, när /25-nätverket är nere, används /24-nätverket som en backup-rutt. Cisco kommer att skicka kundtrafik via sitt interna WAN till DC som förlorade anslutningen.
Virtuellt anslutningstrafikflöde
Trafikflöde när båda tunnlarna är uppe
Den här bilden illustrerar en Virtual Connec t-nätverksarkitektur, som beskriver trafik flödet när både primära och sekundära tunnlar är i drift.
Det representerar en aktiv anslutningsmodell för en kund för att få tillgång till UC-applikationer som finns i Ciscos datacenter och utnyttjar dubbla GRE/IPSEC-tunnlar över internet med BGP för ruttutbyte.
Definitioner:
- Kundpremiss:
- 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 CallingD@@ edikerade instansdatacenter (dedikerade instanser) (WXC-Di DC-
A och WXC-Di DC-B):
- Dessa är Ciscos datacenter som är värd för UC-applikationerna.
- DC-A och DC-B är geografiskt åtskilda och ger redundans.
- Varje datacenter har sitt eget undernät för UC-applikationer:
- DC-A-delnät: X.X.X.0/25
- DC-B-delnät: 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 via det offentliga internet.
- GRE (Generic Routing Encapsulation): Detta protokoll används för att inkapsla olika nätverkslagerprotokoll inuti virtuella punkt-till-punkt-länkar. Det tillåter routing protokoll som BGP att fungera över tunneln.
- IPsec (Internet Protocol Security): Denna svit av 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.
- B@@ order Gateway Protocol (BGP):
- BGP är routningsprotokollet som används för att utbyta routningsinformation mellan kundens lokaler och C iscos datacenter.
Som visas i diagrammet ovan måste enheter som distribueras i kundens lokaler etablera två GRE/IPSEC-tunnlar.
Namnkonventionerna som används nedan med XX/YY, DC-A DC-B är generiska för alla regioner där Dediker ad 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 tillhandahålls under aktiveringen av den virtuella anslutningen.
På Cisco-sidan kommer IPsec- och GRE-tunnlarna att avslutas på olika enheter. Så kunden måste se till att konfigurera IPsec-destination och GRE-destinations-IP på enheterna i enlighet därmed. Kunder kan använda samma IP för GRE och IPSEC om den stöds på deras enheter. Se diagrammet ovan. IP-relaterade värden tillhandahålls vid aktivering av den virtuella anslutningen på portalen.
- Tunnel 1: Ansluter kundens lokaler till ”Dedikerad instans DC-A” (datacenter A) via Internet. Denna tunnel använder BGP AS: 64XX1 på kundsidan och BGP AS: 64XX2 på DC-A-sidan med dedikerad instans. IPSEC- och GRE-tunnelkällkonfigurationerna är uppdelade mellan kundtillhandahållna och Cisco-tillhandahållna detaljer.
- Tunnel 2: Ansluter kundens lokaler till ”Dedikerad instans DC-B” (datacenter B) via Internet. Denna tunnel använder BGP AS: 64YY1 på kundsidan och BGP AS: 64YY2 på DC-B-sidan för dedikerad instans. Liksom Tunnel 1 delas IPSEC- och GRE-tunnelkäll konfigurationer 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-tunnlarna har etablerats till datacenter för Webex Calling dedikerade instanser (A och B) bör kunden få följande rutter som annonseras från Cisco över motsvarande BGP-sessioner.
- För DC-A: Rutter som annonseras från Cisco kommer att vara X.X.0/25 och X.X.0/24. Eventuellt om IaaS begärs och konfigureras för kundrutterna kommer YY.Y.0/25 och Y.Y.0/24 att annonseras från Cisco.
- För DC-B: Rutter som annonseras från Cisco kommer att vara X.X.128/25 och X.X.X.0/24. Eventuellt om IaaS begärs och konfigureras för kundrutterna kommer YY.Y.128/25 och Y.Y.0/24 att annonseras från Cisco.
- Kunden måste annonsera 0.0.0./0-rutten till Cisco genom båda anslutningarna (tunnlar)
- Kunden måste följa de längsta prefixrutterna (/25) 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.0/25) från kundlokalen flyter genom tunnel 1.
- Trafik som är avsedd för ”DC-B UC Apps” (X.X.128/25) från kundens anläggning flyter genom Tunnel 2.
Misslyckande scenario: trafikflöde när en av tunnelerna är nere
Som visas i diagrammet ovan när tunneln till DC-A är nere kommer bgp etablerad genom tunneln till DC-A att gå ner.
Påverkan på BGP: När tunnel 1 går ner kommer BGP-sessionen över tunneln också att gå ner. Följaktligen kommer DC-A inte längre att kunna annonsera sina rutter (specifikt X. X.0/25) till kunden via denna sökväg. Därför kommer kundens router att upptäcka sökvägen som oåtkomlig.
Eftersom Tunnel 1 är nere kommer kundens router på kundens anläggning automatiskt att ta bort de rutter som lärts via Tunnel 1 från sin routingtabell eller markera dem som oåtkomliga.
- Trafik avsedd för UC App Network (X.X.0/24) eller DC-A-undernätet (X.X.0/25) kommer sedan att omdirigeras genom arbetstunneln mot DC-B som fortsätter att marknadsföra X.X.0/24 som inkluderar X.X.0/25-nätverket.
- Liknande beteende kommer att ses om tunneln till DC-B är nere medan tunneln till DC-A fortfarande är uppe.
Anslutningsprocess
| 1 | |
| 2 | |
| 3 | |
| 4 |
Steg 1: CCW-beställning
Virtual Connect är ett tillägg för dedikerad instans i CCW.
| 1 |
Navigera till CCW-beställningssidan och klicka sedan på Logga in för att logga in på webbplatsen: |
| 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 antal och antal regioner där Virtual Connect krävs. Antalet virtuella anslutningar bör inte överstiga det totala antalet regioner som köpts för Dedikerad instans. Dessutom är endast en Virtual Connect-beställning tillåten per region. |
| 8 |
När du är nöjd med dina val klickar du på Verifiera och spara längst upp till höger på sidan. |
| 9 |
Klicka på Spara och fortsätt för att slutföra din beställning. Din slutgiltiga beställning visas nu i orderrutnätet. |
Steg 2: Aktivering av Virtual Connect i Control Hub
| 1 |
Logga in på Control Hub https://admin.webex.com/login. |
| 2 |
I avsnittet Tjän ster navigerar du till Samtal > Dedikerad instacnce > Molnanslutning. |
| 3 |
På Virtual Connect-kortet visas den köpta Virtual Connect-kvantiteten. Administratören kan nu klicka på Aktivera för att initiera Virtual Connect-aktiveringen. 
Aktiveringsprocessen kan endast utlösas av administratörer med rollen ”Fullständig kundadministratör”. En administratör med rollen ”Kundskrivskyddad administratör” kan bara visa statusen. |
| 4 |
När du klickar på knappen Akti vera visas formuläret Aktivera virtuell anslutning för administratören för att tillhandahålla de tekniska detaljer för Virtual Connect som krävs för peering-konfigurationerna på Ciscos sida. Formuläret ger också statisk information på Ciscos sida, baserat på den valda regionen. Denna information kommer att vara användbar för kundadministratörer att konfigurera CPE på sin sida för att upprätta anslutningen. |
| 5 |
Klicka på knappen Akti vera när alla obligatoriska fält är fyllda. |
| 6 |
När formuläret Virtual Connect Activation är ifyllt för en viss region kan kunden exportera aktiveringsformuläret från Control Hub, Ring > Dedikerad instans > Molnanslutning fliken 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 visa detsamma i Control Hub genom att klicka på Visa inställningar under Control Hub, Ring > Dedikerad instans > fliken Cloud Connectivity. |
Steg 3: Cisco utför nätverkskonfiguration
| 1 |
När formuläret Aktivering av virtuell anslutning har slutförts uppdateras statusen till Pågående aktivering i Samtal > D edikerad instans > Cloud Connectivity Virtual Connect-kort. |
| 2 |
Cisco kommer att slutföra de nödvändiga konfigurationerna på Ciscos sidoutrustning inom 5 arbetsdagar. När slutförandet har slutförts uppdateras statusen till ”Aktiverad” för just den regionen i Control Hub. |
Steg 4: Kunden utför nätverkskonfiguration
|
Statusen ändras till ”Aktiverad” för att meddela Kundens administratör att Ciscos sida av konfigurationer för IP-VPN-anslutningen har slutförts baserat på de ingångar som tillhandahålls av kunden. Men, kundadministratören förväntas slutföra sin sida av konfigurationerna på CPE: erna och testa anslutningsvägarna för att Virtual Connect-tunneln ska vara online. Om det uppstår problem vid konfigurationen eller anslutningen kan kunden kontakta Cisco TAC för hjälp. |
Felsökning
IPsecs första fas (IKEv2-förhandling) Felsökning och validering
IPsec-tunnelförhandlingen omfattar två faser, IKEv2-fasen och IPsec-fasen. Om IKEv2-fasförhandlingen inte slutförs initieras ingen andra IPsec-fas. Utfärda först kommandot ”visa crypto ikev2 sa” (på Cisco-utrustning) eller liknande kommando på tredjepartsutrustningen för att verifiera om IKEv2-sessionen är aktiv. Om IKEv2-sessionen inte är aktiv kan de potentiella orsakerna vara:
-
Intressant trafik utlöser inte IPsec-tunneln.
-
IPsec-tunnelåtkomstlistan är felkonfigurerad.
-
Det finns ingen anslutning mellan kunden och IPsec-tunnelslutpunktens IP för dedikerad instans.
-
IKEv2-sessionsparametrarna matchar inte mellan den dedikerade instanssidan och kundsidan.
-
En brandvägg blockerar IKEv2 UDP-paketen.
Kontrollera först IPsec-loggarna för eventuella meddelanden som visar förloppet för IKEv2-tunnelförhandlingen. Loggarna kan indikera var det finns ett problem med IKEv2-förhandlingen. Brist på loggningsmeddelanden kan också indikera att IKEv2-sessionen inte aktiveras.
Några vanliga fel med IKEv2-förhandlingen är:
-
Inställningarna för IKEv2 på CPE-sidan matchar inte Cisco-sidan, 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å sidan Dedikerad instans.
När ”GCM” -krypteringen används hanterar GCM-protokollet autentiseringen och ställer in autentiseringsparametern till NULL.
-
Kontrollera livstidsinställningen.
-
Kontrollera Diffie Hellman-modulgruppen.
-
Kontrollera inställningarna för Pseudo Random Function.
-
-
Åtkomstlistan för kryptokartan är inte inställd på:
-
Tillstånd 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 och ”IP” -protokollet fungerar inte.
-
Om loggmeddelandena inte visar någon förhandlingsaktivitet för IKEv2-fasen kan en paketupptagning behövas.
Dedikerad instanssida kanske inte alltid startar IKEv2-utbytet och kan ibland förvänta sig att kundens CPE-sida är initiativtagaren.
Kontrollera CPE-sidans konfiguration för följande förutsättningar för IKEv2-sessionsinitiering:
-
Sök efter en IPsec-krypto-åtkomstlista för GRE-trafik (protokoll 50) från CPE-tunneltransport-IP till tunneltransport-IP för dedikerad instans.
-
Se till att GRE-tunnelgränssnittet är aktiverat för GRE keepalives, om utrustningen inte stöder GRE keepalives meddelas Cisco eftersom GRE keepalives kommer att aktiveras på Dedicated Instance-sidan som standard.
-
Se till att BGP är aktiverat och konfigurerat med grannadressen för den dedikerade instanstunnelns IP.
När den är korrekt konfigurerad startar IPsec-tunneln och IKEv2-förhandlingen i första fasen:
-
GRE håller från GRE-tunnelgränssnittet på CPE-sidan till GRE-tunnelgränssnittet på dedikerad instans.
-
BGP granne TCP-session från CPE-sidan BGP-granne till BGP-grannen på dedikerad instans.
-
Ping från CPE-sidetunnelns IP-adress till IP-adressen för sidotunneln för dedikerad instans.
Ping kan inte vara tunneltransport-IP till tunneltransport IP, det måste vara tunnel IP till tunnel IP.
Om en paketspårning behövs 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 i mitten av IPsec-slutpunkterna).
Kontrollera att IKEv2 UDP-paket med port 500 eller 4500 skickas och tas emot till och från DI IPsec-IP-adressen.
Datacentret för dedikerade instanser kanske inte alltid startar 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 också en ping till fjärr-IPsec-adressen. Om pingen inte lyckas från lokal IPsec-adress till fjärradress utför du en spårningsväg för att hjälpa till och avgöra var paketet släpps.
Vissa brandväggar och internetutrustning kanske inte tillåter spårväg.
IPsec andra fas (IPsec-förhandling) Felsökning och validering
Kontrollera att IPsecs första fas (det vill säga IKEv2-säkerhetsassociationen) är aktiv innan du felsöker IPsecs andra fas. Utför ett ”show crypto ikev2 sa” eller motsvarande kommando för att verifiera IKEv2-sessionen. Kontrollera i utgången att IKEv2-sessionen har varit uppe i mer än några sekunder och att den inte studsar. Sessionens drifttid visas som sessionen ”Aktiv tid” eller motsvarande i utdata.
När IKEv2-sessionen har verifierats som aktiv undersöker du IPsec-sessionen. Precis som med IKEv2-sessionen utför du 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 kontrollerar du IPsec-loggarna för felmeddelanden eller förhandlingsfel.
Några av de vanligaste problemen som kan uppstå under IPsec-förhandlingarna är:
Inställningarna på CPE-sidan matchar inte sidan Dedikerad instans, kontrollera inställningarna igen:
-
Kontrollera att parametrarna Kryptering och Autentisering matchar inställningarna på sidan Dedikerad instans.
-
Kontrollera inställningarna för Perfect Forward Secrecy och att inställningarna matchar på sidan Dedicated Instance.
-
Kontrollera livstidsinställningarna.
-
Kontrollera att IPsec har konfigurerats i tunnelläge.
-
Kontrollera käll- och mål-IPsec-adresserna.
Felsökning och validering av tunnelgränssnitt
När IPsec- och IKEv2-sessionerna verifieras som uppe och aktiva kan GRE-tunnelns keepalive-paket flöda mellan slutpunkterna Dedicated Instance och CPE-tunneln. Om tunnelgränssnittet inte visar status är några vanliga problem:
-
Tunnelgränssnittstransportens VRF matchar inte VRF för loopback-gränssnittet (om VRF-konfiguration används på tunnelgränssnittet).
Om VRF-konfigurationen inte används i tunnelgränssnittet kan denna kontroll ignoreras.
-
Keepalives är inte aktiverade på CPE-sidetunnelgränssnittet
Om keepalives inte stöds på CPE-utrustningen måste Cisco meddelas så att standardvärdena på den dedikerade instanssidan också är inaktiverade.
Om keepalives stöds, kontrollera att keepalives är aktiverade.
-
Masken eller IP-adressen för tunnelgränssnittet är inte korrekt och matchar inte de förväntade värdena för dedikerad instans.
-
Källa- eller destinationstunnelns transportadress är inte korrekt och matchar inte de förväntade värdena för dedikerad instans.
-
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 uppe och anslutningen är bra till fjärrtunnelgränssnittet. Utför pingkontrollen från tunnelns IP (inte transport-IP) till fjärrtunnelns IP.
Kryptoåtkomstlistan för IPsec-tunneln som bär GRE-tunneltrafiken tillåter endast GRE-paket att korsa. Som ett resultat kommer ping inte att fungera från tunneltransport IP till fjärrtunneltransport IP.
Ping-kontrollen resulterar i ett GRE-paket som genereras från källtunneltransport-IP till destinationstunneltransport-IP medan nyttolasten för GRE-paketet (den inre IP) kommer att vara källa- och destinationstunnelns IP.
Om ping-testet inte lyckas och föregående objekt verifieras, då kan en paketupptagning krävas för att säkerställa att icmp-ping resulterar i ett GRE-paket som sedan inkapslas i ett IPsec-paket och sedan skickas från käll-IPsec-adressen till destinationens IPsec-adress. Räknare på GRE-tunnelgränssnittet och IPsec-sessionsräknarna kan också hjälpa till att visa. om skicka och ta emot paket ökar.
Förutom ping-trafiken bör fångsten också 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 också över VPN.
BGP Felsökning och validering
BGP-sessioner
BGP krävs som routningsprotokoll över VPN IPsec-tunneln. Den lokala BGP-grannen bör upprätta en eBGP-session med BGP-grannen för dedikerad instans. EBgP-grannens IP-adresser är desamma som de lokala och fjärrtunnelns IP-adresser. Kontrollera först att BGP-sessionen är igång och kontrollera sedan att rätt rutter tas emot från Dedicated Instance och att rätt standardrutt skickas till Dedicated Instance.
Om GRE-tunneln är uppe, kontrollera att en ping är framgångsrik mellan den lokala och fjärranslutna GRE-tunneln IP. Om pingen lyckas men BGP-sessionen inte kommer upp, undersök sedan BGP-loggen för BGP-etableringsfel.
Några av de vanligaste BGP-förhandlingsfrågorna är:
-
Fjärr-AS-numret matchar inte AS-numret som är konfigurerat på sidan Dedikerad instans, kontrollera grannens AS-konfiguration igen.
-
Det lokala AS-numret överensstämmer inte med vad sidan Dedikerad instans förväntar sig. Kontrollera att det lokala AS-numret matchar de förväntade parametrarna för dedikerad instans.
-
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-grann-IP-adressen matchar inte den fjärranslutna GRE-tunnel-IP-adressen.
BGP-ruttutbyte
När BGP-sessionen har verifierats för båda tunnlarna, se till att rätt rutter skickas och tas emot från den dedikerade instanssidan.
VPN-lösningen för dedikerad instans förväntar sig att två tunnlar ska etableras från kund/partnersidan. Den första tunneln pekar till datacentret för dedikerad instans A och den andra tunneln pekar till datacentret för dedikerad instans B. Båda tunnlarna måste vara i aktivt tillstånd och lösningen kräver en aktiv/aktiv driftsättning. Varje datacenter med dedikerad instans kommer att annonsera sin lokala /25-rutt samt en /24-backup-rutt. När du kontrollerar inkommande BGP-rutter från Dedikerad instans ska du se till att BGP-sessionen som är associerad med tunneln som pekar på datacenter A för dedikerad instans tar emot den lokala rutten för datacenter A /25 samt säkerhetskopieringsrutten /24. Se dessutom till att tunneln som pekar mot datacenter B för dedikerad instans tar emot den lokala rutten för datacenter B /25 samt backup-rutten /24. Observera att säkerhetskopieringsrutten /24 kommer att vara samma rutt som annonseras från datacenter A för dedikerad instans och datacenter B.
Redundans tillhandahålls till ett datacenter med dedikerad instans om tunnelgränssnittet till det datacentret går ner. Om anslutningen till datacenter A för dedikerad instans går förlorad vidarebefordras trafik från datacenter B för dedikerad instans till datacenter A. I det här scenariot använder tunneln till datacenter B vägen B /25 för att skicka trafik till datacenter B och tunneln till datacenter B kommer att använda backup-/24-rutten för att skicka trafik till datacenter A via datacenter B.
Det är viktigt att när båda tunnlarna är aktiva att datacenter A-tunnel inte används för att skicka trafik till datacenter B och vice versa. I det här scenariot, om trafik skickas till datacenter A med en destination för datacenter B, kommer datacenter A att vidarebefordra trafiken till datacenter B och sedan kommer datacenter B att försöka skicka trafik tillbaka till källan via datacenter B-tunneln. Detta kommer att resultera i suboptimal routing och kan också bryta trafikkorsande brandväggar. Därför är det viktigt att båda tunnlarna är i en aktiv/aktiv konfiguration under normal drift.
Rutten 0.0.0.0/0 måste annonseras från kundsidan till datacentersidan för dedikerad instans. Mer specifika rutter accepteras inte av den dedikerade instanssidan. Se till att rutten 0.0.0.0/0 annonseras från både tunneln för dedikerad instans datacenter A och datacenter B-tunneln för dedikerad instans.
MTU-konfiguration
På sidan Dedicated Instance ä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 flyter genom VPN-sessionen. IPsec-tunneln lägger till ytterligare rubriker ovanpå GRE-rubrikerna för att ytterligare minska den största tillåtna MTU över tunneln.
GRE-tunneln justerar MSS-funktionen och GRE-tunnelbanan i MTU-upptäcktsfunktionen är aktiverad på sidan Dedicated Instance. Konfigurera ”ip tcp just-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 för trafik genom VPN-tunneln.
