Alternativet Virtual Connect hjälper till att på ett säkert sätt utöka sitt privata nätverk över internet med hjälp av punkt-till-punkt IP VPN-tunnlar.
Inledning
Virtual Connect är ett ytterligare 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 på ett säkert sätt 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 en privat nätverksanslutning med hjälp av befintlig utrustning för kundlokaler (CPE) och internetanslutning.
Cisco är värd för, hanterar och säkerställer redundanta IP VPN-tunnlar och den nödvändiga internetåtkomsten i Ciscos datacenterregion(er) för dedikerade instanser där tjänsten krävs. På samma sätt ansvarar administratören för sina motsvarande CPE- och Internettjänster som krävs för etablering av virtuell anslutning.
Varje beställning av virtuell anslutning i en viss region för dedikerad instans skulle innehålla två GRE-tunnlar (Generic Routing Encapsulation) som skyddas av IPSec-kryptering (GRE over IPSec), en till varje Ciscos datacenter i den valda regionen.
Virtual Connect har en bandbreddsgräns på 250 Mbit/s per tunnel och rekommenderas för mindre distributioner. Eftersom två punkt-till-punkt VPN-tunnlar används måste all trafik till molnet gå via kundens headend CPE, och därför kanske det inte är lämpligt där det finns många fjärrplatser. För andra alternativa peering-alternativ, se Molnanslutning .
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
Offentliga IP-adress för två IPSec-tunnlar
GRE-transport av IP-adresser på kundsidan för de två GRE-tunnlarna
Partner och kund
Samarbeta för att utvärdera bandbreddskrav
Se till att nätverksenhet stöd för BGP-routning (Border Gateway Protocol) och en GRE over IPSec-tunneldesign
Partner eller kund tillhandahåller
Nätverksteam med kunskap om plats-till-plats VPN-tunnelteknik
Nätverksteam med kunskaper i BGP, eBGP och allmänna routningsprinciper
Cisco
Cisco har tilldelat privata autonooma systemnummer (ASN) och tillfällig IP-adressering för GRE-tunnelgränssnitt
Cisco tilldelat offentligt men inte dirigerbart nätverk av klass C (/24) via Internet för dedikerad molnadressering för instanser
 |
Om en kund bara har 1 CPE-enhet kommer de 2 tunnlarna mot Ciscos datacenter (DC1 och DC2) i varje region att vara från den CPE-enheten. Kunden har även ett alternativ för 2 CPE-enheter, därefter ska varje CPE-enhet anslutas till 1 tunnel endast 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. |
Teknisk information
Distributionsmodell
Virtual Connect använder en headend-arkitektur med dubbla nivåer, där routnings- och GRE-kontrollplanen tillhandahålls av en enhet och IPSec-kontrollplanen tillhandahålls av en annan.
Efter avslutad Virtuell anslutning anslutningsmöjligheter kommer två GRE over IPSec-tunnlar att skapas mellan kundens företagsnätverk och Ciscos dedikerade instansers datacenter. En till varje redundant datacenter inom respektive region. Ytterligare nätverkselement som krävs för peering utbyter av partnern eller kunden till Cisco via aktiveringsformuläret för Control Hub Virtual Connect.
Bild 1 visar ett exempel på distributionsmodell Virtual Connect för alternativet med två koncentratorer på kundsidan.
Virtuell anslutning – VPN är en Hub-design där kundens Hub-platser är anslutna till DC1 och DC2 i Dedicated Instances datacenter inom en viss region.
Två Hub-platser rekommenderas för bättre redundans, men En Hub-plats med två tunnlar distributionsmodell också.
|
Bandbredden per tunnel är begränsad till 250 Mbit/s. |
 |
Kundens fjärrplatser inom samma region skulle behöva ansluta tillbaka till Hub-webbplatserna via kundens WAN och det är inte Ciscos ansvar för den anslutningen. |
Partners förväntas ha ett nära samarbete med kunderna för att säkerställa att den mest optimala sökvägen väljs för tjänsteregionen ”Virtual Connect”.
I figur 2 visas peeringregioner för dedikerad molnanslutning för instanser.
Dirigering
Routning för tillägget Virtual Connect implementeras med hjälp av extern BGP (eBGP) mellan dedikerad instans och Customer Premise Equipment (CPE). Cisco kommer att annonsera sina respektive nätverk för varje redundant DC inom en region till kundens CPE och CPE krävs för att annonsera en standardrutt till Cisco.
Cisco underhåller och tilldelar
Tunnelgränssnittets IP-adressering (transient länk för dirigering) Cisco tilldelar från ett utsett delat adressutrymme (ej offentligt dirigerbar)
Destinationsadress för tunneltransport (Ciscos sida)
Privata autonoma systemnummer (ASN) för kundens BGP-routningskonfiguration
Cisco tilldelar från det angivna intervallet för privat användning: 64512 till 65534
eBGP används för att utbyta rutter mellan dedikerad instans och CPE
Cisco kommer att dela upp det tilldelade /24-nätverket i 2/25 ett för varje DC i respektive region
I Virtual Connect annonseras varje /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, varav en pekar mot varje fjärrtunnel. Om du använder två CPE kommer varje CPE att ha en eBGP-granne som pekar mot den enda fjärrtunneln för CPE.
Cisco sidan av varje GRE-tunnel (tunnel interface 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 vid behov omdistribuera de inlärda rutterna inom kundens företagsnätverk.
Om länken inte fungerar fel 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. Vid icke-fel-scenario måste trafiken delas upp i två tunnlar som går till rätt /25-destinationer. Om en av tunnlarna går ner kan den återstående tunneln bära trafik för båda. I ett sådant felscenario, när /25-nätverket är nere, används /24-nätverket som en reservrutt. Cisco skickar kundtrafik via sitt interna WAN till den DC som förlorade anslutningen.
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ällningswebbplatsen 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 | På prenumerationsfliken som visas väljer du Alternativ och Tillägg. |
||
| 6 | Under Ytterligare tillägg markerar du kryssrutan bredvid ”Virtual Connect for dedikerad instans”. SKU-namnet är ”A-FLEX-DI-VC”. |
||
| 7 | Ange antal och antal regioner där Virtual Connect krävs.
|
||
| 8 | När du är nöjd med dina val klickar du på Bekräfta och spara längst upp till höger på sidan. |
||
| 9 | Klicka på Spara och fortsätt för att slutföra beställningen. Din slutförda beställning visas nu i beställningsrutnätet. |
Steg 2: Aktivering av Virtual Connect i Control Hub
| 1 | Logga in på Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | I Tjänster avsnitt, navigera till Samtal > Dedikerad Instacnce > Molnanslutning . |
||||||||
| 3 | På Virtual Connect-kortet visas den köpta kvantiteten för Virtual Connect. Administratören kan nu klicka på Aktivera för att initiera aktiveringen av virtuell anslutning. 
|
||||||||
| 4 | När du klickar på Aktivera knapp, Aktivera virtuell anslutning formuläret visas där administratören kan tillhandahålla den tekniska information om virtuell anslutning som krävs för peering-konfigurationer på Ciscos sida.
|
||||||||
| 5 | Klicka på Aktivera när alla obligatoriska fält är ifyllda. |
||||||||
| 6 | När formuläret för aktivering av virtuell anslutning har fyllts i för en viss region kan kunden exportera aktiveringsformuläret från Control Hub, Samtal > Dedikerad instans > fliken Molnanslutning och klicka på Exportinställningar. 
|
Steg 3: Cisco utför nätverkskonfiguration
| 1 | När formuläret för aktivering av virtuell anslutning har fyllts i uppdateras statusen till Aktivering pågår i Samtal > Dedikerad instans > Cloud Connectivity Virtual Connect-kort. |
| 2 | Cisco kommer att slutföra nödvändiga konfigurationer på Ciscos sida utrustning inom 5 arbetsdagar . När programmet är klart uppdateras statusen till ”Aktiverad” för just den regionen i Control Hub. |
Steg 4: Kunden utför nätverkskonfigurationen
Statusen ändras till ”Aktiverad” för att meddela kundadministratören att Ciscos sida av konfigurationer för IP VPN-anslutning har slutförts baserat på indata från 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 tidpunkten för konfigurationen eller anslutningen kan kunden kontakta Cisco TAC för att få hjälp. |
Felsökning
IPsec First Phase (IKEv2 Negotiation) Felsökning och validering
IPsec-tunnelförhandlingen omfattar två faser, IKEv2-fasen och IPsec-fasen. Om IKEv2-fasförhandlingen inte slutförs startas ingen andra IPsec-fas. Utför först kommandot ”show 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 möjliga orsakerna vara:
Intressant trafik utlöser inte IPsec-tunneln.
Åtkomstlistan för IPsec-tunnlar är felkonfigurerad.
Det finns ingen anslutning mellan kunden och den dedikerade slutpunkts-IPsec-instansens IPsec-tunnel.
IKEv2-sessionsparametrarna matchar inte mellan sidan för dedikerad instans och kundsidan.
En brandvägg blockerar IKEv2 UDP-paket.
Kontrollera först i IPsec-loggarna om det finns meddelanden som visar förloppet för IKEv2-tunneln. Loggarna kan indikera om det finns ett problem med IKEv2-förhandlingen. Brist på loggningsmeddelanden kan också indikera att IKEv2-sessionen inte aktiveras.
Inställningarna för IKEv2 på CPE-sidan stämmer inte överens med Cisco . Kontrollera inställningarna igen:
Kontrollera att IKE-versionen är version 2.
Kontrollera att parametrarna för kryptering och autentisering matchar den förväntade krypteringen på sidan för dedikerad instans.
När ”GCM”-chifferet används hanterar GCM-protokollet autentiseringen och anger att autentiseringsparametern ska vara NULL.
Kontrollera livstidsinställningen.
Kontrollera Diffie Hellman-modulgruppen.
Kontrollera inställningarna för pseudoslumpfunktion.
Å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 och ”IP”-protokollet fungerar inte.
Om loggmeddelandena inte visar någon förhandlingsaktivitet för IKEv2-fasen kan en pakethämtning behövas.
|
Sidan med dedikerad instans kanske inte alltid startar IKEv2-utbytet och ibland förväntar sig kundens CPE-sida som initiativtagare. Kontrollera att CPE-sidans konfiguration har följande förutsättningar för IKEv2-sessionsinitiering:
|
När den har konfigurerats korrekt startar följande IPsec-tunneln och den första IKEv2-förhandlingen:
GRE keepalives från GRE-tunnelgränssnittet på CPE-sidan till GRE-tunnelgränssnittet på sidan för dedikerad instans.
BGP-granne TCP-session från BGP-granne på CPE-sidan till BGP-granne på sidan för dedikerad instans.
Ping från CPE-sidotunnelns IP-adress till IP-adressen för sidotunneln för dedikerad instans .
Ping kan inte vara tunneltransportens IP till tunneltransportens IP, det måste vara tunnelns IP till tunnelns IP.
Om en paketspårning krävs för IKEv2-trafik anger du filtret för UDP och antingen port 500 (när ingen NAT-enhet befinner sig i mitten av IPsec-slutpunkterna) eller port 4500 (när en NAT-enhet är införd i mitten av IPsec slutpunkter).
Kontrollera att IKEv2 UDP-paket med port 500 eller 4500 skickas och tas emot till och från DI IPsec IP-adress.
|
Datacentret för dedikerad instans kanske inte alltid startar det första IKEv2-paketet. Kravet är att CPE-enheten kan initiera det första IKEv2-paketet mot sidan för dedikerad instans. Om den lokala brandväggen tillåter det försöker du även att plinga till fjärr-IPsec-adressen. Om ping inte lyckas från den lokala IPsec-adressen till fjärr-IPsec-adressen ska du utföra en spårningsrutt för att hjälpa till och avgöra var paketet har släppts. Vissa brandväggar och internetutrustning tillåter eventuellt inte spårningsrutt. |
IPsec Second Phase (IPsec Negotiation) Felsökning och validering
Kontrollera att den första fasen i IPsec (det vill säga IKEv2-säkerhetskopplingen) är aktiv innan du felsöker den andra fasen i IPsec. Utför kommandot ”show crypto ikev2 sa” eller motsvarande för att verifiera IKEv2-sessionen. I utdata kontrollerar du 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 och aktiv undersöker du IPsec-sessionen. Precis som med IKEv2-sessionen utför du kommandot ”show crypto ipsec sa” eller motsvarande för att verifiera IPsec-sessionen. Både IKEv2-sessionen och IPsec-sessionen måste vara aktiva innan GRE-tunneln etableras. Om IPsec-sessionen inte visas som aktiv ska du kontrollera om det finns felmeddelanden eller förhandlingsfel i IPsec-loggarna.
Några av de vanligaste problemen som kan uppstå under IPsec-förhandlingarna är:
Inställningarna på CPE-sidan stämmer inte överens med sidan för dedikerad instans. Kontrollera inställningarna igen:
Kontrollera att parametrarna för kryptering och autentisering matchar inställningarna på sidan för dedikerad instans.
Kontrollera inställningarna för Perfect Forward-sekretess och att inställningarna matchar på sidan för dedikerad instans.
Kontrollera livstidsinställningarna.
Kontrollera att IPsec har konfigurerats i tunnelläge.
Kontrollera käll- och destinations-IPsec-adressen.
Felsökning och validering av tunnelgränssnittet
När IPsec- och IKEv2-sessionerna har verifierats som aktiva kan Keepalive-paketen i GRE-tunneln flyta mellan den dedikerade förekomsten och slutpunkterna i CPE-tunneln. Om status för tunnelgränssnittet inte visas är några vanliga problem:
Transport-VRF för tunnelgränssnitt matchar inte VRF för loopback-gränssnittet (om VRF-konfiguration används i tunnelgränssnittet).
Om VRF-konfigurationen inte används i tunnelgränssnittet kan denna kontroll ignoreras.
Keepalives är inte aktiverade i CPE-sidotunnelns gränssnitt
Om keepalives inte stöds på CPE-utrustningen måste Cisco meddelas så att standard-keealives på sidan för dedikerad instans också inaktiveras.
Om Keepalives stöds kontrollerar du att Keepalives är aktiverade.
Masken eller IP-adress för tunnelgränssnittet är felaktig och matchar inte förväntade värden för dedikerad instans.
Källans eller destinationstunnelns transportadress är felaktig och matchar inte förväntade värden 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 via IPsec-tunneln)
Ett pingtest bör verifiera att det lokala tunnelgränssnittet är aktiverat och att anslutningen är god till fjärrtunnelgränssnittet. Utför ping-kontrollen från tunnelns IP (inte transport IP) till fjärrtunnelns IP.
|
Krypteringsåtkomstlistan för IPsec-tunneln som överför GRE-tunneltrafiken tillåter endast att GRE-paket korsas. Därför fungerar ping inte 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) blir käll- och destinationstunnelns IP.
Om ping-testet inte lyckas och de föregående objekten verifieras kan en pakethämtning krävas för att säkerställa att icmp-pingen resulterar i ett GRE-paket som sedan kapslas in i ett IPsec-paket och sedan skickas från käll-IPsec-adressen till destinationens IPsec-adress. Räknare i GRE-tunnelgränssnittet och IPsec-sessionsräknare kan också hjälpa till att visas. om sändnings- och mottagningspaketen ökar.
Utöver ping-trafiken bör infångningen även visa Keepalive GRE-paket även under inaktiv trafik. Slutligen, om BGP har konfigurerats, bör Keepalive-paket av BGP även skickas som GRE-paket inkapslade i IPSEC-paket via 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-grannnen för dedikerad instans. eBGP:s grann-IP-adresser är samma som de lokala IP-adresserna 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 dedikerad instans och att rätt standardrutt skickas till dedikerad instans.
Om GRE-tunneln är igång kontrollerar du att en ping har genomförts mellan den lokala IP-adressen för GRE-tunneln och den fjärranslutna tunneln. Om pingningen lyckas men BGP-sessionen inte kommer igång ska du undersöka BGP-loggen efter BGP-etableringsfel.
Några av de vanligaste problemen med BGP-förhandling är:
Fjärr-AS-numret stämmer inte överens med AS-numret som är konfigurerat på sidan för dedikerad instans. Kontrollera konfigurationen för grann-AS på nytt.
Det lokala AS-numret stämmer inte överens med vad sidan för 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 till IPsec-tunneln eller tas emot från IPSEC-tunneln
Fjärr-BGP-grann-IP:en matchar inte GRE-fjärrtunnelns IP.
BGP Route Exchange
När BGP-sessionen har verifierats för båda tunnlarna kontrollerar du att rätt rutter skickas och tas emot från sidan för dedikerad instans.
VPN-lösningen för dedikerad instans förväntar sig att två tunnlar etableras från kund-/partnersidan. Den första tunneln pekar på datacenter A för dedikerad instans och den andra tunneln till datacenter B för dedikerad instans. Båda tunnlarna måste vara i aktivt läge och lösningen kräver en aktiv/aktiv distribution. Varje datacenter för dedikerad instans kommer att annonsera sin lokala /25-rutt samt en /24-backuprutt. När du kontrollerar inkommande BGP-rutter från dedikerad instans ska du se till att BGP-sessionen som är kopplad till tunneln som pekar mot datacenter A för dedikerad instans tar emot den lokala rutten /25 för datacenter A /24 för dedikerad instans. Kontrollera dessutom att tunneln som pekar mot datacenter B för dedikerad instans tar emot den lokala rutten för datacenter B /25 för dedikerad instans samt /24-backupvägen. Observera att /24-backupvägen kommer att vara samma väg som annonseras ut från datacenter A för dedikerad instans och datacenter B för dedikerad instans.
Redundans ges till ett dedikerat datacenter om tunnelgränssnittet till det datacentret går ner. Om anslutningen till datacenter A för dedikerad instans bryts kommer trafik att vidarebefordras från datacenter B för dedikerad instans till datacenter A. I det här scenariot kommer tunneln till datacenter B att använda rutten för datacenter B/25 för att skicka trafik till datacenter B och tunneln till datacenter B använder rutten /24 för säkerhetskopiering för att skicka trafik till datacenter A via datacenter B.
När båda tunnlarna är aktiva är det viktigt att tunneln i datacenter A inte används för att skicka trafik till datacenter B och vice versa. Om trafik i det här scenariot 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 tillbaka trafik till källan via datacenter B-tunneln. Detta kommer att resultera i suboptimal dirigering och kan även störa trafik som korsar brandväggar. Därför är det viktigt att båda tunnlarna är i 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 sidan för dedikerad instans. Se till att rutten 0.0.0.0/0 annonseras ut från både tunneln för datacenter A för dedikerad instans och tunneln för datacenter B för dedikerad instans.
MTU-konfiguration
På sidan för dedikerad instans är två funktioner aktiverade för att dynamiskt justera MTU för stora paketstorlekar. GRE-tunneln lägger till fler rubriker i IP-paketen som flödar genom VPN-sessionen. IPsec-tunneln lägger till ytterligare rubriker ovanpå GRE-rubrikerna kommer att ytterligare minska den största tillåtna MTU över tunneln.
GRE-tunneln justerar MSS-funktionen och GRE-tunnelsökvägen i MTU-identifieringsfunktionen är aktiverad på sidan för 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 för trafik genom VPN-tunneln.