Miksi Junos L2VPN näyttää leiman mutta ei välitä mitään eteenpäin

Asiakasraportit kertovat, että L2VPN-yhteys on Up, liitäntä on ylhäällä eikä yhtään kehystä kulje. Tilavalot ovat rehellisiä; kehys luokitellaan palveluun, jolla kauempana päässä ei ole käyttökelpoista edelleenvälitystilaa. BGP:llä signaloidussa pisteestä pisteeseen -L2VPN:ssä ensimmäinen päätös kuuluu liitännälle eikä reittihaulle. Asiakkaan kehys saapuu loogiselle liittymälle, ja tämä liitäntä nimeää yhteyden ja siten etäkohteen. Kaikki sen jälkeen on leimoihin perustuvaa edelleenvälitystilaa, joka on rakennettu siitä, mitä vertaiset ilmoittivat.

Kehys ei koskaan tee reittihakua

Signalointi valmisteli tilan; pakettikohtainen käsittely on leimahaku yhteydeltä, joka on jo valittu. Siksi kysymys siitä, miksi reitti puuttuu, on väärä kysymys, ja se kätkee kaksi tärkeää arvoa: liitännän yhteyden ja sen käyttämän palveluleiman.

Tämä selittää myös vaivan epäsymmetrian. Kokoonpanon tarkastelu kertoo, mitä olisi pitänyt asentaa, kun taas yhteyden näkymä kertoo, mitä todella johdettiin, ja vain jälkimmäinen kestää leimalohkon epäsopivuuden.

Kaksi leimaa, kaksi suuntaa

Jokainen PE varaa paikallisesti leimalohkon, ilmoittaa sen kannan ja koon, ja sen vertaiset lisäävät siirtymän johtaakseen leiman tietylle kohteelle. Varaukset ovat siksi paikallisesti merkitseviä: kaksi PE:tä voi käyttää eri kantoja ja eri lohkokokoja samalle palvelulle. Lue yhteys molemmista päistä ennen kuin muutat mitään. Lohko, joka mitoitettiin yhden leiman liian pieneksi, näyttää täsmälleen yhteydeltä, jota ei koskaan asenneta.

show l2vpn connections instance CUST-A extensive

Tässä tulosteessa saapuva leima on se, jonka tämä PE varasi ja käski vertaisensa käyttää, kun taas lähtevä leima on vertaisen varaus, jonka tämä PE työntää. Näiden kahden lukeminen väärinpäin on klassinen virhe, ja se lähettää sinut etsimään arvoa, jonka ei koskaan pitänyt näkyä tällä puolella. Yhteyden viite dokumentoi leimojen vieressä olevat kentät, mukaan lukien kohde, tila ja lohkotiedot.

Mitä leimahaku todistaa

Kun sinulla on saapuva arvo, paikallinen haku on yksi komento:

show route label 160042

Tämän tulosteen pitäisi näyttää l2vpn-merkintä seuraavan hypyn kanssa, ja leimaoperaatio kertoo, työnnetäänkö kehys, vaihdetaanko se vai poistetaanko se ennen lähtöä. Jos se ei näytä mitään, palvelun tilaa ei koskaan asennettu, vaikka yhteys näyttää Up, ja ristiriita on signaloinnissa eikä siirrossa.

Seuraa yhtä kehystä

Yksi liitäntään työnnetty paketti ratkaisee enemmän kuin mikään kokoonpanon tarkastelu. Palveluleiman reitin pitäisi osoittaa siirto-LSP:tä kohti etäistä PE:tä, ja kahden leiman pitäisi vastata arvoja, jotka vertainen ilmoitti. Kun siirto on kunnossa ja palveluleima on väärä, kehys saavuttaa oikean reitittimen ja hylätään siellä, minkä vuoksi etäpään laskurit näyttävät tyhjiltä, kun taas lähipään laskurit näyttävät kiireisiltä.

Tarkista liitännän kapselointi, ohjaussanan asetus ja MTU samanaikaisesti, koska ne ovat neuvoteltuja ominaisuuksia eivätkä hyppykohtaista käyttäytymistä.

Pidä palvelumallit erillään

VPLS oppii MAC-osoitteita ja EVPN ilmoittaa päätepisteitä, kun taas pisteestä pisteeseen -L2VPN ei tee kumpaakaan, joten niiden kehyksen valintamenettelyt eivät ole vaihdettavissa, vaikka ne ratsastavat samalla BGP- ja MPLS-infrastruktuurilla. Vianetsintävaiheen siirtäminen mallista toiseen tuottaa itsevarmoja johtopäätöksiä ilman perustaa.

Puuttuvalle polulle kirjaa molempien vertaisten yhteystila, liitäntä, molemmat leiman suunnat, kapselointi, ohjaussanan asetus ja MTU. Tämä kirjaus yhdistää ilmoitetun siihen, mitä edelleenvälitystaso todella tekee, ja se on ainoa merkitsevä lenkki, ja myös se, mitä seuraava insinööri kysyy.