Puuttuva reitti VRF:ssä: paikallinen, VPNv4 vai välitystaulu?

Asiakas sanoo, että etuliite puuttuu reittikohteen muutoksen jälkeen, ja ensimmäinen lähettämäsi kuvakaappaus on yleensä väärä taulu. Kolme eri taulua vastaa kolmeen eri kysymykseen: onko etuliite VRF:n sisällä, ilmoitettiinko ja tuotiinko se VPNv4-reittinä, ja asennettiinko välitysmerkintä todella. Niiden lukeminen väärässä järjestyksessä tuottaa varmoja ja vääriä johtopäätöksiä. Tämä ohje vie yhden paikallisen ja yhden etäetuliitteen kaikkien kolmen taulun läpi järjestyksessä ja päättyy palautussuunnitelmaan sille RT-muutokselle, joka sen aloitti.

Nimeä etuliite ja taulu, johon se kuuluu

Kirjoita kaksi etuliitettä ennen kuin kirjoitat mitään. Toinen on paikallinen asiakkaan toimipisteessä, opittu liitetystä rajapinnasta tai CE-ilmoituksesta. Toinen on etäinen ja sen odotetaan saapuvan palveluntarjoajan runkoverkon kautta. Ne kulkevat eri polkuja samaan VRF:ään, eikä vika toisessa kerro mitään toisesta.

Pidä kahden tunnisteen ero selvänä, sillä suurin osa näiden tikettien sekaannuksesta tulee siitä. Reittierotin on osa VPNv4:n NLRI:tä ja se on olemassa tehdäkseen muuten samanlaiset asiakasetuliitteet yksilöllisiksi runkoverkossa. Reittikohde on laajennettu yhteisö, jota kuljetetaan attribuuttina, ja juuri siihen tuonti- ja vientikäytäntö täsmää. Se ei ole erottimen toinen nimi eikä sitä kuljeteta asiakkaan paketeissa.

Vaihe 1: todista, että etuliite on VRF:ssä

Aloita paikallisesta näkymästä ja sitten niistä RT:istä, jotka ohjaavat tuontia. Jos paikallinen etuliite puuttuu täältä, mikään ylempänä ei voi olla syyllinen:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Etuliite, joka näkyy liitettynä tai staattisena, on opittu paikallisesti, eikä sen läsnäolo kerro mitään siitä, vietiinkö se. Tämä on tämän työnkulun yleisin väärinluku: terve VRF-taulu on todiste vain paikallisesta oppimisesta. Vientipuoli on erillinen kysymys, johon naapurinäkymä ja liitetty vientikohde vastaavat.

Tarkista VRF:n RT-luettelot, kun olet täällä. Jos aiottu tuontikohde ei ole luettelossa, kaikki alavirrassa on merkityksetöntä. Jos se on siellä mutta eroaa siitä, mitä etäinen PE vie, olet löytänyt vian avaamatta yhtään pakettikaappausta.

Vaihe 2: lue VPNv4-taulu ja sen kohteet

VPNv4-taulu näyttää, mitä ohjaustaso todella vaihtoi. Etsi etäinen etuliite oikean erottimen alta ja katso sitten siihen liitettyjä yhteisöjä:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Merkintä, jolla on oikea reittikohde mutta ei paikallista asennusta, viittaa tuontikäytäntöön tai reitin valintaan, ei tavoitettavuuteen. Merkintä, joka ei näy VPNv4-taulussa lainkaan, viittaa ylöspäin: lähde-PE ei ehkä vienyt sitä tai istunto ei kuljeta osoiteperhettä.

On kolmaskin tapaus, joka hämmentää ihmisiä muutosten aikana. Jotkin alustat rajoittavat, mitä VPN-reittejä ne pyytävät tai pitävät, käyttämällä reittikohteiden jäsenyystietoja, joten etäisen NLRI:n puuttuminen yhdestä suodatetusta näkymästä ei todista, ettei ilmoitusta ole missään. Tarkista suodattamaton taulu ja naapurin ilmoittamat reitit ennen kuin päättelet, että reitti vedettiin takaisin maailmanlaajuisesti.

Vaihe 3: varmista, että jotain asennettiin ja merkittiin

BGP-merkintä on päätös, ei polku. Välitystaulut kertovat, onko paketeilla minne mennä:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

CEF-merkintä, jossa on ratkaistu viereisyys ja lähtevä tunniste, tarkoittaa, että datatason liikenteen pitäisi toimia, ja mahdollinen jäljellä oleva oire kuuluu sovellukselle tai VRF:n sisäiselle suodatukselle. CEF-merkintä, joka näyttää ratkaisemattoman seuraavan hypyn, tarkoittaa, että tunnistepolku on vaillinainen vaikka BGP näyttää terveeltä, ja juuri tässä tapauksessa BGP-taulun kuvakaappaus on johtanut muutoksen tarkistuksen harhaan.

Vertaa tunnistetta, jonka paikallinen PE asettaa, siihen, jonka etäinen PE odottaa vastaanottavansa. Näkymien välinen ero on tunnisteiden jakamisen tai istunnon ongelma, eikä sitä korjata muokkaamalla reittikohteita, kuinka monta kertaa tahansa.

Peru RT-muutos ilmoitetulla laajuudella

Jos vika alkoi reittikohteen muokkauksesta, peru se yhtenä tarkoituksellisena askeleena ja kerro, mitä laajuutta muutat. Tuontikohteen poistaminen vetää kelpoisuuden pois kyseisen VRF:n sisällä. Se ei poista VPNv4-ilmoitusta runkoverkosta, ja joillakin alustoilla reitti jää pidätetyksi tauluun. Nämä ovat eri lopputuloksia ja käyttäjälle näkyvä vaikutus riippuu siitä, kumpaa tarkoitat.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Pehmeä saapuva uudelleenkonfigurointi riittää, kun istunto jo tallentaa etuliitteet; palveluntarjoajaan päin olevalle istunnolle tehtävä kova nollaus työaikana on päätös, jonka jonkun muun pitäisi tehdä. Junosissa vastaavat tarkistukset lukevat VRF-kohtaisen taulun ja VPN-taulun suoraan, ja palautus on commitin aikainen paluu eikä komentokohtainen peruutus, joten tallenna kokoonpanon ero ennen aloittamista.

Lopeta samoilla kolmella komennolla, joilla aloitit, samassa järjestyksessä, ja tallenna niiden tuloste aikaleimalla. Tiketti, joka sanoo, että RT oli väärä ja nyt se on oikea, ei ole uudelleenkäytettävä; se, joka näyttää etuliitteen VRF:ssä, VPNv4:ssä ja CEF:iin asennettuna, on todiste, johon seuraava henkilö voi verrata. Jos vain kaksi ensimmäistä muuttuivat, et ole saanut muutosta valmiiksi.