Virtual Connect käyttää kaksitasoista videokeskusarkkitehtuuria, jossa reititys- ja GRE-ohjaustasot tarjoaa yksi laite ja IPSec-ohjaustason toinen.

Kun Virtual Connect -yhteys on valmis , asiakkaan yritysverkon ja Dedicated Instance Ciscon palvelinkeskusten välille luodaan kaksi GRE over IPSec -tunnelia. Yksi kutakin redundanttia palvelinkeskusta kohden kyseisellä alueella. Kumppani tai asiakas vaihtaa vertaisverkon tarvitsemat lisäelementit Ciscoon Control Hub Virtual Connect -aktivointilomakkeella.

Kuvassa 1 on esimerkki Virtual Connect -käyttöönottomallista 2-keskitinvaihtoehdolle asiakaspuolella.

Virtual Connect - VPN on keskitinsuunnittelu, jossa asiakkaan keskitinsivustot on yhdistetty DC1: een ja DC2: een Dedicated Instancen palvelinkeskuksissa tietyllä alueella.

Kahta Hub-toimipaikkaa suositellaan paremman redundanssin saavuttamiseksi, mutta One Hub -toimipaikka, jossa on kaksi tunnelia, on myös tuettu käyttöönottomalli.

Tunnelin kaistanleveys on rajoitettu 250 Mbps:iin.

Samalla alueella sijaitsevien asiakkaan etätoimipaikkojen on muodostettava yhteys takaisin keskittimen toimipaikkoihin asiakkaan WAN-verkon kautta, eikä Cisco ole vastuussa tästä yhteydestä.

Kumppaneiden odotetaan tekevän tiivistä yhteistyötä asiakkaiden kanssa varmistaen, että "Virtual Connect" -palvelualueelle valitaan optimaalisin polku.

Kuvassa 2 esitetään Dedicated Instance Cloud Connectivity -vertaisalueet.

Virtual Connect -lisäosan reititys toteutetaan käyttämällä ulkoista BGP:tä (eBGP) Dedicated Instancen ja Customer Premise Equipmentin (CPE) välillä. Cisco mainostaa omaa verkkoaan jokaiselle alueen redundantille ohjauskoneelle asiakkaan CPE:lle, ja CPE:n on mainostettava oletusreittiä Ciscoon.

• Cisco ylläpitää ja luovuttaa

  • Tunneliliittymän IP-osoite (tilapäinen linkki reititystä varten), jonka Cisco määrittää määritetystä jaetusta osoitetilasta (ei julkisesti reititettävissä)

  • Tunnelikuljetuksen kuivausosoite (Ciscon puolella)

  • Yksityiset autonomiset järjestelmänumerot (ASN) asiakkaan BGP-reitityskonfiguraatiota varten

    • Cisco määrittää määritetyltä yksityisen käytön alueelta: 64512–65534

• eBGP, jota käytetään reittien vaihtamiseen Dedicated Instancen ja CPE:n välillä

  • Cisco jakaa määritetyn /24-verkon 2/25 yhdeksi kullekin kyseisen alueen DC: lle

  • Virtual Connectissa Cisco mainostaa jokaista /25-verkkoa takaisin CPE:lle vastaavien point-to-point-VPN-tunneleiden kautta (ohimenevä linkki)

  • CPE on määritettävä asianmukaisten eBGP-naapureiden kanssa. Jos käytetään yhtä CPE:tä, käytetään kahta eBGP-naapuria, joista yksi osoittaa kuhunkin etätunneliin. Jos käytetään kahta CPE:tä, jokaisella CPE:llä on yksi eBGP-naapuri, joka ponitoi yhteen CPE:n etätunneliin.

  • Kunkin GRE-tunnelin Cisco-puoli (tunneliliittymän IP) määritetään CPE:n BGP-naapuriksi

  • CPE:n on mainostettava oletusreittiä kunkin tunnelin kautta

  • CPE on vastuussa opittujen reittien uudelleenjakamisesta tarvittaessa kutomerin yritysverkossa.

• Ei-vikaisen linkin vikatilanteessa yhdellä CPE:llä on kaksi aktiivista/aktiivista tunnelia. Kahdessa CPE-solmussa kussakin CPE:ssä on yksi aktiivinen tunneli, ja molempien CPE-solmujen tulee olla aktiivisia ja ohikulkevia liikennettä. Vikaantumattoman skenaarion mukaan liikenne on jaettava kahteen tunneliin, jotka menevät oikeisiin /25 määränpäihin, jos toinen tunneleista kaatuu, jäljellä oleva tunneli voi kuljettaa liikenteen molemmille. Tällaisessa vikatilanteessa, kun /25-verkko on poissa käytöstä, /24-verkkoa käytetään varareittinä. Cisco lähettää asiakasliikennettä sisäisen WAN-verkon kautta kohti DC: tä, joka menetti yhteyden.

IPsec-tunnelineuvottelut sisältävät kaksi vaihetta, IKEv2-vaiheen ja IPsec-vaiheen. Jos IKEv2-vaiheen neuvottelua ei suoriteta loppuun, toista IPsec-vaihetta ei aloiteta. Anna ensin komento "show crypto ikev2 sa" (Cisco-laitteissa) tai vastaava komento kolmannen osapuolen laitteissa tarkistaaksesi, onko IKEv2-istunto aktiivinen. Jos IKEv2-istunto ei ole aktiivinen, mahdolliset syyt voivat olla:

• Mielenkiintoinen liikenne ei käynnistä IPsec-tunnelia.

• IPsec-tunnelin käyttöluettelo on määritetty väärin.

• Asiakkaan ja Dedicated Instance IPsec -tunnelin päätepisteen IP:n välillä ei ole yhteyttä.

• IKEv2-istunnon parametrit eivät vastaa Dedicated Instance -puolen ja asiakaspuolen välillä.

• Palomuuri estää IKEv2 UDP -paketit.

Tarkista ensin IPsec-lokeista kaikki viestit, jotka osoittavat IKEv2-tunnelineuvottelujen edistymisen. Lokit voivat osoittaa, missä IKEv2-neuvotteluissa on ongelma. Lokiviestien puuttuminen voi myös tarkoittaa, että IKEv2-istuntoa ei ole aktivoitu.

Joitakin yleisiä virheitä IKEv2-neuvotteluissa ovat:

• CPE-puolen IKEv2: n asetukset eivät vastaa Cisco-puolta, tarkista mainitut asetukset uudelleen:

  • Tarkista, että IKE-versio on versio 2.

  • Varmista, että salaus- ja todennusparametrit vastaavat odotettua salausta Varattu esiintymä -puolella.

    Kun GCM-salaus on käytössä, GCM-protokolla käsittelee todennuksen ja asettaa todennusparametriksi NULL.

  • Tarkista elinkaariasetus.

  • Tarkista Diffie Hellmanin moduuliryhmä.

  • Tarkista Pseudo Random Function -asetukset.

• Kryptokartan käyttöoikeusluetteloksi ei ole asetettu:

  • Lupa GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (tai vastaava komento)

    Käyttöluettelon on oltava erityisesti "GRE" -protokollaa varten, ja "IP" -protokolla ei toimi.

Jos lokiviesteissä ei näy mitään IKEv2-vaiheen neuvottelutoimintaa, paketin sieppaus saattaa olla tarpeen.

Dedikoitu instanssipuoli ei välttämättä aina aloita IKEv2-vaihtoa ja saattaa joskus odottaa, että asiakkaan CPE-puoli on aloittaja. Tarkista CPE-puolen kokoonpanosta seuraavat IKEv2-istunnon aloittamisen edellytykset: Tarkista IPsec-salauskäyttöluettelo GRE-liikenteelle (protokolla 50) CPE-tunnelin siirron IP-osoitteesta Dedicated Instance -tunnelikuljetuksen IP-osoitteeseen. Varmista, että GRE-tunneliliitäntä on käytössä GRE-keepaliveille, jos laite ei tue GRE-keepaliveja, Ciscolle ilmoitetaan, koska GRE-keepalives otetaan oletusarvoisesti käyttöön Dedicated Instance -puolella. Varmista, että BGP on käytössä ja määritetty Dedicated Instance -tunnelin IP-osoitteen naapuriosoitteella.

Kun asetukset on määritetty oikein, seuraava aloittaa IPsec-tunnelin ja ensimmäisen vaiheen IKEv2-neuvottelut:

• GRE pitää CPE-puolen GRE-tunneliliitännästä Dedicated Instance -puolen GRE-tunneliliitäntään.

• BGP-naapurin TCP-istunto CPE-puolen BGP-naapurista Dedicated Instance -puolen BGP-naapuriin.

• Pingaa CPE-sivutunnelin IP-osoitteesta Dedicated Instance -sivutunnelin IP-osoitteeseen.

  Ping ei voi olla tunnelikuljetuksen IP tunneliliikenteen IP: hen, sen on oltava tunnelin IP tunnelin IP: hen.

Jos pakettijäljitystä tarvitaan IKEv2-liikennettä varten, aseta suodatin UDP:lle ja joko portille 500 (kun NAT-laite ei ole IPsec-päätepisteiden keskellä) tai portille 4500 (kun NAT-laite asetetaan IPsec-päätepisteiden keskelle).

Varmista, että portilla 500 tai 4500 varustetut IKEv2 UDP -paketit lähetetään ja vastaanotetaan DI IPsec IP -osoitteeseen ja DI IPsec -IP-osoitteesta.

Dedikoidun instanssin palvelinkeskus ei välttämättä aina käynnistä ensimmäistä IKEv2-pakettia. Vaatimuksena on, että CPE-laite pystyy käynnistämään ensimmäisen IKEv2-paketin Dedicated Instance -puolelle. Jos paikallinen palomuuri sallii sen, yritä pingata myös IPSec-etäosoitteeseen. Jos ping-kutsu ei onnistu paikallisesta IPSec-etäosoitteeseen, suorita jäljitysreitti auttaaksesi ja määritä, mihin paketti on pudonnut. Jotkin palomuurit ja Internet-laitteet eivät välttämättä salli jäljitysreittiä.

Varmista, että IPsecin ensimmäinen vaihe (eli IKEv2-suojauskytkentä) on aktiivinen, ennen kuin suoritat IPsecin toisen vaiheen vianmäärityksen. Suorita "show crypto ikev2 sa" tai vastaava komento vahvistaaksesi IKEv2-istunnon. Varmista tulosteessa, että IKEv2-istunto on ollut käynnissä yli muutaman sekunnin ja että se ei pomppi. Istunnon käyttöaika näkyy istunnossa "Active Time" tai vastaavana tulosteessa.

Kun IKEv2-istunto on vahvistettu toimivaksi ja aktiiviseksi, tutki IPsec-istuntoa. Kuten IKEv2-istunnossa, suorita "näytä salaus ipsec sa" tai vastaava komento vahvistaaksesi IPsec-istunnon. Sekä IKEv2-istunnon että IPsec-istunnon on oltava aktiivisia, ennen kuin GRE-tunneli muodostetaan. Jos IPsec-istunto ei näy aktiivisena, tarkista IPsec-lokeista virhesanomat tai neuvotteluvirheet.

Joitakin yleisimpiä ongelmia, joita voi ilmetä IPsec-neuvottelujen aikana, ovat:

CPE-puolen asetukset eivät vastaa Dedicated Instance -puolta, tarkista asetukset uudelleen:

• Varmista, että Salaus- ja Todennus-parametrit vastaavat Varattu esiintymä -puolen asetuksia.

• Tarkista Perfect Forward Secrecy -asetukset ja että vastaavat asetukset Dedicated Instance -puolella.

• Tarkista käyttöiän asetukset.

• Varmista, että IPsec on määritetty tunnelitilassa.

• Tarkista lähde- ja kohde-IPsec-osoitteet.

Kun IPsec- ja IKEv2-istunnot on vahvistettu ylös ja aktiivisiksi, GRE-tunnelin keepalive-paketit voivat virrata Dedicated Instance- ja CPE-tunnelin päätepisteiden välillä. Jos tunnelin käyttöliittymän tila ei näy, yleisiä ongelmia ovat esimerkiksi seuraavat:

• Tunneliliitännän siirto VRF ei vastaa silmukkaliittymän VRF-tiedostoa (jos tunnelirajapinnassa käytetään VRF-konfiguraatiota).

  Jos VRF-konfiguraatiota ei käytetä tunneliliittymässä, tämä tarkistus voidaan ohittaa.

• Keepalives ei ole käytössä CPE-sivutunnelin liittymässä

  Jos CPE-laitteet eivät tue keepaliveja, Ciscolle on ilmoitettava asiasta, jotta myös Dedicated Instance -puolen oletuskeepalives poistetaan käytöstä. Jos keepaliveja tuetaan, varmista, että keepalives on käytössä.

• Tunneliliittymän peite tai IP-osoite ei ole oikea eikä vastaa Dedicated Instance -odotusarvoja.

• Tunnelin lähde- tai kohdekuljetusosoite ei ole oikea eikä vastaa Dedicated Instance -odotusarvoja.

• Palomuuri estää GRE-pakettien lähettämisen IPsec-tunneliin tai vastaanottamisen IPsec-tunnelista (GRE-tunneli siirretään IPsec-tunnelin kautta)

Ping-testin pitäisi varmistaa, että paikallinen tunneliliitäntä on toiminnassa ja yhteys etätunneliliitäntään on hyvä. Suorita ping-tarkistus tunnelin IP-osoitteesta (ei siirron IP-osoitteesta) etätunnelin IP-osoitteeseen.

GRE-tunneliliikennettä kuljettavan IPsec-tunnelin salauskäyttöluettelo sallii vain GRE-pakettien ylittämisen. Tämän seurauksena pingit eivät toimi tunnelikuljetuksen IP: stä etätunneliliikenteen IP: hen.

Ping-tarkistus johtaa GRE-pakettiin, joka luodaan lähdetunnelin kuljetus-IP: stä kohdetunnelin kuljetus-IP: hen, kun taas GRE-paketin hyötykuorma (sisäinen IP) on lähde- ja kohdetunnelin IP.

Jos ping-testi ei onnistu ja edelliset kohteet tarkistetaan, paketin sieppaus voi olla tarpeen sen varmistamiseksi, että icmp-ping johtaa GRE-pakettiin, joka sitten kapseloidaan IPsec-pakettiin ja lähetetään sitten IPsec-lähdeosoitteesta IPsec-kohdeosoitteeseen. GRE-tunneliliittymän laskurit ja IPsec-istuntolaskurit voivat myös auttaa näyttämään. jos lähetys- ja vastaanottopaketit kasvavat.

Ping-liikenteen lisäksi sieppauksen pitäisi näyttää myös keepalive GRE -paketit myös tyhjäkäynnillä. Lopuksi, jos BGP on määritetty, BGP keepalive -paketit tulisi lähettää myös IPSEC-paketteihin kapseloituina GRE-paketteina myös VPN: n kautta.

Dedikoidun instanssin puolella on kaksi ominaisuutta, jotka voivat säätää MTU:ta dynaamisesti suurille pakettikokoille. GRE-tunneli lisää otsikoita VPN-istunnon läpi kulkeviin IP-paketteihin. IPsec-tunneli lisää lisäotsikot GRE-otsikoiden päälle, mikä vähentää entisestään suurinta tunnelin yli sallittua MTU: ta.

GRE-tunneli säätää MSS-ominaisuutta ja GRE-tunnelin polku MTU-etsintäominaisuudessa on käytössä Dedicated Instance -puolella. Määritä "ip tcp adjust-mss 1350" tai vastaava komento sekä "tunnel path\u0002mtu-discovery" tai vastaava komento asiakaspuolelle auttamaan VPN-tunnelin kautta kulkevan liikenteen MTU: n dynaamisessa säätämisessä.