Junos-exportbeleid: de naam is niet de matchvoorwaarde

Iemand noemde een beleid EXPORT-STATIC, hing het aan en vraagt zich nu af waarom een prefix uit de VPN-routinginstantie nooit de verre kant bereikt. De naam heeft geen invloed op de selectie. Een beleid is een definitie plus een aanhechting, en wat het exporteert wordt bepaald door de matchvoorwaarden, de geordende termen en de context die het gebruikt. Lees die drie in die volgorde, en het raadsel valt meestal terug tot één term die nooit matchte.

De naam is een label, geen voorwaarde

Junos interpreteert beleidsnamen niet. Een beleid dat je redelijkerwijs statische export zou noemen, kan overeenkomen met het protocol static, of het kan overeenkomen met een adresprefix, of het kan nergens op passen en alles doorlaten wat langskomt. Het label is documentatie geschreven door degene die het aanmaakte, en het is precies zo betrouwbaar als diens geheugen over de bedoeling.

Behandel een verrassend exportresultaat als een verzoek om de definitie te lezen, niet als bewijs dat de aanhechting stuk is. Lees de definitie en laat die het label tegenspreken.

Vind de aanhechting vóór de termen

Een correcte definitie die op de verkeerde plek is aangehangen, verandert een andere uitwisseling. Stel vast welke routinginstantie, welk protocol en welke buur of groep daadwerkelijk naar het beleid verwijzen, want een beleid dat onder de ene BGP-groep hangt, beïnvloedt een andere niet, en een beleid dat aan de instantie hangt, geldt niet noodzakelijk voor elk protocol erin. Junos onderscheidt deze niveaus, en een ontbrekende export op groepsniveau komt vaak voor wanneer de bedoeling op instantieniveau is uitgedrukt.

Schrijf het aanhechtingspad op voordat je één term leest. De helft van dit onderzoek eindigt daar, met de definitie onaangeroerd en de exportopdracht verplaatst. Noteer het verschil in het changelog zodat niemand het als fout terugdraait.

Termen worden in volgorde geëvalueerd, en de eerste beslissing wint

Termen lopen van de eerste naar de laatste, en een term die accepteert of verwerpt is een beëindigende beslissing. Een latere term die op de bedoelde uitzondering lijkt, loopt nooit als een eerdere term al het lot van de route heeft beslist, waardoor een beleid van boven naar beneden correct kan lezen en zich toch tegen de bedoeling kan gedragen. Controleer de volgorde tegen de route die je belangrijk vindt, niet tegen de volgorde waarin de termen zijn getypt.

Een term die zijn actie weglaat, beëindigt niet; de evaluatie gaat verder naar de volgende term, en de uiteindelijke uitkomst hangt af van wat volgt en van de geldende standaard. Dat is een werkelijk nuttige constructie en een betrouwbare bron van verrassing wanneer het onbedoeld is.

Een voorbeeld dat alleen statische routes exporteert, met de aanhechting op de groep:

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

Een prefix die via OSPF is geleerd in plaats van als statische route geconfigureerd, faalt de match en valt door, hoe het beleid ook heet.

Acties wijzigen een kopie, niet de oorspronkelijke route

Beleidsacties werken op de route zoals die voor die aankondiging wordt geëvalueerd, dus op een kopie en niet op het item in de routingtabel. Een lokale show route kan daarom een route met één set attributen tonen terwijl de geëxporteerde versie andere draagt, en het origineel wordt niet door de export herschreven. Dat onderscheid verklaart verschillende discussies over wiens uitvoer correct is: beide zijn het, en ze beschrijven verschillende objecten. Zeg welke weergave je citeert wanneer twee ingenieurs het oneens zijn over een routeattribuut.

Accepteren en verwerpen zijn beëindigende beslissingen; attribuutwijzigingen zijn dat niet noodzakelijk. Ga er niet van uit dat het instellen van een community het beleid beëindigt, want de evaluatie kan doorgaan in termen die je niet hebt overwogen.

Vergelijk de geadverteerde weergave met de verwachting

Gebruik de protocolspecifieke weergave op de werkelijke peer, zoals show route advertising-protocol bgp 192.0.2.1, en lees die in de juiste routinginstantiecontext. Een route die in een VRF aanwezig is, is niet noodzakelijk door het exportbeleid gegaan, en een route die in de geadverteerde uitvoer verschijnt, is niet noodzakelijk door de verre kant geaccepteerd. Dat zijn drie afzonderlijke toestanden en ze falen verschillend.

Accepteer het ontwerp met één prefix die geadverteerd moet worden en één die lokaal moet blijven. Dat geeft het beleid een contract dat je kunt testen, en het vermijdt de alternatieve oplossing om de export te verbreden totdat eindelijk één genoemde route verschijnt.