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.

Virtual Connect – 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 seg tilbake til Hub-nettstedet(e) over 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 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 overflødig 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 feil i koblingen 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 en 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.

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. Først gir du kommandoen «vis 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 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.

Noen vanlige feil med IKEv2-forhandlingen er:

• 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 godkjenning 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 av CPE-siden for følgende forutsetninger for IKEv2-øktstart: Se etter en IPsec-krypteringstilgangsliste for GRE-trafikk (protokoll 50) fra CPE- tilgangsliste -IP-en til tunneltransport-IP for dedikert forekomst. Kontroller at GRE-tunnelgrensesnittet er aktivert for GRE Keepalives. Hvis utstyret ikke støtter GRE Keepalives, blir Cisco varslet fordi GRE Keepalives vil bli aktivert på den dedikerte forekomst-siden som standard. Kontroller at BGP er aktivert og konfigurert med naboadressen til den dedikerte forekomstens tunnel-IP.

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, 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 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. Enkelte brannmurer og Internett-utstyr tillater kanskje ikke sporingsruter.

Kontroller at IPsec-første fase (det vil si IKEv2-sikkerhetstilknytning) er aktiv før du feilsøker IPsec andre fase. Utfør en «vis crypto ikev2 sa» eller tilsvarende kommando 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.

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 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 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 er vellykket 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.

På dedikert forekomst-siden 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.