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 in peering-begäran om virtuell anslutning ska du se till att tjänsten dedikerad instans ä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

Distributionsmodell

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.

Figur 1 visar ett exempel på distribueringsmodellen för Virtual Connect för alternativet 2-koncentrator 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.

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.

Partner förväntas jobba i nära samarbete med kunderna, vilket säkerställer att den mest optimala sökvägen väljs för tjänsteregionen "Virtual Connect".

Figur 2 visar de dedikerade peeringområdena för molnanslutning.

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.

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. IP-adress för transport av GRE-tunnel: 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. IPS-kolleger: 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 visa detta i Control Hub genom att klicka på Visa inställningar under fliken Samtal > Dedikerad instans > 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 IP-sek första fasen (IKEv2 Negotiation)

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

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

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

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

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

  • En brandvägg blockerar IKEv2 UDP-paketen.

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

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

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

    • Kontrollera att IKE-versionen är version 2.

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

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

    • Verifiera livstidsinställningen.

    • Verifiera modulusgruppen Diffie Hellman.

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

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

    • Tillstånd GRE (local_tunnel_transport_ip) 255.255.255.255.255 remote_tunnel_transport_ip() 255.255.255.255" (eller motsvarande kommando)

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

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

Sidan för dedikerad instans kanske inte alltid startar IKEv2-utbytet och kan ibland förvänta sig att kundens CPE-sida ska vara initiatorn.

Kontrollera konfigurationen av CPE-sidan för följande förutsättningar för initiering av IKEv2-sessionen:

  • Kontrollera om du har en IP-sec kryptoåtkomstlista för GRE-trafik (protokoll 50) från CPE-tunneltransport-IP till den dedikerade instans-tunneltransport-IP.

  • Se till att gränssnittet för GRE-tunneln är aktiverat för GRE-keepalives. Om utrustningen inte har stöd för GRE-keepalives meddelas Cisco eftersom GRE-keepalives kommer att aktiveras på sidan Dedikerad instans som standard.

  • Kontrollera att BGP är aktiverat och konfigurerat med grannadressen till den dedikerade instans-IP-tunneln.

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

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

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

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

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

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

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

Datacenter för dedikerad instans kanske inte alltid startar det första IKE v2-paketet. Kravet är att CPE-enheten kan initiera det första IKEv2-paketet mot sidan Dedikerad instans.

Om den lokala brandväggen tillåter det kan du också försöka en ping till fjärradressen IP-sek. Om ping inte lyckas från lokal till fjärransluten IP-sek-adress utför du en spårningsväg för att hjälpa till och bestämma var paketet tappas.

Vissa brandväggar och Internet-utrustning tillåter eventuellt inte spårningsväg.

Felsökning och validering av IP-sek andra fasen (IP-sek Negotiation)

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

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

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

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

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

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

  • Verifiera livstidsinställningarna.

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

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

Felsökning och validering av tunnelgränssnittet

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

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

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

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

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

    Om keepalives stöds kontrollerar du att keepalives är aktiverade.

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

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

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

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

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

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

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

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

BGP-felsökning och validering

BGP-sessioner

BGP krävs som routningsprotokoll över VPN IPsec tunnel. Den lokala BGP-grannen ska upprätta en eBGP-session med den dedikerade instansens BGP-granne. EBGP-grannens IP-adresser är samma som lokala och fjärrtunnels IP-adresser. Kontrollera först att BGP-sessionen är igång och kontrollera sedan att de korrekta rutorna tas emot från Dedicated Instance och att den korrekta standardrouten skickas till Dedicated Instance.

Om GRE-tunneln är igång ska du kontrollera att en ping har lyckats mellan lokal och fjärrstyrd GRE-tunnel-IP. Om ping lyckas men BGP-sessionen inte kommer upp ska du undersöka BGP-loggen för BGP-etableringsfel.

Några av de vanligaste frågorna i förhandlingarna om BGP är:

  • Det fjärranslutna AS-numret matchar inte det AS-nummer som har konfigurerats på sidan Dedikerad instans. Kontrollera konfigurationen av granne AS på nytt.

  • Det lokala AS-numret matchar inte 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 inkapslat i GRE-paket från att skickas in i IPsec-tunneln eller tas emot från IPSEC-tunneln

  • Fjärransluten BGP-granne-IP matchar inte fjärransluten GRE-tunneln-IP.

BGP-dirigeringsbyte

När BGP-sessionen har verifierats för båda tunnlarna ska du se till att de rätta vägarna skickas och tas emot från sidan Dedikerad instans.

VPN-lösningen för dedikerad instans förväntar sig att två tunnlar ska upprättas från kund-/partnersidan. Den första tunneln pekar på datacenter A och den andra tunneln pekar på datacenter B. Båda tunnlarna måste vara i aktivt tillstånd och lösningen kräver aktiv/aktiv distribution. Varje datacenter för dedikerad instans kommer att annonsera dess lokala /25-route samt en /24-backuproute. När du kontrollerar inkommande BGP-rutter från Dedicated Instance ska du se till att BGP-sessionen som är associerad med tunneln som pekar mot Dedicated Instance-datacenter A får den lokala rutten för Dedicated Instance-datacenter A /25 samt säkerhetskopieringsrutten /24. Kontrollera dessutom att tunneln som pekar mot datacenter B får den lokala rutten för dedikerad instans B och säkerhetskopieringsrutten för dedikerad instans B /25. Observera att säkerhetskopieringsvägen /24 kommer att annonseras på samma rutt utanför datacenter A och datacenter B för dedikerad instans.

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

När båda tunnlarna är aktiva är det viktigt att datacenter A-tunneln inte används för att skicka trafik till datacenter B och vice versa. I detta scenario, om trafiken 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 tillbaka trafiken till källan via datacenter B-tunneln. Detta kommer att resultera i sub-optimal dirigering och kan även bryta trafikgenomfartsbrandvä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 sidan Dedikerad instans datacenter. Mer specifika rutter kommer inte att accepteras av den dedikerade instansens sida. Se till att 0.0.0.0/0-rutten annonseras från både Dedicated Instance-datacenter A-tunneln och Dedicated Instance-datacenter B-tunneln.

MTU-konfiguration

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

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