Dedikert instans-Virtual Connect

Introduksjon

Virtual Connect er et ekstra tilleggsalternativ for Cloud Connectivity to Dedicated Instance for Webex Calling (Dedikert forekomst). Virtual Connect gjør det mulig for kunder å utvide sitt private nettverk på en sikker måte over internett ved hjelp av punkt-til-punkt IP VPN-tunneler. Dette tilkoblingsalternativet gir en rask etablering av privat nettverkstilkobling ved å bruke eksisterende CPE (Customer Premise Equipment) og Internett-tilkobling.

Cisco er vert for, administrerer og sikrer redundante IP-VPN-tunneler og nødvendig Internett-tilgang i Ciscos Dedicated Instance-datasenterregion (er) der tjenesten kreves. Tilsvarende er administrator ansvarlig for deres tilsvarende CPE- og Internett-tjenester som kreves for Virtual Connect-etablering.

Hver Virtual Connect-ordre i en bestemt dedikert instansregion vil omfatte to generiske rutinginnkapslingstunneler (GRE) beskyttet av IPsec-kryptering (GRE over IPsec), en til hvert Ciscos datasenter i den valgte regionen.

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

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

Forutsetninger

Forutsetningene for å etablere Virtual Connect inkluderer:

Kunden gir
- Internett-tilkobling med nok tilgjengelig båndbredde til å støtte distribusjonen
- Offentlige IP-adresser for to IPsec-tunneler
- Kundesiden GRE transport IP-adresser for de to GRE-tunnelene
Partner og kunde
- Arbeid sammen for å evaluere båndbreddekrav
- Sørg for at nettverksenheter støtter BGP-ruting (Border Gateway Protocol) og en GRE over IPsec-tunneldesign
Partner eller kunde leverer
- Nettverksteam med kunnskap om VPN-tunnelteknologier fra sted til sted
- Nettverksteam med kunnskap om BGP, eBGP og generelle rutingprinsipper
Cisco
- Cisco tildelte private autonome systemnumre (ASN) og forbigående IP-adressering for GRE-tunnelgrensesnitt
- Cisco tilordnet offentlig, men ikke Internett-rutbart klasse C (/24) nettverk for dedikerte instanser Cloud-adressering

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å et alternativ for 2 CPE-enheter, da skal hver CPE-enhet bare koble til 1 tunnel mot Ciscos datasentre (DC1 og DC2) i hver region. Ytterligere redundans kan oppnås ved å avslutte hver tunnel på et separat fysisk sted/sted innenfor kundens infrastruktur.

Tekniske detaljer

Distribusjonsmodell

Virtual Connect bruker en hodeendarkitektur med to nivåer, der ruting- og GRE- kontrollplanene leveres av en enhet og IPsec-kontrollplanet leveres av en annen.

Når Virtual Connec t-tilkoblingen er fullført, opprettes to GRE over IPsec-tunneler mellom kundens bedriftsnettverk og Ciscos datasentre for dedikert fore komst. Ett til hvert redundant datasenter i den respektive regionen. Ytterligere nettverkselementer som kreves for peering, byttes av partneren eller kunden til Cisco via Control Hub Virtual Connect-aktiveringsskjemaet.

Figuren nedenfor viser eksemplet på distribusjonsmodellen for virtuell tilkobling for 2-konsentratoralternativet på kundesiden.

Virtual Connect - VPN er en hub-design, der kundens hub-nettsteder er koblet til DC1 og DC2 i datasentre for dedikert forekomst innenfor en bestemt region.

To hub-områder anbefales for bedre redundans, men One Hub-område 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 over begge tunnelene ikke overstige 250 Mbps, da all trafikk vil bli dirigert gjennom en tunnel i tilfelle feil.

Kundens eksterne nettsteder i samme region må koble seg tilbake til Hub-området (e) over kundens WAN, og det er ikke Ciscos ansvar for denne tilkoblingen.

Det forventes at partnere samarbeider tett med kundene for å sikre at den mest optimale banen velges for Virtual Connect-tjen esteområdet.

Figuren nedenfor viser peeringsområdene for skytilkobling for dedikert forekomst.

ruting

Routing for Virtual Connect-tillegg implementeres ved hjelp av ekstern BGP (eBGP) mellom Dedicated Instance og Customer Premise Equipment (CPE). Cisco vil annonsere sitt respektive nettverk for hver redundant DC i en region til kundens CPE, og CPE er pålagt å annonsere en standardrute til Cisco.

Cisco vedlikeholder og tildeler
- Tunnelgrensesnitt IP-adressering (forbigående kobling for ruting) Cisco tilordner fra et angitt delt adresseområde (ikke offentlig rutbart)
- Adresse for tunneltransport (Ciscos side)
- Private autonome systemnumre (ASN) for kundens BGP-rutekonfigurasjon
  - Cisco tildeler fra det angitte området for privat bruk: 64512 til 65534

EBGP brukes til å utveksle ruter mellom dedikert forekomst og CPE
- Cisco vil dele det tildelte /24-nettverket i 2/25 en for hver DC i den respektive regionen
- I Virtual Connect annonseres hvert /25-nettverk tilbake til CPE av Cisco over de respektive punkt-til-punkt-VPN-tunnelene (transientkobling)
- CPE må konfigureres med de aktuelle EBgP-naboene. Hvis du bruker en CPE, vil to eBgP-naboer bli brukt, en peker på hver fjerntliggende tunnel. Hvis du bruker to CPE, vil hver CPE ha en EBgP-nabo som peker på den eneste eksterne tunnelen for CPE.
- Cisco-siden av hver GRE-tunnel (tunnelgrensesnitt IP) er konfigurert som BGP-nabo på CPE
- CPE er påkrevd for å annonsere en standardrute over hver av tunnelene
- CPE er ansvarlig for å omfordele, etter behov, de lærte rutene i kundens bedriftsnettverk.
Under ikke-sviktende koblingsfeil vil en enkelt CPE ha to aktive/aktive tunneler. For to CPE-noder vil hver CPE ha én aktiv tunnel, og begge CPE-nodene skal være aktive og passere trafikk. Under ikke-sviktsscenario må trafikken deles i to tunneler som går til riktige /25 destinasjoner, hvis en av tunnelene går ned, kan den gjenværende tunnelen bære trafikken for begge. Under et slikt feilscenario, når /25-nettverket er nede, blir /24-nettverket brukt som en backup-rute. Cisco vil sende kundetrafikk via sitt interne WAN mot DC som mistet tilkoblingen.

Virtuell tilkobling trafikkflyt

Trafikken flyter når begge tunnelene er oppe

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

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

Definisjoner:

Kundeforutsetning:
- Dette representerer kundens nettverk på stedet, der brukere og deres enheter (f.eks. IP-telefoner, datamaskiner som kjører UC-klienter) befinner seg.
- Trafikk som kommer herfra må nå UC-applikasjonene som er vert i Ciscos datasentre.
Cisco Webex CallingDatas@@ entre for dedikert forekomst (dedikert forekomst) (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, og gir redundans.
- Hvert datasenter har sitt eget delnett for UC-applikasjoner:
  - DC-A-delnett: X.X.X.0/25
  - DC-B-delnett: X.X.X.128/25
GRE/IPsec-tunneler (Tunnel 1 og Tunnel 2):
- Dette er de sikre, krypterte forbindelsene mellom kundens lokaler og Ciscos datasenter over det offentlige internett.
- GRE (Generic Routing Encapsulation): Denne protokollen brukes til å innkapsle forskjellige nettverkslagsprotokoller inne i virtuelle punkt-til-punkt-koblinger. Det gjør at rut eprotokoller som BGP kan operere over tunnelen.
- IPsec (Internet Protocol Security): Denne pakken med protokoller gir kryptografiske sikkerhetstjenester (autentisering, integritet, konfidensialitet) for IP- kommunikasjon. Den krypterer den GRE-innkapslede trafikken, og sikrer sikker data overføring over Internett.
Grensegateway-protokoll (BGP):
- BGP er rutingsprotokollen som brukes til å utveksle ruteinformasjon mellom kundepremissene og Cisco-datasentrene.

Som vist i diagrammet ovenfor, må enheter som er distribuert i kundens lokaler etablere to GRE/IPSEC-tunneler.

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

På Cisco-siden vil IPsec- og GRE-tunnelene bli avsluttet på forskjellige enheter. Så kunden må sørge for å konfigurere IPsec-destinasjon og GRE-destinasjons-IP-er på enhetene tilsvarende. Kunder kan bruke samme IP for GRE og IPSEC hvis den støttes på enhetene deres. Se diagrammet ovenfor. De IP-relaterte verdiene blir gitt under aktivering av den virtuelle tilkoblingen på portalen.

Tunnel 1: Kobler kundepremisset til «Dedikert forekomst DC-A» (datasenter A) via Internett. Denne tunnelen bruker BGP AS: 64XX1 på kundesiden og BGP AS: 64XX2 på DC-A-siden for dedikert forekomst. IPSEC- og GRE-tunnelkildekonfigurasjoner er delt mellom kundeleverte og Cisco-leverte detaljer.
Tunnel 2: Kobler kundepremisset til «Dedicated Instance DC-B» (datasenter B) via Internett. Denne tunnelen bruker BGP AS: 64YY1 på kundesiden og BGP AS: 64YY2 på DC-B-siden for dedikert forekomst. I likhet med Tunnel 1 deles IPSEC- og GRE-tunnelkilde konfigurasjoner mellom kunden og Cisco.

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

Når GRE/IPSEC-tunnelene er etablert til datasentre for Webex Calling dedikert forekomst (A og B), bør 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.0/25 og X.X.0/24. Eventuelt hvis IaaS blir bedt om og konfigurert for kunderutene vil YY.Y.0/25 og Y.Y.0/24 bli annonsert fra Cisco.
For DC-B: Ruter annonsert fra Cisco vil være X.X.128/25 og X.X.X.0/24. Eventuelt hvis IaaS blir bedt om og konfigurert for kunderutene, vil YY.Y.128/25 og Y.Y.0/24 bli annonsert fra Cisco.
Kunden må annonsere ruten 0.0.0./0 til Cisco gjennom begge tilkoblingene (tunnelene)
Kunden må følge de lengste prefiksrutene (/25) for å sende trafikk til Cisco gjennom de respektive tunnelene når begge tunnelene er oppe.
Cisco vil returnere trafikken gjennom de samme tunnelene for å holde trafikken symmetrisk.

Trafikkflyt:

Trafikk bestemt for «DC-A UC Apps» (X.X.X.0/25) fra kundens lokaler strømmer gjennom Tunnel 1.
Trafikk bestemt til «DC-B UC Apps» (X.X.128/25) fra kundens lokaler strømmer gjennom Tunnel 2.

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

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

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

Siden Tunnel 1 er nede, vil kunderuteren på kundens premisse automatisk fjerne rutene som er lært via tunnel 1 fra rutetabellen eller markere dem som utilgjengelige.

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

Tilkoblingsprosess

Følgende trinn på høyt nivå beskriver hvordan du oppretter tilkobling med virtuell tilkobling for dedikert forekomst.

1	Legg inn en bestilling i Cisco CCW
2	Aktiver Virtual Connect fra Control Hub
3	Cisco utfører nettverkskonfigurasjon
4	Kunden utfører nettverkskonfigurasjon

Trinn 1: CCW-bestilling

Virtual Connect er et tillegg for dedikert forekomst i CCW.

1	Naviger til CCW-bestillingssiden, og klikk deretter Logg inn for å logge på nettstedet: https://apps.cisco.com/Commerce/guest.
2	Opprett estimat.
3	Legg til «A-FLEX-3" SKU.
4	Velg Rediger alternativer.
5	I abonnementsfanen som vises, Velg Alternativer og tillegg.
6	Under Tilleggstillegg merker du av i boksen ved siden av «Virtuell tilkobling for dedikert forekomst». SKU-navnet er «A-FLEX-DI-VC».
7	Angi antall og antall regioner der Virtual Connect er påkrevd. Antall Virtual Connect bør ikke overstige det totale antallet regioner som er kjøpt for dedikert forekomst. Også, bare en Virtual Connect-ordre er 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. Den ferdige bestillingen din vises nå i ordrerutenettet.

Trinn 2: Aktivering av Virtual Connect i Control Hub

1	Logg på Control Hub https://admin.webex.com/login.
2	I Tjen ester-delen navigerer du til An rop > Dedikert instacnce > Skytilkobling.
3	På Virtual Connect-kortet vises det kjøpte Virtual Connect-antallet. Administratoren kan nå klikke på Aktiver for å starte Virtual Connect-aktiveringen. Aktiveringsprosessen kan bare utløses av administratorer med rollen «Kunden full administrator». Mens en administrator med rollen «Kundeadministrator skrivebeskyttet» bare kan se statusen.
4	Når du klikker på Akti ver-knappen, vises Aktiver virtuell tilkoblingsskjema for administratoren for å gi de tekniske detaljene for Virtual Connect som kreves for peering-konfigurasjonene på Ciscos side. Skjemaet gir også statisk informasjon på Ciscos side, basert på den valgte regionen. Denne informasjonen vil være nyttig for kundeadministratorer til å konfigurere CPE på sin side for å etablere tilkoblingen. GRE Tunnel Transport IP-adresse: Kunden er pålagt å oppgi kundens side Tunnel Transport IP-adresser, og Cisco vil dynamisk tildele IP-adressene når aktiveringen er fullført. IPsec ACL for Interesting Traffic bør tillate lokal tunneltransport IP/32 til ekstern tunneltransport IP/32. ACL bør også spesifisere bare GRE IP-protokollen. IP-adressen oppgitt av kunden kan være privat eller offentlig. IPsec-jevnaldrende: Kunden må oppgi IPsec-tunnelens kilde-IP-adresser, og Cisco tildeler IPsec-destinasjons-IP-adressen. Utførelse av NAT-oversettelse av en intern IPSEC-tunneladresse til en offentlig adresse støttes også om nødvendig. IP-adressen oppgitt av kunden skal være offentlig. All annen statisk informasjon som er gitt i aktiveringsskjermen, er Ciscos sidesikkerhets- og krypteringsstandarder som følges. Denne statiske konfigurasjonen kan ikke tilpasses eller modifiseres. For ytterligere hjelp angående de statiske konfigurasjonene på Ciscos side, må kunden kontakte TAC.
5	Klikk på Aktiver -knappen når alle obligatoriske felt er fylt ut.
6	Etter at Virtual Connect-aktiveringsskjemaet er fylt ut for en bestemt region, kan kunden eksportere aktiveringsskjemaet fra Control Hub, Calling > Dedicated Instance > Cloud Connectivity fanen og klikke på Eksporter innstillinger. Av sikkerhetsmessige årsaker vil autentisering og BGP-passord ikke være tilgjengelig i det eksporterte dokumentet, men administratoren kan se det samme i Control Hub ved å klikke på Vis innstillinger under Control Hub, Anrop > Dedikert forekomst > Cloud Connection-fanen.

Trinn 3: Cisco utfører nettverkskonfigurasjon

1	Når skjemaet Aktivering av virtuell tilkobling er fullført, oppdateres statusen til Aktivering pågår i Anrop > Dedikert forekomst > Cloud Connectivity Virtual Connect-kort.
2	Cisco vil fullføre de nødvendige konfigurasjonene på Ciscos sideutstyr innen 5 virkedager. Etter vellykket gjennomføring oppdateres statusen til «Aktivert» for den aktuelle regionen i Control Hub.

Trinn 4: Kunden utfører nettverkskonfigurasjon

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

Feilsøking

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

IPsec-tunnelforhandlingene omfatter to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fullføres, er det ingen igangsetting av en annen IPsec-fase. Først utsteder du kommandoen «show crypto ikev2 sa» (på Cisco-utstyr) eller lignende kommando på tredjepartsutstyret for å bekrefte om IKEv2-økten er aktiv. Hvis IKEv2-økten ikke er aktiv, kan de potensielle årsakene være:

Interessant trafikk utløser ikke IPsec-tunnelen.
IPsec-tunneltilgangslisten er feilkonfigurert.
Det er ingen tilkobling mellom kunden og den dedikerte instansens IPsec-tunnelendepunkt IP.
IKEv2-øktparametrene samsvarer ikke mellom den dedikerte instanssiden og kundesiden.
En brannmur blokkerer IKEv2 UDP-pakkene.

Kontroller først IPsec-loggene for meldinger som viser fremdriften for IKEv2-tunnelforhandlingene. Loggene kan indikere hvor det er et problem med IKEv2-forhandlingen. Mangel på loggingsmeldinger kan også indikere at IKEv2-økten ikke blir aktivert.

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 krypterings- og godkjenningsparametrene samsvarer med forventet kryptering på siden Dedikert forekomst.
  
  Når «GCM» -krypteringen er i bruk, håndterer GCM-protokollen autentiseringen og setter autentiseringsparameteren til NULL.
- Kontroller levetidsinnstillingen.
- Bekreft Diffie Hellman-modulusgruppen.
- Bekreft innstillingene for Pseudo Random Function.
Tilgangslisten for kryptokartet er ikke satt til:
- Tillatelse GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (eller tilsvarende kommando)
  
  Tilgangslisten må være spesielt for «GRE» -protokollen, og «IP» -protokollen vil ikke fungere.

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

Dedikert instansside starter kanskje ikke alltid IKEv2-utvekslingen, og kan noen ganger forvente at kundens CPE-side er initiativtakeren.

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

Se etter en IPsec-kryptotilgangsliste for GRE-trafikk (protokoll 50) fra CPE-tunneltransport-IP-en til den dedikerte instanstunneltransport-IP-en.
Forsikre deg om at GRE-tunnelgrensesnittet er aktivert for GRE keepalives, hvis utstyret ikke støtter GRE keepalives, blir Cisco varslet fordi GRE keepalives vil være aktivert på Dedicated Instance-siden som standard.
Kontroller at BGP er aktivert og konfigurert med nabo-adressen til den dedikerte instanstunnel-IP-en.

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

GRE holder fra GRE-tunnelgrensesnittet på CPE-siden til GRE-tunnelgrensesnittet på dedikerte instanser.
BGP-nabo TCP-økt fra CPE-siden BGP-nabo til BGP-naboen på dedikert forekomst.
Ping fra CPE-sidetunnelens IP-adresse til IP-adressen for den dedikerte instanssidetunnelen.

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

Hvis en pakkesporing er nødvendig for IKEv2-trafikken, angir du filteret for UDP og enten port 500 (når ingen NAT-enhet er midt i IPsec-endepunktene) eller port 4500 (når en NAT-enhet settes inn midt i IPsec-endepunktene).

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

Datasenteret for dedikert forekomst starter kanskje ikke alltid den første IKEv2-pakken. Kravet er at CPE-anordningen er i stand til å initiere den første IKEv2-pakken mot den dedikerte instanssiden.

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

Noen brannmurer og internettutstyr tillater kanskje ikke sporingsrute.

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

Kontroller at IPsecs første fase (det vil si IKEv2-sikkerhetstilknytningen) er aktiv før du feilsøker IPsecs andre fase. Utfør en «show crypto ikev2 sa» eller tilsvarende kommando for å bekrefte IKEv2-økten. I utgangen må du kontrollere at IKEv2-økten har vært oppe i mer enn noen få sekunder, og at den ikke spretter. Sesjonens oppetid vises som økten «Aktiv tid» eller tilsvarende i utdata.

Når IKEv2-økten er bekreftet som oppe og aktiv, undersøker du 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 etableres. Hvis IPsec-økten ikke vises som aktiv, kontrollerer du 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 Dedikert forekomst, sjekk innstillingene på nytt:

Kontroller at krypterings- og godkjenningsparametrene samsvarer med innstillingene på siden Dedikert forekomst.
Bekreft innstillingene for Perfect Forward Secrecy og at innstillingene samsvarer med innstillingene på siden Dedicated Instance.
Kontroller levetidsinnstillingene.
Kontroller at IPsec er konfigurert i tunnelmodus.
Bekreft kilde- og destinasjons-IPsec-adressene.

Feilsøking og validering av tunnelgrensesnitt

Når IPsec- og IKEv2-øktene er verifisert som oppe og aktive, kan GRE-tunnelens keepalive-pakker flyte mellom Dedicated Instance og CPE-tunnelendepunkter. Hvis tunnelgrensesnittet ikke viser status, er noen vanlige problemer:

Tunnelgrensesnitttransport-VRF samsvarer ikke med VRF for loopback-grensesnittet (hvis VRF-konfigurasjon brukes på tunnelgrensesnittet).

Hvis VRF-konfigurasjonen ikke brukes på tunnelgrensesnittet, kan denne kontrollen 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å er deaktivert.

Hvis keepalives støttes, må du kontrollere at keepalives er aktivert.
Masken eller IP-adressen til tunnelgrensesnittet er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.
Kilde- eller destinasjonstunneltransportadressen er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.
En brannmur blokkerer GRE-pakker fra å sendes inn i IPsec-tunnelen eller mottas fra IPsec-tunnelen (GRE-tunnelen transporteres over IPsec-tunnelen)

En ping-test skal bekrefte at det lokale tunnelgrensesnittet er oppe og tilkoblingen er god til det eksterne tunnelgrensesnittet. Utfør ping-kontrollen fra tunnelens IP (ikke transport-IP) til den eksterne tunnel-IP-en.

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

Ping-sjekken resulterer i en GRE-pakke som genereres fra kildetunneltransport-IP til destinasjonstunneltransport IP mens nyttelasten til GRE-pakken (den indre IP-en) vil være kilde- og destinasjonstunnelens IP.

Hvis ping-testen ikke er vellykket og de foregående elementene blir verifisert, kan det være nødvendig med en pakkeopptak 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-sesjontellerne kan også bidra til å vise. om sende- og mottakspakkene er inkrementerende.

I tillegg til ping-trafikken, bør fangsten 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 også over VPN.

BGP Feilsøking og validering

BGP-økter

BGP kreves som rutingsprotokoll over VPN IPsec-tunnelen. Den lokale BGP-naboen bør etablere en eBGP-økt med BGP-naboen for dedikert forekomst. EBgP-nabo-IP-adressene er de samme som de lokale og eksterne tunnel-IP-adressene. Kontroller først at BGP-økten er oppe, og kontroller deretter at de riktige rutene mottas fra dedikert forekomst og at riktig standardrute sendes til dedikert forekomst.

Hvis GRE-tunnelen er oppe, kontroller at en ping er vellykket mellom den lokale og den eksterne GRE-tunnel-IP-en. Hvis pingen er vellykket, men BGP-økten ikke kommer opp, undersøk deretter BGP-loggen for BGP-etableringsfeil.

Noen av de vanligste BGP-forhandlingsproblemene er:

Det eksterne AS-nummeret samsvarer ikke med AS-nummeret som er konfigurert på den dedikerte instanssiden. Kontroller nabo-AS-konfigurasjonen på nytt.
Det lokale AS-nummeret samsvarer ikke med det Dedikert forekomstsiden forventer. Kontroller at det lokale AS-nummeret samsvarer med de forventede parametrene for dedikert forekomst.
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-en samsvarer ikke med den eksterne GRE-tunnel-IP-en.

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 det skal etableres to tunneler fra kunde/partnersiden. Den første tunnelen peker til datasenteret A for dedikert forekomst og den andre tunnelen peker til datasenteret B for dedikert forekomst. Begge tunnelene må være i aktiv tilstand og løsningen krever en aktiv/aktiv distribusjon. Hvert datasenter for dedikert forekomst vil annonsere sin lokale /25-rute samt en /24-backup-rute. Når du sjekker de innkommende BGP-rutene fra dedikert forekomst, må du sørge for at BGP-økten som er knyttet til tunnelen som peker til datasenter A for dedikert forekomst mottar den lokale ruten for datasenter A /25 samt sikkerhetskopieruten /24. I tillegg må du sørge for at tunnelen som peker til datasenter B for dedikert forekomst mottar den lokale ruten for datasenter B /25 i tillegg til sikkerhetskopieruten /24. Merk at sikkerhetskopieruten /24 vil være den samme ruten som annonseres ut fra datasenter A for dedikert forekomst og datasenter B for dedikert forekomst.

Redundans leveres til et dedikert instansdatasenter hvis tunnelgrensesnittet til datasenteret går ned. Hvis tilkoblingen til datasenter A for dedikert forekomst går tapt, blir trafikken videresendt fra datasenter B for dedikert forekomst til datasenter A. I dette scenariet vil tunnelen til datasenteret B bruke datasenteret B/25-ruten for å sende trafikk til datasenter B og tunnelen til datasenteret B vil bruke backup-ruten /24 for å sende trafikk til datasenter A via datasenter B.

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

Ruten 0.0.0.0/0 må annonseres fra kundesiden til datasentersiden for dedikert forekomst. Mer spesifikke ruter vil ikke bli akseptert av den dedikerte instanssiden. Kontroller at ruten 0.0.0.0/0 annonseres ut av både tunnelen for dedikert forekomst av datasenter A og Dedikert forekomstdatasenter B-tunnel.

MTU-konfigurasjon

På siden Dedicated Instance er to funksjoner aktivert for dynamisk justering av MTU for store pakkestørrelser. GRE-tunnelen legger til flere overskrifter til IP-pakkene som strømmer gjennom VPN-økten. IPsec-tunnelen legger til de ekstra overskriftene på toppen av GRE-overskriftene, vil ytterligere redusere den største MTU som er tillatt over tunnelen.

GRE-tunnelen justerer MSS-funksjonen og GRE-tunnelbanen i MTU-oppdagelsesfunksjonen er aktivert på Dedicated Instance-siden. Konfigurer «ip tcp just-mss 1350" eller tilsvarende kommando samt «tunnel path\ u0002mtu-discovery» eller tilsvarende kommando på kundesiden for å hjelpe med dynamisk justering av MTU av trafikk gjennom VPN-tunnelen.

Cisco AI Assistant

Takk for tilbakemeldingen.