Introduktion

Virtual Connect er en ekstra tilføjelsesvalgmulighed for Cloud-tilslutning til dedikeret forekomst Webex-opkald tilfælde (dedikeret instans). Virtuel tilslutning gør det muligt for kunder at udvide deres private netværk sikkert over internettet ved hjælp af punkt til punkt IP VPN-tunneller. Denne valgmulighed for tilslutning giver en hurtig kobling af privat netværksforbindelse ved at bruge det eksisterende kundeudstyr (CPE) og internetforbindelsen.

Cisco-værter, administrerer og sikrer redundante IP VPN-tunneller og den nødvendige internetadgang i Ciscos dedikerede instans-datacenterområde(er), hvor tjenesten er påkrævet. På samme måde er administratoren ansvarlig for deres tilsvarende CPE- og internettjenester, som er nødvendige for at kunne bruge Virtual Connect.

Hver virtuel tilslutningsordre i en bestemt dedikeret instans-region vil omfatte to generiske routing-indkapslings-tunneller (VEDR)-tunneller beskyttet med IPSec-kryptering (SSL over IPSec), én til hver Ciscos datacenter i den valgte region.

Virtual Connect har en båndbreddegrænse på 250 Mbps pr. tunnel og anbefales til mindre installationer. Da VPN-tunneler to punkt til punkt bruges, skal al trafik til skyen gå gennem kundens hovedende CPE, og derfor er den muligvis ikke egnet til der, hvor der er mange eksterne websteder. For andre alternative peeringmuligheder, se Cloud Connectivity.

Før du indsender peering-anmodningen om virtuel forbindelse, skal du sørge for, at tjenesten for dedikeret forekomst er aktiveret i det pågældende område.

Forudsætninger

Forudsætningerne for oprettelse af Virtuel tilslutning omfatter:

  • Kunden leverer

    • Internetforbindelse med tilstrækkelig tilgængelig båndbredde til at understøtte udrulningen

    • Offentlig(e) IP-adresse(er) til to IPSec-tunneler

    • Kundens SIDE VEDR.s transport-IP-adresser til de to VEDR.-tunneller

  • Partner og kunde

    • Arbejd sammen for at evaluere krav til båndbredde

    • Sørg for, at netværksenheden/-enhederne understøtter Border Gateway-protokol (BGP) routing og et ROUTER over IPSec tunnel-design

  • Partner eller kunde leverer

    • Netværksteam med viden om WEBSTED-til-websted VPN-tunnelteknologier

    • Netværksteam med viden om BGP, eBGP og generelle routing-principper

  • Cisco

    • Cisco tildelte private autonoumous systemnumre (ASN'er) og kortvarig IP-adressering til FREELANCE-tunnelgrænseflader

    • Cisco tildelte offentlige, men ikke internetrourtable klasse C-netværk (/24) for dedikeret forekomst cloud-adresse

Hvis en kunde kun har 1 CPE-enhed, vil de 2 tunneller mod Ciscos datacentre (DC1 og DC2) i hver region være fra den CPE-enhed. Kunden har også mulighed for 2 CPE-enheder, så hver CPE-enhed kun skal oprette forbindelse til 1 tunnel mod Ciscos datacentre (DC1 og DC2) i hver region. Yderligere redundans kan adskilles ved at afslutte hver tunnel på et separat fysisk websted/sted inden for kundens infrastruktur.

Tekniske detaljer

Ibrugtagningsmodel

Virtual Connect bruger en hovedarkitektur på dual-niveau, hvor routing- og PLATINUM-kontrolsystemer leveres af én enhed, og IPSec-kontrolenheden leveres af en anden.

Efter afslutning af den virtuelle Tilslutning-forbindelse oprettes to VIA IPSec-tunneler mellem kundens virksomhedsnetværk og Dedikerede forekomster Ciscos datacentre. En til hver redundant datacenter inden for den respektive region. Yderligere netværkselementer, som er nødvendige for peering'en, udveksles af partneren eller kunden med Cisco via Aktiveringsformularen for Virtual Connect til Control Hub.

Figur 1 viser et eksempel på udrulningsmodel for Virtuel tilslutning til 2-vælgerindstillingen på kundens side.

Virtual Connect – VPN er et Hub-design, hvor kundens Hub-websteder er forbundet til DC1 og DC2 for dedikerede tilfældes datacentre inden for en bestemt region.

To Hub-websteder anbefales for bedre redundans, men One Hub-websted med to tunneler er også en understøttet udrulningsmodel.

Båndbredden pr. tunnel er begrænset til 250 Mbps.

Kundens eksterne websteder inden for samme region skal oprette forbindelse tilbage til Hub-webstedet/-webstederne via kundens WAN, og det er ikke Ciscos ansvar for denne forbindelse.

Partnere forventes at arbejde tæt sammen med kunderne for at sikre, at den mest optimale sti er valgt for "Virtual Connect"-tjenesteområdet.

Figur 2 viser de dedikerede cloudforbindelses-peeringområder for dedikerede tilfælde.

Ruteplanlægning

Dirigering til Virtual Connect-tilføjelsesprogrammet er implementeret ved hjælp af ekstern BGP (eBGP) mellem dedikeret forekomst og kundens udstyr på stedet (CPE). Cisco vil annoncere deres respektive netværk for hver redundant DC inden for en region til kundens CPE, og CPE er påkrævet for at annoncere en standardrute til Cisco.

  • Cisco opretholder og tildeler

    • Tunnel Interface IP-adresse (kortvarigt link til routing) Cisco tildeler fra et angivet delt adresserum (ikke-offentligt kan routing)

    • Tunnel transport desitination adresse (Cisco side)

    • Private autonome systemnumre (ASN'er) til kunde BGP-routingkonfiguration

      • Cisco tildeler fra det udpegede område for privat brug: 64512 til 65534

  • eBGP bruges til at udveksle ruter mellem dedikeret forekomst og CPE

    • Cisco vil opdele det tildelte/24 netværk i 2/25 et for hver DC i den respektive region

    • I Virtual Connect annonceres hvert /25-netværk tilbage til CPE af Cisco over de respektive punkt til punkt VPN-tunneller (kortvarigt link)

    • CPE skal konfigureres med de relevante eBGP-naboe. Hvis der bruges én CPE, vil to eBGP-naboe blive brugt, en der peger på hver ekstern tunnel. Hvis der bruges to CPE, vil hver CPE have en eBGP nabo poniting til den enkelte eksterne tunnel for CPE.

    • Cisco-side af hver FREELANCE-tunnel (tunnelgrænseflade-IP) er konfigureret som BGP-naboen på CPE

    • CPE er påkrævet for at annoncere en standardrute over hver af tunnellerne

    • CPE kan omfordeles, efter behov, de lærde ruter inden for cutomer's virksomhedsnetværk.

  • Under manglende fejltilstand for link vil en enkelt CPE have to aktive/aktive tunneller. For to CPE-knudepunkter vil hver CPE have én aktiv tunnel, og begge CPE-knudepunkter bør være aktive og videregive trafik. Under manglende scenarie skal trafik opdeles i to tunneler, der går til de korrekte /25 destinationer, hvis en af tunnelen går ned, kan den resterende tunnel udføre trafikken for begge. I et sådant scenarie med fejl, når /25-netværket er nede, bruges /24-netværket som backup-rute. Cisco vil sende kundetrafik via den interne WAN mod DC, som mistede forbindelsen.

Forbindelsesproces

De følgende trin på højt niveau beskriver, hvordan du opretter forbindelse med virtuel tilslutning til dedikeret forekomst.
1

Afstil en ordre i Cisco CCW

2

Aktivér virtuel tilslutning fra Control Hub

3

Cisco udfører netværkskonfiguration

4

Kunden udfører netværkskonfiguration

Trin 1: CCW-ordre

Virtuel tilslutning er et tilføjelsesprogrammet til en dedikeret forekomst i CCW.

1

Naviger til CCW-bestillingswebstedet, og klik derefter på Login for at logge på webstedet:

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

Opret estimat.

3

Tilføj "A-FLEX-3" SKU.

4

Vælg Rediger valgmuligheder.

5

I abonnementsfanen, der vises, skal du vælge Valgmuligheder og tilføjelser.

6

Under Yderligere tilføjelser marker afkrydsningsfeltet ved siden af "Virtuel tilslutning til dedikeret instans". SKU-navnet er "A-FLEX-DI-VC".

7

Indtast antallet og antallet af regioner, hvor Virtuel tilslutning er påkrævet.

Antallet af Virtuel tilslutning bør ikke overstige det samlede antal regioner, der er købt for en dedikeret forekomst. Desuden er kun én virtuel tilslutningsordre tilladt pr. region.
8

Når du er tilfreds med dine valg, så klik på Bekræft og Gem i øverste højre del af siden.

9

Klik på Gem og fortsæt for at færdiggøre din ordre. Din færdiggjorte ordre indeholder nu app'er i ordregitrene.

Trin 2: Aktivering af Virtuel tilslutning i Control Hub

1

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

2

I afsnittet Tjenester skal du navigere til Opkaldsforbindelse> Dedikeret instacnce-> Cloud-tilslutning.

3

I det virtuelle tilslutningskort er det købte Antal Virtuel tilslutning angivet. Administratoren kan nu klikke på Aktiver for at starte aktivering af Virtual Connect.

Aktiveringsprocessen kan kun udløses af administratorer med "Kunde fuld administrator"-rolle. Mens en administrator med "Kunde skrivebeskyttet administrator"-rolle kun kan se status.
4

Ved et klik på knappen Aktiver vises virtuel tilslutningsformular, så administratoren kan give de tekniske oplysninger om Virtuel tilslutning, som er nødvendige for peeringkonfigurationerne på Ciscos side.

Formularen giver også statiske oplysninger på Ciscos side, baseret på den region, der er valgt. Disse oplysninger vil være nyttige for kundeadministratorer til at konfigurere CPE på deres side til at etablere forbindelsen.

  1. IP-adresse for GRE-tunnel-transport: Kunden skal angive kundens SIDE Tunnel-IP-adresser, og Cisco tildeler dynamisk IP-adresserne, når aktiveringen er fuldført. IPSec ACL for interessante trafik skal tillade lokal tunnel transport IP/32 til ekstern Tunnel Transport IP/32. ACL'en bør også kun angive "DEN NYE" IP-protokol.

    Den IP-adresse, der gives af kunden, kan være privat eller offentlig.

  2. IPS: Kunden skal levere IPSec Tunnels kilde-IP-adresser, og Cisco tildeler IPSec-destinations-IP-adressen. Udførelse af NAT-oversættelse af en intern IPSEC-tunneladresse til en offentlig adresse understøttes også, hvis påkrævet.

    Den IP-adresse, der gives af kunden, skal være offentlig.

    Alle de andre statiske oplysninger, der gives i aktiveringsskærmen, er Ciscos sidesikkerheds- og krypteringsstandarder efterfulgt. Denne statiske konfiguration kan ikke tilpasses eller ændres. For yderligere assistance vedrørende de statiske konfigurationer på Ciscos side skal kunden kontakte TAC.
5

Klik på knappen Aktiver , når alle obligatoriske felter er udfyldt.

6

Når aktiveringsformularen for Virtuel tilslutning er udfyldt for en deliclusiv region, kan kunden eksportere aktiveringsformularen fra Control Hub, Calling > Dedikeret > Cloud Connectivity-fanen og klikke på Eksporter indstillinger.

Af sikkerhedsmæssige årsager vil godkendelse og BGP-adgangskode ikke være tilgængelig i det eksporterede dokument, men administratoren kan se den samme i Control Hub ved at klikke på Visningsindstillinger under Control Hub, Opkald > Dedikeret forekomst > Cloud-forbindelse.

Trin 3: Cisco udfører netværkskonfiguration

1

Når aktiveringsformularen for Virtuel tilslutning er udfyldt, opdateres status for igangværende aktivering af opkald > dedikeret forekomst > Cloud Connectivity Virtual Connect-kort .

2

Cisco fuldfører de nødvendige konfigurationer på Ciscos sideudstyr inden for 5 arbejdsdage. Når den er fuldført, opdateres statussen til "Aktiveret" for den pågældende region i Control Hub.

Trin 4: Kunden udfører netværkskonfiguration

Statussen ændres til "Aktiveret" for at underrette kundens administrator om, at Ciscos side af konfigurationer for IP VPN-forbindelsen er fuldført baseret på de input, som kunden har givet. Men kundens administrator forventes at færdiggøre sin side af konfigurationerne på CPEs og teste tilslutningsruterne for den virtuelle tilslutnings-tunnel til at være online. I tilfælde af problemer, hvor konfiguration eller tilslutning er vilkårlig, kan kunden kontakte Cisco TAC for at få hjælp.

Fejlfinding

IP sec First Phase (IKE v2-forhandling) fejlfinding og validering

Forhandlingerne om IP sec-tunnelen omfatter to faser, IKE v2-fasen og IP-sec-fasen. Hvis forhandlingerne om IKE v2-fasen ikke afsluttes, vil der ikke blive indledt en anden IP-sek-fase. Først skal du udstede kommandoen "vis crypto ikev2 sa" (på Cisco-udstyr) eller lignende kommando på tredjepartsudstyret for at kontrollere, om IKEV2-sessionen er aktiv. Hvis IKE v2-sessionen ikke er aktiv, kan de potentielle årsager være:

  • Interessant trafik udløser ikke IP sec-tunnelen.

  • IP-sek-tunneladgangslisten er forkert konfigureret.

  • Der er ingen forbindelse mellem kunden og IP-sek-tunnelslutpunkt-IP for dedikeret forekomst.

  • IKE v2-sessionsparametrene matcher ikke mellem siden dedikeret forekomst og kundesiden.

  • En firewall blokerer IKE v2 UDP-pakkerne.

Kontrollér først IP-sec-logfilerne for alle meddelelser, der viser status for IKE v2-tunnelforhandlingerne. Logfilerne kan angive, hvor der er et problem med IKE v2-forhandlingerne. Manglende logføringsmeddelelser kan også indikere, at IKE v2-sessionen ikke aktiveres.

Nogle almindelige fejl i IKE v2-forhandlingerne er:

  • Indstillingerne for IKE v2 på CPE-siden stemmer ikke overens med Cisco-siden. Kontrollér de nævnte indstillinger igen:

    • Kontroller, at IKE-versionen er version 2.

    • Kontrollér, at krypterings- og godkendelsesparametrene stemmer overens med den forventede kryptering på siden Dedikeret forekomst.

      Når "GCM"-krypteringen er i brug, håndterer GCM-protokollen godkendelsen og indstiller godkendelsesparameteren til NULL.

    • Bekræft indstillingen for levetid.

    • Bekræft Diffie Hellman modulus-gruppen.

    • Bekræft indstillingerne for pseudo-tilfældig funktion.

  • Adgangslisten for krypteringskortet er ikke indstillet til:

    • Tillad GRE (local_tunnel_transport_ip) 255.255.255.255.255 remote_tunnel_transport_ip() 255.255.255.255" (eller tilsvarende kommando)

      Adgangslisten skal være specifik for "GRE"-protokollen, og "IP"-protokollen fungerer ikke.

Hvis logmeddelelserne ikke viser nogen forhandlingsaktivitet for IKEV2-fasen, kan det være nødvendigt med en pakkeløsning.

Siden dedikeret forekomst begynder muligvis ikke altid IKEV2-udvekslingen og kan nogle gange forvente, at kunde CPE-siden er initiativtageren.

Kontrollér CPE-sidekonfigurationen for følgende forudsætninger for start af IKE v2-sessioner:

  • Kontrollér for en IP-sec-krypto-adgangsliste for GRE-trafik (protokol 50) fra CPE-tunneltransport-IP til den dedikerede forekomst-tunnel-transport-IP.

  • Sørg for, at GRE-tunnelgrænsefladen er aktiveret for GRE-keepalives, hvis udstyret ikke understøtter GRE-keepalives, underrettes Cisco, fordi GRE-keepalives vil blive aktiveret på siden Dedikeret forekomst som standard.

  • Sørg for, at BGP er aktiveret og konfigureret med naboadressen for tunnelen til dedikeret forekomst.

Når den er konfigureret korrekt, starter følgende IP sec-tunnelen og første fase IKE v2-forhandling:

  • GRE keepalives fra CPE-side GRE-tunnelgrænsefladen til GRE-tunnelgrænsefladen for dedikeret forekomst-side GRE-tunnel.

  • BGP-naboens TCP-session fra CPE-side BGP-naboen til den dedikerede forekomst-side BGP-nabo.

  • Ping fra CPE-sidetunnelens IP-adresse til den dedikerede forekomst-sidetunnelens IP-adresse.

    Ping kan ikke være tunnel transport IP til tunnel transport IP, det skal være tunnel IP til tunnel IP.

Hvis der er behov for en pakkestørrelse til IKEV2-trafikken, skal du indstille filteret til UDP og enten port 500 (når ingen NAT-enhed er midt i IP-sek-slutpunkterne) eller port 4500 (når en NAT-enhed er placeret midt i IP-sek-slutpunkterne).

Kontrollér, at IKEV2 UDP-pakker med port 500 eller 4500 sendes og modtages til og fra DI IP-sec-IP-adressen.

Datacenteret for dedikeret forekomst starter muligvis ikke altid den første IKE v2-pakke. Kravet er, at CPE-enheden er i stand til at starte den første IKEV2-pakke mod siden Dedikeret forekomst.

Hvis den lokale firewall tillader det, skal du også forsøge at ping til den eksterne IP-sek-adresse. Hvis ping ikke lykkes fra lokal til ekstern IP-sek-adresse, skal du udføre en sporingsrute for at hjælpe og bestemme, hvor pakken skal kasseres.

Nogle firewalls og internetudstyr tillader muligvis ikke sporingsrute.

Fejlfinding og validering af IP sek Anden fase (IP sec Negotiation)

Kontrollér, at IP sec første fase (dvs. IKEV2-sikkerhedstilknytning) er aktiv, før der foretages fejlfinding af IP sec anden fase. Udfør en "vis krypto ikev2 sa" eller tilsvarende kommando for at bekræfte IKE v2-sessionen. Kontrollér, at IKE v2-sessionen har været oppe i mere end et par sekunder, og at den ikke springer ud. Sessionsoptiden vises som sessionen "Aktiv tid" eller tilsvarende i output.

Når IKE v2-sessionen bekræfter at være oppe og aktiv, skal du undersøge IPsek-sessionen. Som med IKE v2-sessionen skal du udføre en "vis krypto ipsec sa" eller tilsvarende kommando for at bekræfte IP-sessionen. Både IKE v2-sessionen og IP sec-sessionen skal være aktiv, før GRE-tunnelen etableres. Hvis IP-sek-sessionen ikke vises som aktiv, skal du kontrollere IP-sek-logfilerne for fejlmeddelelser eller forhandlingsfejl.

Nogle af de mere almindelige problemer, der kan opstå under IP-sec-forhandlingerne, er:

Indstillingerne på CPE-siden stemmer ikke overens med siden Dedikeret forekomst. Kontrollér indstillingerne igen:

  • Kontrollér, at parametrene for kryptering og godkendelse stemmer overens med indstillingerne på siden Dedikeret forekomst.

  • Bekræft indstillingerne for Perfekt viderestilling af hemmeligholdelse, og at matchindstillingerne på siden Dedikeret forekomst.

  • Bekræft livstidsindstillingerne.

  • Kontrollér, at IP-sek er konfigureret i tunneltilstand.

  • Bekræft kilde- og destinations-IP-sek-adresser.

Fejlfinding og validering af tunnelgrænseflade

Når IP-sec- og IKE v2-sessioner bekræftes som op og aktive, kan GRE-tunnelens keepalive-pakker flyde mellem den dedikerede forekomst og CPE-tunnelslutpunkter. Hvis tunnelgrænsefladen ikke viser status, er nogle almindelige problemer:

  • Tunnelgrænsefladetransport-VRF matcher ikke VRF'ens VRF for loopback-grænsefladen (hvis der bruges VRF-konfiguration på tunnelgrænsefladen).

    Hvis VRF-konfigurationen ikke bruges på tunnelgrænsefladen, kan denne kontrol ignoreres.

  • Keepalives er ikke aktiveret på CPE-sidetunnelgrænsefladen

    Hvis keepalives ikke understøttes på CPE-udstyret, skal Cisco underrettes, så standardkeepaliverne på siden Dedikeret forekomst også deaktiveres.

    Hvis keepaliverne understøttes, skal du kontrollere, at keepaliverne er aktiveret.

  • Masken eller IP-adressen for tunnelgrænsefladen er ikke korrekt og svarer ikke til de forventede værdier for dedikeret forekomst.

  • Kilde- eller destinationstunneltransportadressen er ikke korrekt og stemmer ikke overens med de forventede værdier for dedikeret forekomst.

  • En firewall blokerer GRE-pakker fra sendt ind i IP sec-tunnelen eller modtaget fra IP sec-tunnelen (GRE-tunnelen transporteres over IP sec-tunnelen)

En ping-test skal kontrollere, at den lokale tunnelgrænseflade er oppe, og at forbindelsen er god til den eksterne tunnelgrænseflade. Udfør ping-kontrollen fra tunnel-IP (ikke transport-IP) til den eksterne tunnel-IP.

Krypteringsadgangslisten for den IP sec-tunnel, der transporterer GRE-tunneltrafikken, tillader kun GRE-pakker at krydse. Som følge heraf vil pings ikke fungere fra tunneltransport-IP til fjerntransport-IP.

Ping-kontrollen resulterer i en GRE-pakke, der genereres fra kildetunneltransport-IP til destinationstunneltransport-IP, mens nyttelasten af GRE-pakken (den indvendige IP) vil være kilde- og destinationstunnelens IP.

Hvis ping-testen ikke lykkes, og de foregående elementer bekræftes, kan det være nødvendigt at foretage en pakkeoptagelse for at sikre, at icmp ping resulterer i en GRE-pakke, som derefter indlejres i en IP-sec-pakke og derefter sendes fra kilde-IP-sec-adressen til destinations-IP-sec-adressen. Tællere på GRE-tunnelgrænsefladen og IP sec-sessionstællerne kan også hjælpe med at vise. Hvis afsendelses- og modtagelsespakkerne stiger.

Ud over pingetrafikken skal fangsten også vise keepalive GRE-pakker, selv under inaktiv trafik. Hvis BGP er konfigureret, skal BGP keepalive-pakker også sendes som GRE-pakker indkapslet i IPSEC-pakker samt over VPN.

BGP-fejlfinding og validering

BGP-sessioner

BGP er påkrævet som distributionsprotokol over VPN IP-sek-tunnelen. Den lokale BGP-nabo bør etablere en e-BGP-session med den dedikerede forekomst-BGP-nabo. e-BGP-naboens IP-adresser er de samme som de lokale og eksterne tunnelers IP-adresser. Sørg først for, at BGP-sessionen er oppe, og bekræft derefter, at de korrekte ruter modtages fra dedikeret forekomst, og at den korrekte standardrute sendes til dedikeret forekomst.

Hvis GRE-tunnelen er oppe, skal du kontrollere, at en ping er lykkedes mellem den lokale og den eksterne GRE-tunnel IP. Hvis ping lykkes, men BGP-sessionen ikke kommer op, skal du undersøge BGP-logfilen for BGP-etableringsfejl.

Nogle af de mere almindelige BGP-forhandlingsspørgsmål er:

  • Det eksterne AS-nummer matcher ikke det AS-nummer, der er konfigureret på siden Dedikeret forekomst. Kontrollér naboens AS-konfiguration.

  • Det lokale AS-nummer matcher ikke det, som siden Dedikeret forekomst forventer. Kontrollér, at det lokale AS-nummer matcher de forventede parametre for dedikeret forekomst.

  • En firewall blokerer BGP TCP-pakker, der er indkapslet i GRE-pakker, fra at blive sendt ind i IP sec-tunnelen eller modtages fra IPSEC-tunnelen

  • Den eksterne BGP-nabo-IP stemmer ikke overens med den eksterne GRE-tunnel-IP.

BGP-ruteudveksling

Når BGP-sessionen er bekræftet for begge tunneler, skal du sikre, at de korrekte ruter sendes og modtages fra siden Dedikeret forekomst.

VPN-løsningen for dedikeret forekomst forventer, at der etableres to tunneler fra kunde-/partnersiden. Den første tunnel peger på datacenter for dedikeret forekomst A, og den anden tunnel peger på datacenter for dedikeret forekomst B. Begge tunneler skal være i aktiv tilstand, og løsningen kræver en aktiv/aktiv installation. Hvert datacenter med dedikeret forekomst vil annoncere den lokale /25-rute samt en /24-sikkerhedskopieringsrute. Når du kontrollerer de indgående BGP-ruter fra dedikeret forekomst, skal du sørge for, at den BGP-session, der er knyttet til tunnelen, der peger mod dedikeret forekomst-datacenter A, modtager den lokale rute Dedikeret forekomst-datacenter A /25 samt den ekstra rute /24. Derudover skal du sørge for, at tunnelen, der peger på datacenter B for dedikeret forekomst, modtager den lokale rute for dedikeret forekomst datacenter B /25 samt sikkerhedskopieringsruten /24. Bemærk, at /24-backup-ruten vil være den samme rute, der annonceres fra datacenter A for dedikeret forekomst og datacenter for dedikeret forekomst B.

Redundans leveres til et dedikeret forekomst-datacenter, hvis tunnelgrænsefladen til det datacenter går ned. Hvis forbindelsen til datacenter A går tabt, videresendes trafikken fra datacenter B til datacenter A. I dette scenarie vil tunnelen til datacenter B bruge datacenter B /25-ruten til at sende trafik til datacenter B, og tunnelen til datacenter B vil bruge sikkerhedskopieret /24-ruten til at sende trafik til datacenter A via datacenter B.

Når begge tunneler er aktive, er det vigtigt, at datacenter A tunnel ikke bruges til at sende trafik til datacenter B og omvendt. I dette scenario, hvis trafik sendes til datacenter A med en destination for datacenter B, videresender datacenter A trafikken til datacenter B, og derefter vil datacenter B forsøge at sende trafikken tilbage til kilden via datacenter B-tunnellen. Dette vil resultere i sub-optimal distribution og kan også bryde trafik gennem firewalls. Derfor er det vigtigt, at begge tunneler er i en aktiv/aktiv konfiguration under normal drift.

0.0.0.0/0-ruten skal annonceres fra kundesiden til datacentersiden for dedikeret forekomst. Mere specifikke ruter vil ikke blive accepteret af siden Dedikeret forekomst. Sørg for, at 0.0.0.0/0-ruten annonceres ud af både Dedikeret forekomst-datacenter A-tunnel og Dedikeret forekomst-datacenter B-tunnelen.

MTU-konfiguration

På siden Dedikeret forekomst er to funktioner aktiveret til dynamisk at justere MTU for store pakkestørrelser. GRE-tunnelen tilføjer flere overskrifter til de IP-pakker, der flyder gennem VPN-sessionen. IP sec-tunnelen tilføjer de ekstra overskrifter oven for GRE-overskrifterne vil yderligere reducere den største MTU, der er tilladt over tunnelen.

GRE-tunnelen justerer MSS-funktionen, og GRE-tunnelstien i MTU-registreringsfunktionen er aktiveret på siden Dedikeret forekomst. Konfigurer "ip tcp adjustment-mss 1350" eller tilsvarende kommando samt "tunnelsti\u0002mtu-discovery" eller tilsvarende kommando på kundesiden for at hjælpe med den dynamiske justering af MTU af trafik gennem VPN-tunnelen.