Bygg EVPN-grensa rundt eksportpolicy, ikkje tilknytingar

Den vanlege føresetnaden er at Layer 2-tilknytingsmodellen ved grensa avgjer alt over henne, så designet startar med eit vPC-par og arbeider oppover. Det endar oftast med rutingsavgjerder som blir tekne ved eit uhell. Ei EVPN-grense er fyrst og fremst ei rutingsgrense: ein leigetakars rutingskontekst møter eit eksternt rutingsdomene, og det som kryssar den lina, er eit policytilsegn. Vel rutene, ASN-tilhøvet og feilvegane før nokon byrjar å krangle om port-channels. Tilknytingsmodellen følgjer deretter av eit krav i staden for å diktere eit.

Byrj med det som kryssar grensa

Skriv ned rutene som skal vere synlege på kvar side, retninga dei går i, og kven som godkjenner ei endring i den lista. Ei grense som godtek alt og annonserer alt, har inga policy, berre ein kabel.

Namngje så feilen du har tenkt å drive med: éin uplink nede, éin border leaf nede, eller heile det eksterne domenet utilgjengeleg. Kvart svar endrar om du treng to uavhengige naboar, ein delt Layer 2-tilknyting, eller begge.

Fyrst etter at desse to listene finst, blir tilknytingsspørsmålet svarande. Før det ser kvar mekanisme like gyldig ut. Etterpå eliminerer dei fleste seg sjølv. Det er heile argumentet for å gjere rutearbeidet fyrst.

Fastset ASN- og peering-grensa

Ein private-AS-fabrikk peeringar vanlegvis med det offentlege grensedomenet over eBGP, og det interessante er policyen på begge sider. Avgjer kva prefiks som blir godtekne, kva som blir annonserte, og kva AS path upstream skal motta.

RFC 6996 reserverer eit ASN-område for privat bruk, og desse ASN-ane skal ikkje førekome i globale annonseringar. Bruk plattformas støtta fjerning- eller filtreringspolicy og verifiser den resulterande annonseringa i staden for å anta at eininga gjorde det. Det trinnet gir deg heller ikkje mynde til å annonsere eit vilkårleg offentleg prefiks, som er ein eigen samtale med adresseigaren.

Ein konføderasjon eller ein local-AS-funksjon er eit designval for ein bestemt topologi. Ingen av dei er obligatoriske berre fordi fabrikken og upstream brukar ulike ASN-roller, og å ta i bruk ein utan kravet legg til bevegelege delar i kvar framtidig endring.

Layer 3-uplinkar treng ikkje multichassis LAG

Uavhengige ruta grensesnitt med eigne BGP-naboar gir to tydelege vegar og to tydelege feildomene. vPC eller ein annan multichassis LAG tener eit Layer 2-tilknytingskrav, og det er rett verktøy når det kravet finst.

Ei generell regel om at kvart grenseepar må bruke vPC, eller må unngå det, skjuler vilkåra som faktisk avgjer saka. Spør kva tilknytinga må bere, og vel så mekanismen som ber det med færrast delte feilmodi.

Rutepolicyen du skreiv fyrst, endrar seg ikkje når tilknytingsmekanismen endrar seg, og det er eit godt teikn på at rekkjefølgja var rett.

Eksporter berre det leigetakaren treng

Ein leigetakar kan trengje ei standardrute, eit sett utvalde eksterne prefiks, eller ein mykje større tabell. Vel det omfanget mot reell videresendings- og kontrollplankapasitet, ikkje mot eit gammalt tal på internett-ruter som ingen har målt på nytt.

EVPN IP Prefix-ruta, vanlegvis kalla Type 5 og definert i RFC 9136ber prefiksinformasjon i overlayet. Implementasjonen treng framleis samsvarande eksport- og importpolicy pluss next-hop-oppslag, så å ta imot ei ekstern BGP-rute ved grensa betyr ikkje at kvar leigetakar-VRF importerer henne.

Ikkje kvar leaf treng den komplette tabellen berre fordi grensa held han. Fordel det leigetakarens trafikk krev, og lat grensa eige resten.

Verifiser eitt prefiks frå ende til ende

Vel eit representativt eksternt prefiks og følg det gjennom den tiltenkte VRF-en til grensa, eksportpolicyen, videresendingskonteksten til den mottakande leafen og returvegen til ein leigetakarkjelde. Eit prefiks som dukkar opp på eitt stad og ikkje på det neste, lokaliserer feilen med ein gong.

Stadfest korleis next hop blir løyst opp gjennom overlayet, for ei rute som er til stades med ein uoppløyst next hop, videresender ingenting. Gjenta så kontrollen etter ei uplink-endring, sidan det er då policy og next-hop-oppslag oftast går frå kvarandre.

Arbeidsrekkjefølgje: list opp kryssrutene, bli samde om ASN-policyen, vel tilknytinga for den faktiske jobben sin, avgrens eksporten per leigetakar, og verifiser så eitt prefiks og returvegen.