Introduktion

Virtual Connect er en ekstra tilføjelsesmulighed for Cloud Connectivity til dedikeret forekomst til Webex Calling (dedikeret forekomst). Virtual Connect giver kunderne mulighed for sikkert at udvide deres private netværk over internettet ved hjælp af punkt-til-punkt IP VPN -tunneler. Denne tilslutningsmulighed giver en hurtig oprettelse af en privat netværksforbindelse ved hjælp af det eksisterende Customer Premise Equipment (CPE) og internetforbindelse.

Cisco hoster, administrerer og sikrer redundante IP VPN -tunneler og den påkrævede internetadgang i Ciscos dedikerede datacenterregion(er), hvor tjenesten er påkrævet. På samme måde er administratoren ansvarlig for deres tilsvarende CPE- og internettjenester, som er påkrævet for at oprette virtuel forbindelse.

Hver Virtual Connect-ordre i en bestemt dedikeret forekomstregion vil omfatte to GRE-tunneler (Generic Routing Encapsulation) beskyttet af IPSec -kryptering (GRE over IPSec), en til hvert Ciscos datacenter i den valgte region.

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

Før du sender peeringanmodningen for Virtual Connect, skal du sørge for, at tjenesten Dedikeret forekomst er aktiveret i det pågældende område.

Forudsætninger

Forudsætningerne for at oprette Virtual Connect omfatter:

  • Kunden leverer

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

    • Offentlige IP-adresse for to IPSec -tunneler

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

  • Partner og kunde

    • Samarbejd om at evaluere krav til båndbredde

    • Sørg for, at netværksenhed(er) understøtter BGP-routing (Border Gateway Protocol) og et GRE over IPSec tunneldesign

  • Partner eller kunde leverer

    • Netværksteam med viden om sted-til-sted VPN -tunnelteknologier

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

  • Cisco

    • Cisco -tildelte ASN'er (private autonome systemnumre) og midlertidig IP adressering til GRE-tunnelgrænseflader

    • Cisco tildelt offentligt, men ikke internetroubart klasse C-netværk (/24) til dedikeret cloud-forekomst-adressering

Hvis en kunde kun har 1 CPE-enhed, vil de 2 tunneler mod Ciscos datacentre (DC1 og DC2) i hver region være fra den pågældende CPE-enhed. Kunden har også mulighed for 2 CPE-enheder, så skal hver CPE-enhed kun tilsluttes 1 tunnel mod Ciscos datacentre (DC1 og DC2) i hver region. Yderligere redundans kan opnås ved at afslutte hver tunnel på et separat fysisk sted/placering i Kundens infrastruktur.

Tekniske detaljer

Ibrugtagningsmodel

Virtual Connect bruger en dual tier headend-arkitektur, hvor routing- og GRE-kontrolplanerne leveres af én enhed, og IPSec -kontrolplanet leveres af en anden.

Efter afslutningen af Virtuel forbindelse forbindelse oprettes der to GRE over IPSec -tunneller mellem kundens virksomhedsnetværk og dedikerede forekomster af Ciscos datacentre. Én til hvert redundant datacenter inden for den respektive region. Yderligere netværkselementer, der kræves til peering, udveksles af partneren eller kunden til Cisco via aktiveringsformularen til Control Hub Virtual Connect.

Figur 1 viser et eksempel på implementeringsmodel Virtual Connect for valgmuligheden med 2 koncentratorer på kundesiden.

Virtuel forbindelse – VPN er et Hub-design, hvor kundens Hub-websteder er tilsluttet DC1 og DC2 af dedikerede instansers datacentre inden for en bestemt region.

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

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

Kundens eksterne websteder inden for den samme region skal oprette forbindelse tilbage til Hub-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 vej vælges for tjenesteregionen 'Virtual Connect'.

Figur 2 viser peering-regioner for dedikeret forekomst af Cloud Connectivity.

Ruteplanlægning

Routing til Virtual Connect-tilføjelsesprogrammet implementeres ved hjælp af ekstern BGP (eBGP) mellem dedikeret forekomst og Customer Premise Equipment (CPE). Cisco annoncerer deres respektive netværk for hver redundant DC inden for en region til kundens CPE, og CPE'en er påkrævet for at annoncere en standardrute til Cisco.

  • Cisco vedligeholder og tildeler

    • Tunnelgrænseflade IP -adressering (transient link til routing) Cisco tildeler fra et udpeget delt adresseområde (kan ikke dirigeres offentligt)

    • Destinationsadresse for tunneltransport (Ciscos side)

    • Private autonome systemnumre (ASN) til kundens BGP-routingkonfiguration

      • Cisco tildeler fra det angivne område for privat brug: 64512 til og med 65534

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

    • Cisco opdeler det tildelte /24-netværk i 2/25 for hver DC i den respektive region

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

    • CPE skal konfigureres med de relevante eBGP-naboer. Hvis du bruger én CPE, bruges to eBGP-naboer, hvor én peger på hver ekstern tunnel. Hvis du bruger to CPE, vil hver CPE have en eBGP-nabo, der peger på den enkelte eksterne tunnel for CPE.

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

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

    • CPE er ansvarlig for efter behov omfordeling af de indlærte ruter inden for kundens virksomhedsnetværk.

  • Ved fejl i forbindelsen uden fejl vil en enkelt CPE have to aktive/aktive tunneler. For to CPE-knuder vil hver CPE have én aktiv tunnel, og begge CPE-knuder skal være aktive og gennemgående trafik. I et scenarie uden fejl skal trafikken opdeles i to tunneller, der går til de rigtige /25-destinationer. Hvis en af tunnelerne går ned, kan den resterende tunnel bære trafikken for begge. I et sådant fejlscenarie, når /25-netværket er nede, bruges /24-netværket som en backuprute. Cisco sender kundetrafik via sit interne WAN mod det DC, der mistede forbindelsen.

Forbindelsesproces

Følgende trin på højt niveau beskriver, hvordan du opretter forbindelse med virtuel Connect for dedikeret forekomst.

1

Afgiv en ordre i Cisco CCW
2

Aktivér Virtual Connect fra Control Hub
3

Cisco udfører netværkskonfiguration
4

Kunden udfører netværkskonfiguration

Trin 1: CCW-rækkefølge

Virtual Connect er et tilføjelsesprogram til dedikeret forekomst i CCW.

1

Gå til CCW-bestillingswebstedet, og klik derefter på Log på for at logge på webstedet:

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

Opret skøn.
3

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

Vælg Rediger valgmuligheder.
5

På den abonnementsfane, der vises, skal du vælge Valgmuligheder og Tilføjelsesprogrammer.
6

Under Yderligere tilføjelsesprogrammer skal du markere afkrydsningsfelt ved siden af "Virtuel forbindelse til dedikeret forekomst". SKU-navnet er "A-FLEX-DI-VC".
7

Indtast antallet og antallet af regioner, hvor Virtual Connect er påkrævet.


 
Mængden af Virtual Connect må ikke overstige det samlede antal regioner, der er købt til dedikeret forekomst. Desuden er der kun tilladt én virtuel forbindelse pr. område.
8

Når du er tilfreds med dine valg, skal du klikke på Bekræft og gem i den øverste højre del af siden.
9

Klik på Gem og fortsæt for at færdiggøre din ordre. Din afsluttede ordre vises nu i ordregitteret.

Trin 2: Aktivering af Virtual Connect i Control Hub

1

Log ind på Control Hubhttps://admin.webex.com/login .
2

I den Tjenester sektion, skal du navigere til Opkald > Dedikeret Instacnce > Cloud-forbindelse .
3

På Virtual Connect-kortet er det købte antal Virtual Connect angivet. Administratoren kan nu klikke på Aktivér for at starte den virtuelle forbindelsesaktivering.


 
Aktiveringsprocessen kan kun udløses af administratorer med rollen "Fuld kundeadministrator". Hvorimod en administrator med rollen "Kunde skrivebeskyttet administrator" kun kan se statussen.
4

Ved at klikke på Aktivér knap, Aktivér virtuel forbindelse formularen vises, så administratoren kan angive de tekniske oplysninger om Virtual Connect, der kræves til peering-konfigurationer på Ciscos side.


 
Formularen indeholder også statiske oplysninger på Ciscos side, baseret på den valgte region. Disse oplysninger vil være nyttige for kundeadministratorer til at konfigurere CPE på deres side for at oprette forbindelsen.

  1. IP-adresse for GRE-tunneltransport : Kunden er forpligtet til at oplyse Tunnel Transport IP -adresser på kundens side, og Cisco tildeler IP -adresserne dynamisk, når aktiveringen er fuldført. IPSec ACL for Interesting Traffic bør tillade lokal tunneltransport IP/32 til ekstern tunneltransport IP/32. ACL'en skal også kun angive GRE IP -protokollen.


     
    Den IP-adresse , som kunden oplyser, kan være privat eller offentlig.

  2. IPSec peers : Kunden skal angive IPSec -tunnellens kilde- IP -adresser, og Cisco tildeler IPSec destinations-IP-adresse. Udførelse af NAT-oversættelse af en intern IPSEC-tunneladresse til en offentlig adresse understøttes også, hvis det er nødvendigt.


     

    Den IP-adresse , som kunden angiver, skal være offentlig.

     
    Alle andre statiske oplysninger på aktiveringsskærmen er sikkerheds- og krypteringsstandarder på Ciscos side, der følges. 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å Aktivér knappen, når alle de obligatoriske felter er udfyldt.
6

Når aktiveringsformularen til virtuel forbindelse er udfyldt for en bestemt region, kan kunden eksportere aktiveringsformularen fra Control Hub, Opkald > Dedikeret forekomst > fanen Cloud-forbindelse og klikke på Eksporter indstillinger.


 
Af sikkerhedsmæssige årsager vil godkendelsen og BGP-adgangskoden ikke være tilgængelige i det eksporterede dokument, men administratoren kan se det samme i Control Hub ved at klikke på Vis indstillinger under Control Hub, Opkald > Dedikeret forekomst > fanen Cloud-forbindelse.

Trin 3: Cisco udfører netværkskonfiguration

1

Når formularen til aktivering af virtuel forbindelse er udfyldt, opdateres statussen til Aktivering i gang i Opkald > Dedikeret forekomst > Cloud Connectivity Virtual Connect-kort.
2

Cisco vil gennemføre de påkrævede konfigurationer på Ciscos udstyr inden for 5 hverdage . Når den er gennemfø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 kundeadministratoren om, at Ciscos side af konfigurationerne for IP VPN -forbindelsen er blevet fuldført baseret på de input, som kunden har leveret. Men det forventes, at kundeadministratoren fuldfører sin side af konfigurationerne på CPE'erne og teste forbindelsesruterne for, at den virtuelle forbindelsestunnel er online. I tilfælde af problemer på tidspunktet for konfiguration eller tilslutning, kan kunden kontakte Cisco TAC for at få assistance.

Fejlfinding

Fejlfinding og validering af IPsec First Phase (IKEv2 Negotiation).

IPsec-tunnelforhandlingen omfatter to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fuldføres, startes der ikke en anden IPsec-fase. Udfør først kommandoen "vis crypto ikev2 sa" (på Cisco -udstyr) eller en lignende kommando på tredjepartsudstyret for at kontrollere, om IKEv2-sessionen er aktiv. Hvis IKEv2-sessionen ikke er aktiv, kan de potentielle årsager være:

  • Interessant trafik udløser ikke IPsec-tunnelen.

  • adgangsliste til IPsec-tunnel er forkert konfigureret.

  • Der er ingen forbindelse mellem kunden og den dedikerede forekomst IPsec-tunnelslutpunkts IP.

  • IKEv2-sessionsparametrene matcher ikke mellem den dedikerede forekomstside og kundesiden.

  • En firewall blokerer IKEv2 UDP -pakkerne.

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

Nogle almindelige fejl med IKEv2-forhandling 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.

    • Kontrollér, at parametrene for kryptering og godkendelse svarer til den forventede kryptering på siden med dedikeret forekomst.

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

    • Kontrollér indstillingen for levetid.

    • Bekræft Diffie Hellman-modulgruppen.

    • Kontrollér indstillingerne for Pseudo-tilfældig funktion.

  • adgangsliste for 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)

      adgangsliste skal være specifikt til "GRE"-protokollen, og "IP"-protokollen vil ikke fungere.

Hvis logmeddelelserne ikke viser nogen forhandlingsaktivitet for IKEv2-fasen, kan det være nødvendigt at foretage en pakkeindsamling .

Dedikeret forekomstside starter muligvis ikke altid IKEv2-udvekslingen og kan nogle gange forvente, at kundens CPE-side er initiativtager.

Kontrollér konfigurationen på CPE-siden for følgende forudsætninger for IKEv2-sessionsstart:

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

  • 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 vil være aktiveret på siden med dedikeret forekomst som standard.

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

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

  • GRE keepalives fra GRE-tunnelgrænsefladen på CPE-siden til GRE-tunnelgrænsefladen på siden med dedikerede forekomster.

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

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

    Ping kan ikke være IP til tunneltransport til tunneltransport IP, den skal være IP IP fra tunnel til tunnel.

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

Kontrollér, at IKEv2 UDP -pakker med port 500 eller 4500 sendes og modtages til og fra DI IPsec IP-adresse.

Det dedikerede datacenter for 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 den dedikerede forekomstside.

Hvis den lokale firewall tillader det, så forsøg også 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 finde ud af, hvor pakken er droppet.

Nogle firewalls og internetudstyr tillader muligvis ikke sporingsruter.

Fejlfinding og validering af IPsec Second Phase (IPsec Negotiation).

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

Når IKEv2-sessionen bekræftes som aktiv og aktiv, skal du undersøge IPsec-sessionen. Som med IKEv2-sessionen skal du udføre en "vis crypto ipsec sa" eller tilsvarende kommando for at bekræfte IPsec-sessionen. Både IKEv2-sessionen og IPsec-sessionen skal være aktive, før GRE-tunnellen oprettes. Hvis IPsec-sessionen ikke vises som aktiv, skal du kontrollere IPsec-loggerne 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 med dedikeret forekomst. Kontrollér indstillingerne igen:

  • Kontrollér, at parametrene for kryptering og godkendelse svarer til indstillingerne på siden med dedikeret forekomst.

  • Kontrollér indstillingerne for Perfect Forward-hemmelighed, og at indstillingerne matcher indstillingerne på siden med dedikeret forekomst.

  • Kontrollér indstillingerne for levetid.

  • Kontrollér, at IPsec er blevet konfigureret i tunneltilstand.

  • Kontrollér kilde- og destinations-IPsec-adresserne.

Fejlfinding og validering af tunnelgrænsefladen

Når IPsec- og IKEv2-sessionerne bekræftes som aktive og aktive, kan Keepalive-pakkerne i GRE-tunnelen flyde mellem den dedikerede forekomst og slutpunkterne i CPE-tunnelen. Hvis statussen for tunnelgrænsefladen ikke vises, er nogle almindelige problemer:

  • Transport-VRF for tunnelgrænsefladen svarer ikke til 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å standard keepalives på siden med dedikerede forekomster også deaktiveres.

    Hvis Keepalives er understøttet, skal du kontrollere, at Keepalives er aktiveret.

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

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

  • En firewall blokerer for, at GRE-pakker sendes ind i IPsec-tunnellen eller modtages fra IPsec-tunnellen (GRE-tunnellen overføres via IPsec-tunnellen)

En ping-test skal bekræfte, at den lokale tunnelgrænseflade er aktiveret, og at der er god forbindelse til den eksterne tunnelgrænseflade. Udfør ping-kontrollen fra tunnelens IP (ikke transport IP) til den eksterne tunnel IP.

adgangsliste for IPsec-tunnelen, der overfører GRE-tunneltrafikken, tillader kun at krydse GRE-pakker. Som følge heraf fungerer ping ikke fra IP -adresse til tunneltransport til IP til ekstern tunneltransport .

Pingkontrollen resulterer i en GRE-pakke, der genereres fra kildens tunneltransport IP til destinationstunnelens transport IP , mens GRE-pakkens nyttelast (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 pakkeindsamling for at sikre, at icmp-pinget resulterer i en GRE-pakke, der derefter indkapsles i en IPsec-pakke og derefter sendes fra kildens IPsec-adresse til destinationens IPsec-adresse. Tællere på GRE-tunnelgrænsefladen og IPsec-sessionstællerne kan også hjælpe med at vise. hvis afsendelses- og modtagelsespakkerne stiger.

Ud over ping-trafikken skal capture også vise keepalive GRE-pakker, selv under inaktiv trafik. Endelig, 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 routingprotokol over VPN IPsec-tunnelen. Den lokale BGP-nabo bør oprette en eBGP-session med den dedikerede BGP-nabo for forekomster. eBGP-nabo IP -adresserne er de samme som de lokale og eksterne tunnel IP -adresser. Sørg først for, at BGP-sessionen er oppe, og kontroller derefter, at de rigtige ruter modtages fra dedikeret forekomst, og at den rigtige standardrute sendes til dedikeret forekomst.

Hvis GRE-tunnelen er oppe, skal du kontrollere, at der gennemføres et ping mellem den lokale og den eksterne GRE-tunnel IP. Hvis pingen lykkes, men BGP-sessionen ikke kommer op, skal du undersøge BGP-loggen for BGP-etableringsfejl.

Nogle af de mere almindelige problemer med BGP-forhandling er:

  • Det eksterne AS-nummer stemmer ikke overens med det AS-nummer, der er konfigureret på siden for dedikeret forekomst. Kontrollér den tilstødende AS-konfiguration igen.

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

  • En firewall blokerer for, at BGP TCP -pakker, der er indkapslet i GRE-pakker, ikke sendes til IPsec-tunnellen eller modtages fra IPSEC-tunnlen

  • 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 sørge for, at de rigtige ruter sendes og modtages fra siden med dedikeret forekomst.

Den dedikerede instans 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 dedikeret forekomst datacenter vil annoncere sin lokale /25 rute samt en /24 backup rute. 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 på datacenter A for dedikeret forekomst, modtager den lokal rute for datacenter A /25 for dedikeret forekomst samt /24-sikkerhedskopieringsruten. Derudover skal du sørge for, at den tunnel, der peger på datacenter B for dedikeret forekomst, modtager den lokal rute for datacenter B /25 for dedikeret forekomst samt ruten /24 til sikkerhedskopiering. Bemærk, at /24-sikkerhedskopieringsruten vil være den samme rute, der annonceres fra dedikeret forekomst datacenter A og dedikeret forekomst datacenter B.

Redundans leveres til et dedikeret forekomst-datacenter, hvis tunnelgrænsefladen til det pågældende datacenter går ned. Hvis forbindelsen til datacenter A med dedikeret forekomst mistes, videresendes trafikken fra datacenter B til dedikeret forekomst til datacenter A. I dette scenarie bruger tunnellen til datacenter B ruten datacenter B/25 til at sende trafik til datacenter B og tunnelen til datacenter B bruger ruten backup /24 til at sende trafik til datacenter A via datacenter B.

Det er vigtigt, at når begge tunneler er aktive, bruges datacenter A-tunnelen ikke til at sende trafik til datacenter B og omvendt. I dette scenarie, hvis der sendes trafik 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 trafik tilbage til kilden via datacenter B-tunnelen. Dette vil resultere i suboptimal routing og kan også ødelægge trafik, der krydser firewalls. Derfor er det vigtigt, at begge tunneler er i en aktiv/aktiv konfiguration under normal drift.

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

MTU-konfiguration

På siden dedikeret forekomst er to funktioner aktiveret til dynamisk at justere MTU til store pakkestørrelser. GRE-tunnelen tilføjer flere headere til de IP pakker, der flyder gennem VPN -sessionen. IPsec-tunnellen tilføjer de ekstra headers oven på GRE-headerne vil yderligere reducere den største tilladte MTU over tunnelen.

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