pull-filter compară text, nu subrețele: citește-l ca pe un prefix

Intenția era să se renunțe la o rută împinsă. După modificare lipsește o altă opțiune de rutare sau clientul se reconectează în buclă. Ambele rezultate vin din citirea filtrului ca regulă de subrețea, deși el compară text. Clientul verifică dacă o opțiune împinsă începe cu caracterele furnizate, iar în nicio etapă nu este implicată logica adreselor.

Ce compară de fapt filtrul

Fiecare opțiune împinsă sosește ca o linie formată dintr-un nume și argumentele sale. Filtrul compară caracterele tale cu începutul acelei linii, înainte ca vreo adresă să fie analizată și înainte ca vreo rută să fie instalată. De aceea o regulă scrisă pentru un nume prinde fiecare opțiune care începe cu acele litere, nu doar pe cea la care te uitai. Din acest motiv un filtru poate părea corect izolat și totuși poate elimina ceva nelegat.

Un șir care arată ca un interval de rețea rămâne doar caractere. Nu selectează niciun prefix, nu face aritmetică pe biții rețelei și nu poate exprima o mulțime de destinații. Când o astfel de regulă pare să funcționeze și apoi se oprește, textul împins de obicei și-a schimbat forma.

Un spațiu schimbă mulțimea potrivirilor

Același nume de opțiune cu și fără separator final selectează linii diferite. Fără separator potrivirea rămâne deschisă, iar cu el numele opțiunii trebuie să se încheie exact acolo înainte de a începe argumentele.

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

Forma deschisă prinde și opțiuni care doar încep cu aceleași litere, și astfel comportamentul de rutare nelegat dispare împreună cu ruta pe care voiai să o elimini. Copiază linia împinsă din jurnal înainte de a scrie filtrul. Păstrează o copie nemodificată a profilului lângă cea editată, pentru că o potrivire largă se anulează mai ușor dintr-un fișier decât din memorie.

Ordinea și acțiunea produc simptome diferite

Regulile sunt evaluate în ordine și prima potrivire decide rezultatul, așa că o regulă largă plasată devreme face fiecare regulă specifică ulterioară inaccesibilă. Acțiunea schimbă și ea defectul: ignorarea unei potriviri aruncă opțiunea și sesiunea continuă, în timp ce respingerea ridică o eroare care repornește conexiunea. Prin urmare, o linie împinsă repetat împreună cu acțiunea de respingere produce un ciclu de reconectare. Acel ciclu se citește ușor ca defect de rețea, iar linia de jurnal care numește opțiunea potrivită este cea care separă cele două.

Notează ce linie a corespuns și ce acțiune a rulat. O rută eliminată și un ciclu de repornire necesită reparații diferite, iar nota trebuie să spună care dintre ele s-a întâmplat în loc să le lase pe amândouă deschise.

Verifică ce a instalat gazda

Citește rutele aplicate după reconectare și testează destinația pe care voiai să o păstrezi, precum și pe cea pe care voiai să o elimini. Eliminarea unei rute împinse nu oferă niciun substitut, așa că o resursă poate deveni inaccesibilă pe altă cale în timp ce ruta nedorită a dispărut. Dacă un nume se rezolvă acum în altă parte, verifică dacă opțiunea de rezolvare împinsă a fost prinsă de același prefix larg. O modificare care trece testul pe care l-ai rulat și pică pe cel pe care îl aveai în minte este rezultatul normal aici.

Păstrează această diferență în tichet: ruta pe care ai eliminat-o, ruta pe care te așteptai să o păstrezi și ce arată tabelul acum. Următoarea modificare va fi judecată față de acea înregistrare.

Nu îl trata ca pe o graniță de încredere

Un filtru peste text este o comoditate de configurare, nu un control împotriva unui server în care nu ai încredere. Doar variațiile de formatare îl înving, motiv pentru care manualul limitează această afirmație. Când serverul aparține organizației tale, corectarea politicii de împingere este mai clară decât acumularea de excepții locale.

Scrie de ce există filtrul local, astfel încât următoarea persoană să poată decide dacă mai este necesar. Filtrele se acumulează mult după ce motivul a dispărut.