Rakenna EVPN-raja vientikäytännön, älä liitäntöjen ympärille

Yleinen oletus on, että rajalla oleva Layer 2 -liitäntämalli määrää kaiken sen yläpuolella, joten suunnittelu alkaa vPC-parista ja etenee ylöspäin. Yleensä se päättyy vahingossa tehtyihin reitityspäätöksiin. EVPN-raja on ensisijaisesti reititysraja: vuokralaisen reitityskonteksti kohtaa ulkoisen reititysalueen, ja sen rajan yli kulkeva asia on käytäntölause. Valitse reitit, ASN-suhde ja vikapolut ennen kuin kukaan alkaa väitellä port-channels-ratkaisuista. Liitäntämalli seuraa sitten vaatimuksesta sen sijaan että sanelee sen.

Aloita siitä, mikä ylittää rajan

Kirjoita ylös reitit, joiden pitäisi näkyä kummallakin puolella, suunta johon ne kulkevat ja kuka hyväksyy muutoksen siihen luetteloon. Rajalla, joka hyväksyy kaiken ja ilmoittaa kaiken, ei ole käytäntöä, vain kaapeli.

Nimeä sitten vika, jota aiot operoida: yksi uplink alas, yksi border leaf alas tai koko ulkoinen alue saavuttamattomissa. Jokainen vastaus muuttaa sitä, tarvitsetko kaksi riippumatonta naapuria, jaetun Layer 2 -liitännän vai molemmat.

Vasta kun nämä kaksi luetteloa ovat olemassa, liitäntäkysymykseen voi vastata. Sitä ennen jokainen mekanismi näyttää yhtä kelvolliselta. Sen jälkeen useimmat sulkevat itsensä pois. Tässä on koko perustelu tehdä reititystyö ensin.

Vakiinnuta ASN- ja peering-raja

Yksityisten AS-tunnusten fabric tekee peeringin julkisen raja-alueen kanssa eBGP:n kautta, ja kiinnostava osa on käytäntö molemmilla puolilla. Päätä, mitkä prefiksit hyväksytään, mitkä ilmoitetaan ja minkä AS pathin upstream saa.

RFC 6996 varaa ASN-alueen yksityiskäyttöön, eikä näiden ASN-tunnusten pitäisi näkyä globaaleissa ilmoituksissa. Sovella alustan tukemaa poisto- tai suodatuskäytäntöä ja varmista syntyvä ilmoitus sen sijaan että olettaisit laitteen tehneen sen. Tämä vaihe ei myöskään anna sinulle valtuutta ilmoittaa mielivaltaista julkista prefiksiä, se on erillinen keskustelu osoitteen omistajan kanssa.

Konfederaatio tai local-AS-ominaisuus on suunnitteluvalinta tiettyä topologiaa varten. Kumpikaan ei ole pakollinen vain siksi, että fabric ja upstream käyttävät eri ASN-rooleja, ja toisen käyttöönotto ilman vaatimusta lisää liikkuvia osia jokaiseen tulevaan muutokseen.

Layer 3 -uplinkit eivät tarvitse multichassis LAGia

Itsenäiset reititetyt liitännät omine BGP-naapureineen antavat kaksi selvää polkua ja kaksi selvää vika-aluetta. vPC tai muu multichassis LAG palvelee Layer 2 -liitäntävaatimusta, ja se on oikea työkalu, kun sellainen vaatimus on olemassa.

Yleissääntö, että jokaisen rajaparin on käytettävä vPC:tä tai vältettävä sitä, kätkee ehdot, jotka todella ratkaisevat tapauksen. Kysy, mitä liitännän on kuljetettava, ja valitse sitten mekanismi, joka kuljettaa sen vähimmillä jaetuilla vikamuodoilla.

Ensin kirjoittamasi reitityskäytäntö ei muutu, kun liitäntämekanismi muuttuu, mikä on hyvä merkki siitä, että järjestys oli oikea.

Vie vain se, mitä vuokralainen tarvitsee

Vuokralainen voi tarvita oletusreitin, joukon valittuja ulkoisia prefiksejä tai paljon suuremman taulun. Valitse laajuus todellisen välitys- ja ohjaustason kapasiteetin mukaan, ei vanhan internetreittien määrän mukaan, jota kukaan ei ole mitannut uudelleen.

EVPN IP Prefix -reitti, jota yleisesti kutsutaan nimellä Type 5 ja joka on määritelty RFC 9136-dokumentissa, kuljettaa prefiksitietoa overlay-verkossa. Toteutus tarvitsee edelleen vastaavan vienti- ja tuontikäytännön sekä next-hop-selvityksen, joten ulkoisen BGP-reitin vastaanottaminen rajalla ei tarkoita, että jokainen vuokralaisen VRF tuo sen.

Jokainen leaf ei tarvitse täydellistä taulua vain siksi, että raja pitää sitä. Jaa se, mitä vuokralaisen liikenne vaatii, ja anna rajan omistaa loput.

Varmista yksi prefiksi päästä päähän

Valitse edustava ulkoinen prefiksi ja seuraa sitä rajan aiottuun VRF:ään, vientikäytäntöön, vastaanottavan leafin välityskontekstiin ja paluupolkuun vuokralaisen lähteeseen. Prefiksi, joka näkyy yhdessä paikassa eikä seuraavassa, paikantaa virheen heti.

Vahvista, miten next hop selvitetään overlay-verkon kautta, koska reitti, joka on olemassa selvittämättömällä next hopilla, ei välitä mitään. Toista sitten tarkistus uplink-muutoksen jälkeen, koska silloin käytäntö ja next-hop-selvitys eroavat useimmin.

Työjärjestys: luettele rajan ylittävät reitit, sovi ASN-käytännöstä, valitse liitäntä sen todellisen tehtävän mukaan, rajaa vienti vuokralaisittain ja varmista sitten yksi prefiksi ja sen paluupolku.