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 for virtuel tilslutning, skal du sørge for, at tjenesten 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

Udrulningsmodel

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.

Nedenstående figur viser eksemplet på den virtuelle tilslutningsmodel for indstillingen 2-koncentrator på kundesiden.

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 vælges til Virtual Connect -tjenesteområdet.

Nedenstående figur viser peering-områderne for cloud-forbindelse til dedikeret forekomst.

Områder for virtuelle forbindelser

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. GRE-tunneltransport-IP-adresse: 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. IPSec-peers: 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

Fejlfinding og validering af IPsec i første fase (IKEv2-forhandling)

Forhandlingerne om IPsec-tunnel involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-fasen ikke afsluttes, er der ingen igangsættelse af en anden IPsec-fase. Først skal du udstede kommandoen "show crypto ikev2 sa" (på Cisco-udstyr) eller lignende kommando på tredjepartsudstyr for at bekræfte, om IKEv2-sessionen er aktiv. Hvis IKEv2-sessionen ikke er aktiv, kan de mulige årsager være:

  • Interessant trafik udløser ikke IPsec-tunnelen.

  • IPsec-tunneladgangslisten er konfigureret forkert.

  • Der er ingen forbindelse mellem kunden og slutpunkt-IPsec-tunnel for dedikeret forekomst.

  • IKEv2-sessionsparametrene matcher ikke mellem siden Dedikeret forekomst og kundesiden.

  • En firewall blokerer IKEv2 UDP-pakkerne.

Kontrollér først IPsec-logfilerne for meddelelser, der viser status for IKEv2-tunnelforhandlingen. Logfilerne kan angive, hvor der er et problem med IKEv2-forhandlingen. Manglende logføringsmeddelelser kan også indikere, at IKEv2-sessionen ikke aktiveres.

Nogle almindelige fejl i IKEv2-forhandlingen er:

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

    • Kontrollér, at IKE-versionen er version 2.

    • Bekræft, at krypterings- og godkendelsesparametrene stemmer overens med den forventede kryptering på siden Dedikeret forekomst.

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

    • Bekræft levetidsindstillingen.

    • Bekræft Diffie Hellman-modulus-gruppen.

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

  • Adgangslisten til kryptokortet er ikke indstillet til:

    • Tillad GRE (local_tunnel_transport_ip) 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 en pakkeregistrering være nødvendig.

Siden med dedikeret forekomst starter muligvis ikke altid IKEv2-udvekslingen og kan nogle gange forvente, at kunde-CPE-siden er igangsætteren.

Kontrollér konfigurationen af CPE-siden for følgende forudsætninger for initiering af IKEv2-session:

  • Kontrollér, om der er en IPsec-kryptoadgangsliste for GRE-trafik (protokol 50) fra CPE-tunneltransport-IP til tunneltransport-IP for dedikeret forekomst.

  • Sørg for, at GRE-tunnelgrænsefladen er aktiveret for GRE keepalives. Hvis udstyret ikke understøtter GRE keepalives, får Cisco besked, fordi GRE keepalives aktiveres på siden Dedikeret forekomst som standard.

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

Når det er konfigureret korrekt, starter følgende IPsec-tunnelen og den første fase IKEv2-forhandling:

  • GRE vedligeholdes fra GRE-tunnelgrænsefladen på CPE-siden til GRE-tunnelgrænsefladen for dedikeret forekomst på siden.

  • BGP-naboens TCP-session fra BGP-naboen på CPE-siden til den dedikerede forekomst på BGP-naboen.

  • Ping fra CPE-sidetunnel-IP-adressen til den dedikerede forekomst i sidetunnel.

    Ping må ikke være tunneltransport-IP til tunneltransport-IP. Det skal være tunnel-IP til tunnel-IP.

Hvis der kræves et pakkespor til IKEv2-trafikken, skal du indstille filteret for UDP og enten port 500 (når ingen NAT-enhed er i midten af IPsec-slutpunkterne) eller port 4500 (når en NAT-enhed er indsat i midten af IPsec-slutpunkterne).

Bekræft, at IKEv2 UDP-pakker med port 500 eller 4500 sendes og modtages til og fra DI IPsec IP-adressen.

Datacenteret for dedikeret forekomst starter muligvis ikke altid den første IKEv2-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 pinge til den eksterne IPsec-adresse. Hvis ping ikke lykkes fra lokal til ekstern IPsec-adresse, skal du udføre en sporingsrute for at hjælpe og bestemme, hvor pakken droppes.

Nogle firewalls og internetudstyr tillader muligvis ikke sporingsrute.

Fejlfinding og validering af IPsec i anden fase (IPsec-forhandling)

Bekræft, at IPsec første fase (dvs. IKEv2-sikkerhedstilknytning) er aktiv, før der foretages fejlfinding af IPsec anden fase. Udfør en "show crypto ikev2 sa" eller tilsvarende kommando for at bekræfte IKEv2-sessionen. I output skal du bekræfte, at IKEv2-sessionen har været oppe i mere end et par sekunder, og at den ikke springer. Sessionens oppetid vises som sessionen "Aktiv tid" eller tilsvarende i output.

Når IKEv2-sessionen bekræfter som op og aktiv, skal du undersøge IPsec-sessionen. Som med IKEv2-sessionen skal du udføre en "show crypto ipsec sa" eller en tilsvarende kommando for at bekræfte IPsec-sessionen. Både IKEv2-sessionen og IPsec-sessionen skal være aktiv, før GRE-tunnelen oprettes. Hvis IPsec-sessionen ikke vises som aktiv, skal du kontrollere IPsec-logfilerne for fejlmeddelelser eller forhandlingsfejl.

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

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

  • Bekræft, at krypterings- og godkendelsesparametrene stemmer overens med indstillingerne på siden Dedikeret forekomst.

  • Kontrollér indstillingerne for Perfekt viderestil hemmelighed, og at indstillingerne stemmer overens på siden Dedikeret forekomst.

  • Bekræft levetidsindstillingerne.

  • Bekræft, at IPsec er konfigureret i tunneltilstand.

  • Bekræft kilde- og destinations-IPsec-adresserne.

Fejlfinding og validering af tunnelgrænseflade

Når IPsec- og IKEv2-sessionerne bekræftes som op og aktive, holder GRE-tunnelen live-pakker i stand til at flyde mellem slutpunkterne for dedikeret forekomst og CPE-tunnel. Hvis tunnelgrænsefladen ikke viser status, er nogle almindelige problemer:

  • VRF for tunnelgrænsefladetransport stemmer ikke overens med VRF for loopback-grænsefladen (hvis VRF-konfiguration bruges 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å standard keepalives på siden Dedikeret forekomst også deaktiveres.

    Hvis keepalives understøttes, skal du bekræfte, at keepalives er aktiveret.

  • Masken eller IP-adressen for tunnelgrænsefladen er ikke korrekt og stemmer ikke overens med 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 at blive sendt ind i IPsec-tunnelen eller modtaget fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En ping-test skal bekræfte, 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 ekstern tunnel-IP.

Kryptoadgangslisten for IPsec-tunnelen, der bærer GRE-tunneltrafikken, tillader kun GRE-pakker at krydse. Som følge heraf fungerer pings ikke fra tunneltransport-IP til ekstern tunneltransport-IP.

Ping-kontrollen resulterer i en GRE-pakke, der genereres fra kildetunnelens transport-IP til destinationstunnelens transport-IP, mens nyttelasten for 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 der være behov for en pakkeregistrering for at sikre, at icmp-ping resulterer i en GRE-pakke, som derefter indkapsles i en IPsec-pakke og derefter sendes fra kilde-IPsec-adressen til destinations-IPsec-adressen. Tællere på GRE-tunnelgrænsefladen og IPsec-sessionstællerne kan også hjælpe med at vise. hvis afsendelse og modtagelse af pakker stiger.

Ud over ping-trafikken skal optagelsen 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'en.

BGP-fejlfinding og -validering

BGP-sessioner

BGP er påkrævet som distributionsprotokol over VPN IPsec-tunnelen. Den lokale BGP-nabo skal oprette en eBGP-session med den dedikerede forekomst BGP-nabo. eBGP naboens IP-adresser er de samme som de lokale og eksterne tunnel-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 bekræfte, at en ping er gennemført mellem den lokale og den eksterne GRE-tunnel-IP. Hvis ping er vellykket, men BGP-sessionen ikke kommer, skal du undersøge BGP-loggen for fejl i BGP-oprettelse.

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

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

  • Det lokale AS-nummer stemmer ikke overens med, hvad siden den afdikterede forekomst forventer. Kontrollér, at det lokale AS-nummer stemmer overens med de forventede parametre for dedikeret forekomst.

  • En firewall blokerer BGP TCP-pakker, der er indkapslet i GRE-pakker, fra at blive sendt til IPsec-tunnelen eller modtaget fra IPSEC-tunnelen

  • Den eksterne BGP-nabo-IP svarer ikke til den eksterne GRE-tunnel-IP.

BGP-ruteudveksling

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

Dedikeret forekomst VPN-løsning forventer, at der oprettes to tunneler fra kunde-/partnersiden. Den første tunnel peger på datacenter A for dedikeret forekomst og den anden tunnel peger på datacenter B for dedikeret forekomst. 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 sikre dig, at den BGP-session, der er tilknyttet tunnelen, der peger mod datacenter for dedikeret forekomst A, modtager datacenter for dedikeret forekomst A /25 lokal rute samt /24 backup-ruten. Derudover skal du sikre, at den tunnel, der peger mod datacenter for dedikeret forekomst B, modtager datacenter for dedikeret forekomst B /25 lokal rute samt sikkerhedskopieringsruten /24. Bemærk, at sikkerhedskopieringsruten /24 vil være den samme rute, der er annonceret fra datacenter for dedikeret forekomst A og datacenter for dedikeret forekomst B.

Redundans leveres til et datacenter med dedikeret forekomst, hvis tunnelgrænsefladen til det pågældende datacenter går ned. Hvis forbindelsen til datacenter A afbrydes, vil trafik blive videresendt fra datacenter B til datacenter A. I dette scenarie vil tunnel til datacenter B bruge datacenter B /25-ruten til at sende trafik til datacenter B, og tunnel til datacenter B vil bruge backup /24-ruten til at sende trafik til datacenter A via datacenter B.

Når begge tunneler er aktive, er det vigtigt, at datacenter En tunnel ikke bruges til at sende trafik til datacenter B og omvendt. Hvis der i dette scenarie sendes trafik til datacenter A med en destination for datacenter B, videresender datacenter A trafikken til datacenter B, og datacenter B forsøger derefter at sende trafik tilbage til kilden via datacenter B-tunnelen. Dette vil resultere i ikke-optimal dirigering 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 datacenteret for dedikeret forekomst. Mere specifikke ruter accepteres ikke af siden Dedikeret forekomst. Sørg for, at 0.0.0.0/0-ruten annonceres fra både datacenter for dedikeret forekomst A-tunnel og datacenter for dedikeret forekomst B-tunnel.

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 strømmer gennem VPN-sessionen. IPsec-tunnelen tilføjer de ekstra headers oven på GRE-headerne 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 kommandoen "ip tcp adjust-mss 1350" eller tilsvarende samt kommandoen "tunnelsti\u0002mtu-discovery" eller tilsvarende på kundesiden for at hjælpe med den dynamiske justering af MTU af trafik gennem VPN-tunnelen.