Junos exportszabályzat: a név nem az egyeztetési feltétel

Valaki EXPORT-STATIC névre keresztelt egy szabályzatot, csatolta, és most azon tűnődik, miért nem ér el soha egy előtag a VPN-útválasztási példányból a távoli végpontig. A névnek nincs hatása a kiválasztásra. A szabályzat egy definíció plusz egy csatolás, és azt, hogy mit exportál, az egyeztetési feltételei, a rendezett feltételei és az őt használó környezet döntik el. Olvassa el ezt a hármat ebben a sorrendben, és a rejtély általában egyetlen feltételre zsugorodik, amely soha nem egyezett.

A név címke, nem feltétel

A Junos nem értelmezi a szabályzatneveket. Egy szabályzat, amelyet ésszerűen statikus exportnak neveznénk, egyezhet a static protokollal, egyezhet egy címelőtaggal, vagy egyezhet semmivel, és elfogadhat mindent, ami átmegy. A címke az általa létrehozó által írt dokumentáció, és pontosan olyan megbízható, mint az illető emlékezete a szándékról.

Kezelje a meglepő exporteredményt a definíció elolvasására vonatkozó kérésként, nem pedig a csatolás hibájának bizonyítékaként. Olvassa el a definíciót, és engedje, hogy ellentmondjon a címkének.

A feltételek előtt találja meg a csatolást

A helyes definíció rossz helyen csatolva más cserét változtat meg. Állapítsa meg, melyik útválasztási példány, protokoll és szomszéd vagy csoport hivatkozik valójában a szabályzatra, mert az egyik BGP-csoport alatt csatolt szabályzat nem hat a másikra, és a példányhoz csatolt szabályzat nem feltétlenül érvényes a benne lévő összes protokollra. A Junos megkülönbözteti ezeket a szinteket, és a csoportszinten hiányzó export gyakori, amikor a szándékot példányszinten fejezték ki.

Írja fel a csatolás útvonalát, mielőtt egyetlen feltételt elolvasna. Ezeknek a vizsgálatoknak a fele ott véget ér, a definíció érintetlenül, az exportutasítás pedig áthelyezve. Jegyezze fel a különbséget a változásnaplóba, hogy senki ne állítsa vissza tévedésként.

A feltételek sorrendben értékelődnek, és az első döntés győz

A feltételek az elsőtől az utolsóig futnak, és az elfogadó vagy elutasító feltétel lezáró döntés. Egy későbbi feltétel, amely a szándékolt kivételnek látszik, soha nem fut le, ha egy korábbi feltétel már eldöntötte az útvonal sorsát, ezért egy szabályzat fentről lefelé helyesen olvasható, és mégis a szándékkal ellentétesen viselkedhet. Ellenőrizze a sorrendet a számára fontos útvonalhoz képest, ne ahhoz képest, ahogy a feltételeket begépelték.

A feltétel, amely elhagyja a műveletét, nem zár le; az értékelés a következő feltétellel folytatódik, és a végső eredmény attól függ, mi következik, és az alkalmazandó alapértelmezéstől. Ez valóban hasznos szerkezet és megbízható meglepetésforrás, ha nem szándékos.

Egy példa, amely csak statikus útvonalakat exportál, a csatolás a csoporton:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Az OSPF-fel tanult, statikus útvonalként nem konfigurált előtag nem felel meg az egyeztetésnek, és kiesik, bárhogy is hívják a szabályzatot.

A műveletek egy másolatot változtatnak meg, nem az eredeti útvonalat

A szabályzat műveletei az útvonalon úgy hatnak, ahogyan az adott hirdetéshez értékelődik, tehát egy másolaton, nem az útválasztási táblázat bejegyzésén. Ezért egy helyi show route mutathat egy útvonalat az egyik attribútumkészlettel, míg az exportált változat másokat hordoz, és az eredetit az export nem írja át. Ez a különbség magyarázza azokat a vitákat, hogy kinek a kimenete helyes: mindkettő az, és különböző objektumokat írnak le. Mondja meg, melyik nézetet idézi, amikor két mérnök vitatkozik egy útvonalattribútumról.

Az elfogadás és az elutasítás lezáró döntések; az attribútumváltozások nem feltétlenül azok. Ne feltételezze, hogy a community beállítása befejezi a szabályzatot, mert az értékelés olyan feltételekbe folytatódhat, amelyeket nem vett figyelembe.

Hasonlítsa össze a meghirdetett nézetet az elvárással

Használja a protokollspecifikus nézetet a tényleges peeren, például show route advertising-protocol bgp 192.0.2.1, és olvassa a megfelelő útválasztási példány környezetében. Egy VRF-ben jelen lévő útvonal nem feltétlenül ment át az exportszabályzaton, és egy útvonal, amely megjelenik a meghirdetett kimenetben, nem feltétlenül lett elfogadva a távoli oldalon. Ez három különálló állapot, és különböző módon hibáznak.

Fogadja el a tervet egy előtaggal, amelyet hirdetni kell, és egy másikkal, amelynek helyinek kell maradnia. Ez szerződést ad a szabályzatnak, amelyet tesztelhet, és elkerüli azt az alternatív javítást, hogy az exportot szélesítik, amíg végre fel nem tűnik egyetlen megnevezett útvonal.