Introduksjon

Virtual Connect er et ekstra tilleggsalternativ for skytilkobling til dedikert instans for Webex Calling (dedikert instans). Virtual Connect lar kunder utvide sitt private nettverk sikkert over internett ved hjelp av punkt-til-punkt IP VPN-tunneler. Dette tilkoblingsalternativet gir rask etablering av en privat nettverkstilkobling ved å bruke eksisterende kundeutstyr (CPE) og internettforbindelse.

Cisco er vert for, administrerer og sikrer redundante IP VPN-tunneler og nødvendig internettilgang i Ciscos dedikerte instansdatasenterregion(er) der tjenesten er nødvendig. På samme måte er administratoren ansvarlig for tilhørende CPE og internettjenester som kreves for etablering av virtuell tilkobling.

Hver virtuelle tilkoblingsordre i en bestemt dedikert instansregion vil inkludere to generiske rutingsinnkapslingstunneler (GRE) beskyttet av IPSec-kryptering (GRE over IPSec), én til hvert Cisco-datasenter i den valgte regionen.

Virtual Connect har en båndbreddegrense på 250 Mbps per tunnel og anbefales for mindre implementeringer. Siden to punkt-til-punkt VPN-tunneler brukes, må all trafikk til skyen gå gjennom kundens headend CPE, og derfor er det kanskje ikke egnet der det er mange eksterne steder. For andre alternative peering-alternativer, se Cloud Connectivity.

Før du sender inn peering-forespørselen for Virtual Connect, må du sørge for at Dedicated Instance-tjenesten er aktivert i den respektive regionen.

Forutsetninger

Forutsetningene for å etablere Virtual Connect inkluderer:

  • Kunden tilbyr

    • Internettforbindelse med nok tilgjengelig båndbredde til å støtte utrullingen

    • Offentlig(e) IP-adresse(r) for to IPSec-tunneler

    • Kundesidens GRE-transport-IP-adresser for de to GRE-tunnelene

  • Partner og kunde

    • Samarbeid for å evaluere båndbreddekrav

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

  • Partner eller kunde leverer

    • Nettverksteam med kunnskap om site-to-site VPN-tunnelteknologier

    • Nettverksteam med kunnskap om BGP, eBGP og generelle rutingprinsipper

  • Cisco

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

    • Cisco tilordnet offentlig, men ikke Internett-rutbar klasse C (/24) nettverk for dedikert instans-skyadressering

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

Tekniske detaljer

Distribusjonsmodell

Virtual Connect bruker en tolags headend-arkitektur, der rutings- og GRE-kontrollplanene leveres av én enhet og IPSec-kontrollplanet leveres av en annen.

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

Figuren nedenfor viser et eksempel på en virtuell tilkoblingsdistribusjonsmodell for alternativet med 2 konsentratorer på kundesiden.

Virtuell tilkobling – VPN er et hub-design, der kundens hub-steder er koblet til DC1 og DC2 for dedikerte instansers datasentre innenfor en bestemt region.

To hub-steder anbefales for bedre redundans, men ett hub-sted med to tunneler er også en støttet distribusjonsmodell.

Båndbredden per tunnel er begrenset til 250 Mbps. For å sikre effektiv failover, må den kombinerte trafikken på tvers av begge tunnelene ikke overstige 250 Mbps, ettersom all trafikk vil bli rutet gjennom én tunnel i tilfelle feil.

Kundens eksterne steder innenfor samme region må koble seg tilbake til huben(e) via kundens WAN, og det er ikke Ciscos ansvar for denne tilkoblingen.

Partnere forventes å samarbeide tett med kundene og sørge for at den mest optimale veien velges for tjenesteregionen Virtual Connect.

Figuren nedenfor viser peering-regionene for dedikert instans for skytilkobling.

Virtuelle tilkoblingsregioner

Ruting

Ruting for Virtual Connect-tillegget implementeres ved hjelp av ekstern BGP (eBGP) mellom dedikert instans og kundens lokale utstyr (CPE). Cisco vil annonsere sitt respektive nettverk for hver redundante domenekontroller innenfor en region til kundens CPE, og CPE-en er pålagt å annonsere en standardrute til Cisco.

  • Cisco vedlikeholder og tildeler

    • Tunnelgrensesnitt IP-adressering (transient lenke for ruting) Cisco tildeler fra et angitt delt adresseområde (ikke offentlig rutbart)

    • Destinasjonsadresse for tunneltransport (Ciscos side)

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

      • Cisco tildeler fra det angitte private bruksområdet: 64512 til 65534

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

    • Cisco vil dele den tildelte /24 nettverk i 2 /25 én for hver DC i den respektive regionen

    • I Virtual Connect hver /25 nettverket annonseres tilbake til CPE av Cisco over de respektive punkt-til-punkt VPN-tunnelene (transient link)

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

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

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

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

  • Under en tilstand uten koblingsfeil vil en enkelt CPE ha to active/active tunneler. For to CPE-noder vil hver CPE ha én aktiv tunnel, og begge CPE-nodene skal være aktive og sende trafikk. Under et scenario uten feil må trafikken deles i to tunneler som går til riktig retning. /25 destinasjoner, hvis en av tunnelene går ned, kan den gjenværende tunnelen frakte trafikken for begge. Under et slikt feilscenario, når /25 nettverket er nede, så /24 nettverket brukes som en backup-rute. Cisco vil sende kundetrafikk via sitt interne WAN mot domenet som mistet tilkoblingen.

Virtuell tilkoblingstrafikkflyt

Trafikkflyten når begge tunnelene er oppe

Dedikert instans – virtuell tilkobling

Dette bildet illustrerer en Virtual Connect nettverksarkitektur, som beskriver trafikkflyten når både primære og sekundære tunneler er i drift.

Den representerer en aktiv tilkoblingsmodell for en kunde for å få tilgang til UC-applikasjoner som ligger i Ciscos datasentre, og utnytter dobbel GRE/IPSEC tunneler over internett med BGP for ruteutveksling.

Definisjoner:

  • Kundelokale:
    • Dette representerer kundens nettverk på stedet, der brukere og enhetene deres (f.eks. IP-telefoner, datamaskiner som kjører UC-klienter) befinner seg.
    • Trafikk som kommer herfra må nå UC-applikasjonene som ligger i Ciscos datasentre.
  • Cisco Webex Calling Dedikert instans (Dedikert instans) datasentre (WxC-DI DC-A og WxC-DI DC-B):
    • Dette er Ciscos datasentre som er vert for UC-applikasjonene.
    • DC-A og DC-B er geografisk forskjellige, noe som gir redundans.
    • Hvert datasenter har sitt eget delnett for UC-applikasjoner:
      • 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, krypterte forbindelsene mellom kundens lokaler og Cisco-datasenteret over det offentlige internett.
    • GRE (generisk rutinginnkapsling): Denne protokollen brukes til å innkapsle ulike nettverkslagsprotokoller inne i virtuelle punkt-til-punkt-koblinger. Det tillater rutingsprotokoller som BGP å operere over tunnelen.
    • IPsec (Internettprotokollsikkerhet): Denne protokollpakken tilbyr kryptografiske sikkerhetstjenester (autentisering, integritet, konfidensialitet) for IP-kommunikasjon. Den krypterer GRE-innkapslet trafikk, noe som sikrer sikker dataoverføring over Internett.
  • Border Gateway-protokollen (BGP):
    • BGP er rutingsprotokollen som brukes til å utveksle rutingsinformasjon mellom kundens lokaler og Cisco-datasentrene.

Som vist i diagrammet ovenfor, må enheter som er distribuert hos kunden etablere to GRE/IPSEC tunneler.

Navnekonvensjonene som brukes nedenfor med XX / YY, DC-A DC-B er generiske for alle regioner der dedikert instans tilbys. Disse verdiene vil være unike for hver region, og de faktiske verdiene for hver region. De spesifikke verdiene oppgis under aktiveringen av den virtuelle tilkoblingen.

På Cisco-siden vil IPSec- og GRE-tunnelene bli terminert på forskjellige enheter. Så kunden må sørge for å konfigurere IPSec-destinasjons- og GRE-destinasjons-IP-adresser på enhetene deretter. Kunder kan bruke samme IP-adresse for GRE og IPSEC hvis det støttes på enhetene deres. Se diagrammet ovenfor. IP-relaterte verdier oppgis under aktivering av den virtuelle tilkoblingen på portalen.

  • Tunnel 1: Kobler kundens lokaler til «Dedikert instans DC-A» (datasenter A) via Internett. Denne tunnelen bruker BGP AS:64XX1 på kundesiden og BGP AS:64XX2 på den dedikerte instansens DC-A-side. IPSEC- og GRE-tunnelkildekonfigurasjoner er delt mellom kundeleverte og Cisco-leverte detaljer.
  • Tunnel 2: Kobler kundens lokaler til «Dedikert instans DC-B» (datasenter B) via Internett. Denne tunnelen bruker BGP AS:64YY1 på kundesiden og BGP AS:64YY2 på den dedikerte instansens DC-B-side. I likhet med tunnel 1 deles IPSEC- og GRE-tunnelkildekonfigurasjoner mellom kunden og Cisco.

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

Når den GRE/IPSEC Når tunneler er etablert til Webex Calling Dedicated Instance-datasentre (A og B), skal kunden motta følgende ruter annonsert fra Cisco over de tilsvarende BGP-øktene.

  • For DC-A: Ruter annonsert fra Cisco vil være X.X.X.0/25 og X.X.x.0/24. Valgfritt hvis IaaS er forespurt og konfigurert for kundens ruter Y.Y.Y.0/25 og Y.Y.Y.0/24 vil bli annonsert fra Cisco.
  • For DC-B: Ruter annonsert fra Cisco vil være X.X.X.128/25 og X.X.x.0/24. Valgfritt hvis IaaS er forespurt og konfigurert for kundens ruter Y.Y.Y.128/25 og Y.Y.Y.0/24 vil bli annonsert fra Cisco.
  • Kunden må annonsere 0.0.0./0 rute til Cisco gjennom begge forbindelsene (tunnelene)
  • Kunden må følge det lengste prefikset (/25) ruter for å sende trafikk til Cisco gjennom de respektive tunnelene når begge tunnelene er oppe.
  • Cisco vil føre trafikken tilbake gjennom de samme tunnelene for å holde trafikken symmetrisk.

Trafikkflyt:

  • Trafikk som er ment for «DC-A UC-apper» (X.X.X.0/25) fra kundens lokaler strømmer gjennom tunnel 1.
  • Trafikk som er ment for «DC-B UC Apps» (X.X.X.128/25) fra kundens lokaler strømmer gjennom tunnel 2.

Failover-scenario : trafikkflyt når en av tunnelene er nede

Dedikert instans – virtuell tilkobling

Som vist i diagrammet ovenfor, når tunnelen til DC-A er nede, vil bgp-en som er etablert gjennom tunnelen til DC-A gå ned.

Innvirkning på BGP: Når tunnel 1 går ned, vil også BGP-økten over den tunnelen gå ned. Følgelig vil ikke DC-A lenger kunne annonsere rutene sine (spesielt X.X.X.0/25) til kunden via denne veien. Derfor vil kundens ruter oppdage banen som utilgjengelig.

Siden Tunnel 1 er nede, vil kundens ruter hos kunden automatisk fjerne rutene som er lært via Tunnel 1 fra rutingstabellen, eller merke dem som utilgjengelige.

  • Trafikk som er rettet mot UC App Network (X.X.X.0/24) eller DC-A-undernettet (X.X.X.0/25) vil deretter bli omdirigert gjennom arbeidstunnelen mot DC-B som fortsetter å annonsere X.X.X.0/24 som inkluderer X.X.X.0/25 nettverk.
  • Lignende oppførsel vil sees hvis tunnelen til DC-B er nede mens tunnelen til DC-A fortsatt er oppe.

Tilkoblingsprosess

Følgende trinn på overordnet nivå beskriver hvordan du oppretter tilkobling med virtuell tilkobling for dedikert instans.
1

Legg inn en bestilling i Cisco CCW

2

Aktiver virtuell tilkobling fra kontrollhub

3

Cisco utfører nettverkskonfigurasjon

4

Kunden utfører nettverkskonfigurasjon

Skritt 1: CCW-ordre

Virtual Connect er et tillegg for Dedicated Instance i CCW.

1

Naviger til CCWs bestillingsnettsted og klikk deretter på Logg inn for å logge på nettstedet:

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

Opprett estimat.

3

Legg til «A-FLEX-3»-varenummer.

4

Velg Rediger alternativer.

5

I abonnementsfanen som vises, velg Alternativer og Tillegg.

6

Under Ekstra tillegg merker du av i boksen ved siden av «Virtuell tilkobling for dedikert instans». SKU-navnet er «A-FLEX-DI-VC».

7

Angi antall og antall regioner der Virtual Connect er nødvendig.

Antallet virtuelle tilkoblinger skal ikke overstige det totale antallet regioner som er kjøpt for dedikert instans. I tillegg er bare én Virtual Connect-bestilling tillatt per region.
8

Når du er fornøyd med valgene dine, klikker du på Bekreft og lagre øverst til høyre på siden.

9

Klikk på Lagre og fortsett for å fullføre bestillingen. Din endelige bestilling vises nå i bestillingsskjemaet.

Skritt 2: Aktivering av Virtual Connect i Control Hub

1

Logg på Kontrollhub https://admin.webex.com/login.

2

I delen [ Tjenester navigerer du til Anrop > Dedikert instans > Skytilkobling.

3

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

Aktiveringsprosessen kan bare utløses av administratorer med rollen «Kunde full administrator». Mens en administrator med rollen «Kunde med skrivebeskyttet administrator» bare kan se statusen.
4

Når du klikker på knappen Aktiver vises skjemaet Aktiver virtuell tilkobling der administratoren kan oppgi de tekniske detaljene for virtuell tilkobling som kreves for peering-konfigurasjonene på Cisco-siden.

Skjemaet gir også statisk informasjon om Ciscos side, basert på den valgte regionen. Denne informasjonen vil være nyttig for kundeadministratorer for å konfigurere CPE-en på sin side for å etablere tilkoblingen.

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

    IP-adressen som kunden oppgir kan være privat eller offentlig.

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

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

    All annen statisk informasjon som oppgis på aktiveringsskjermen er Ciscos sikkerhets- og krypteringsstandarder som følges. Denne statiske konfigurasjonen kan ikke tilpasses eller modifiseres. For ytterligere hjelp angående de statiske konfigurasjonene fra Ciscos side, må kunden kontakte TAC.
5

Klikk på Aktiver -knappen når alle obligatoriske felt er fylt ut.

6

Etter at aktiveringsskjemaet for virtuell tilkobling er fullført for et bestemt område, kan kunden eksportere aktiveringsskjemaet fra Control Hub, Ringe > Dedikert instans > fanen Skytilkobling og klikk på Eksporter innstillinger.

Av sikkerhetsmessige årsaker vil ikke autentisering og BGP-passord være tilgjengelig i det eksporterte dokumentet, men administratoren kan se det samme i Control Hub ved å klikke på Vis innstillinger under Control Hub, Ringe. > Dedikert instans > Skytilkobling-fanen.

Skritt 3: Cisco utfører nettverkskonfigurasjon

1

Når aktiveringsskjemaet for virtuell forbindelse er fullført, oppdateres statusen til Aktivering pågår i Anrop > Dedikert instans > Virtuelt tilkoblingskort for skytilkobling.

2

Cisco vil fullføre de nødvendige konfigurasjonene på Ciscos sideutstyr innen 5 virkedager. Når dette er fullført, oppdateres statusen til «Aktivert» for den aktuelle regionen i Control Hub.

Skritt 4: Kunden utfører nettverkskonfigurasjon

Statusen endres til «Aktivert» for å varsle kundeadministratoren om at Ciscos konfigurasjonsside for IP VPN-tilkoblingen er fullført basert på inndataene som kunden har gitt. Men kundeadministratoren forventes å fullføre sin del av konfigurasjonene på CPE-ene og teste tilkoblingsrutene for at Virtual Connect-tunnelen skal være online. Hvis kunden oppstår problemer under konfigurasjon eller tilkobling, kan de kontakte Cisco TAC for å få hjelp.

Feilsøking

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

IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingene ikke fullføres, starter ingen andre IPsec-fase. Først utfør kommandoen «show crypto ikev2 sa» (på Cisco-utstyr) eller en lignende kommando på tredjepartsutstyret for å bekrefte om IKEv2-økten er aktiv. Hvis IKEv2-økten ikke er aktiv, kan de mulige årsakene være:

  • Interessant trafikk utløser ikke IPsec-tunnelen.

  • IPsec-tunneltilgangslisten er feilkonfigurert.

  • Det er ingen tilkobling mellom kunden og endepunktet for IPsec-tunnelen for den dedikerte instansen.

  • IKEv2-øktparameterne samsvarer ikke mellom den dedikerte instanssiden og kundesiden.

  • En brannmur blokkerer IKEv2 UDP-pakkene.

Først må du sjekke IPsec-loggene for eventuelle meldinger som viser fremdriften til IKEv2-tunnelforhandlingen. Loggene kan indikere hvor det er et problem med IKEv2-forhandlingen. Mangel på loggmeldinger kan også indikere at IKEv2-økten ikke aktiveres.

Noen vanlige feil med IKEv2-forhandlingen er:

  • Innstillingene for IKEv2 på CPE-siden samsvarer ikke med Cisco-siden. Sjekk innstillingene som er nevnt på nytt:

    • Sjekk at IKE-versjonen er versjon 2.

    • Kontroller at parameterne for kryptering og autentisering samsvarer med forventet kryptering på siden med dedikert instans.

      Når «GCM»-krypteringen er i bruk, håndterer GCM-protokollen autentiseringen og setter autentiseringsparameteren til NULL.

    • Bekreft levetidsinnstillingen.

    • Bekreft Diffie Hellman-modulgruppen.

    • Bekreft innstillingene for pseudotilfeldig funksjon.

  • Tilgangslisten for kryptokartet er ikke satt til:

    • Tillat GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (eller tilsvarende kommando)

      Tilgangslisten må være spesifikt for «GRE»-protokollen, ellers vil ikke «IP»-protokollen fungere.

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

Den dedikerte instanssiden starter ikke alltid IKEv2-utvekslingen, og kan noen ganger forvente at kundens CPE-side er initiativtaker.

Sjekk CPE-sidekonfigurasjonen for følgende forutsetninger for IKEv2-øktstart:

  • Se etter en IPsec-kryptotilgangsliste for GRE-trafikk (protokoll 50) fra CPE-tunneltransport-IP-adressen til den dedikerte instansens tunneltransport-IP-adresse.

  • Sørg for at GRE-tunnelgrensesnittet er aktivert for GRE keepalives. Hvis utstyret ikke støtter GRE keepalives, varsles Cisco fordi GRE keepalives vil bli aktivert på den dedikerte instanssiden som standard.

  • Sørg for at BGP er aktivert og konfigurert med naboadressen til den dedikerte instansens tunnel-IP.

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

  • GRE-keepalives fra CPE-sidens GRE-tunnelgrensesnitt til den dedikerte instanssidens GRE-tunnelgrensesnitt.

  • BGP-nabo TCP-økt fra CPE-sidens BGP-nabo til dedikert instans-sidens BGP-nabo.

  • Ping fra CPE-sidetunnelens IP-adresse til sidetunnelens IP-adresse for den dedikerte instansen.

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

Hvis det er behov for en pakkesporing for IKEv2-trafikken, angi filteret for UDP og enten port 500 (når ingen NAT-enhet er midt mellom IPsec-endepunktene) eller port 4500 (når en NAT-enhet er satt inn midt mellom IPsec-endepunktene).

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

Det er ikke alltid datasenteret for dedikerte instanser starter den første IKEv2-pakken. Kravet er at CPE-enheten er i stand til å starte den første IKEv2-pakken mot den dedikerte instanssiden.

Hvis den lokale brannmuren tillater det, kan du også prøve å pinge til den eksterne IPsec-adressen. Hvis pingen ikke lykkes fra lokal til ekstern IPsec-adresse, utfør en sporingsrute for å finne ut hvor pakken slippes.

Enkelte brannmurer og internettutstyr tillater kanskje ikke sporingsruter.

Feilsøking og validering av IPsec andre fase (IPsec-forhandling)

Kontroller at den første fasen av IPsec (det vil si IKEv2-sikkerhetstilknytningen) er aktiv før du feilsøker den andre fasen av IPsec. Utfør en «show crypto ikev2 sa»- eller tilsvarende kommando for å bekrefte IKEv2-økten. I utdataene må du bekrefte at IKEv2-økten har vært oppe i mer enn noen få sekunder, og at den ikke hopper. Oppetiden for økten vises som øktens «Aktiv tid» eller tilsvarende i utdataene.

Når IKEv2-økten er bekreftet som oppe og aktiv, undersøk IPsec-økten. Som med IKEv2-økten, utfør en «show crypto ipsec sa» eller tilsvarende kommando for å bekrefte IPsec-økten. Både IKEv2-økten og IPsec-økten må være aktive før GRE-tunnelen opprettes. Hvis IPsec-økten ikke vises som aktiv, sjekk IPsec-loggene for feilmeldinger eller forhandlingsfeil.

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

Innstillingene på CPE-siden samsvarer ikke med siden for dedikert instans. Kontroller innstillingene på nytt:

  • Kontroller at parameterne for kryptering og autentisering samsvarer med innstillingene på siden Dedikert instans.

  • Bekreft innstillingene for perfekt forward-hemmelighet og at de samsvarer med innstillingene på siden for dedikert instans.

  • Bekreft levetidsinnstillingene.

  • Kontroller at IPsec er konfigurert i tunnelmodus.

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

Feilsøking og validering av tunnelgrensesnitt

Når IPsec- og IKEv2-øktene er bekreftet som oppe og aktive, kan GRE-tunnelens keepalive-pakker flyte mellom den dedikerte instansen og CPE-tunnelens endepunkter. Hvis tunnelgrensesnittet ikke viser status, er noen vanlige problemer:

  • Tunnelgrensesnittets transport-VRF samsvarer ikke med VRF-en til loopback-grensesnittet (hvis VRF-konfigurasjon brukes på tunnelgrensesnittet).

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

  • Keepalives er ikke aktivert på CPE-sidetunnelgrensesnittet

    Hvis keepalives ikke støttes på CPE-utstyret, må Cisco varsles slik at standard keepalives på den dedikerte instanssiden også deaktiveres.

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

  • Masken eller IP-adressen til tunnelgrensesnittet er ikke riktig og samsvarer ikke med de forventede verdiene for den dedikerte instansen.

  • Kilde- eller måltunnelens transportadresse er ikke riktig og samsvarer ikke med de forventede verdiene for den dedikerte instansen.

  • En brannmur blokkerer GRE-pakker fra å sendes inn i IPsec-tunnelen eller mottas fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En pingtest bør bekrefte at det lokale tunnelgrensesnittet er oppe og at tilkoblingen til det eksterne tunnelgrensesnittet er god. Utfør ping-sjekken fra tunnel-IP-adressen (ikke transport-IP-adressen) til den eksterne tunnel-IP-adressen.

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

Ping-sjekken resulterer i en GRE-pakke som genereres fra kilde-tunnelens transport-IP til destinasjons-tunnelens transport-IP, mens nyttelasten til GRE-pakken (den indre IP-adressen) vil være kilde- og destinasjons-tunnelens IP.

Hvis ping-testen ikke er vellykket og de foregående elementene er bekreftet, kan det være nødvendig med en pakkeregistrering for å sikre at icmp-pingen resulterer i en GRE-pakke som deretter innkapsles i en IPsec-pakke og deretter sendes fra kilde-IPsec-adressen til destinasjons-IPsec-adressen. Tellere på GRE-tunnelgrensesnittet og IPsec-økttellerne kan også bidra til å vise om sende- og mottakspakkene øker.

I tillegg til ping-trafikken, bør opptaksprogrammet også vise keepalive GRE-pakker selv under inaktiv trafikk. Til slutt, hvis BGP er konfigurert, bør BGP keepalive-pakker også sendes som GRE-pakker innkapslet i IPSEC-pakker over VPN-et.

BGP-feilsøking og validering

BGP-økter

BGP er nødvendig som rutingsprotokoll over VPN IPsec-tunnelen. Den lokale BGP-naboen bør opprette en eBGP-økt med den dedikerte instansens BGP-nabo. eBGP-nabo-IP-adressene er de samme som de lokale og eksterne tunnel-IP-adressene. Først må du sørge for at BGP-økten er oppe, og deretter må du bekrefte at de riktige rutene mottas fra den dedikerte instansen, og at riktig standardrute sendes til den dedikerte instansen.

Hvis GRE-tunnelen er oppe, må du bekrefte at en ping er vellykket mellom den lokale og den eksterne GRE-tunnelens IP-adresse. Hvis pingen er vellykket, men BGP-økten ikke starter, undersøk BGP-loggen for BGP-etableringsfeil.

Noen av de vanligste BGP-forhandlingsproblemene er:

  • Nummeret på det eksterne AS-et samsvarer ikke med AS-nummeret som er konfigurert på siden av den dedikerte instansen. Kontroller konfigurasjonen av det nærliggende AS-et på nytt.

  • Det lokale AS-nummeret samsvarer ikke med det den dedikerte instanssiden forventer. Kontroller at det lokale AS-nummeret samsvarer med de forventede parameterne for den dedikerte instansen.

  • En brannmur blokkerer BGP TCP-pakker innkapslet i GRE-pakker fra å bli sendt inn i IPsec-tunnelen eller mottatt fra IPSEC-tunnelen.

  • Den eksterne BGP-nabo-IP-adressen samsvarer ikke med den eksterne GRE-tunnelens IP-adresse.

BGP-ruteutveksling

Når BGP-økten er bekreftet for begge tunnelene, må du sørge for at de riktige rutene sendes og mottas fra den dedikerte instanssiden.

VPN-løsningen for dedikerte instanser forventer at to tunneler etableres fra customer/partner side. Den første tunnelen peker til datasenteret for den dedikerte instansen A, og den andre tunnelen peker til datasenteret for den dedikerte instansen B. Begge tunnelene må være i aktiv tilstand, og løsningen krever en active/active utplassering. Hvert dedikerte instansdatasenter vil annonsere sin lokale /25 rute så vel som en /24 sikkerhetskopieringsrute. Når du sjekker innkommende BGP-ruter fra Dedikert Instans, må du sørge for at BGP-sesjonen som er tilknyttet tunnelen som peker til Dedikert Instans-datasenter A, mottar Dedikert Instans-datasenter A. /25 lokalrute så vel som /24 sikkerhetskopieringsrute. I tillegg må du sørge for at tunnelen som peker til dedikert instansdatasenter B mottar dedikert instansdatasenter B /25 lokalrute så vel som /24 sikkerhetskopieringsrute. Merk at /24 Sikkerhetskopieruten vil være den samme ruten som annonseres fra dedikert instansdatasenter A og dedikert instansdatasenter B.

Redundans gis til et dedikert instansdatasenter hvis tunnelgrensesnittet til det datasenteret går ned. Hvis tilkoblingen til dedikert instans-datasenter A går tapt, vil trafikken bli videresendt fra dedikert instans-datasenter B til datasenter A. I dette scenariet vil tunnelen til datasenter B bruke datasenter B. /25 ruten for å sende trafikk til datasenter B, og tunnelen til datasenter B vil bruke sikkerhetskopien /24 rute for å sende trafikk til datasenter A via datasenter B.

Det er viktig at når begge tunnelene er aktive, brukes ikke datasenter A-tunnel til å sende trafikk til datasenter B og omvendt. I dette scenariet, hvis trafikk sendes til datasenter A med destinasjon datasenter B, vil datasenter A videresende trafikken til datasenter B, og deretter vil datasenter B forsøke å sende trafikk tilbake til kilden via datasenter B-tunnelen. Dette vil resultere i suboptimal ruting og kan også bryte trafikk som krysser brannmurer. Derfor er det viktig at begge tunnelene er i en active/active konfigurasjon under normal drift.

De 0.0.0.0/0 Ruten må annonseres fra kundesiden til datasentersiden for den dedikerte instansen. Mer spesifikke ruter vil ikke bli akseptert av den dedikerte instanssiden. Sørg for at 0.0.0.0/0 Ruten annonseres fra både den dedikerte instansens datasenter A-tunnel og den dedikerte instansens datasenter B-tunnel.

MTU-konfigurasjon

På siden Dedikert instans er to funksjoner aktivert for dynamisk å justere MTU for store pakkestørrelser. GRE-tunnelen legger til flere overskrifter til IP-pakkene som flyter gjennom VPN-økten. IPsec-tunnelen legger til de ekstra overskriftene oppå GRE-overskriftene, noe som ytterligere reduserer den største MTU-en som er tillatt over tunnelen.

GRE-tunnelen justerer MSS-funksjonen, og GRE-tunnelbanen i MTU-oppdagelsesfunksjonen er aktivert på den dedikerte instanssiden. Konfigurer "ip tcp adjust-mss 1350" eller tilsvarende kommando samt "tunnel path\u0002mtu-discovery" eller tilsvarende kommando på kundesiden for å hjelpe med dynamisk justering av MTU for trafikk gjennom VPN-tunnelen.