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 sender peering-anmodningen for Virtual Connect, skal du sørge for, at Dedicated Instance-tjenesten er aktiveret i den respektive region.

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

Implementeringsmodel

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.

Figuren nedenfor viser et eksempel på den virtuelle forbindelsesimplementeringsmodel for 2-koncentrator-muligheden 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. For at sikre effektiv failover må den samlede trafik på tværs af begge tunneler ikke overstige 250 Mbps, da al trafik vil blive dirigeret gennem én tunnel i tilfælde af en fejl.

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 og sikre, at den mest optimale vej vælges for Virtual Connect serviceregionen.

Figuren nedenfor viser peering-områderne for dedikeret instans-cloudforbindelse.

Virtuelle forbindelsesregioner

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.

Virtuel forbindelsestrafikflow

Trafikflowet når begge tunneler er oppe

Dedikeret instans - Virtuel forbindelse

Dette billede illustrerer en Virtual Connect netværksarkitektur, der beskriver trafikflowet, når både primære og sekundære tunneler er i drift.

Det repræsenterer en aktiv forbindelsesmodel, der giver en kunde adgang til UC-applikationer, der hostes i Ciscos datacentre, og udnytter dobbelt GRE/IPSEC tunneler over internettet med BGP til ruteudveksling.

Definitioner:

  • Kundelokalitet:
    • Dette repræsenterer kundens lokale netværk, hvor brugerne og deres enheder (f.eks. IP-telefoner, computere, der kører UC-klienter) er placeret.
    • Trafik, der stammer herfra, skal nå de UC-applikationer, der hostes i Ciscos datacentre.
  • Cisco Webex Calling Dedikeret Instans (Dedikeret Instans) datacentre (WxC-DI DC-A og WxC-DI DC-B):
    • Dette er Ciscos datacentre, der hoster UC-applikationerne.
    • DC-A og DC-B er geografisk adskilte, hvilket giver redundans.
    • Hvert datacenter har sit eget undernet til UC-applikationer:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Tunneler (Tunnel 1 og Tunnel 2):
    • Dette er de sikre, krypterede forbindelser mellem kundens lokaler og Cisco-datacenteret via det offentlige internet.
    • GRE (Generisk Routing Indkapsling): Denne protokol bruges til at indkapsle forskellige netværkslagsprotokoller i virtuelle punkt-til-punkt-links. Det tillader routingprotokoller som BGP at operere over tunnelen.
    • IPsec (Internetprotokolsikkerhed): Denne pakke af protokoller leverer kryptografiske sikkerhedstjenester (godkendelse, integritet, fortrolighed) til IP-kommunikation. Den krypterer den GRE-indkapslede trafik, hvilket sikrer sikker dataoverførsel over internettet.
  • Border Gateway-protokol (BGP):
    • BGP er den routingprotokol, der bruges til at udveksle routinginformation mellem kundens lokaler og Cisco-datacentrene.

Som vist i ovenstående diagram skal enheder, der er installeret hos kunden, etablere to GRE/IPSEC tunneler.

Navngivningskonventionerne anvendt nedenfor med XX / YY, DC-A DC-B er generiske for alle regioner, hvor dedikeret instans tilbydes. Disse værdier vil være unikke for hver region, og de faktiske værdier for hver region. De specifikke værdier angives under aktiveringen af den virtuelle forbindelse.

På Cisco-siden vil IPSec- og GRE-tunnellerne blive termineret på forskellige enheder. Så kunden skal sørge for at konfigurere IPSec-destinations- og GRE-destinations-IP'er på enhederne i overensstemmelse hermed. Kunder kan bruge den samme IP-adresse til GRE og IPSEC, hvis det understøttes på deres enheder. Se diagrammet ovenfor. De IP-relaterede værdier angives under aktivering af den virtuelle forbindelse på portalen.

  • Tunnel 1: Forbinder kundens lokaler til "Dedikeret instans DC-A" (datacenter A) via internettet. Denne tunnel bruger BGP AS:64XX1 på kundesiden og BGP AS:64XX2 på den dedikerede instans DC-A-side. IPSEC- og GRE-tunnelkildekonfigurationer er opdelt mellem kundeleverede og Cisco-leverede detaljer.
  • Tunnel 2: Forbinder kundens lokaler til "Dedicated Instance DC-B" (Datacenter B) via internettet. Denne tunnel bruger BGP AS:64YY1 på kundesiden og BGP AS:64YY2 på den dedikerede instans DC-B-side. Ligesom Tunnel 1 deles IPSEC- og GRE-tunnelkildekonfigurationer mellem kunden og Cisco.

I BGP AS:64XX og BGP AS:64YY, XX og YY er specifikke for en bestemt region.

Når den GRE/IPSEC Hvis tunneler etableres til Webex Calling Dedicated Instance-datacentre (A og B), bør kunden modtage følgende ruter annonceret fra Cisco over de tilsvarende BGP-sessioner.

  • Til DC-A: Ruter annonceret fra Cisco vil være X.X.X.0/25 og X.X.x.0/24. Valgfrit hvis IaaS anmodes om og konfigureres til kundens ruter Y.Y.Y.0/25 og Y.Y.Y.0/24 vil blive annonceret fra Cisco.
  • Til DC-B: Ruter annonceret fra Cisco vil være X.X.X.128/25 og X.X.x.0/24. Valgfrit hvis IaaS anmodes om og konfigureres til kundens ruter Y.Y.Y.128/25 og Y.Y.Y.0/24 vil blive annonceret fra Cisco.
  • Kunden skal reklamere for 0.0.0./0 rute til Cisco gennem begge forbindelser (tunneler)
  • Kunden skal følge det længste præfiks (/25) ruter til at sende trafik til Cisco gennem de respektive tunneler, når begge tunneler er oppe.
  • Cisco vil føre trafikken tilbage gennem de samme tunneler for at holde trafikken symmetrisk.

Trafikflow:

  • Trafik beregnet til "DC-A UC Apps" (X.X.X.0/25) fra kundens præmis strømmer gennem Tunnel 1.
  • Trafik beregnet til "DC-B UC Apps" (X.X.X.128/25) fra kundens præmis strømmer gennem Tunnel 2.

Failover-scenarie : trafikflow, når en af tunnellerne er nede

Dedikeret instans - Virtuel forbindelse

Som vist i ovenstående diagram, når tunnelen til DC-A er nede, vil bgp'en etableret gennem tunnelen til DC-A gå ned.

Indvirkning på BGP: Når Tunnel 1 går ned, vil BGP-sessionen over den tunnel også gå ned. Derfor vil DC-A ikke længere kunne annoncere sine ruter (specifikt X.X.X.0/25) til kunden via denne vej. Derfor vil kundens router registrere stien som uopnåelig.

Da Tunnel 1 er nede, vil kundens router på kundens adresse automatisk fjerne de ruter, der er lært via Tunnel 1, fra sin routingtabel eller markere dem som utilgængelige.

  • Trafik beregnet til UC App Network (X.X.X.0/24) eller DC-A-undernettet (X.X.X.0/25) vil derefter blive omdirigeret gennem arbejdstunnelen mod DC-B, som fortsætter med at reklamere for X.X.X.0/24 der inkluderer X.X.X.0/25 netværk.
  • Lignende adfærd vil ses, hvis tunnelen til DC-B er nede, mens tunnelen til DC-A stadig er oppe.

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 Tunnel Transport 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ængelige i det eksporterede dokument, men administratoren kan se dem i Control Hub ved at klikke på Vis indstillinger under Control Hub, Opkald. > Dedikeret instans > Fanen 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 vil færdiggøre de nødvendige konfigurationer på Ciscos sideudstyr inden for 5 hverdage. 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 første fase (IKEv2-forhandling)

IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fuldføres, starter der ingen anden IPsec-fase. Udfør først kommandoen "show 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 mulige årsager være:

  • Interessant trafik udløser ikke IPsec-tunnelen.

  • IPsec-tunneladgangslisten er forkert konfigureret.

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

  • IKEv2-sessionsparametrene stemmer ikke overens på siden med den dedikerede instans og kundesiden.

  • En firewall blokerer IKEv2 UDP-pakkerne.

Først skal du kontrollere IPsec-loggene for eventuelle meddelelser, der viser status for IKEv2-tunnelforhandlingen. Loggene kan indikere, hvor der er et problem med IKEv2-forhandlingen. Manglende logmeddelelser kan også indikere, at IKEv2-sessionen ikke aktiveres.

Nogle almindelige fejl med IKEv2-forhandlingen er:

  • Indstillingerne for IKEv2 på CPE-siden stemmer ikke overens med Ciscos. Kontroller de nævnte indstillinger igen:

    • Kontroller, at IKE-versionen er version 2.

    • Bekræft, at parametrene for kryptering og godkendelse matcher den forventede kryptering på siden af den dedikerede instans.

      Når "GCM"-chifferen er i brug, håndterer GCM-protokollen godkendelsen og sætter godkendelsesparameteren til NULL.

    • Bekræft levetidsindstillingen.

    • Verificer Diffie Hellman modulusgruppen.

    • Bekræft indstillingerne for pseudotilfældig funktion.

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

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

Hvis logmeddelelserne ikke viser nogen forhandlingsaktivitet for IKEv2-fasen, kan en pakkeoptagelse være nødvendig.

Den dedikerede instansside starter ikke altid IKEv2-udvekslingen og kan nogle gange forvente, at kundens CPE-side er initiativtager.

Kontrollér CPE-sidekonfigurationen for følgende forudsætninger for IKEv2-sessionsstart:

  • Tjek efter en IPsec-kryptoadgangsliste for GRE-trafik (protokol 50) fra CPE-tunneltransport-IP'en til den dedikerede instans' tunneltransport-IP.

  • Sørg for, at GRE-tunnelgrænsefladen er aktiveret til GRE keepalives. Hvis udstyret ikke understøtter GRE keepalives, får Cisco besked, da GRE keepalives som standard vil være aktiveret på den dedikerede instansside.

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

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

  • GRE keepalives fra CPE-sidens GRE-tunnelgrænseflade til den dedikerede instanssides GRE-tunnelgrænseflade.

  • BGP-nabo TCP-session fra CPE-sidens BGP-nabo til den dedikerede instanssides BGP-nabo.

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

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

Hvis der er behov for en pakkesporing til IKEv2-trafikken, skal filteret indstilles til UDP og enten port 500 (når der ikke er nogen NAT-enhed midt mellem IPsec-slutpunkterne) eller port 4500 (når en NAT-enhed er indsat midt mellem 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 den dedikerede instans starter muligvis ikke altid den første IKEv2-pakke. Kravet er, at CPE-enheden er i stand til at initiere den første IKEv2-pakke mod den dedikerede instansside.

Hvis den lokale firewall tillader det, skal du også forsøge at pinge til den eksterne IPsec-adresse. Hvis pingen ikke lykkes fra den lokale til den eksterne IPsec-adresse, skal du udføre en sporingsrute for at finde ud af, hvor pakken er blevet sendt.

Nogle firewalls og internetudstyr tillader muligvis ikke sporingsruter.

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

Bekræft, at den første IPsec-fase (dvs. IKEv2-sikkerhedstilknytningen) er aktiv, før du foretager fejlfinding af den anden IPsec-fase. Udfør en "show crypto ikev2 sa" eller tilsvarende kommando for at verificere IKEv2-sessionen. I outputtet skal du kontrollere, at IKEv2-sessionen har været aktiv i mere end et par sekunder, og at den ikke hopper. Sessionens oppetid vises som sessionens "Aktiv tid" eller tilsvarende i outputtet.

Når IKEv2-sessionen er bekræftet som aktiv, skal du undersøge IPsec-sessionen. Ligesom med IKEv2-sessionen skal du udføre en "show 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-tunnelen etableres. Hvis IPsec-sessionen ikke vises som aktiv, skal du kontrollere IPsec-loggene for fejlmeddelelser eller forhandlingsfejl.

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

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

  • Bekræft, at parametrene for kryptering og godkendelse stemmer overens med indstillingerne på siden Dedikeret instans.

  • Bekræft indstillingerne for Perfect Forward Secrecy, og at de matcher indstillingerne på siden med dedikeret instans.

  • 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 er verificeret som aktive, kan GRE-tunnelens keepalive-pakker flyde mellem den dedikerede instans og CPE-tunnelens slutpunkter. Hvis tunnelgrænsefladen ikke viser status, er der nogle almindelige problemer:

  • Tunnelgrænsefladens transport-VRF matcher ikke loopback-grænsefladens VRF (hvis VRF-konfigurationen 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å den dedikerede instans-side også deaktiveres.

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

  • Masken eller IP-adressen for tunnelgrænsefladen er ikke korrekt og stemmer ikke overens med de forventede værdier for den dedikerede instans.

  • Kilde- eller destinationstunnelens transportadresse er ikke korrekt og stemmer ikke overens med de forventede værdier for den dedikerede instans.

  • 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 bør bekræfte, at den lokale tunnelgrænseflade er aktiv, og at forbindelsen til den eksterne tunnelgrænseflade er god. Udfør ping-tjekket fra tunnel-IP'en (ikke transport-IP'en) til den eksterne tunnel-IP.

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

Ping-tjekket resulterer i en GRE-pakke, der genereres fra kildetunneltransport-IP'en til destinationtunneltransport-IP'en, mens GRE-pakkens nyttelast (den interne IP) vil være kilde- og destinationtunnel-IP'en.

Hvis ping-testen ikke lykkes, og de foregående punkter verificeres, kan en pakkeoptagelse være nødvendig for at sikre, at icmp-pingen resulterer i en GRE-pakke, som derefter indkapsles i en IPsec-pakke og 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, om antallet af sendte og modtagede pakker stiger.

Ud over ping-trafikken bør optagelsen også vise keepalive GRE-pakker, selv under inaktiv trafik. Endelig, hvis BGP er konfigureret, bør BGP keepalive-pakker også sendes som GRE-pakker indkapslet i IPSEC-pakker over VPN'en.

BGP-fejlfinding og validering

BGP-sessioner

BGP er påkrævet som routingprotokol over VPN IPsec-tunnelen. Den lokale BGP-nabo skal etablere en eBGP-session med den dedikerede instans BGP-nabo. eBGP-nabo-IP-adresserne er de samme som de lokale og eksterne tunnel-IP-adresser. Sørg først for, at BGP-sessionen er aktiv, og bekræft derefter, at de korrekte ruter modtages fra den dedikerede instans, og at den korrekte standardrute sendes til den dedikerede instans.

Hvis GRE-tunnelen er aktiv, skal du kontrollere, at en ping er vellykket mellem den lokale og den eksterne GRE-tunnel-IP. Hvis pingen lykkes, men BGP-sessionen ikke starter, skal du undersøge BGP-loggen for BGP-etableringsfejl.

Nogle af de mere almindelige BGP-forhandlingsproblemer er:

  • Nummeret på den eksterne AS stemmer ikke overens med det AS-nummer, der er konfigureret på siden af den dedikerede instans. Kontroller konfigurationen af den tilstødende AS igen.

  • Det lokale AS-nummer stemmer ikke overens med, hvad den dedikerede instansside forventer. Kontroller, at det lokale AS-nummer stemmer overens med de forventede parametre for den dedikerede instans.

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

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

BGP-ruteudveksling

Når BGP-sessionen er verificeret for begge tunneler, skal du sørge for, at de korrekte ruter sendes og modtages fra den dedikerede instansside.

VPN-løsningen med dedikeret instans forventer, at der etableres to tunneler fra customer/partner side. Den første tunnel peger på datacenter A for den dedikerede instans, og den anden tunnel peger på datacenter B for den dedikerede instans. Begge tunneler skal være i aktiv tilstand, og løsningen kræver en active/active implementering. Hvert dedikeret instansdatacenter vil annoncere sin lokale /25 rute samt en /24 backup-rute. Når du kontrollerer de indgående BGP-ruter fra Dedikeret Instans, skal du sørge for, at den BGP-session, der er knyttet til tunnelen, der peger på Dedikeret Instans datacenter A, modtager Dedikeret Instans datacenter A. /25 den lokale rute samt /24 backup-rute. Derudover skal du sørge for, at tunnelen, der peger på Dedicated Instance datacenter B, modtager Dedicated Instance datacenter B. /25 den lokale rute samt /24 backup-rute. Bemærk at /24 Backupruten vil være den samme rute, der annonceres fra Dedikeret Instans-datacenter A og Dedikeret Instans-datacenter B.

Der gives redundans til et dedikeret instansdatacenter, hvis tunnelgrænsefladen til det pågældende datacenter går ned. Hvis forbindelsen til Dedikeret Instans datacenter A mistes, videresendes trafikken fra Dedikeret Instans 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 backup'en /24 rute til at sende trafik til datacenter A via datacenter B.

Det er vigtigt, at når begge tunneler er aktive, bruges datacenter A-tunnel ikke til at sende trafik til datacenter B og omvendt. I dette scenarie, hvis trafik sendes til datacenter A med destinationen datacenter B, vil datacenter A videresende 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 active/active konfiguration under normal drift.

De 0.0.0.0/0 Ruten skal annonceres fra kundesiden til datacentersiden for den dedikerede instans. Mere specifikke ruter vil ikke blive accepteret af den dedikerede instans-side. Sørg for, at 0.0.0.0/0 Ruten annonceres fra både den dedikerede instans datacenter A-tunnel og den dedikerede instans datacenter B-tunnel.

MTU-konfiguration

På siden Dedikeret instans er to funktioner aktiveret til dynamisk at justere MTU for store pakkestørrelser. GRE-tunnelen tilføjer flere headere til IP-pakkerne, der flyder gennem VPN-sessionen. IPsec-tunnelen tilføjer de ekstra headere oven på GRE-headerne, hvilket yderligere reducerer den største MTU, der er tilladt over tunnelen.

GRE-tunnelen justerer MSS-funktionen, og GRE-tunnelstien i MTU-opdagelsesfunktionen er aktiveret på den dedikerede instansside. 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 for trafik gennem VPN-tunnelen.