Introduksjon

Virtuell tilkobling er et tilleggsalternativ for skytilkobling til dedikert forekomst for Webex Calling (dedikert forekomst). Virtual Connect gjør det mulig for kunder å utvide sitt private nettverk sikkert over internett ved hjelp av punkt-til-punkt IP VPN-tunneler. Dette tilkoblingsalternativet gir rask etablering av privat nettverkstilkobling ved hjelp av eksisterende Customer Premise Equipment (CPE) og Internett-tilkobling.

Cisco er vert for, administrerer og sikrer overflødige IP VPN-tunneler og den nødvendige Internett-tilgangen i Ciscos dedikerte forekomstdatasenterregion(er) der tjenesten er nødvendig. På samme måte er administratoren ansvarlig for de tilsvarende CPE- og Internett-tjenestene som kreves for etablering av virtuell tilkobling.

Hver virtuell tilkoblingsordre i et bestemt dedikert forekomstområde vil inkludere to GRE-tunneler (Generic Routing Encapsulation) beskyttet av IPSec-kryptering (GRE over IPSec), én til hvert Ciscos datasentre i den valgte regionen.

Virtual Connect har en båndbreddegrense på 250 Mbps per tunnel og anbefales for mindre distribusjoner. Siden to punkt-til-punkt VPN-tunneller brukes, må all trafikk til skyen gå gjennom kundens kalt CPE, og derfor er det kanskje ikke egnet der det er mange eksterne nettsteder. Hvis du vil ha andre alternative nodealternativer, kan du se Skytilkobling.

Før du sender inn nodeforespørselen for Virtual Connect, må du sørge for at tjenesten for dedikert forekomst er aktivert i den respektive regionen.

Forutsetninger

Forutsetningene for å etablere Virtual Connect inkluderer:

  • Kunden oppgir

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

    • Offentlige IP-adresser for to IPSec-tunneler

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

  • Partner og kunde

    • Samarbeid om å evaluere båndbreddekrav

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

  • Partner eller kunde oppgir

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

    • Nettverksteam med kunnskap om BGP, eBGP og generelle rutingprinsipper

  • Cisco

    • Cisco tilordnet private autonome systemnumre (ASN-er) og midlertidig IP-adressering for GRE-tunnelgrensesnitt

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

Hvis en kunde bare har én CPE-enhet, vil de 2 tunnelene mot Ciscos datasentre (DC1 og DC2) i hver region være fra den CPE-enheten. Kunden har også et alternativ for 2 CPE-enheter, da skal hver CPE-enhet kun koble til 1 tunnel mot Ciscos datasentre (DC1 og DC2) i hver region. Ytterligere redundans kan oppnås ved å avslutte hver tunnel på et separat fysisk sted/sted innenfor kundens infrastruktur.

Tekniske detaljer

Distribusjonsmodell

Virtual Connect bruker en arkitektur med to nivåer, der ruting- og GRE-kontrollflyene leveres av én enhet og IPSec-kontrollflyet leveres av en annen.

Når Virtual Connect -tilkoblingen er fullført, opprettes det to GRE over IPSec-tunneler mellom kundens bedriftsnettverk og Ciscos datasentre for dedikert forekomst. Ett til hvert overflødig datasenter i den respektive regionen. Ytterligere nettverkselementer som kreves for nodenettverk, utveksles av partneren eller kunden til Cisco via aktiveringsskjemaet for Control Hub Virtual Connect.

Figur 1 viser et eksempel på distribusjonsmodellen for Virtual Connect for alternativet 2-konsentratator på kundesiden.

Virtual Connect – VPN er en hub-design, der kundens hub-nettsteder er koblet til DC1 og DC2 av dedikerte forekomstdatasentre i en bestemt region.

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

Båndbredden per tunnel er begrenset til 250 Mbps.

Kundens eksterne nettsteder innenfor samme område må koble tilbake til Hub-nettstedet(e) via 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 «Virtual Connect»-tjenesteregionen.

Figur 2 viser nodeområdene for dedikert forekomst av skytilkobling.

Ruting

Ruting for Virtual Connect-tillegg implementeres ved hjelp av ekstern BGP (eBGP) mellom dedikert forekomst og kundens lokalutstyr (CPE). Cisco vil annonsere sitt respektive nettverk for hver overflødig DC i en region til kundens CPE, og CPE er pålagt å annonsere en standardrute til Cisco.

  • Cisco vedlikeholder og tilordner

    • IP-adressering for tunnelgrensesnitt (midlertidig kobling for ruting) Cisco tilordner fra et bestemt delt adresseområde (ikke-offentlig rutebar)

    • Adresse for tunneltransport (Ciscos side)

    • Private autonome systemnumre (ASN-er) for konfigurasjon av BGP-ruting av kunder

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

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

    • Cisco vil dele opp 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 over de respektive punkt-til-punkt VPN-tunnelene (midlertidig kobling)

    • CPE må konfigureres med de aktuelle eBGP-naboene. Hvis du bruker én CPE, vil det bli brukt to eBGP-naboer, én som peker til hver ekstern tunnel. Hvis du bruker to CPE-er, vil hver CPE ha én eBGP-nabo som peker til den enkelte eksterne tunnelen for CPE-en.

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

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

    • CPE er ansvarlig for å omfordele, etter behov, de lærte rutene innenfor cutomerens bedriftsnettverk.

  • Hvis koblingsfeil ikke er feil, 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. I et ikke-mislykket scenario må trafikken deles inn i to tunneler som går til de riktige /25 destinasjonene. 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 reserve-rute. Cisco vil sende kundetrafikk via sin interne WAN til DC 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 virtuell tilkobling fra Control Hub

3

Cisco utfører nettverkskonfigurasjon

4

Kunden utfører nettverkskonfigurasjon

Trinn 1: CCW-bestilling

Virtual Connect er et tillegg for dedikert forekomst i CCW.

1

Gå til CCWs bestillingsnettsted, og klikk deretter på Logg på for å logge på nettstedet:

https://apps.cisco.com/Commerce/guest.
2

Opprett estimat.

3

Legg til «A-FLEX-3» SKU.

4

Velg Rediger alternativer.

5

Velg alternativer og tillegg i abonnementsfanen som vises.

6

Under Flere tillegg merker du av i avkrysningsboksen ved siden av "Virtuell tilkobling for dedikert forekomst". SKU-navnet er "A-FLEX-DI-VC".

7

Angi antall og antall regioner der virtuell tilkobling kreves.

Antall virtuelle tilkoblinger skal ikke overskride det totale antallet regioner som er kjøpt for dedikert forekomst. I tillegg er bare én virtuell tilkobling-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. Din ferdige bestilling er nå i ordrerutenettet.

Trinn 2: Aktivering av virtuell tilkobling i Control Hub

1

Logg på https://admin.webex.com/loginControl Hub.

2

I delen Tjenester navigerer du til Anrop > Dedikert instacnce > Skytilkobling.

3

På Virtual Connect-kortet er den kjøpte Virtual Connect-mengden oppført. Administratoren kan nå klikke på Aktiver for å starte aktiveringen av Virtual Connect.

Aktiveringsprosessen kan bare utløses av administratorer med rollen som fullstendig kundeadministrator. Men en administrator med rollen «skrivebeskyttet kundeadministrator» kan bare se statusen.
4

Når du klikker på Aktiver -knappen, vises skjemaet Aktiver virtuell tilkobling slik at administratoren kan oppgi de tekniske detaljene for virtuell tilkobling som kreves for nodekonfigurasjonene på Ciscos side.

Skjemaet inneholder også statisk informasjon på Ciscos side, basert på den valgte regionen. Denne informasjonen vil være nyttig for kundeadministratorer til å konfigurere CPE på deres side for å opprette tilkoblingen.

  1. GRE tunneltransport IP-adresse: Kunden må oppgi kundens IP-adresser for tunneltransport, og Cisco vil dynamisk tilordne IP-adressene når aktiveringen er fullført. IPSec ACL for interessant trafikk bør tillate lokal tunneltransport IP/32 til ekstern tunneltransport IP/32. ACL skal også bare spesifisere GRE IP-protokollen.

    IP-adressen som kunden har oppgitt, kan være privat eller offentlig.

  2. IPsec-motparter: Kunden må oppgi IPSec-tunnelens kilde-IP-adresser, og Cisco tilordner IPSec-destinasjonens IP-adresse. Utføring av NAT-oversettelse av en intern IPSEC-tunneladresse til en offentlig adresse støttes også om nødvendig.

    IP-adressen som kunden har oppgitt, skal være offentlig.

    All annen statisk informasjon som vises på aktiveringsskjermen, er Ciscos sikkerhetsstandarder og krypteringsstandarder på 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 obligatoriske felt er fylt ut.

6

Når aktiveringsskjemaet for virtuell tilkobling er fullført for et delområde, kan kunden eksportere aktiveringsskjemaet fra Control Hub, Anrop > Dedikert forekomst > Skytilkobling-fanen og klikke på Eksporter innstillinger.

Av sikkerhetsgrunner vil ikke godkjennings- og BGP-passordet være tilgjengelig i det eksporterte dokumentet, men administratoren kan vise det samme i Control Hub ved å klikke på Vis innstillinger under Control Hub, Anrop > Dedikert forekomst > Skytilkobling-fanen.

Trinn 3: Cisco utfører nettverkskonfigurasjon

1

Når aktiveringsskjemaet for virtuell tilkobling er fullført, oppdateres statusen til Aktivering pågår i Anrop > Dedikert forekomst > Virtuell tilkobling-kort for skytilkobling.

2

Cisco fullfører de nødvendige konfigurasjonene på Ciscos sideutstyr innen 5 virkedager. Når det 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 konfigurasjonsside for IP VPN-tilkoblingen er fullført basert på inndataene fra kunden. Men kundeadministratoren forventes å fullføre sin side av konfigurasjonene på CPE-ene og teste tilkoblingsrutene for at den virtuelle tilkoblingstunnelen skal være tilkoblet. Hvis det oppstår problemer ved konfigurasjonen eller tilkoblingen, kan kunden ta kontakt med Cisco TAC for å få hjelp.

Feilsøking

Feilsøking og validering av IPsec første fase (IKEv2-forhandling)

IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-fasen ikke fullføres, er det ingen oppstart av en ny IPsec-fase. Først utsteder du kommandoen "vis krypto ikev2 sa" (på Cisco-utstyr) eller lignende kommando på tredjepartsutstyret for å bekrefte om IKEv2-økten er aktiv. Hvis IKEv2-økten ikke er aktiv, kan mulige årsaker være:

  • Interessant trafikk utløser ikke IPsec-tunnelen.

  • Tilgangslisten for IPsec-tunnel er feilkonfigurert.

  • Det er ingen tilkobling mellom kunden og den dedikerte forekomsten IPsec-tunnelendepunktet IP.

  • IKEv2-øktparametrene samsvarer ikke mellom siden for dedikert forekomst og kundesiden.

  • En brannmur blokkerer IKEv2 UDP-pakkene.

Først må du sjekke IPsec-loggene for meldinger som viser fremdriften av IKEv2-tunnelforhandlingen. Loggene kan indikere hvor det er et problem med IKEv2-forhandlingen. Mangel på loggingsmeldinger 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 autentisering samsvarer med den forventede krypteringen på siden for dedikert forekomst.

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

    • Kontroller innstillingen for levetid.

    • Sjekk Diffie Hellman-modulusgruppen.

    • Kontroller innstillingene for pseudo-tilfeldig funksjon.

  • Tilgangslisten 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)

      Tilgangslisten må være spesifikk for "GRE"-protokollen, og "IP"-protokollen vil ikke fungere.

Hvis loggmeldingene ikke viser noen forhandlingsaktivitet for IKEv2-fasen, kan det være nødvendig med et pakkeopptak.

Dedikert forekomst-siden starter kanskje ikke alltid IKEv2-utvekslingen, og kan noen ganger forvente at kundens CPE-side er initiativtakeren.

Kontroller konfigurasjonen av CPE-siden for følgende forutsetninger for å starte IKEv2-økten:

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

  • Sørg for at GRE tunnelgrensesnittet er aktivert for GRE keepalives. Hvis utstyret ikke støtter GRE keepalives, blir Cisco varslet fordi GRE keepalives aktiveres på siden Dedikert forekomst på standard.

  • Kontroller at BGP er aktivert og konfigurert med naboadressen til tunnel-IP for dedikert forekomst.

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

  • GRE holder palives fra CPE-siden GRE tunnelgrensesnittet til GRE tunnelgrensesnittet for dedikert forekomst.

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

  • Ping fra CPE-sidetunnelens IP-adresse til Dedikert forekomst-sidetunnelens IP-adresse.

    Ping kan ikke være tunneltransport IP til tunneltransport IP, det må være tunnel IP til tunnel IP.

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

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

Det dedikerte forekomstdatasenteret starter kanskje ikke alltid den første IKEv2-pakken. Kravet er at CPE-enheten kan starte den første IKEv2-pakken mot Dedikert forekomst-siden.

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

Enkelte brannmurer og Internett-utstyr tillater kanskje ikke sporingsrute.

Feilsøking og validering av IPsec Second Phase (IPsec-forhandling)

Kontroller at den første fasen av IPsec (dvs. IKEv2-sikkerhetsassociasjonen) er aktiv før du feilsøker den andre fasen av IPsec. Utfør en "vis krypto ikev2 sa" eller tilsvarende kommando for å bekrefte IKEv2-økten. I utdataene bekrefter du at IKEv2-økten har vært på i mer enn noen sekunder og at den ikke hopper. Øktens oppetid vises som økten «Aktiv tid» eller tilsvarende i utdata.

Når IKEv2-økten bekrefter som opp og aktiv, undersøker du IPsec-økten. Som med IKEv2-økten, utfør en "vis krypto ipsec sa" eller tilsvarende kommando for å bekrefte IPsec-økten. Både IKEv2-økten og IPsec-økten må være aktiv før GRE-tunnelen opprettes. Hvis IPsec-økten ikke vises som aktiv, må du sjekke IPsec-loggene for feilmeldinger eller forhandlingsfeil.

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

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

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

  • Bekreft innstillingene for Perfect Forward Secrecy og at innstillingene samsvarer med innstillingene på siden Dedikert forekomst.

  • Kontroller innstillingene for levetid.

  • Kontroller at IPsec er konfigurert i tunnelmodus.

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

Feilsøking og validering av tunnelgrensesnitt

Når IPsec- og IKEv2-øktene bekreftes som aktive og aktive, holder GRE-tunnelen levende pakker i stand til å flyte mellom endepunktene for dedikert forekomst og endepunktene for CPE-tunnel. Hvis tunnelgrensesnittet ikke viser status, er noen vanlige problemer:

  • Tunnelgrensesnittet transport VRF samsvarer ikke med VRF for loopback-grensesnittet (hvis VRF-konfigurasjon brukes på tunnelgrensesnittet).

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

  • Oppbevaringsbøker er ikke aktivert på CPE-tunnelgrensesnittet

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

    Hvis oppbevaringene støttes, må du bekrefte at oppbevaringene er aktivert.

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

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

  • En brannmur blokkerer GRE-pakker fra å bli sendt inn i IPsec-tunnelen eller mottatt fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En ping-test bør bekrefte at det lokale tunnelgrensesnittet er på plass og at tilkoblingen er god til det eksterne tunnelgrensesnittet. Utfør ping-kontrollen fra tunnel-IP (ikke transport-IP) til ekstern tunnel-IP.

Kryptotilgangslisten for IPsec-tunnelen som transporterer GRE-tunneltrafikk tillater bare GRE-pakker å krysse. Som et resultat vil pings ikke fungere fra tunneltransport IP til ekstern tunneltransport IP.

Ping-kontrollen resulterer i en GRE-pakke som genereres fra kildetunneltransport-IP til måltunneltransport-IP mens nyttelasten til GRE-pakken (innvendig IP) vil være kilde- og måltunneltransport-IP.

Hvis ping-testen ikke lykkes og de foregående elementene er bekreftet, kan det være nødvendig med et pakkeopptak for å sikre at icmp ping resulterer i en GRE-pakke som deretter innkapsles i en IPsec-pakke og deretter sendes fra kilde-IPsec-adressen til mål-IPsec-adressen. Tellere på GRE-tunnelgrensesnittet og IPsec-økttellere kan også bidra til å vise om sending og mottak av pakker øker.

I tillegg til ping-trafikk bør opptaket også vise opprettholdt GRE-pakker selv under inaktiv trafikk. Til slutt, hvis BGP er konfigurert, skal BGP holde live-pakker også sendes som GRE-pakker innkapslet i IPSEC-pakker over VPN-en.

Feilsøking og validering av BGP

BGP-økter

BGP kreves som rutingsprotokoll over VPN IPsec-tunnelen. Den lokale BGP-naboen bør etablere en eBGP-økt med den dedikerte forekomsten BGP-naboen. Naboens eBGP IP-adresser er de samme som de lokale og eksterne tunnelens IP-adresser. Kontroller først at BGP-økten er i gang, og bekreft deretter at de riktige rutene mottas fra dedikert forekomst og at den riktige standardruten sendes til dedikert forekomst.

Hvis GRE-tunnelen er oppe, må du kontrollere at en ping er vellykket mellom den lokale og den eksterne GRE-tunnelen IP. Hvis ping lykkes, men BGP-økten ikke kommer, må du undersøke BGP-loggen for BGP-opprettelsesfeil.

Noen av de vanligste BGP-forhandlingsproblemene er:

  • Det eksterne AS-nummeret samsvarer ikke med AS-nummeret som er konfigurert på siden Dedikert forekomst. Kontroller naboens AS-konfigurasjon på nytt.

  • Det lokale AS-nummeret samsvarer ikke med det siden Dedikted Instance 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 å bli sendt inn i IPsec-tunnelen eller mottatt fra IPSEC-tunnelen

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

BGP Route Exchange

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

Dedikert forekomst VPN-løsningen forventer at to tunneler skal opprettes fra kunde-/partnersiden. Den første tunnelen peker til det dedikerte forekomstdatasenteret A og den andre tunnelen peker til det dedikerte forekomstdatasenteret B. Begge tunnelene må være i aktiv tilstand og løsningen krever en aktiv/aktiv distribusjon. Hvert dedikert forekomstdatasenter vil annonsere det lokale /25-ruten i tillegg til en /24-reserverute. Når du sjekker de innkommende BGP-rutene fra dedikert forekomst, må du kontrollere at BGP-økten som er knyttet til tunnelen som peker til dedikert forekomst-datasenter A, mottar den lokale ruten for dedikert forekomst-datasenter A /25 samt reserveruten for dedikert forekomst-datasenter A /24. I tillegg må du sørge for at tunnelen som peker til Dedikert forekomst-datasenter B mottar den lokale ruten Dedikert forekomst-datasenter B /25 samt reserveruten /24. Vær oppmerksom på at reservasjonsruten /24 vil være den samme ruten annonsert ut av Dedikert forekomst datasenter A og Dedikert forekomst datasenter B.

Overflødighet gis til et dedikert forekomst datasenter hvis tunnelgrensesnittet til det datasenteret går ned. Hvis tilkoblingen til Dedikert forekomst-datasenter A går tapt, vil trafikk videresendes fra Dedikert forekomst-datasenter B til datasenter A. I dette scenariet vil tunnel til datasenter B bruke ruten for datasenter B /25 til å sende trafikk til datasenter B, og tunnelen til datasenter B vil bruke backup /24-ruten for å sende trafikk til datasenter A via datasenter B.

Når begge tunnelene er aktive, er det viktig at datasenteret A-tunnel ikke brukes til å sende trafikk til datasenter B og omvendt. I dette scenariet, hvis trafikk sendes til datasenter A med en destinasjon for datasenter B, vil datasenter A viderekoble trafikken til datasenter B, og deretter vil datasenter B forsøke å sende trafikk tilbake til kilden via datasenter B-tunnelen. Dette vil føre til sub-optimal ruting og kan også bryte trafikk gjennom brannmurer. Derfor er det viktig at begge tunnelene er i aktiv/aktiv konfigurasjon under normal drift.

0.0.0.0/0-ruten må annonseres fra kundesiden til datasentersiden for dedikert forekomst. Mer spesifikke ruter vil ikke bli akseptert av siden for dedikert forekomst. Sørg for at 0.0.0.0/0-ruten annonseres ut av både Dedikert forekomst-datasenter A-tunnel og Dedikert forekomst-datasenter B-tunnelen.

MTU-konfigurasjon

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

GRE-tunnelen justerer MSS-funksjonen, og GRE-tunnelbanen i MTU-oppdagelsesfunksjonen er aktivert på siden Dedikert forekomst. Konfigurer «ip tcp adjust-mss 1350» eller tilsvarende kommando samt «tunnelbane\u0002mtu-discovery» eller tilsvarende kommando på kundesiden for å hjelpe deg med dynamisk justering av MTU av trafikk gjennom VPN-tunnelen.