pull-filter sammenligner tekst, ikke subnett: les det som et prefiks

Hensikten var å droppe én dyttet rute. Etter endringen mangler et annet rutealternativ, eller klienten kobler til på nytt i en løkke. Begge utfallene kommer av å lese filteret som en subnettregel mens det sammenligner tekst. Klienten sjekker om et dyttet alternativ begynner med tegnene du oppga, og ingen adresselogikk er involvert på noe tidspunkt.

Hva filteret faktisk sammenligner

Hvert dyttet alternativ kommer som en linje bygget av et navn og argumentene dets. Filteret sammenligner tegnene dine med starten på den linjen, før noen adresse tolkes og før noen rute installeres. Derfor fanger en regel skrevet for et navn hvert alternativ som begynner med de bokstavene, ikke bare det du så på. Det er derfor et filter kan se riktig ut isolert og likevel fjerne noe urelatert.

En streng som ser ut som et nettverksområde, er fortsatt bare tegn. Den velger ikke noe prefiks, gjør ingen aritmetikk på nettverksbiter og kan ikke uttrykke et sett med mål. Når en slik regel ser ut til å virke og senere stopper, har den dyttede teksten vanligvis endret form.

Én plass endrer treffsettet

Det samme alternativnavnet med og uten en avsluttende skilletegn velger forskjellige linjer. Uten skilletegnet holder treffet seg åpent, mens alternativnavnet med det må slutte nøyaktig der før argumentene begynner.

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

Den åpne formen fanger også alternativer som bare begynner med de samme bokstavene, og det er slik urelatert ruteatferd forsvinner sammen med ruten du ville droppe. Kopier den dyttede linjen fra loggen før du skriver filteret. Hold en uendret kopi av profilen ved siden av den redigerte, fordi en bred treff er lettere å reversere fra en fil enn fra hukommelsen.

Rekkefølge og handling gir forskjellige symptomer

Regler vurderes i rekkefølge og det første treffet avgjør utfallet, så en bred regel plassert tidlig gjør hver senere spesifikk regel utilgjengelig. Handlingen endrer også feilen: å ignorere et treff dropper alternativet og økten fortsetter, mens avvisning reiser en feil som starter tilkoblingen på nytt. En linje som dyttes gjentatte ganger kombinert med avvisningshandlingen gir derfor en gjenoppkoblingssyklus. Den syklusen er lett å lese som en nettverksfeil, og logglinjen som navngir det samsvarende alternativet er det som skiller de to.

Noter hvilken linje som samsvarte og hvilken handling som kjørte. En droppet rute og en omstartssyklus krever forskjellige reparasjoner, og notatet bør si hvilken av dem som skjedde i stedet for å la begge stå åpne.

Sjekk hva verten installerte

Les de anvendte rutene etter gjenoppkobling og test målet du ville beholde så vel som det du ville fjerne. Å droppe en dyttet rute gir ingen erstatning, så en ressurs kan bli utilgjengelig via en annen vei mens den uønskede ruten er borte. Hvis et navn nå løses et annet sted, sjekk om det dyttede resolver-alternativet ble fanget av det samme brede prefikset. En endring som består testen du kjørte og feiler den du mente, er det normale utfallet her.

Behold den forskjellen i saken: ruten du fjernet, ruten du forventet å beholde, og hva tabellen viser nå. Den neste endringen vil bli vurdert mot den registreringen.

Ikke behandle det som en tillitsgrense

Et filter over tekst er en konfigurasjonsbekvemmelighet, ikke en kontroll mot en server du ikke stoler på. Bare formateringsvariasjoner beseirer det, og derfor begrenser håndboken den påstanden. Når serveren tilhører organisasjonen din, er det klarere å rette dyttetpolicyen enn å samle lokale unntak.

Skriv ned hvorfor det lokale filteret i det hele tatt finnes, slik at neste person kan avgjøre om det fortsatt trengs. Filtre hoper seg opp lenge etter at grunnen er borte.