Introduksjon

Virtual Connect er et ekstra tilleggsalternativ for skytilkobling til dedikert forekomst for Webex Calling (dedikert forekomst). Virtual Connect lar kunder utvide sitt private nettverk over internett på en sikker måte ved hjelp av punkt-til-punkt IP VPN-tunneler. Dette tilkoblingsalternativet gir en rask etablering av privat nettverkstilkobling ved hjelp av eksisterende CPE (Customer Premise Equipment) og Internett-tilkobling.

Cisco er vert for, administrerer og sikrer redundante IP VPN-tunneler og nødvendig Internett-tilgang i Ciscos dedikerte forekomst-datasenterregion(er) der tjenesten er nødvendig. På samme måte er administrator ansvarlig for sine tilsvarende CPE- og Internett-tjenester som kreves for etablering av Virtual Connect.

Hver Virtual Connect-bestilling i en bestemt dedikert forekomst-region vil omfatte to generiske routing encapsulation (GRE)-tunneler beskyttet av IPSec-kryptering (GRE over IPSec), én til hvert Ciscos datasenter i den valgte regionen.

Virtual Connect har en båndbreddegrense på 250 Mbps per tunnel og anbefales for mindre distribusjoner. Siden det brukes to punkt-til-punkt VPN-tunneler, må all trafikk til skyen gå gjennom kundehodeendens CPE, og det kan derfor hende at det ikke er egnet der det er mange eksterne nettsteder. For andre alternative peering-alternativer, se Skytilkobling .


 

Før du sender inn peering-forespørselen for Virtual Connect, må du kontrollere at tjenesten dedikert forekomst er aktivert i det respektive området.

Forutsetninger

Forutsetningene for å etablere Virtual Connect inkluderer:

  • Kunden gir

    • Internett-tilkobling med nok tilgjengelig båndbredde til å støtte distribusjonen

    • Offentlig(e) IP-adresse(r) for to IPSec-tunneler

    • GRE-transport-IP-adresser på kundesiden for de to GRE-tunnelene

  • Partner og kunde

    • Arbeid sammen for å evaluere båndbreddekrav

    • Sørg for at nettverksenhet støtter BGP-ruting (Border Gateway Protocol) og en GRE over IPSec-tunneldesign

  • Partner eller kunde gir

    • Nettverksteam med kunnskap om sted-til-sted VPN-tunnelteknologier

    • Nettverksteam med kunnskap om BGP, eBGP og generelle rutingsprinsipper

  • Cisco

    • Cisco tildelte private autonoumous systemnumre (ASN) og forbigående IP-adressering for GRE-tunnelgrensesnitt

    • Cisco tilordnet offentlig, men ikke rutebart Internett-nettverk i klasse C (/24) for dedikert skyadressering for forekomster


 

Hvis en kunde bare har én CPE-enhet, vil de to tunnelene mot Ciscos datasentre (DC1 og DC2) i hver region komme fra den aktuelle CPE-enheten. Kunden har også mulighet for 2 CPE-enheter, da skal hver CPE-enhet kobles til 1 tunnel kun mot Ciscos datasentre (DC1 og DC2) i hver region. Ytterligere redundans kan oppnås ved å avslutte hver tunnel på et eget fysisk sted/sted innenfor Kundens infrastruktur.

Tekniske detaljer

Distribusjonsmodell

Virtual Connect bruker en hodeendarkitektur med to lag, der ruting- og GRE-kontrollplanene leveres av én enhet og IPSec-kontrollplanet leveres av en annen.

Etter fullføring av Virtuell tilkobling tilkobling opprettes det to GRE over IPSec-tunneler mellom kundens bedriftsnettverk og Ciscos datasentre for dedikert forekomst. Én til hvert redundant datasenter i den respektive regionen. Ytterligere nettverkselementer som kreves for peering, utveksles av partneren eller kunden til Cisco via aktiveringsskjemaet for Control Hub Virtual Connect.

Figur 1 viser et eksempel på distribusjonsmodell for Virtual Connect for alternativet med to konsentratorer på kundesiden.

Virtual Connect – VPN er en Hub-design der kundens Hub-nettsteder er koblet til DC1 og DC2 i dedikerte forekomsters datasentre i en bestemt region.

To Hub-områder anbefales for bedre redundans, men One Hub-nettsted med to tunneler er også en støttet distribusjonsmodell.


 

Båndbredden per tunnel er begrenset til 250 Mbps.


 

Kundens eksterne nettsteder i samme region må koble seg tilbake til Hub-nettstedet(e) over kundens WAN, og det er ikke Ciscos ansvar for denne tilkoblingen.

Partnere forventes å samarbeide tett med kundene for å sikre at den mest optimale banen velges for tjenesteregionen Virtuell tilkobling.

Figur 2 viser noderegioner for dedikerte forekomster av skytilkobling.

Ruting

Ruting for Virtual Connect-tillegget implementeres ved hjelp av ekstern BGP (eBGP) mellom dedikert forekomst og Customer Premise Equipment (CPE). Cisco vil annonsere sine respektive nettverk for hver overflødig DC i en region til kundens CPE og CPE er påkrevd for å annonsere en standard rute til Cisco.

  • Cisco vedlikeholder og tilordner

    • IP-adressering for tunnelgrensesnitt (forbigående kobling for ruting) Cisco tilordner fra et angitt delt adresseområde (ikke offentlig rutingbar)

    • Destinasjonsadresse for tunneltransport (Ciscos side)

    • Private autonome systemnumre (ASN) for kundekonfigurasjon for BGP-ruting

      • Cisco tilordner fra det angitte området for privat bruk: 64512 til og med 65534

  • eBGP brukes til å utveksle ruter mellom dedikert forekomst og CPE

    • Cisco vil dele det tilordnede /24-nettverket i 2/25 én for hver DC i den respektive regionen

    • I Virtual Connect annonseres hvert /25-nettverk tilbake til CPE av Cisco via de respektive punkt-til-punkt VPN-tunnelene (forbigående kobling)

    • CPE må konfigureres med de riktige eBGP-naboene. Hvis du bruker én CPE, brukes to eBGP-naboer, én som peker til hver ekstern tunnel. Hvis du bruker to CPE, vil hver CPE ha én eBGP-nabo som peker til den enkelt eksterne tunnelen for CPE.

    • Cisco-siden av hver GRE-tunnel (tunnel interface IP) er konfigurert som BGP-nabo på CPE

    • CPE er påkrevd for å annonsere en standard rute over hver av tunnelene

    • CPE er ansvarlig for å omdistribuere, etter behov, de lærte rutene i kundens bedriftsnettverk.

  • Ved feil i koblingen vil en enkelt CPE ha to aktive/aktive tunneler. For to CPE-noder vil hver CPE ha én aktiv tunnel, og begge CPE-nodene skal være aktive og passere trafikk. Under scenariet ikke-feil må trafikken dele seg i to tunneler som går til riktige /25-destinasjoner, hvis en av tunnelen går ned, kan den gjenværende tunnelen bære trafikken for begge. I et slikt feilscenario, når /25-nettverket er nede, brukes /24-nettverket som en reserverute. Cisco vil sende kundetrafikk via sitt interne WAN mot DC-en som mistet tilkoblingen.

Tilkoblingsprosess

Følgende trinn på høyt nivå beskriver hvordan du oppretter tilkobling med virtuell tilkobling for dedikert forekomst.
1

Legg inn en bestilling i Cisco CCW

2

Aktiver Virtual Connect fra Control Hub

3

Cisco utfører nettverkskonfigurasjon

4

Kunden utfører nettverkskonfigurasjon

Trinn 1: CCW-rekkefølge

Virtual Connect er et tillegg for dedikert forekomst i CCW.

1

Naviger til CCW-bestillingsnettstedet, og klikk deretter på Logg på for å logge på nettstedet:

2

Opprett overslag.

3

Legg til «A-FLEX-3» SKU.

4

Velg Rediger alternativer.

5

I abonnementsfanen som vises, velger du Alternativer og Tillegg.

6

Under Flere tillegg merker du av i avmerkingsboks ved siden av «Virtual Connect for dedikert forekomst». SKU-navnet er «A-FLEX-DI-VC».

7

Angi antall og antall regioner der Virtual Connect er nødvendig.


 
Antallet Virtual Connect skal ikke overskride det totale antallet regioner som er kjøpt for dedikert forekomst. Dessuten er bare én Virtual Connect-bestilling tillatt per region.
8

Når du er fornøyd med valgene dine, klikker du på Bekreft og Lagre øverst til høyre på siden.

9

Klikk på Lagre og fortsett for å fullføre bestillingen. Den fullførte bestillingen vises nå i bestillingsrutenettet.

Trinn 2: Aktivering av Virtual Connect i Control Hub

1

Logg på Control Hub https://admin.webex.com/login .

2

I Tjenester -delen, gå til Anrop > Dedikert Instacnce > Skytilkobling .

3

På Virtual Connect-kortet er det kjøpte antallet Virtual Connect oppført. administrator kan nå klikke på Aktiver for å starte aktiveringen av Virtual Connect.


 
Aktiveringsprosessen kan bare utløses av administratorer med rollen «Fullstendig kundeadministrator». Mens en administrator med rollen «Kunde skrivebeskyttet administrator» bare kan vise statusen.
4

Ved å klikke på Aktiver knapp, Aktiver Virtuell tilkobling skjemaet vises slik at administrator kan oppgi de tekniske detaljene for Virtual Connect som kreves for peering-konfigurasjonene på Cisco-siden.


 
Skjemaet gir også statisk informasjon på Ciscos side, basert på valgt region. Denne informasjonen vil være nyttig for kundeadministratorer å konfigurere CPE på sin side for å etablere tilkobling.
  1. IP-adresse for GRE Tunnel Transport : Kunden er pålagt å oppgi IP-adresser for tunneltransport på kundens side, og Cisco vil dynamisk tildele IP-adressene når aktiveringen er fullført. IPSec ACL for Interesting Traffic skal tillate lokal tunneltransport IP/32 til ekstern tunneltransport IP/32. Tilgangskontrollisten skal også angi bare GRE IP-protokollen.


     
    IP-adresse oppgitt av kunden, kan være privat eller offentlig.
  2. IPSec-motparter : Kunden er pålagt å oppgi IPSec-tunnelens kilde-IP-adresser, og Cisco tildeler IPSec- destinasjons-IP-adresse. Utføring av NAT-oversettelse av en intern IPSEC-tunneladresse til en offentlig adresse støttes også om nødvendig.


     

    IP-adresse oppgitt av kunden, skal være offentlig.


     
    All annen statisk informasjon som vises på aktiveringsskjermen, er sikkerhets- og krypteringsstandardene på Cisco-siden som følges. Denne statiske konfigurasjonen kan ikke tilpasses eller endres. For ytterligere hjelp angående de statiske konfigurasjonene på Ciscos side, må kunden ta kontakt med TAC.
5

Klikk på Aktiver -knappen når alle de obligatoriske feltene er fylt ut.

6

Etter at skjemaet for aktivering av virtuell tilkobling er utfylt for et bestemt område, kan kunden eksportere aktiveringsskjemaet fra Control Hub, Calling > Dedikert forekomst > kategorien Skytilkobling og klikke på Eksporter innstillinger.


 
Av sikkerhetsmessige årsaker vil ikke autentiseringen og BGP-passordet være tilgjengelig i det eksporterte dokumentet, men administrator kan vise det samme i Control Hub ved å klikke på Vis innstillinger under Control Hub, Anrop > Dedikert forekomst > kategorien Skytilkobling.

Trinn 3: Cisco utfører nettverkskonfigurasjon

1

Når aktiveringsskjemaet for virtuell tilkobling er fullført, oppdateres statusen til Aktivering pågår i Calling > Dedikert forekomst > Cloud Connectivity Virtual Connect-kort.

2

Cisco vil fullføre de nødvendige konfigurasjonene på Cisco-siden utstyret innenfor 5 virkedager . Når fullføringen er fullført, oppdateres statusen til «Aktivert» for den bestemte regionen i Control Hub.

Trinn 4: Kunden utfører nettverkskonfigurasjon

Statusen endres til «Aktivert» for å varsle kundeadministratoren om at Ciscos side av konfigurasjonene for IP VPN-tilkoblingen er fullført basert på inndataene fra kunden. Det forventes imidlertid at administrator fullfører sin side av konfigurasjonene på CPE-ene og teste tilkoblingsrutene for at Virtual Connect-tunnelen skal være tilkoblet. Hvis det oppstår problemer på tidspunktet for konfigurasjonen eller tilkoblingen, kan kunden ta kontakt med Cisco TAC for å få hjelp.

Feilsøking

Feilsøking og validering for IPsec First Phase (IKEv2 Negotiation).

IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fullføres, er det ingen initiering av en andre IPsec-fase. Først gir du kommandoen «vis crypto ikev2 sa» (på Cisco-utstyr) eller en lignende kommando på tredjepartsutstyret for å bekrefte om IKEv2-økten er aktiv. Hvis IKEv2-økten ikke er aktiv, kan de potensielle årsakene være:

  • Interessant trafikk utløser ikke IPsec-tunnelen.

  • tilgangsliste for IPsec-tunnelen er feilkonfigurert.

  • Det er ingen tilkobling mellom kunden og IPsec-tunnelendepunktet for dedikert forekomst.

  • IKEv2-øktparametrene samsvarer ikke mellom den dedikerte forekomstsiden og kundesiden.

  • En brannmur blokkerer IKEv2 UDP-pakkene.

Kontroller først at IPsec-loggene ser etter meldinger som viser fremdriften for IKEv2-tunnelforhandlingen. Loggene kan indikere hvor det er et problem med IKEv2-forhandlingen. Mangel på loggmeldinger kan også indikere at IKEv2-økten ikke aktiveres.

Noen vanlige feil med IKEv2-forhandlingen er:

  • Innstillingene for IKEv2 på CPE-siden samsvarer ikke med Cisco-siden. Kontroller innstillingene som er nevnt på nytt:

    • Kontroller at IKE-versjonen er versjon 2.

    • Kontroller at parametrene for kryptering og godkjenning samsvarer med forventet kryptering på den dedikerte forekomst-siden.


       

      Når «GCM»-chifferen er i bruk, håndterer GCM-protokollen godkjenningen og angir autentiseringsparameteren til NULL.

    • Kontroller innstillingen for levetid.

    • Kontroller Diffie Hellman-modulgruppen.

    • Kontroller innstillingene for Pseudo-tilfeldig funksjon.

  • tilgangsliste for kryptokartet er ikke satt til:

    • Tillat GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (eller tilsvarende kommando)


       

      tilgangsliste må være spesifikt for «GRE»-protokollen, og «IP»-protokollen vil ikke fungere.

Hvis loggmeldingene ikke viser forhandlingsaktivitet for IKEv2-fasen, kan det hende at en pakkelagring er nødvendig.


 

Dedikert forekomstside starter kanskje ikke alltid IKEv2-utvekslingen og kan noen ganger forvente at kundens CPE-side er initiativtaker.

Kontroller konfigurasjonen av CPE-siden for følgende forutsetninger for IKEv2-øktstart:

  • Se etter en IPsec-krypteringstilgangsliste for GRE-trafikk (protokoll 50) fra CPE- tilgangsliste -IP-en til tunneltransport-IP for dedikert forekomst.

  • Kontroller at GRE-tunnelgrensesnittet er aktivert for GRE Keepalives. Hvis utstyret ikke støtter GRE Keepalives, blir Cisco varslet fordi GRE Keepalives vil bli aktivert på den dedikerte forekomst-siden som standard.

  • Kontroller at BGP er aktivert og konfigurert med naboadressen til den dedikerte forekomstens tunnel-IP.

Når den er riktig konfigurert, starter følgende IPsec-tunnelen og førstefase IKEv2-forhandlingen:

  • GRE keepalives fra GRE-tunnelgrensesnittet på CPE-siden til GRE-tunnelgrensesnittet for dedikert forekomst.

  • TCP-økt for BGP-nabo fra BGP-nabo på CPE-siden til BGP-nabo på dedikert forekomst.

  • Ping fra CPE-sidetunnelens IP-adresse til den dedikerte forekomstens IP- IP-adresse for sidetunnelen.


     

    Ping kan ikke være IP-adressen til tunneltransporten til tunnelens transport-IP-adresse, den må være IP-adressen fra tunnelen til tunnelen.

Hvis en pakkesporing er nødvendig for IKEv2-trafikken, angir du filteret for UDP og enten port 500 (når ingen NAT-enhet er midt i IPsec-endepunktene) eller port 4500 (når en NAT-enhet er satt inn i midten av IPsec endepunkter).

Kontroller at IKEv2 UDP-pakker med port 500 eller 4500 sendes og mottas til og fra DI IPsec IP-adresse.


 

Datasenteret for dedikert forekomst starter kanskje ikke alltid den første IKEv2-pakken. Kravet er at CPE-enheten er i stand til å starte den første IKEv2-pakken mot den dedikerte forekomstsiden.

Hvis den lokale brannmuren tillater det, kan du også prøve å pinge til den eksterne IPsec-adressen. Hvis pingingen ikke er vellykket fra lokal til ekstern IPsec-adresse, må du utføre en sporingsrute for å hjelpe og finne ut hvor pakken droppes.

Enkelte brannmurer og Internett-utstyr tillater kanskje ikke sporingsruter.

Feilsøking og validering for IPsec Second Phase (IPsec Negotiation).

Kontroller at IPsec-første fase (det vil si IKEv2-sikkerhetstilknytning) er aktiv før du feilsøker IPsec andre fase. Utfør en «vis crypto ikev2 sa» eller tilsvarende kommando for å bekrefte IKEv2-økten. I utdataene kontrollerer du at IKEv2-økten har vært oppe i mer enn noen få sekunder, og at den ikke returnerer. Oppetiden for økten vises som «Aktiv tid» for økten eller tilsvarende i utdata.

Når IKEv2-økten er bekreftet som oppe og aktiv, undersøker du IPsec-økten. Som med IKEv2-økten, utfører du en «vis crypto ipsec sa» eller tilsvarende kommando for å bekrefte IPsec-økten. Både IKEv2-økten og IPsec-økten må være aktive før GRE-tunnelen etableres. Hvis IPsec-økten ikke vises som aktiv, må du se etter feilmeldinger eller forhandlingsfeil i IPsec-loggene.

Noen av de vanligste problemene som kan oppstå under IPsec-forhandlingene er:

Innstillingene på CPE-siden samsvarer ikke med siden for dedikert forekomst. Kontroller innstillingene på nytt:

  • Kontroller at parametrene for kryptering og autentisering samsvarer med innstillingene på den dedikerte forekomst-siden.

  • Kontroller at innstillingene for Perfect Forward Secrecy og at innstillingene samsvarer med dedikert forekomst-siden.

  • Kontroller levetidsinnstillingene.

  • Kontroller at IPsec er konfigurert i tunnelmodus.

  • Kontroller kilde- og mål-IPsec-adressene.

Feilsøking og validering av tunnelgrensesnitt

Når IPsec- og IKEv2-øktene er bekreftet som oppe og aktive, kan Keepalive-pakkene for GRE-tunnelen flyte mellom den dedikerte forekomsten og CPE-tunnelendepunktene. Hvis status for tunnelgrensesnittet ikke vises, er noen vanlige problemer:

  • Transport-VRF for tunnelgrensesnitt samsvarer ikke med VRF for tilbakekoblingsgrensesnittet (hvis VRF-konfigurasjon brukes på tunnelgrensesnittet).


     

    Hvis VRF-konfigurasjonen ikke brukes på tunnelgrensesnittet, kan denne kontrollen ignoreres.

  • Keepalives er ikke aktivert i CPE-sidetunnelgrensesnittet


     

    Hvis keepalives ikke støttes på CPE-utstyret, må Cisco varsles slik at standard keepalives på den dedikerte forekomst-siden også deaktiveres.

    Hvis Keepalives støttes, må du kontrollere at Keepalives er aktivert.

  • Masken eller IP-adresse til tunnelgrensesnittet er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.

  • Kilde- eller måltunneltransportadressen er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.

  • En brannmur blokkerer GRE-pakker fra å sendes inn i IPsec-tunnelen eller mottas fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En ping-test skal bekrefte at det lokale tunnelgrensesnittet er oppe, og at tilkoblingen er god til det eksterne tunnelgrensesnittet. Utfør ping-kontrollen fra tunnel-IP-en (ikke transport-IP-en) til den eksterne tunnel-IP-en.


 

Krypteringstilgangslisten for IPsec-tunnelen som bærer GRE- tilgangsliste , tillater bare å krysse GRE-pakker. Som et resultat vil ikke ping fungere fra tunneltransport-IP til ekstern tunneltransport-IP.

Ping-kontrollen resulterer i en GRE-pakke som genereres fra transport-IP-en til kildetunnelen til transport-IP-en for måltunnelen, mens nyttelasten til GRE-pakken (den indre IP-adressen) vil være IP-adressen for kilden og måltunnelen.

Hvis ping-testen ikke er vellykket og de foregående elementene er bekreftet, kan det hende at en pakkelagring er nødvendig for å sikre at icmp-pingen resulterer i en GRE-pakke som deretter innkapsles i en IPsec-pakke og deretter sendes fra kildens IPsec-adresse til mål-IPsec-adressen. Tellere på GRE-tunnelgrensesnittet og IPsec-økttellerne kan også bidra til å vise. hvis sende- og mottakspakkene øker.

I tillegg til ping-trafikken, skal registreringen også vise keepalive GRE-pakker selv under inaktiv trafikk. Til slutt, hvis BGP er konfigurert, skal BGP keepalive-pakker også sendes som GRE-pakker innkapslet i IPSEC-pakker, i tillegg til via VPN.

BGP-feilsøking og -validering

BGP-økter

BGP kreves som rutingsprotokoll over VPN IPsec-tunnelen. Den lokale BGP-naboen bør etablere en eBGP-økt med den dedikerte BGP-naboen for forekomsten. eBGP-nabo-IP-adressene er de samme som de lokale og eksterne tunnel-IP-adressene. Kontroller først at BGP-økten er oppe, og kontroller deretter at de riktige rutene mottas fra dedikert forekomst, og at riktig standardrute sendes til dedikert forekomst.

Hvis GRE-tunnelen er oppe, kontrollerer du at en ping er vellykket mellom den lokale og den eksterne GRE-tunnel-IP-en. Hvis pingen er vellykket, men BGP-økten ikke kommer, kan du undersøke BGP-loggen for BGP-etableringsfeil.

Noen av de vanligste BGP-forhandlingsproblemene er:

  • Det eksterne AS-nummeret samsvarer ikke med AS-nummeret som er konfigurert på siden for dedikert forekomst. Kontroller konfigurasjonen av nabo-AS på nytt.

  • Det lokale AS-nummeret samsvarer ikke med det den Dedikerte forekomst-siden forventer. Kontroller at det lokale AS-nummeret samsvarer med de forventede parametrene for dedikert forekomst.

  • En brannmur blokkerer BGP TCP-pakker innkapslet i GRE-pakker fra å sendes inn i IPsec-tunnelen eller mottas fra IPSEC-tunnelen

  • Den eksterne BGP-nabo-IP-en samsvarer ikke med den eksterne GRE-tunnelens IP.

BGP-ruteutveksling

Når BGP-økten er bekreftet for begge tunnelene, må du kontrollere at de riktige rutene sendes og mottas fra siden for dedikert forekomst.

Den dedikerte VPN-løsningen for forekomst forventer at det etableres to tunneler fra kunde-/partnersiden. Den første tunnelen peker til datasenteret A for dedikert forekomst og den andre tunnelen til datasenteret B for dedikert forekomst. Begge tunnelene må være i aktiv tilstand, og løsningen krever en aktiv/aktiv distribusjon. Hvert dedikert forekomst-datasenter vil annonsere sin lokale /25-rute i tillegg til en /24-reserverute. Når du kontrollerer de innkommende BGP-rutene fra dedikert forekomst, må du sørge for at BGP-økten som er knyttet til tunnelen som peker til datasenteret A for dedikert forekomst, mottar den lokal rute /25 for dedikert forekomst av datasenteret A /25 i tillegg til /24-sikkerhetskopiruten. I tillegg må du sørge for at tunnelen som peker til datasenteret B for dedikert forekomst, mottar den lokal rute for dedikert forekomst av datasenteret B /25 i tillegg til /24-reserveruten. Merk at /24-reserveruten vil være den samme ruten som annonseres ut av datasenter A for dedikert forekomst og datasenter B for dedikert forekomst.

Redundans gis til et dedikert forekomst-datasenter hvis tunnelgrensesnittet til dette datasenteret går ned. Hvis tilkoblingen til datasenteret A for dedikert forekomst mistes, vil trafikk bli videresendt fra datasenteret B for dedikert forekomst til datasenteret A. I dette scenariet vil tunnelen til datasenteret B bruke ruten for datasenteret B /25 til å sende trafikk til datasenteret B og tunnelen til datasenter B vil bruke ruten for sikkerhetskopi /24 til å sende trafikk til datasenter A via datasenter B.

Det er viktig at når begge tunnelene er aktive at datasenter A-tunnelen ikke brukes til å sende trafikk til datasenter B og omvendt. I dette scenariet, hvis trafikk sendes til datasenter A med mål for datasenter B, vil datasenter A videresende trafikken til datasenter B, og deretter vil datasenter B forsøke å sende trafikk tilbake til kilden via datasenter B-tunnelen. Dette vil resultere i suboptimal ruting og kan også bryte trafikk som krysser brannmurer. Derfor er det viktig at begge tunnelene er i en aktiv/aktiv konfigurasjon under normal drift.

0.0.0.0/0-ruten må annonseres fra kundesiden til datasentersiden for dedikert forekomst. Mer spesifikke ruter godtas ikke av den dedikerte forekomst-siden. Kontroller at ruten 0.0.0.0/0 annonseres ut av både A-tunnelen for dedikert forekomst og B-tunnelen for datasenteret for dedikert forekomst.

MTU-konfigurasjon

På dedikert forekomst-siden er to funksjoner aktivert for dynamisk å justere MTU for store pakkestørrelser. GRE-tunnelen legger til flere overskrifter i IP-pakkene som flyter gjennom VPN-økten. IPsec-tunnelen legger til de ekstra overskriftene på toppen av GRE-hodene, vil ytterligere redusere den største MTU-en som er tillatt over tunnelen.

GRE-tunnelen justerer MSS-funksjonen og GRE-tunnelbanen i MTU-oppdagingsfunksjonen er aktivert på siden for dedikert forekomst. Konfigurer «ip tcp adjust-mss 1350» eller tilsvarende kommando i tillegg til «tunnel path\u0002mtu-discovery» eller tilsvarende kommando på kundesiden for å hjelpe med dynamisk justering av MTU for trafikk gjennom VPN-tunnelen.