Inledning

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

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

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

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

Innan du skickar peering-begäran för 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.

Bilden nedan visar exemplet på distributionsmodellen för virtuell anslutning för alternativet med 2-koncentratorer på kundsidan.

Virtuell anslutning – VPN är en hubbdesign där kundens hubbwebbplatser är anslutna till DC1 och DC2 av dedikerade instansens datacenter inom en viss region.

Två Hub-webbplatser rekommenderas för bättre redundans, men One Hub-webbplatser med två tunneler är också en distributionsmodell som stöds.

Bandbredden per tunnel är begränsad till 250 Mbit/s.

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

Partners förväntas samarbeta nära med Kunderna och se till att den mest optimala sökvägen väljs för tjänsteregionen Virtuell anslutning .

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

Regioner för virtuell anslutning

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

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

  2. IPSec-kollegor: 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 det 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 slutför de nödvändiga konfigurationerna på Ciscos sidoutrustning inom fem arbetsdagar. När slutförandet är slutförd kommer statusen att uppdateras till "Aktiverad" för den specifika regionen i Control Hub.

Steg 4: Kunden utför nätverkskonfiguration

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

Felsökning

Felsökning och validering av IPsec första fas (IKEv2-balansering)

IPsec-tunnelförhandling omfattar två faser, IKEv2-fasen och IPsec-fasen. Om IKEv2-fasförhandling inte slutförs, initieras inte en andra IPsec-fas. Först utfärdar du kommandot ”visa crypto ikev2 sa” (på Cisco-utrustning) eller liknande kommando på tredjeparts utrustning 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 IPsec-tunneln.

  • IPsec-tunnelåtkomstlistan är felaktigt konfigurerad.

  • Det finns ingen anslutning mellan kunden och slutpunkten för IPsec-tunnel 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 i IKEv2-förhandlingen är:

  • Inställningarna för IKEv2 på CPE-sidan stämmer inte överens med Cisco-sidan. Kontrollera de angivna inställningarna igen:

    • 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"-chiffren används hanterar GCM-protokollet autentiseringen och ställer in autentiseringsparametern på NULL.

    • Verifiera livstidsinställningen.

    • Verifiera modulgruppen Diffie Hellman.

    • 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” (eller motsvarande kommando)

      Åtkomstlistan måste vara specifik för "GRE"-protokollet och "IP"-protokollet kommer inte att fungera.

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

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

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

  • Sök efter en IPsec-kryptoåtkomstlista för GRE-trafik (protokoll 50) från CPE-tunneltransport-IP till Dedicated Instance-tunneltransport-IP.

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

  • Se till att BGP är aktiverat och konfigurerat med närliggande adress till tunnel-IP för dedikerad instans.

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

  • GRE-keepalives från GRE-tunnelgränssnittet på CPE-sidan till GRE-tunnelgränssnittet på sidan Dedikerad instans.

  • BGP-granne TCP-session från BGP-granne på CPE-sidan till BGP-granne på sidan Dedikerad instans.

  • Ping från CPE-sidotunnelns IP-adress till IP-adressen för den dedikerade instansen.

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

Om en paketspårning krävs för IKEv2-trafik ställer du in filtret för UDP och antingen port 500 (när ingen NAT-enhet befinner sig mitt i IPsec-slutpunkterna) eller port 4500 (när en NAT-enhet infogas 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-adressen.

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 Dedikerad instans.

Om den lokala brandväggen tillåter det kan du även försöka pinga till den fjärranslutna IPsec-adressen. Om ping inte lyckas från lokal IPsec-adress till fjärr-IPsec-adress utför du en spårningsväg som hjälp och fastställer var paketet tas bort.

Vissa brandväggar och internetutrustning kanske inte tillåter spårningsväg.

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

Kontrollera att den första fasen av IPsec (dvs. IKEv2-säkerhetsanslutningen) är aktiv innan du felsöker den andra fasen av IPsec. Utför ett "show crypto ikev2 sa" eller motsvarande kommando för att verifiera IKEv2-sessionen. Kontrollera i utmatningen 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 verifieras som aktiv och aktiv Undersöker du IPsec-sessionen. Precis som med IKEv2-sessionen, utför ett "show crypto ipsec sa" eller motsvarande kommando för att verifiera IPsec-sessionen. Både IKEv2-sessionen och IPsec-sessionen måste vara aktiva innan GRE-tunneln upprättas. Om IPsec-sessionen inte visas som aktiv 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 stämmer inte överens med den dedikerade instanssidan. 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 vidarebefordran av sekretess och att matchningsinställningarna finns på sidan Dedikerad instans.

  • Kontrollera livslängdsinställningarna.

  • Kontrollera att IPsec har konfigurerats i tunnelläge.

  • Verifiera IPsec-adresserna för källa och mål.

Felsökning och validering av tunnelgränssnitt

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

  • VRF för tunnelgränssnittets transport stämmer inte överens med 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:s sidtunnelgränssnitt

    Om det inte finns stöd för keepalives på CPE-utrustningen måste Cisco aviseras så att standardkeepalives på sidan Dedikerad instans också inaktiveras.

    Om det finns stöd för keepalives kontrollerar du att keepalives är aktiverade.

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

  • Överföringsadressen för käll- 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 att skickas till IPsec-tunneln eller tas emot från IPsec-tunneln (GRE-tunneln transporteras över IPsec-tunneln)

Ett pingtest 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 tunnelns IP (inte transport-IP) till fjärrtunnelns IP.

Kryptoåtkomstlistan för IPsec-tunneln som bär GRE-tunneltrafik tillåter endast GRE-paket att korsa. Därför fungerar inte ringsignaler från tunneltransport-IP till fjärrtunneltransport-IP.

Ping-kontrollen resulterar i ett GRE-paket som genereras från källtunnelöverförings-IP till destinationstunnel, medan nyttolasten för GRE-paketet (den inre IP-adressen) kommer att vara käll- och destinationstunnel-IP.

Om ping-testet inte lyckas och föregående objekt verifieras kan en paketfångst krävas 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äll-IPsec-adressen till destinations-IPsec-adressen. Räknare i GRE-tunnelgränssnittet och IPsec-sessionsräknare kan också vara till hjälp för att visa. om skicka och ta emot paket ökar.

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

BGP felsökning och validering

BGP-sessioner

BGP krävs som dirigeringsprotokoll över VPN IPsec-tunneln. Den lokala BGP-grannen bör upprätta en eBGP-session med BGP-grannen för dedikerad instans. IP-adresserna för eBGP-granne är samma som IP-adresserna för lokal tunnel och fjärrtunnel. Kontrollera först att BGP-sessionen är igång och kontrollera sedan att rätt vägar tas emot från Dedikerad instans och att rätt standardväg skickas till Dedikerad instans.

Om GRE-tunneln är igång kontrollerar du att en ping lyckades mellan GRE-tunnelns lokala och fjärranslutna IP-adress. Om ping lyckas men BGP-sessionen inte kommer upp ska du undersöka BGP-loggen för BGP-etableringsfel.

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

  • Det fjärranslutna AS-numret stämmer inte överens med AS-numret som har konfigurerats på sidan Dedikerad instans. Kontrollera grannens AS-konfiguration igen.

  • Det lokala AS-numret stämmer inte överens med vad sidan för dedikerad instans förväntas. Kontrollera att det lokala AS-numret överensstämmer med de förväntade parametrarna för dedikerad instans.

  • En brandvägg blockerar BGP TCP-paket som ingår i GRE-paket från att skickas till IPsec-tunneln eller tas emot från IPSEC-tunneln

  • IP för fjärransluten BGP-granne stämmer inte överens med GRE-tunnelns IP.

BGP-ruttbyte

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

Dedikerad instans VPN-lösning förväntar sig att två tunnlar etableras från kund-/partnersidan. Den första tunneln pekar på datacentret A för dedikerad instans och den andra tunneln pekar på datacentret B för dedikerad instans. Båda tunnlarna måste vara i aktivt tillstånd och lösningen kräver en 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-vägar från Dedikerad instans ska du se till att BGP-sessionen som är associerad med tunneln som pekar på Dedikerad instans datacenter A tar emot den lokala rutten för Dedikerad instans A/25 samt reservrutten för /24. Se dessutom till att tunneln som pekar på Dedikerad instans datacenter B får den lokala routningen för Dedikerad instans B/25 samt reservroutningen för /24. Observera att säkerhetskopieringsvägen /24 kommer att vara samma väg som annonseras utanför Dedikerad instans datacenter A och Dedikerad instans datacenter B.

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 kommer trafiken att vidarebefordras från datacenter B till datacenter A. I det här fallet kommer tunneln till datacenter B att använda datacenter B/25-rutten för att skicka trafik till datacenter B och tunneln till datacenter B kommer att använda säkerhetskopieringsrutten /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-tunnel inte används för att skicka trafik till datacenter B och vice versa. I det här fallet, om trafik skickas till datacenter A med en destination för datacenter B, vidarebefordrar datacenter A trafiken till datacenter B och sedan försöker datacenter B skicka tillbaka trafiken till källan via datacenter B-tunneln. Detta leder till suboptimal dirigering och kan även bryta trafikbrandvä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 vägar godkänns inte av sidan Dedikerad instans. Se till att 0.0.0.0/0-rutten annonseras ut från både datacenter för dedikerad instans A-tunnel och datacenter för dedikerad instans B-tunnel.

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 till IP-paket som flödar genom VPN-sessionen. IPsec-tunneln lägger till de ytterligare rubrikerna ovanpå GRE-rubrikerna och minskar ytterligare den största tillåtna MTU-gränsen i 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 "tunnelpath\u0002mtu-discovery" eller motsvarande kommando på kundens sida för att hjälpa till med dynamisk justering av MTU för trafik genom VPN-tunneln.