pull-filter compara texto, não sub-redes: leia-o como um prefixo

A intenção era descartar uma rota enviada. Após a alteração falta outra opção de encaminhamento, ou o cliente reconecta em ciclo. Ambos os resultados vêm de ler o filtro como regra de sub-rede quando ele compara texto. O cliente verifica se uma opção enviada começa pelos caracteres que forneceu, e em nenhum momento está envolvida lógica de endereços.

O que o filtro compara realmente

Cada opção enviada chega como uma linha composta por um nome e os seus argumentos. O filtro compara os seus caracteres com o início dessa linha, antes de qualquer endereço ser analisado e antes de qualquer rota ser instalada. Por isso uma regra escrita para um nome apanha todas as opções que começam por essas letras, não apenas aquela que estava a ver. É por isso que um filtro pode parecer correto isoladamente e ainda assim remover algo não relacionado.

Uma cadeia que se parece com um intervalo de rede continua a ser apenas caracteres. Não seleciona nenhum prefixo, não faz aritmética com bits de rede e não consegue expressar um conjunto de destinos. Quando uma regra assim parece funcionar e depois para, o texto enviado normalmente mudou de forma.

Um espaço muda o conjunto de correspondências

O mesmo nome de opção com e sem separador final seleciona linhas diferentes. Sem o separador a correspondência fica aberta, enquanto com ele o nome da opção tem de terminar exatamente ali antes de começarem os argumentos.

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

A forma aberta também apanha opções que apenas começam pelas mesmas letras, e é assim que o comportamento de encaminhamento não relacionado desaparece juntamente com a rota que queria descartar. Copie a linha enviada do registo antes de escrever o filtro. Guarde uma cópia sem alterações do perfil ao lado da editada, porque reverter uma correspondência ampla é mais fácil a partir de um ficheiro do que da memória.

Ordem e ação produzem sintomas diferentes

As regras são avaliadas por ordem e a primeira correspondência decide o resultado, por isso uma regra ampla colocada cedo torna inalcançável qualquer regra específica posterior. A ação também altera a falha: ignorar uma correspondência descarta a opção e a sessão continua, enquanto rejeitar gera um erro que reinicia a ligação. Uma linha enviada repetidamente combinada com a ação de rejeição produz, por isso, um ciclo de reconexão. Esse ciclo lê-se facilmente como falha de rede, e a linha de registo que nomeia a opção correspondida é o que separa os dois casos.

Registe qual linha correspondeu e qual ação foi executada. Uma rota descartada e um ciclo de reinício precisam de reparações diferentes, e a nota deve dizer qual dos dois aconteceu em vez de deixar ambos em aberto.

Verifique o que o anfitrião instalou

Leia as rotas aplicadas depois de reconectar e teste o destino que queria conservar, bem como aquele que queria remover. Descartar uma rota enviada não fornece substituição, por isso um recurso pode ficar inalcançável por outro caminho enquanto a rota indesejada já não está. Se um nome agora é resolvido noutro sítio, verifique se a opção de resolução enviada foi apanhada pelo mesmo prefixo amplo. Uma alteração que passa o teste que executou e falha o que pretendia é o resultado normal aqui.

Guarde essa diferença no ticket: a rota que removeu, a rota que esperava manter e o que a tabela mostra agora. A próxima alteração será julgada contra esse registo.

Não o trate como fronteira de confiança

Um filtro sobre texto é uma comodidade de configuração, não um controlo contra um servidor em que não confia. Só as variações de formatação o derrotam, e é por isso que o manual limita essa afirmação. Quando o servidor pertence à sua organização, corrigir a política de envio é mais claro do que acumular exceções locais.

Escreva porque é que o filtro local existe, para que a próxima pessoa possa decidir se ainda é necessário. Os filtros acumulam-se muito depois de a razão ter desaparecido.