CE:n RIP-reitistä etäiseen VRF:ään: missä vienti tapahtuu

RIPv2-päivitys saapuu palveluntarjoajan reunaan, laskeutuu VRF-reititystauluun ja pysähtyy siihen, ellei jokin vie sitä nimenomaisesti. Kolme päätöstä tapahtuu peräkkäin, ja jokainen voi hylätä prefiksin omasta syystään. Juuri niiden lukeminen yhtenä tapahtumana saa ihmiset etsimään väärää laatikkoa, kun etäsivusto ei tavoita verkkoa, jota CE selvästi mainostaa. Seuraa reittiä PE:n läpi, ja järjestys käy ilmeiseksi.

Mitä PE tekee RIP-päivitykselle

PE vastaanottaa päivityksen VRF-rajapinnalla, tarkistaa, että lähde on sallittu naapuri, ja asentaa prefiksin VRF-reititystauluun mainoksesta johdetulla hyppylaskurilla. Tämä taulu on tavallinen reititystaulu, jolla on omat hallinnolliset etäisyytensä ja oma parhaan polun valintansa. Jos CE mainostaa samaa prefiksiä kahdesti eri metriikoilla, tauluun jää vain parempi. Mikään tässä vaiheessa ei liity palveluntarjoajan runkoverkkoon.

Prefiksi on nyt yhden asiakkaan reitityskontekstin sisällä, mikä on kaukana siitä, että se olisi tavoitettavissa missään muualla.

Vienti on käytännön toimi, ei protokollan seuraus

Poistuakseen VRF:stä reitti on uudelleenjaettava MP-BGP-prosessiin, joka kuljettaa VPN-reittejä, ja se tarvitsee laajennetun route target -yhteisön, joka määrittää, mitkä etäiset VRF:t saavat tuoda sen. Arkkitehtuuri RFC 4364 pitää juuri tästä syystä nämä vaihdot erillään CE-PE-protokollasta. RIP:n käyttäminen reunalla ei kerro mitään siitä, mitä palveluntarjoajan verkon tulisi ylittää.

Kirjoita vientisopimus ylös ennen kuin konfiguroit mitään: asiakkaan prefiksit, joiden on oltava tavoitettavissa etäältä, reitit, joiden on pysyttävä paikallisina, ja mahdolliset oletus-, tarkemmat tai jaettujen palvelujen poikkeukset. Vertaa tätä sopimusta todelliseen VRF:ään, älä samannimiseen, joka kuuluu toiselle asiakkaalle.

Tuontipuoli on toinen käytäntö omine route target -arvoineen, ja sopiva vienti yhteensopimattomalla tuonnilla tuottaa prefiksin, joka on olemassa runkoverkossa eikä näy missään etäisessä taulussa.

Uudelleenjakelu ja nimenomainen alkuperä käyttäytyvät eri tavoin

Uudelleenjakelu ottaa reitit, jotka ovat jo VRF-taulussa, ja kopioi ne BGP:hen reittikartan suodattamina. Kartta päättää, mitkä prefiksit kelpaavat ja mitä attribuutteja ne kantavat, ja metriikka on asetettava nimenomaisesti, koska RIP:n hyppylaskurilla ei ole merkitystä BGP-metriikkana. Kaikki asettamatta jäävä periytyy tavalla, joka yleensä yllättää henkilön, joka lukee konfiguraation puoli vuotta myöhemmin.

Keskinäinen uudelleenjakelu on paikka, jossa hiljainen vahinko tapahtuu. BGP:hen viety prefiksi voi palata toisen uudelleenjakelupisteen kautta, ja ilman tageja tai suodattimia reitti värähtelee, kun molemmat taulut näyttävät uskottavilta millä hetkellä tahansa. Suodata reunalla sovellettavien tagien perusteella sen sijaan, että luottaisit topologian estävän paluupolun.

Nimenomainen alkuperä näyttää siistimmältä eikä ole ehdoton. Verkkoilmoitus tarvitsee yleensä vastaavan reitin reititystauluun ennen kuin prefiksi syntyy, joten mainos katoaa heti, kun CE lakkaa mainostamasta sitä. Se on usein haluttu käyttäytyminen, eikä se ole sama kuin staattinen reitti, joka pysyy konfiguroituna ikuisesti. Tarkista alustan todellinen sääntö sen sijaan, että olettaisit jomman kumman käyttäytymisen.

Kummassakin tapauksessa jokaisesta prefiksistä on kysyttävä, mikä aktiivinen lähde tekee siitä kelpaavan ja mitä tapahtuu, kun se lähde katoaa.

Tarkista ketju neljässä paikassa

Katso CE:n mainosta, VRF-reititystaulua, VPN-reittitaulua ja sen route targetia sekä etäisen VRF:n tuontia tässä järjestyksessä. IOS:llä se tarkoittaa CE-naapurin tulostetta, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, ja samaa komentoa etäisellä PE:llä. IOS-XR:ssä vastaava tuloste löytyy komennon show bgp vrf CUSTOMER ipv4 unicast alta. Komentojen nimet eroavat, neljä tarkistuspistettä eivät.

Tarkista prefiksi, joka pitäisi hylätä, yhtä huolellisesti kuin se, jonka pitäisi mennä läpi, koska kaiken salliva käytäntö näyttää identtiseltä oikean kanssa siihen asti, kun ensimmäinen poikkeus saapuu. Tarkkaile sitten peruutusta: sammuta CE-rajapinta ja varmista, että etäinen merkintä katoaa odotetun ajastimen kuluessa sen sijaan että jäisi roikkumaan.

Kirjaa, kuka omistaa minkäkin käytännön. Kun palveluntarjoaja ylläpitää CE:tä, toimitettu käyttäytyminen kuuluu palvelusopimukseen, ja erilainen protokolla tai peruutuskäytäntö hallinnoidussa laitteessa on dokumentointiongelma ennen kuin se on reititysongelma.