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 .


Innan du skickar in peering-begäran för Virtual Connect måste du 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

    • 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.

Routning

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

Följande steg på hög nivå beskriver hur du upprättar anslutningar med virtuella Connect för dedikerad instans.

1

Gör en beställning i Cisco CCW

2

Aktivera virtuell anslutning från Control Hub

3

Cisco utför nätverkskonfiguration

4

Kunden utför nätverkskonfigurationen

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.


 
Kvantiteten för virtuell anslutning bör inte överskrida det totala antalet köpta regioner för dedikerad instans. Dessutom tillåts endast en beställning av virtuell anslutning per region.
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.


 
Aktiveringsprocessen kan endast utlösas av administratörer med rollen ”fullständig kundadministratör”. En administratör med rollen ”skrivskyddad kund admin” kan endast visa statusen.
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.


 
Formuläret innehåller även statisk information på Ciscos sida, baserat på vald region. Denna information kommer att vara användbar för kundadministratörer att konfigurera CPE på sin sida för att upprätta anslutningen.
  1. IP-adress för GRE IP-adress : Kunden måste tillhandahålla IP-adresser för tunneltransport på kundens sida och Cisco kommer dynamiskt att tilldela IP-adresserna när aktiveringen har slutförts. IPSec ACL for Interesting Traffic bör tillåta lokal tunneltransport IP/32 till fjärrtunneltransport IP/32. ACL bör också endast ange GRE IP-protokoll.


     
    IP-adress som kunden tillhandahåller kan vara privat eller offentlig.
  2. IPSec-peers : Kunden måste tillhandahålla IPSec-tunnelns käll-IP-adresser och Cisco tilldelar IPSec destinationens IP-adress. Det går även att utföra NAT-översättning av en intern IPSEC-tunneladress till en allmän adress vid behov.


     

    IP-adress som kunden tillhandahåller bör vara offentlig.


     
    All annan statisk information som visas på aktiveringsskärmen är säkerhets- och krypteringsstandarder på Ciscos sida som följs. Den här statiska konfigurationen kan inte anpassas eller ändras. För ytterligare hjälp med de statiska konfigurationerna på Ciscos sida måste kunden kontakta TAC.
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.


 
Av säkerhetsskäl kommer autentiseringen och BGP-lösenordet 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, Samtal > Dedikerad instans > fliken Molnanslutning.

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.

Några vanliga fel i IKEv2-förhandlingen är:
  • 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:

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

  • Kontrollera att GRE-tunnelgränssnittet är aktiverat för GRE Keepalives. Om utrustningen inte har stöd för GRE Keepalives aviseras Cisco eftersom GRE Keepalives kommer att vara aktiverat på sidan för dedikerad instans som standard.

  • Kontrollera att BGP är aktiverat och konfigurerat med grannadressen till IP-tunneln för dedikerad instans.

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.