pull-filter matcher tekst, ikke subnets: læs den som et præfiks

Hensigten var at fjerne én skubbet rute. Efter ændringen mangler der en anden ruteindstilling, eller klienten genopretter forbindelsen i en løkke. Begge udfald kommer af, at filteret læses som en subnetregel, mens det sammenligner tekst. Klienten kontrollerer, om en skubbet indstilling begynder med de tegn, du angav, og der indgår ingen adresselogik på noget tidspunkt.

Hvad filteret faktisk sammenligner

Hver skubbet indstilling ankommer som en linje bygget af et navn og dets argumenter. Filteret sammenligner dine tegn med starten af den linje, før nogen adresse parses, og før nogen rute installeres. Derfor fanger en regel skrevet til et navn enhver indstilling, der begynder med de bogstaver, ikke kun den, du kiggede på. Det er derfor, et filter kan se korrekt ud isoleret og alligevel fjerne noget irrelevant.

En streng, der ligner et netværksområde, er stadig bare tegn. Den vælger intet præfiks, udfører ingen aritmetik på netværksbits og kan ikke udtrykke et sæt af destinationer. Når en sådan regel ser ud til at virke og senere stopper, har den skubbede tekst normalt ændret form.

Ét mellemrum ændrer matchsættet

Det samme indstillingsnavn med og uden en afsluttende separator vælger forskellige linjer. Uden separatoren forbliver matchet åbent, mens indstillingsnavnet med separatoren skal slutte præcis der, før argumenterne begynder.

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

Den åbne form fanger også indstillinger, der blot begynder med de samme bogstaver, og det er sådan urelateret ruteadfærd forsvinder sammen med den rute, du ville fjerne. Kopiér den skubbede linje fra loggen, før du skriver filteret. Opbevar en uændret kopi af profilen ved siden af den redigerede, fordi en bred match er lettere at rulle tilbage fra en fil end fra hukommelsen.

Rækkefølge og handling giver forskellige symptomer

Regler evalueres i rækkefølge, og det første match afgør udfaldet, så en bred regel placeret tidligt gør enhver senere specifik regel uopnåelig. Handlingen ændrer også fejlen: at ignorere et match dropper indstillingen, og sessionen fortsætter, mens afvisning rejser en fejl, der genstarter forbindelsen. En linje, der skubbes gentagne gange, kombineret med afvisningshandlingen, giver derfor en genopretningscyklus. Den cyklus er let at læse som en netværksfejl, og loglinjen, der navngiver den matchede indstilling, er det, der skiller de to.

Notér, hvilken linje der matchede, og hvilken handling der kørte. En droppet rute og en genstartscyklus kræver forskellige reparationer, og noten skal sige, hvilken af dem der skete, i stedet for at lade begge stå åbne.

Kontroller, hvad værten installerede

Læs de anvendte ruter efter genoprettelsen, og test den destination, du ville bevare, såvel som den, du ville fjerne. At droppe en skubbet rute giver ingen erstatning, så en ressource kan blive uopnåelig ad en anden vej, mens den uønskede rute er væk. Hvis et navn nu opløses andre steder, så kontroller, om den skubbede resolver-indstilling blev fanget af det samme brede præfiks. En ændring, der består den test, du kørte, og fejler den, du havde til hensigt, er det normale udfald her.

Behold den forskel i sagen: ruten, du fjernede, ruten, du forventede at beholde, og hvad tabellen viser nu. Den næste ændring vil blive vurderet mod den registrering.

Behandl det ikke som en tillidsgrænse

Et filter over tekst er en konfigurationsbekvemmelighed, ikke en kontrol mod en server, du ikke stoler på. Blot formateringsvariationer besejrer det, og derfor begrænser manualen den påstand. Når serveren tilhører din organisation, er det klarere at rette skubbepolitikken end at samle lokale undtagelser.

Skriv ned, hvorfor det lokale filter overhovedet findes, så den næste person kan afgøre, om det stadig er nødvendigt. Filtre hober sig op længe efter, at grunden til dem er væk.