Virtual Connect-alternativet bidrar til å utvide det private nettverket deres over internett på en sikker måte ved hjelp av punkt-til-punkt IP VPN-tunneler.
Introduksjon
Virtual Connect er et ekstra tilleggsalternativ for skytilkobling til dedikert forekomst for Webex Calling (dedikert forekomst). Virtual Connect lar kunder utvide sitt private nettverk over internett på en sikker måte ved hjelp av punkt-til-punkt IP VPN-tunneler. Dette tilkoblingsalternativet gir en rask etablering av privat nettverkstilkobling ved hjelp av 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 dedikerte forekomst-datasenterregion(er) der tjenesten er nødvendig. På samme måte er administrator ansvarlig for sine tilsvarende CPE- og Internett-tjenester som kreves for etablering av Virtual Connect.
Hver Virtual Connect-bestilling i en bestemt dedikert forekomst-region vil omfatte to generiske routing encapsulation (GRE)-tunneler beskyttet av IPSec-kryptering (GRE over IPSec), én 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 det brukes to punkt-til-punkt VPN-tunneler, må all trafikk til skyen gå gjennom kundens headend CPE, og det kan derfor hende at den ikke er egnet der det er mange eksterne nettsteder. For andre alternative peering-alternativer, se Skytilkobling .
 |
Før du sender inn peering-forespørselen for Virtual Connect, må du kontrollere at tjenesten dedikert forekomst er aktivert i det respektive området. |
Forutsetninger
Forutsetningene for å etablere Virtual Connect inkluderer:
Kunden gir
Internett-tilkobling med nok tilgjengelig båndbredde til å støtte distribusjonen
Offentlig(e) IP-adresse(r) for to IPSec-tunneler
GRE-transport-IP-adresser på kundesiden for de to GRE-tunnelene
Partner og kunde
Arbeid sammen for å evaluere båndbreddekrav
Sørg for at nettverksenhet støtter BGP-ruting (Border Gateway Protocol) og en GRE over IPSec-tunneldesign
Partner eller kunde gir
Nettverksteam med kunnskap om sted-til-sted VPN-tunnelteknologier
Nettverksteam med kunnskap om BGP, eBGP og generelle rutingsprinsipper
Cisco
Cisco tildelte private autonoumous systemnumre (ASN) og forbigående IP-adressering for GRE-tunnelgrensesnitt
Cisco tilordnet offentlig, men ikke rutebart Internett-nettverk i klasse C (/24) for dedikert skyadressering for forekomster
|
Hvis en kunde bare har én CPE-enhet, vil de to tunnelene mot Ciscos datasentre (DC1 og DC2) i hver region komme fra den CPE-enheten. Kunden har også mulighet for 2 CPE-enheter, da skal hver CPE-enhet kobles til 1 tunnel kun mot Ciscos datasentre (DC1 og DC2) i hver region. Ytterligere redundans kan oppnås ved å avslutte hver tunnel på et eget fysisk sted/sted innenfor Kundens infrastruktur. |
Tekniske detaljer
Distribusjonsmodell
Virtual Connect bruker en hodeendarkitektur med to lag, der ruting- og GRE-kontrollplanene leveres av én enhet og IPSec-kontrollplanet leveres av en annen.
Etter fullføring av Virtuell tilkobling tilkobling opprettes det to GRE over IPSec-tunneler mellom kundens bedriftsnettverk og Ciscos datasentre for dedikert forekomst. Én til hvert redundant 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.
Figur 1 viser et eksempel på distribusjonsmodell for Virtual Connect for alternativet med to konsentratorer på kundesiden.
Virtuell tilkobling – VPN er en Hub-design der kundens Hub-nettsteder er koblet til DC1 og DC2 i dedikerte forekomsters datasentre i en bestemt region.
To Hub-områder anbefales for bedre redundans, men One Hub-nettsted med to tunneler er også en støttet distribusjonsmodell.
|
Båndbredden per tunnel er begrenset til 250 Mbps. |
 |
Kundens eksterne nettsteder i samme region må koble tilbake til Hub-nettstedet(e) via kundens WAN, og det er ikke Ciscos ansvar for denne tilkoblingen. |
Partnere forventes å samarbeide tett med kundene for å sikre at den mest optimale banen velges for tjenesteregionen Virtuell tilkobling.
Figur 2 viser noderegioner for dedikerte forekomster av skytilkobling.
Ruting
Ruting for Virtual Connect-tillegget implementeres ved hjelp av ekstern BGP (eBGP) mellom dedikert forekomst og Customer Premise Equipment (CPE). Cisco vil annonsere sine respektive nettverk for hver redundante DC i en region til kundens CPE og CPE er påkrevd for å annonsere en standard rute til Cisco.
Cisco vedlikeholder og tilordner
IP-adressering for tunnelgrensesnitt (forbigående kobling for ruting) Cisco tilordner fra et angitt delt adresseområde (ikke offentlig rutingbar)
Destinasjonsadresse for tunneltransport (Ciscos side)
Private autonome systemnumre (ASN) for kundekonfigurasjon for BGP-ruting
Cisco tilordner fra det angitte området for privat bruk: 64512 til og med 65534
eBGP brukes til å utveksle ruter mellom dedikert forekomst og CPE
Cisco vil dele det tilordnede /24-nettverket i 2/25 én for hver DC i den respektive regionen
I Virtual Connect annonseres hvert /25-nettverk tilbake til CPE av Cisco via de respektive punkt-til-punkt VPN-tunnelene (forbigående kobling)
CPE må konfigureres med de riktige eBGP-naboene. Hvis du bruker én CPE, brukes to eBGP-naboer, én som peker til hver ekstern tunnel. Hvis du bruker to CPE, vil hver CPE ha én eBGP-nabo som peker til den enkelt eksterne tunnelen for CPE.
Cisco-siden av hver GRE-tunnel (tunnel interface IP) er konfigurert som BGP-nabo på CPE
CPE er påkrevd for å annonsere en standard rute over hver av tunnelene
CPE er ansvarlig for å omdistribuere, etter behov, de lærte rutene i kundens bedriftsnettverk.
Ved koblingsfeiltilstand 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 scenariet ikke-feil må trafikken dele seg i to tunneler som går til riktige /25-destinasjoner, hvis den ene av tunnelen går ned, kan den gjenværende tunnelen bære trafikken for begge. I et slikt feilscenario, når /25-nettverket er nede, brukes /24-nettverket som en reserverute. Cisco vil sende kundetrafikk via sitt interne WAN mot DC-en som mistet tilkoblingen.
Tilkoblingsprosess
| 1 | |
| 2 | |
| 3 | |
| 4 |
Trinn 1: CCW-rekkefølge
Virtual Connect er et tillegg for dedikert forekomst i CCW.
| 1 | Naviger til CCW-bestillingsnettstedet, og klikk deretter på Logg på for å logge på nettstedet: |
||
| 2 | Opprett overslag. |
||
| 3 | Legg til «A-FLEX-3» SKU. |
||
| 4 | Velg Rediger alternativer. |
||
| 5 | Velg Alternativer og Tillegg i abonnementsfanen som vises. |
||
| 6 | Under Flere tillegg merker du av i avmerkingsboks ved siden av «Virtual Connect for dedikert forekomst». SKU-navnet er «A-FLEX-DI-VC». |
||
| 7 | Angi antall og antall regioner der Virtual Connect er nødvendig.
|
||
| 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 fullførte bestillingen vises nå i bestillingsrutenettet. |
Trinn 2: Aktivering av Virtual Connect i Control Hub
| 1 | Logg på Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | I Tjenester -delen, gå til Anrop > Dedikert Instacnce > Skytilkobling . |
||||||||
| 3 | På Virtual Connect-kortet er det kjøpte antallet Virtual Connect oppført. administrator kan nå klikke på Aktiver for å starte aktiveringen av Virtual Connect. 
|
||||||||
| 4 | Ved å klikke på Aktiver knapp, Aktiver Virtuell tilkobling skjemaet vises for at administrator skal kunne oppgi de tekniske detaljene for Virtual Connect som kreves for peering-konfigurasjonene på Cisco-siden.
|
||||||||
| 5 | Klikk på Aktiver -knappen når alle de obligatoriske feltene er fylt ut. |
||||||||
| 6 | Når aktiveringsskjemaet for virtuell tilkobling er utfylt for et bestemt område, kan kunden eksportere aktiveringsskjemaet fra Control Hub, Calling > Dedikert forekomst > kategorien Skytilkobling og klikke på Eksporter innstillinger. 
|
Trinn 3: Cisco utfører nettverkskonfigurasjon
| 1 | Når aktiveringsskjemaet for virtuell tilkobling er fullført, oppdateres statusen til Aktivering pågår i Calling > Dedikert forekomst > Cloud Connectivity Virtual Connect-kort. |
| 2 | Cisco vil fullføre de nødvendige konfigurasjonene på Cisco-siden utstyret innenfor 5 virkedager . Når fullføringen er fullført, oppdateres statusen til «Aktivert» for den bestemte regionen i Control Hub. |
Trinn 4: Kunden utfører nettverkskonfigurasjon
Statusen endres til «Aktivert» for å varsle kundeadministratoren om at Ciscos side av konfigurasjonene for IP VPN-tilkoblingen er fullført basert på inndataene fra kunden. Det forventes imidlertid at administrator fullfører sin side av konfigurasjonene på CPE-ene og teste tilkoblingsrutene for at Virtual Connect-tunnelen skal være tilkoblet. Hvis det oppstår problemer på tidspunktet for konfigurasjonen eller tilkoblingen, kan kunden ta kontakt med Cisco TAC for å få hjelp. |
Feilsøking
Feilsøking og validering for IPsec First Phase (IKEv2 Negotiation).
IPsec-tunnelforhandlingen involverer to faser, IKEv2-fasen og IPsec-fasen. Hvis IKEv2-faseforhandlingen ikke fullføres, er det ingen initiering av en andre IPsec-fase. Utfør først kommandoen «vis 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.
tilgangsliste for IPsec-tunnelen er feilkonfigurert.
Det er ingen tilkobling mellom kunden og IPsec-tunnelendepunktet for dedikert forekomst.
IKEv2-øktparametrene samsvarer ikke mellom den dedikerte forekomstsiden og kundesiden.
En brannmur blokkerer IKEv2 UDP-pakkene.
Kontroller først at IPsec-loggene ser etter meldinger som viser fremdriften for IKEv2-tunnelforhandlingen. Loggene kan indikere hvor det er et problem med IKEv2-forhandlingen. Mangel på loggmeldinger kan også indikere at IKEv2-økten ikke aktiveres.
Innstillingene for IKEv2 på CPE-siden samsvarer ikke med Cisco-siden. Kontroller innstillingene som er nevnt på nytt:
Kontroller at IKE-versjonen er versjon 2.
Kontroller at parametrene for kryptering og autentisering samsvarer med forventet kryptering på den dedikerte forekomst-siden.
Når «GCM»-chifferen er i bruk, håndterer GCM-protokollen godkjenningen og angir autentiseringsparameteren til NULL.
Kontroller innstillingen for levetid.
Kontroller Diffie Hellman-modulgruppen.
Kontroller innstillingene for Pseudo-tilfeldig funksjon.
tilgangsliste 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)
tilgangsliste må være spesifikt for «GRE»-protokollen, og «IP»-protokollen vil ikke fungere.
Hvis loggmeldingene ikke viser forhandlingsaktivitet for IKEv2-fasen, kan det hende at en pakkelagring er nødvendig.
|
Dedikert forekomstside starter kanskje ikke alltid IKEv2-utvekslingen og kan noen ganger forvente at kundens CPE-side er initiativtaker. Kontroller konfigurasjonen på CPE-siden for følgende forutsetninger for IKEv2-øktstart:
|
Når den er riktig konfigurert, starter følgende IPsec-tunnelen og førstefase IKEv2-forhandlingen:
GRE keepalives fra GRE-tunnelgrensesnittet på CPE-siden til GRE-tunnelgrensesnittet for dedikert forekomst.
TCP-økt for BGP-nabo fra BGP-nabo på CPE-siden til BGP-nabo på dedikert forekomst.
Ping fra CPE-sidetunnelens IP-adresse til den dedikerte forekomstens IP- IP-adresse for sidetunnelen.
Ping kan ikke være IP-adressen til tunneltransporten til tunnelens transport-IP-adresse, den må være IP-adressen fra tunnelen til tunnelen.
Hvis en pakkesporing er nødvendig for IKEv2-trafikken, angi 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 er satt inn i midten av IPsec endepunkter).
Kontroller at IKEv2 UDP-pakker med port 500 eller 4500 sendes og mottas til og fra DI IPsec IP-adresse.
|
Datasenteret for dedikert forekomst starter kanskje ikke alltid den første IKEv2-pakken. Kravet er at CPE-enheten er i stand til å starte den første IKEv2-pakken mot den dedikerte forekomstsiden. Hvis den lokale brannmuren tillater det, kan du også prøve å pinge til den eksterne IPsec-adressen. Hvis pingingen ikke er vellykket fra lokal til ekstern IPsec-adresse, må du utføre en sporingsrute for å hjelpe og finne ut hvor pakken droppes. Noen brannmurer og Internett-utstyr tillater kanskje ikke sporingsruter. |
Feilsøking og validering for IPsec Second Phase (IPsec Negotiation).
Kontroller at IPsecs første fase (det vil si IKEv2-sikkerhetstilknytningen) er aktiv før du feilsøker IPsec andre fase. Utfør kommandoen «vis crypto ikev2 sa» eller tilsvarende for å bekrefte IKEv2-økten. I utdataene kontrollerer du at IKEv2-økten har vært oppe i mer enn noen få sekunder, og at den ikke returnerer. Oppetiden for økten vises som «Aktiv tid» for økten eller tilsvarende i utdata.
Når IKEv2-økten er bekreftet som oppe og aktiv, undersøker du IPsec-økten. Som med IKEv2-økten, utfører du en «vis 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, må du se etter feilmeldinger eller forhandlingsfeil i IPsec-loggene.
Noen av de vanligste problemene som kan oppstå under IPsec-forhandlingene er:
Innstillingene på CPE-siden samsvarer ikke med siden for dedikert forekomst. Kontroller innstillingene på nytt:
Kontroller at parametrene for kryptering og autentisering samsvarer med innstillingene på den dedikerte forekomst-siden.
Kontroller at innstillingene for Perfect Forward Secrecy og at innstillingene samsvarer med dedikert forekomst-siden.
Kontroller levetidsinnstillingene.
Kontroller at IPsec er konfigurert i tunnelmodus.
Kontroller 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 Keepalive-pakkene for GRE-tunnelen flyte mellom den dedikerte forekomsten og CPE-tunnelendepunktene. Hvis status for tunnelgrensesnittet ikke vises, er noen vanlige problemer:
Transport-VRF for tunnelgrensesnitt samsvarer ikke med VRF for tilbakekoblingsgrensesnittet (hvis VRF-konfigurasjon brukes på tunnelgrensesnittet).
Hvis VRF-konfigurasjonen ikke brukes på tunnelgrensesnittet, kan denne kontrollen ignoreres.
Keepalives er ikke aktivert i CPE-sidetunnelgrensesnittet
Hvis keepalives ikke støttes på CPE-utstyret, må Cisco varsles slik at standard keepalives på den dedikerte forekomst-siden også deaktiveres.
Hvis Keepalives støttes, må du kontrollere at Keepalives er aktivert.
Masken eller IP-adresse til tunnelgrensesnittet er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.
Kilde- eller måltunneltransportadressen er ikke riktig og samsvarer ikke med de forventede verdiene for dedikert forekomst.
En brannmur blokkerer at GRE-pakker ikke 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 at tilkoblingen er god til det eksterne tunnelgrensesnittet. Utfør ping-kontrollen fra tunnel-IP-en (ikke transport-IP-en) til den eksterne tunnel-IP-en.
|
Krypteringstilgangslisten for IPsec-tunnelen som bærer GRE- tilgangsliste , tillater bare å krysse GRE-pakker. Som et resultat vil ikke ping fungere fra tunneltransport-IP til ekstern tunneltransport-IP. |
Ping-kontrollen resulterer i en GRE-pakke som genereres fra transport-IP-en til kildetunnelen til transport-IP-en for måltunnelen, mens nyttelasten til GRE-pakken (den indre IP-adressen) vil være IP-adressen for kilden og måltunnelen.
Hvis ping-testen ikke lykkes og de foregående elementene er bekreftet, kan det hende at en pakkelagring er nødvendig for å sikre at icmp-pingen resulterer i en GRE-pakke som deretter innkapsles i en IPsec-pakke og deretter sendes fra kildens IPsec-adresse til mål-IPsec-adressen. Tellere på GRE-tunnelgrensesnittet og IPsec-økttellerne kan også bidra til å vise. hvis sende- og mottakspakkene øker.
I tillegg til ping-trafikken, skal registreringen også vise keepalive GRE-pakker selv under inaktiv trafikk. Til slutt, hvis BGP er konfigurert, skal BGP keepalive-pakker også sendes som GRE-pakker innkapslet i IPSEC-pakker, i tillegg til via 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 den dedikerte BGP-naboen for forekomsten. 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, kontrollerer du at en ping er vellykket mellom den lokale og den eksterne GRE-tunnel-IP-en. Hvis pingen er vellykket, men BGP-økten ikke kommer, kan du undersøke 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å siden for dedikert forekomst. Kontroller konfigurasjonen av nabo-AS på nytt.
Det lokale AS-nummeret samsvarer ikke med det den Dedikerte forekomst-siden 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 å sendes til IPsec-tunnelen eller mottas fra IPSEC-tunnelen
Den eksterne BGP-nabo-IP-en samsvarer ikke med den eksterne GRE-tunnelens IP.
BGP-ruteutveksling
Når BGP-økten er bekreftet for begge tunnelene, må du kontrollere at de riktige rutene sendes og mottas fra siden for dedikert forekomst.
Den dedikerte VPN-løsningen for forekomst forventer at det 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 dedikert forekomstdatasenter vil annonsere sin lokale /25-rute i tillegg til en /24-reserverute. Når du kontrollerer de innkommende BGP-rutene fra dedikert forekomst, må du sørge for at BGP-økten som er knyttet til tunnelen som peker til datasenteret A for dedikert forekomst, mottar den lokal rute /25 for dedikert forekomst av datasenteret A /25 i tillegg til /24-sikkerhetskopieruten. I tillegg må du sørge for at tunnelen som peker til datasenteret B for dedikert forekomst, mottar den lokal rute for dedikert forekomst av datasenteret B /25 i tillegg til /24-reserveruten. Merk at /24-reserveruten vil være den samme ruten som annonseres ut av datasenter A for dedikert forekomst og datasenter B for dedikert forekomst.
Redundans gis til et dedikert forekomst-datasenter hvis tunnelgrensesnittet til dette datasenteret går ned. Hvis tilkoblingen til datasenteret A for dedikert forekomst mistes, viderekobles trafikk fra datasenteret B for dedikert forekomst til datasenteret A. I dette scenariet vil tunnelen til datasenteret B bruke ruten for datasenteret B /25 til å sende trafikk til datasenteret B og tunnelen til datasenter B vil bruke sikkerhetskopi /24-ruten for å sende trafikk til datasenter A via datasenter B.
Det er viktig at når begge tunnelene er aktive at datasenter A-tunnelen ikke brukes til å sende trafikk til datasenter B og omvendt. I dette scenariet, hvis trafikk sendes til datasenter A med mål for 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 aktiv/aktiv konfigurasjon under normal drift.
0.0.0.0/0-ruten må annonseres fra kundesiden til datasentersiden for dedikert forekomst. Mer spesifikke ruter godtas ikke av den dedikerte forekomst-siden. Kontroller at ruten 0.0.0.0/0 annonseres ut av både A-tunnelen for dedikert forekomst og B-tunnelen for datasenteret for dedikert forekomst.
MTU-konfigurasjon
På siden for dedikert forekomst er to funksjoner aktivert for dynamisk å justere MTU for store pakkestørrelser. GRE-tunnelen legger til flere overskrifter i IP-pakkene som flyter gjennom VPN-økten. IPsec-tunnelen legger til de ekstra overskriftene på toppen av GRE-hodene, vil ytterligere redusere den største MTU-en som er tillatt over tunnelen.
GRE-tunnelen justerer MSS-funksjonen og GRE-tunnelbanen i MTU-oppdagingsfunksjonen er aktivert på siden for dedikert forekomst. Konfigurer «ip tcp adjust-mss 1350» eller tilsvarende kommando i tillegg til «tunnel path\u0002mtu-discovery» eller tilsvarende kommando på kundesiden for å hjelpe med dynamisk justering av MTU for trafikk gjennom VPN-tunnelen.
