pull-filter vergelijkt tekst, geen subnetten: lees het als een prefix

De bedoeling was één gepushte route te laten vallen. Na de wijziging ontbreekt een andere routeringsoptie, of de client maakt in een lus opnieuw verbinding. Beide uitkomsten komen doordat het filter als subnetregel wordt gelezen terwijl het tekst vergelijkt. De client controleert of een gepushte optie begint met de tekens die je hebt opgegeven, en op geen enkel moment is adreslogica betrokken.

Wat het filter werkelijk vergelijkt

Elke gepushte optie komt binnen als een regel van een naam en zijn argumenten. Het filter vergelijkt jouw tekens met het begin van die regel, voordat een adres wordt geparseerd en voordat een route wordt geïnstalleerd. Daarom vangt een regel die voor een naam is geschreven elke optie die met die letters begint, niet alleen degene die je bekeek. Daardoor kan een filter los gezien correct lijken en toch iets ongerelateerds verwijderen.

Een tekenreeks die op een netwerkbereik lijkt, blijft gewoon tekens. Hij selecteert geen prefix, doet geen rekenwerk op netwerkbits en kan geen set bestemmingen uitdrukken. Wanneer zo'n regel lijkt te werken en later stopt, heeft de gepushte tekst meestal van vorm veranderd.

Eén spatie verandert de set treffers

Dezelfde optienaam met en zonder scheidingsteken aan het eind selecteert verschillende regels. Zonder het scheidingsteken blijft de treffer open, met het scheidingsteken moet de optienaam precies daar eindigen voordat de argumenten beginnen.

pull-filter ignore "route"
pull-filter ignore "route "

De open vorm vangt ook opties die alleen met dezelfde letters beginnen, en zo verdwijnt ongerelateerd routeringsgedrag samen met de route die je wilde laten vallen. Kopieer de gepushte regel uit het log voordat je het filter schrijft. Bewaar een ongewijzigde kopie van het profiel naast de bewerkte, want een brede treffer terugdraaien gaat makkelijker vanuit een bestand dan uit het geheugen.

Volgorde en actie geven verschillende symptomen

Regels worden op volgorde beoordeeld en de eerste treffer bepaalt de uitkomst, dus een brede regel die vroeg staat maakt elke latere specifieke regel onbereikbaar. De actie verandert de fout ook: een treffer negeren laat de optie vallen en de sessie gaat door, terwijl weigeren een fout opwerpt die de verbinding herstart. Een regel die herhaald wordt gepusht levert samen met de weigerende actie daarom een herverbindingscyclus op. Die cyclus is makkelijk als netwerkstoring te lezen, en de logregel die de gematchte optie noemt, scheidt de twee.

Noteer welke regel overeenkwam en welke actie liep. Een gevallen route en een herstartcyclus vragen verschillende reparaties, en de notitie moet zeggen welke van de twee gebeurde in plaats van beide open te laten.

Controleer wat de host heeft geïnstalleerd

Lees na het opnieuw verbinden de toegepaste routes en test zowel de bestemming die je wilde behouden als die je wilde verwijderen. Een gepushte route laten vallen levert geen vervanging, dus een resource kan via een andere weg onbereikbaar worden terwijl de ongewenste route weg is. Als een naam nu elders wordt opgelost, controleer dan of de gepushte resolveroptie door dezelfde brede prefix is gevangen. Een wijziging die de test doorstaat die je uitvoerde en de bedoelde test faalt, is hier de normale uitkomst.

Bewaar dat verschil in de ticket: de route die je verwijderde, de route die je hoopte te behouden, en wat de tabel nu laat zien. De volgende wijziging wordt tegen dat verslag beoordeeld.

Behandel het niet als een vertrouwensgrens

Een filter over tekst is een configuratiegemak, geen controle tegen een server die je niet vertrouwt. Alleen al opmaakvariaties verslaan het, en daarom beperkt de handleiding die bewering. Als de server bij jouw organisatie hoort, is het duidelijker om het pushbeleid te corrigeren dan om lokale uitzonderingen te verzamelen.

Schrijf op waarom het lokale filter überhaupt bestaat, zodat de volgende persoon kan beslissen of het nog nodig is. Filters hopen zich lang na het verdwijnen van de reden op.