Johdanto

Virtual Connect on lisälaajennusvaihtoehto pilviyhteydelle Dedicated Instance for Webex Calling (Dedicated Instance). Virtual Connectin avulla asiakkaat voivat laajentaa yksityistä verkkoaan turvallisesti Internetissä käyttämällä point-to-point IP VPN -tunneleita. Tämä liitäntävaihtoehto tarjoaa nopean yksityisen verkkoyhteyden muodostamisen käyttämällä olemassa olevaa asiakastilalaitteistoa (CPE) ja Internet-yhteyttä.

Cisco isännöi, hallitsee ja takaa redundantteja IP VPN-tunneleita ja vaaditun Internet-yhteyden Ciscon Dedicated Instance -palvelinkeskuksen alueella/alueilla, joilla palvelua tarvitaan. Vastaavasti Järjestelmänvalvoja on vastuussa vastaavista CPE- ja Internet-palveluistaan, joita tarvitaan Virtual Connectin muodostamiseen.

Jokainen Virtual Connect -tilaus tietyllä Dedicated Instance -alueella sisältäisi kaksi IPSec-salauksella suojattua GRE (Generic Routing Encapsulation) tunnelia (GRE over IPSec), yhden kullekin valitulla alueella sijaitsevaan Ciscon tietokeskukseen.

Virtual Connectin kaistanleveysrajoitus on 250 Mbps tunnelia kohden, ja sitä suositellaan pienemmille käyttöönottoille. Koska käytössä on kaksi point-to-point VPN-tunnelia, kaiken liikenteen pilveen täytyy kulkea asiakkaan headend CPE:n kautta, joten se ei välttämättä sovellu sinne, missä on paljon etäsivustoja. Katso muut vaihtoehtoiset peering-vaihtoehdot Pilviyhteys.

Ennen kuin lähetät peering-pyynnön Virtual Connectille, varmista, että Dedicated Instance -palvelu on aktivoitu kyseisellä alueella.

Edellytykset

Virtuaaliyhteyden perustamisen edellytyksiä ovat:

  • Asiakas tarjoaa

    • Internet-yhteys, jossa on riittävästi vapaata kaistanleveyttä käyttöönoton tukemiseksi

    • Julkiset IP-osoitteet kahdelle IPSec-tunnelille

    • Asiakaspuolen GRE-siirto-IP-osoitteet kahdelle GRE-tunnelille

  • Kumppani ja asiakas

    • Työskentele yhdessä kaistanleveysvaatimusten arvioimiseksi

    • Varmista, että verkkolaitteet tukevat Border Gateway Protocol (BGP) -reititystä ja GRE:tä IPSec-tunnelin kautta.

  • Kumppani tai asiakas tarjoaa

    • Verkkotiimi, joka tuntee paikasta toiseen VPN-tunneliteknologioihin

    • Verkkotiimi, joka tuntee BGP-, eBGP- ja yleiset reititysperiaatteet

  • Cisco

    • Cisco määritti yksityiset autonomiset järjestelmänumerot (ASN) ja ohimenevän IP-osoitteen GRE-tunneliliitäntöille

    • Cisco on määrittänyt julkisen, mutta ei Internetin reititettävän Class C (/24) -verkon erilliselle esiintymän pilviosoitteelle

Jos asiakkaalla on vain yksi CPE-laite, kullakin alueella olevat 2 tunnelia Ciscon tietokeskuksiin (DC1 ja DC2) ovat kyseisestä CPE-laitteesta. Asiakkaalla on myös mahdollisuus valita 2 CPE-laitetta, jolloin jokaisen CPE-laitteen tulee kytkeytyä vain yhteen tunneliin kohti Ciscon tietokeskuksia (DC1 ja DC2) kullakin alueella. Lisäredundanssia voidaan saavuttaa päättämällä jokainen tunneli erilliseen fyysiseen paikkaan/sijaintiin asiakkaan infrastruktuurissa.

Tekniset yksityiskohdat

Käyttöönottomalli

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

Valmistuttuaan Virtuaalinen yhteys Liitettävyyden vuoksi asiakkaan yritysverkon ja Dedicated Instance Ciscon tietokeskusten välille luodaan kaksi GRE over IPSec -tunnelia. Yksi kullekin redundantille datakeskukselle vastaavalla alueella. Kumppani tai asiakas vaihtaa peeringissä tarvittavat lisäverkkoelementit Ciscolle Control Hub Virtual Connect -aktivointilomakkeen kautta.

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

Virtual Connect - VPN on Hub-muotoilu, jossa asiakkaan keskitinsivustot on liitetty Dedicated Instancen datakeskusten DC1:een ja DC2:een tietyllä alueella.

Kaksi Hub-sivustoa suositellaan paremman redundanssin saavuttamiseksi, mutta yksi keskuspaikka, jossa on kaksi tunnelia, on myös tuettu käyttöönottomalli.

Kaistanleveys tunnelia kohden on rajoitettu 250 Mbps:iin.

Asiakkaan samalla alueella sijaitsevien etäsivustojen tulee muodostaa yhteys takaisin Hub-sivustoihin asiakkaan WAN-verkon kautta, eikä Cisco ole vastuussa tästä yhteydestä.

Kumppanien odotetaan toimivan tiiviissä yhteistyössä asiakkaiden kanssa varmistaen, että Virtual Connect -palvelualueelle valitaan optimaalinen polku.

Kuvassa 2 on Dedicated Instance Cloud Connectivity peering -alueet.

Reititys

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 kunkin alueen sisällä olevaa redundanttia DC:tä vastaavaa verkkoaan asiakkaan CPE:lle, ja CPE:tä vaaditaan mainostaakseen oletusreittiä Ciscoon.

  • Cisco ylläpitää ja jakaa

    • Tunnelirajapinnan IP-osoite (transientti linkki reititystä varten) Cisco määrittää määritetystä jaetusta osoiteavaruudesta (ei julkisesti reititettävissä)

    • Tunnelikuljetuksen kohdeosoite (Ciscon puolella)

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

      • Cisco määrittää määritetyltä yksityiskäyttöalueelta: 64512 - 65534

  • eBGP:tä käytettiin reittien vaihtamiseen Dedicated Instancen ja CPE:n välillä

    • Cisco jakaa määritetyn /24-verkon 2/25:ksi kutakin tasavirtaa vastaavalla alueella

    • Virtual Connectissa Cisco mainostaa jokaisen /25-verkon takaisin CPE:hen vastaavien point-to-point VPN-tunneleiden kautta (transient link)

    • 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 kumpaankin etätunneliin. Jos käytetään kahta CPE:tä, kullakin CPE:llä on yksi eBGP-naapuri, joka osoittaa CPE:n yhteen etätunneliin.

    • Jokaisen GRE-tunnelin (tunnelirajapinnan IP) Cisco-puoli on määritetty BGP-naapuriksi CPE:ssä.

    • CPE vaaditaan oletusreitin mainostamiseen jokaisen tunnelin yli

    • CPE vastaa tarvittaessa opittujen reittien uudelleenjakamisesta asiakkaan yritysverkostossa.

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

Yhteysprosessi

Seuraavat korkean tason vaiheet kuvaavat yhteyden muodostamisen virtuaalisen Connect for Dedicated Instance -sovelluksen kanssa.

1

Tee tilaus Cisco CCW:ssä
2

Aktivoi Virtual Connect Control Hubista
3

Cisco suorittaa verkkomäärityksen
4

Asiakas suorittaa verkkomäärityksen

Vaihe 1: CCW tilaus

Virtual Connect on CCW:n erillisen ilmentymän lisäosa.

1

Siirry CCW-tilaussivustolle ja napsauta sitten Kirjaudu sisään kirjautuaksesi sivustolle:

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

Luo arvio.
3

Lisää "A-FLEX-3" SKU.
4

Valitse Muokkaa vaihtoehtoja.
5

Valitse näkyviin tulevalta tilausvälilehdeltä Asetukset ja lisäosat.
6

Valitse Muut lisäosat -kohdassa "Virtual Connect for Dedicated Instance" -kohdan valintaruutu. SKU-nimi on "A-FLEX-DI-VC".
7

Anna niiden alueiden määrä ja lukumäärä, joilla Virtual Connect vaaditaan.


 
Virtual Connect -määrä ei saa ylittää omistetulle ilmentymälle ostettujen alueiden kokonaismäärää. Lisäksi vain yksi Virtual Connect -tilaus on sallittu aluetta kohden.
8

Kun olet tyytyväinen valintoihin, napsauta Tarkista ja tallenna sivun oikeasta yläkulmasta.
9

Viimeistele tilauksesi napsauttamalla Tallenna ja jatka. Lopullinen tilauksesi näkyy nyt tilaustaulukossa.

Vaihe 2: Virtual Connectin aktivointi Control Hubissa

1

Kirjaudu Control Hubiin https://admin.webex.com/login.
2

Vuonna Palvelut -osio, siirry kohtaan Soittaminen > Dedikoitu instanssi > Pilviyhteys.
3

Virtual Connect -kortissa näkyy ostettu Virtual Connect -määrä. Järjestelmänvalvoja voi nyt napsauttaa Aktivoida käynnistääksesi Virtual Connect -aktivoinnin.


 
Aktivointiprosessin voivat käynnistää vain järjestelmänvalvojat, joilla on "Customer Full admin" -rooli. Sen sijaan järjestelmänvalvoja, jolla on "Customer-only-admin" -rooli, voi vain tarkastella tilaa.
4

Napsauttamalla Aktivoida painike, Aktivoi Virtual Connect -lomake näytetään järjestelmänvalvojalle, joka antaa Virtual Connectin tekniset tiedot, joita tarvitaan Ciscon puolen peering-kokoonpanoissa.


 
Lomake tarjoaa myös staattista tietoa Ciscon puolelta valitun alueen perusteella. Nämä tiedot ovat hyödyllisiä asiakkaiden järjestelmänvalvojille, kun he voivat määrittää CPE:n puolellaan yhteyden muodostamiseksi.

  1. GRE Tunnel Transport IP-osoite: Asiakkaan on annettava asiakkaan puolen Tunnel Transport IP-osoitteet, ja Cisco jakaa IP-osoitteet dynaamisesti, kun aktivointi on valmis. Mielenkiintoisen liikenteen IPSec ACL:n pitäisi sallia paikallisen tunnelikuljetuksen IP/32 ja etätunnelikuljetuksen IP/32. ACL:n tulisi myös määrittää vain GRE IP-protokolla.


     
    Asiakkaan antama IP-osoite voi olla yksityinen tai julkinen.

  2. IPSec-vertaiset: Asiakkaan on annettava IPSec-tunnelin lähde-IP-osoitteet ja Cisco varaa IPSec-kohde-IP-osoitteen. Tarvittaessa tuetaan myös sisäisen IPSEC-tunneliosoitteen NAT-kääntämistä julkiseksi osoitteeksi.


     

    Asiakkaan antaman IP-osoitteen tulee olla julkinen.

     
    Kaikki muut aktivointinäytössä olevat staattiset tiedot ovat Ciscon noudatettuja suojaus- ja salausstandardeja. Tämä staattinen kokoonpano ei ole mukautettavissa tai muokattavissa. Asiakkaan tulee ottaa yhteyttä TACiin, jos hän tarvitsee lisäapua Ciscon staattisiin kokoonpanoihin liittyen.
5

Klikkaa Aktivoida -painiketta, kun kaikki pakolliset kentät on täytetty.
6

Kun Virtual Connect -aktivointilomake on täytetty tietylle alueelle, asiakas voi viedä aktivointilomakkeen kohdasta Control Hub, Soittaminen > Dedicated Instance > Cloud Connectivity -välilehti ja klikata Vie asetukset.


 
Turvallisuussyistä todennus ja BGP-salasana eivät ole saatavilla viedyssä asiakirjassa, mutta järjestelmänvalvoja voi tarkastella niitä Control Hubissa napsauttamalla Näytä asetukset kohdassa Ohjauskeskus, Soittaminen > Dedikoitu ilmentymä > Pilviyhteys -välilehti.

Vaihe 3: Cisco suorittaa verkkomäärityksen

1

Kun Virtual Connect -aktivointilomake on täytetty, tilaksi päivitetään Aktivointi käynnissä kohdassa Soittaminen > Dedikoitu ilmentymä > Cloud Connectivity Virtual Connect -kortti.
2

Cisco suorittaa tarvittavat konfiguroinnit Ciscon sivulaitteiden sisällä 5 arkipäivää. Onnistuneen valmistumisen jälkeen Control Hubin tietyn alueen tilaksi päivitetään "Activated".

Vaihe 4: Asiakas suorittaa verkkomäärityksen

Tilaksi muutetaan "Activated" ilmoittaakseen Asiakkaan järjestelmänvalvojalle, että Ciscon IP VPN -yhteyden määritykset on saatu valmiiksi asiakkaan antamien syötteiden perusteella. Asiakkaan järjestelmänvalvojan odotetaan kuitenkin suorittavan CPE:iden määritykset loppuun ja testaavan yhteysreitit, jotta Virtual Connect -tunneli olisi online-tilassa. Jos sinulla on ongelmia määrityksen tai yhteyden muodostamisen aikana, asiakas voi pyytää apua Cisco TAC:lta.

Vianetsintä

IPsec First Phase (IKEv2 Negotiation) -vianmääritys ja validointi

IPsec-tunnelineuvotteluun kuuluu kaksi vaihetta, IKEv2-vaihe ja IPsec-vaihe. Jos IKEv2-vaiheen neuvottelu ei valmistu, toista IPsec-vaihetta ei aloiteta. Anna ensin komento "show crypto ikev2 sa" (Cisco-laitteissa) tai vastaava komento kolmannen osapuolen laitteessa varmistaaksesi, onko IKEv2-istunto aktiivinen. Jos IKEv2-istunto ei ole aktiivinen, mahdolliset syyt voivat olla:

  • Mielenkiintoinen liikenne ei laukaise IPsec-tunnelia.

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

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

  • IKEv2-istunnon parametrit eivät täsmää omistetun ilmentymän puolen ja asiakaspuolen välillä.

  • Palomuuri estää IKEv2 UDP -paketit.

Tarkista ensin IPsec-lokeista viestejä, jotka osoittavat IKEv2-tunnelin neuvottelun edistymisen. Lokit voivat osoittaa, missä IKEv2-neuvottelussa on ongelma. Lokiviestien puute voi myös olla merkki siitä, että IKEv2-istuntoa ei ole aktivoitu.

Joitakin yleisiä virheitä IKEv2-neuvotteluissa ovat:

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

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

    • Varmista, että salaus- ja todennusparametrit vastaavat odotettua salausta Dedicated Instance -puolella.

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

    • Tarkista käyttöikäasetus.

    • Tarkista Diffie Hellman -moduuliryhmä.

    • Tarkista pseudosatunnaisfunktion asetukset.

  • Salauskartan käyttöoikeusluetteloa ei ole asetettu:

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

      Käyttöoikeusluettelon on oltava erityisesti GRE-protokollaa varten, eikä IP-protokolla toimi.

Jos lokiviestit eivät näytä mitään neuvottelutoimintaa IKEv2-vaiheessa, pakettien sieppaus saattaa olla tarpeen.

Dedikoitu ilmentymäpuoli ei välttämättä aina aloita IKEv2-vaihtoa ja saattaa joskus odottaa asiakkaan CPE-puolen olevan aloittaja.

Tarkista seuraavat IKEv2-istunnon aloituksen edellytykset CPE-puolen kokoonpanosta:

  • Tarkista IPsec-salauksen käyttöoikeusluettelo GRE-liikenteelle (protokolla 50) CPE-tunnelin siirto-IP:stä Dedicated Instance -tunnelin siirto-IP:hen.

  • Varmista, että GRE-tunnelirajapinta on otettu käyttöön GRE-kelläpitoa varten. Jos laite ei tue GRE Keepalives -toimintoa, Cisco saa ilmoituksen, koska GRE Keepalives on oletusarvoisesti käytössä Dedicated Instance -puolella.

  • Varmista, että BGP on käytössä ja määritetty Dedicated Instance tunnelin IP:n naapuriosoitteella.

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

  • GRE pysyy CPE-puolen GRE-tunnelirajapinnassa Dedicated Instance -puolen GRE-tunnelirajapinnassa.

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

  • Ping CPE-puolen tunnelin IP-osoitteesta Dedicated Instance -puolen tunnelin IP-osoitteeseen.

    Ping ei voi olla tunnelin kuljetuksen IP-osoite tunnelin kuljetuksen IP-osoitteeseen, sen on oltava tunnelin IP-osoite tunnelin IP-osoitteeseen.

Jos IKEv2-liikenteeseen tarvitaan pakettijäljitystä, aseta suodatin UDP:lle ja joko portille 500 (kun mikään NAT-laitetta ei ole IPsec-päätepisteiden keskellä) tai portille 4500 (kun NAT-laite on asetettu keskelle IPsec-porttia päätepisteet).

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

Dedicated Instance -palvelinkeskus ei välttämättä aina aloita ensimmäistä IKEv2-pakettia. Edellytyksenä on, että CPE-laite pystyy aloittamaan ensimmäisen IKEv2-paketin kohti Dedicated Instance -puolta.

Jos paikallinen palomuuri sallii sen, yritä myös lähettää ping IPsec-etäosoitteeseen. Jos ping ei onnistu paikallisesta IPsec-osoitteesta etäosoitteeseen, suorita jäljitysreitti auttaaksesi ja määritä, mihin paketti on pudonnut.

Jotkut palomuurit ja Internet-laitteet eivät ehkä salli jäljittää reittiä.

IPsec Second Phase (IPsec Negotiation) -vianmääritys ja validointi

Varmista, että IPsecin ensimmäinen vaihe (eli IKEv2-suojausyhteys) on aktiivinen ennen IPsecin toisen vaiheen vianmääritystä. Varmista IKEv2-istunto suorittamalla "show crypto ikev2 sa" tai vastaava komento. Varmista tulosteessa, että IKEv2-istunto on ollut käynnissä yli muutaman sekunnin ja että se ei pomppi. Istunnon käyttöaika näkyy istunnon "Active Time" tai vastaavana lähdössä.

Kun IKEv2-istunto on varmistettu, että se on käynnissä ja aktiivinen, tutki IPsec-istuntoa. Kuten IKEv2-istunnossa, varmista IPsec-istunto suorittamalla "show crypto ipsec sa" tai vastaava komento. Sekä IKEv2-istunnon että IPsec-istunnon on oltava aktiivisia, ennen kuin GRE-tunneli muodostetaan. Jos IPsec-istunto ei näy aktiivisena, tarkista IPsec-lokeista virheilmoituksia tai neuvotteluvirheitä.

Jotkut yleisimmistä ongelmista, joita voidaan kohdata IPsec-neuvottelujen aikana, ovat:

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

  • Varmista, että salaus- ja todennusparametrit vastaavat Dedicated Instance -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.

Tunnelirajapinnan vianmääritys ja validointi

Kun IPsec- ja IKEv2-istunnot varmistetaan, että ne ovat käynnissä ja aktiivisia, GRE-tunnelin paketit voivat virrata erillisen ilmentymän ja CPE-tunnelin päätepisteiden välillä. Jos tunnelin käyttöliittymä ei näytä tilaa, joitain yleisiä ongelmia ovat:

  • Tunnelirajapinnan kuljetus VRF ei vastaa silmukkarajapinnan VRF:ää (jos VRF-konfiguraatiota käytetään tunnelirajapinnassa).

    Jos VRF-konfiguraatiota ei käytetä tunnelirajapinnassa, tämä tarkistus voidaan jättää huomiotta.

  • Keepalves ei ole käytössä CPE-puolen tunnelirajapinnassa

    Jos CPE-laitteet eivät tue säilytystoimintoja, Ciscolle on ilmoitettava, jotta myös Dedicated Instance -puolen oletusarvoiset säilytystoiminnot poistetaan käytöstä.

    Jos Keepalives on tuettu, varmista, että Keepalives on käytössä.

  • Tunnelirajapinnan maski tai IP-osoite ei ole oikea eikä vastaa Dedicated Instance -odotusarvoja.

  • Lähde- tai kohdetunnelin siirtoosoite ei ole oikea eikä vastaa Dedicated Instance -odotusarvoja.

  • Palomuuri estää GRE-paketteja lähettämästä IPsec-tunneliin tai vastaanottamasta IPsec-tunnelista (GRE-tunneli kuljetetaan IPsec-tunnelin yli)

Ping-testin tulee varmistaa, että paikallinen tunnelirajapinta on päällä ja että yhteys etätunnelirajapintaan on hyvä. Suorita ping-tarkistus tunnelin IP-osoitteesta (ei siirto-IP:stä) etätunnelin IP-osoitteeseen.

GRE-tunneliliikennettä kuljettavan IPsec-tunnelin kryptokäyttöluettelo sallii vain GRE-pakettien ylityksen. Tämän seurauksena pingit eivät toimi tunnelinsiirron IP-osoitteesta etätunnelin kuljetuksen IP-osoitteeseen.

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

Jos ping-testi ei onnistu ja edelliset kohteet varmistetaan, pakettien sieppausta saatetaan vaatia sen varmistamiseksi, että icmp ping johtaa GRE-pakettiin, joka sitten kapseloidaan IPsec-pakettiin ja lähetetään sitten IPsec-lähdeosoitteesta kohde IPsec-osoite. GRE-tunnelirajapinnan laskurit ja IPsec-istuntolaskurit voivat myös auttaa näyttämään. jos lähetys- ja vastaanottopaketit kasvavat.

Ping-liikenteen lisäksi kaappauksen tulisi näyttää myös GRE-paketteja, jotka säilyvät hengissä myös käyttämättömän liikenteen aikana. Lopuksi, jos BGP on määritetty, BGP Keepalive -paketit tulee lähettää myös GRE-paketteina, jotka on kapseloitu IPSEC-paketteihin sekä VPN:n kautta.

BGP-vianmääritys ja validointi

BGP-istunnot

BGP vaaditaan reititysprotokollana VPN IPsec -tunnelin yli. Paikallisen BGP-naapurin tulee muodostaa eBGP-istunto Dedicated Instance BGP -naapurin kanssa. eBGP-naapuri-IP-osoitteet ovat samat kuin paikalliset ja etätunnelin IP-osoitteet. Varmista ensin, että BGP-istunto on käynnissä ja varmista sitten, että oikeat reitit vastaanotetaan erillisestä ilmentymästä ja oikea oletusreitti lähetetään omistettuun ilmentymään.

Jos GRE-tunneli on ylhäällä, varmista, että ping onnistuu paikallisen ja etä-GRE-tunnelin IP:n välillä. Jos ping onnistuu, mutta BGP-istunto ei ole tulossa, tutki BGP-lokista BGP-muodostusvirheitä.

Jotkut yleisimmistä BGP-neuvotteluongelmista ovat:

  • Etä-AS-numero ei vastaa AS-numeroa, joka on määritetty Dedicated Instance -puolella. Tarkista naapuri AS -määritykset uudelleen.

  • Paikallinen AS-numero ei vastaa sitä, mitä Dedictaed Instance -puoli odottaa. Varmista, että paikallinen AS-numero vastaa odotettuja erillisen ilmentymän parametreja.

  • Palomuuri estää GRE-paketteihin kapseloitujen BGP TCP -pakettien lähettämisen IPsec-tunneliin tai vastaanottamisen IPSEC-tunnelista

  • BGP-etänaapurin IP-osoite ei vastaa etä-GRE-tunnelin IP-osoitetta.

BGP Route Exchange

Kun BGP-istunto on vahvistettu molemmille tunneleille, varmista, että oikeat reitit lähetetään ja vastaanotetaan Dedicated Instance -puolelta.

Dedicated Instance VPN -ratkaisu edellyttää kahden tunnelin rakentamista asiakkaan/kumppanin puolelta. Ensimmäinen tunneli osoittaa Dedicated Instance -tietokeskukseen A ja toinen tunneli osoittaa Dedicated Instance -tietokeskukseen B. Molempien tunnelien on oltava aktiivisessa tilassa ja ratkaisu vaatii aktiivisen/aktiivisen käyttöönoton. Jokainen Dedicated Instance -palvelinkeskus mainostaa paikallista /25-reittiään sekä /24-varareittiään. Kun tarkistat saapuvia BGP-reittejä erillisestä ilmentymästä, varmista, että BGP-istunto, joka liittyy tunneliin, joka osoittaa Dedicated Instance -tietokeskukseen A, vastaanottaa erillisen ilmentymän tietokeskuksen A /25 paikallisen reitin sekä /24 varareitin. Varmista lisäksi, että tunneli, joka osoittaa Dedicated Instance -palvelinkeskukseen B, vastaanottaa Dedicated Instance -palvelinkeskuksen B /25 paikallisreitin sekä /24 varareitin. Huomaa, että /24-varareitti on sama reitti, joka mainostetaan erillisestä ilmentymän palvelinkeskuksesta A ja erillisestä ilmentymän palvelinkeskuksesta B.

Redundanssi tarjotaan erilliselle ilmentymän palvelinkeskukselle, jos tunnelirajapinta kyseiseen tietokeskukseen katkeaa. Jos yhteys erillisen ilmentymän palvelinkeskukseen A katkeaa, liikenne välitetään erillisestä ilmentymän palvelinkeskuksesta B palvelinkeskukseen A. Tässä skenaariossa tunneli palvelinkeskukseen B käyttää reittiä palvelinkeskukseen B /25 liikenteen lähettämiseen palvelinkeskukseen B ja tunneliin. palvelinkeskukseen B käyttää /24-varareittiä liikenteen lähettämiseen palvelinkeskukseen A palvelinkeskuksen B kautta.

On tärkeää, että kun molemmat tunnelit ovat aktiivisia, palvelinkeskusta A ei käytetä liikenteen lähettämiseen palvelinkeskukseen B ja päinvastoin. Tässä skenaariossa, jos liikenne lähetetään palvelinkeskukseen A, jonka määränpää on palvelinkeskus B, palvelinkeskus A välittää liikenteen palvelinkeskukseen B ja sitten palvelinkeskus B yrittää lähettää liikenteen takaisin lähteeseen palvelinkeskuksen B tunnelin kautta. Tämä johtaa epäoptimaaliseen reititykseen ja voi myös rikkoa palomuurien läpi kulkevan liikenteen. Siksi on tärkeää, että molemmat tunnelit ovat aktiivisessa/aktiivisessa konfiguraatiossa normaalin toiminnan aikana.

Reitti 0.0.0.0/0 on mainostettava asiakkaan puolelta Dedicated Instance -palvelinkeskuksen puolelle. Tarkempia reittejä ei hyväksytä Dedicated Instance -puolella. Varmista, että 0.0.0.0/0-reittiä mainostetaan sekä Dedicated Instance -palvelinkeskuksen A-tunnelista että Dedicated Instance -palvelinkeskuksen B tunnelista.

MTU-kokoonpano

Dedicated Instance -puolella kaksi ominaisuutta on otettu käyttöön MTU:n säätämiseksi dynaamisesti suuria pakettikokoja varten. GRE-tunneli lisää otsikoita VPN-istunnon läpi virtaaviin IP-paketteihin. IPsec-tunneli lisää ylimääräiset otsikot GRE-otsikoiden päälle, mikä vähentää entisestään tunnelin yli sallittua suurinta MTU:ta.

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