Jotkin L2VPN-reitit katoavat, kun lisäät reitinsäteilijöitä

Istunnot pysyvät pystyssä, IGP on vakaa, ja silti muutama L2VPN-reitti ei koskaan ilmesty kahdelle neljästä palveluntarjoajan reunasta. Tämä kuvio kuuluu heijastusongelmaan eikä kuljetusongelmaan, koska rikkoutunut istunto epäonnistuu kokonaan, kun taas uudelleenkäytetty heijastusraja epäonnistuu valikoivasti. Fyysisellä renkaalla ei ole sen kanssa mitään tekemistä; looginen jakelugraafi on paikka, johon ne reitit pysähtyivät. Tämän kohdan löytäminen ei vaadi ohjaustason uudelleenrakentamista.

Katoaminen on valikoivaa, mikä kaventaa hakua

Neljä palveluntarjoajan reunaa fyysisellä renkaalla tarvitsevat kuusi loogista istuntoa täyteen verkkoon, koska jokainen reititin pariutuu kolmen muun kanssa. Ne istunnot kulkevat reititetyn kuljetuksen yli, joten kaapelointi ei kerro mitään siitä, kuinka monta naapuruussuhdetta on tai mikä niistä heijastaa. Kun kaksi reunaa menettää tietyn etuliitejoukon samalla kun kaikki muu konvergoituu, kaapeli ei ole epäilty.

Valikoiva katoaminen viittaa silmukoiden estoon, käytäntöön tai suhteen suuntaan, jossa jotkin reitit ylittävät rajan ja toiset pudotetaan matkalla. Täydellinen katoaminen viittaa istuntoon tai osoiteperheeseen. Sen päättäminen, kumpaa näistä kahdesta katselet, on ensimmäinen hyödyllinen askel, ja se vie yhden komennon.

Mitä heijastus oikeastaan muuttaa

Reittien heijastus löysentää sääntöä, jonka mukaan iBGP-puhuja ei saa mainostaa uudelleen reittiä, jonka se oppi toiselta iBGP-puhujalta. RFC 4456 ilmaisee poikkeuksen puhujan ja reitin lähteen välisen suhteen kautta, ja tuon suhteen suunnalla on enemmän väliä kuin useimmat tiivistelmät antavat ymmärtää. Asiakkaalta opittu reitti voidaan heijastaa muille asiakkaille ja ei-asiakkaille, kun taas ei-asiakkaalta opittu reitti voidaan heijastaa vain asiakkaille. Lue epäsymmetria kahdesti, sillä se selittää, miten asiakassuhteen lisääminen voi piilottaa suunnitteluvirheen: se avaa polun, jota topologia ei koskaan tarkoittanut.

CLUSTER_LIST-attribuutti tallentaa heijastushistorian, ja heijastimen, joka löytää oman klusteritunnuksensa tästä luettelosta, on jätettävä ilmoitus huomiotta. Se on silmukoiden estoa, ja se on myös mekanismi, joka poistaa reittejä, kun tunnuksia käytetään vahingossa uudelleen. ORIGINATOR_ID näyttelee sukulaistehtävää nimeämällä reitittimen, joka mainosti reitin ensimmäisenä.

Uudelleenkäytetyt klusteritunnukset ovat se tapa, jolla reitit katoavat

Pieni verkko houkuttaa oikotiehen: anna jokaiselle reitittimelle klusteritunnus, joka on yhtä suuri kuin sen loopback, lisää myöhemmin vielä yksi heijastin ja käytä olemassa olevaa loopbackia uudelleen, koska se on kätevästi käsillä. Jos tämä tunnus nyt esiintyy kahdessa riippumattomassa heijastusvaiheessa, toinen vaihe näkee oman tunnuksensa CLUSTER_LISTissä ja hylkää reitin. Mikään ei kirjaa virhettä, koska hylkääminen on oikea vastaus silmukkaan.

Yhtä klusteria palvelevat redundantit heijastimet ovat laillinen poikkeus: ne jakavat tunnuksen tarkoituksella, jotta kumpi tahansa voi palvella samoja asiakkaita. Tunnuksen on vastattava heijastussuunnittelua eikä erotettava rungon nimiä.

Piirrä aiottu graafi ennen kuin kosket mihinkään konfiguraatioon: kuka luo etuliitteen, mikä asiakassuhde sallii ensimmäisen heijastuksen, mikä heijastin kuljettaa sen seuraavaan vaiheeseen ja missä viimeinen asiakas istuu. Jokainen hyppy siinä graafissa on paikka, jossa uudelleenkäytetty tunnus, puuttuva asiakassuhde tai käytäntösuodatin voi pysäyttää reitin. Kun graafi on piirretty, puuttuvalla reitillä on sijainti mysteerin sijaan.

Vastusta kiusausta tehdä jokaisesta naapurista asiakas

Nopea korjaus puuttuvalle reitille on tehdä jokaisesta naapurista jokaisen heijastimen asiakas. Leviäminen palaa, ja suunnittelu lakkaa kertomasta sinulle mitään: se moninkertaistaa reitit, joita kukin puhuja kantaa, ja samalla kätkee, minkä suhteen piti tehdä työ.

Pieni verkko tarvitsee yleensä yhden kahdesta muodosta. Täysi iBGP-verkko on kuusi istuntoa neljälle reitittimelle täysin ilman heijastusta, ja nimetty heijastinpari, joka palvelee loput reunat, on toinen. Molempia on helpompi pohtia kuin osittaista verkkoa, jossa jokainen reititin heijastaa hieman. Valitse muoto mittakaavan ja vikatilanteen käyttäytymisen mukaan, ei kaapelointikaavion mukaan.

Tarkista osoiteperhe ennen kuin syytät heijastusta

TCP-istunto portissa 179 todistaa, että kaksi puhujaa voivat puhua, eikä mitään siitä, vaihtoiko VPN-osoiteperhe yhtään reittiä. Selvitä istunnon tila, sitten perhe, sitten yksittäinen etuliite.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Nämä kolme tulostetta erottavat naapuruusongelman vaihto-ongelmasta ja puuttuvan etuliitteen ongelmasta. Jos perhe ei näytä lainkaan etuliitteitä, tarkista naapurin aktivointitila ja vientikäytäntö ennen kuin katsot heijastusta. Jos etuliitteitä näkyy yhdellä reunalla mutta ei toisella, vertaa klusteriluetteloa ja originaattoria vastaanottavalla puolella ja käy sitten läpi edellisen osan graafi.

Pidä seuraavan hypyn tavoitettavuus ja edelleenlähetystila tuon tarkistuksen ulkopuolella. Heijastettu reitti, jolla on tavoittamaton seuraava hyppy, on olemassa ja käyttökelvoton, mikä näyttää heijastusvialta, kunnes katsot seuraavan hypyn saraketta. Ratkaise seuraava hyppy, vahvista edelleenlähetysmerkintä ja päätä vasta sitten, tarvitseeko jakelugraafi vielä yhden heijastimen.