pull-filter compara texto, no subredes: léalo como un prefijo

La intención era descartar una ruta enviada. Tras el cambio falta otra opción de enrutamiento, o el cliente se reconecta en bucle. Ambos resultados vienen de leer el filtro como una regla de subred cuando compara texto. El cliente comprueba si una opción enviada empieza por los caracteres que proporcionó, y en ningún momento interviene lógica de direcciones.

Qué compara realmente el filtro

Cada opción enviada llega como una línea formada por un nombre y sus argumentos. El filtro compara sus caracteres con el inicio de esa línea, antes de que se analice cualquier dirección y antes de que se instale cualquier ruta. Por eso una regla escrita para un nombre captura toda opción que empiece por esas letras, no solo la que estaba mirando. Ese es el motivo de que un filtro pueda parecer correcto de forma aislada y aun así eliminar algo no relacionado.

Una cadena que parece un rango de red sigue siendo solo caracteres. No selecciona ningún prefijo, no hace aritmética con bits de red y no puede expresar un conjunto de destinos. Cuando una regla así parece funcionar y luego deja de hacerlo, el texto enviado normalmente ha cambiado de forma.

Un espacio cambia el conjunto de coincidencias

El mismo nombre de opción con y sin un separador final selecciona líneas distintas. Sin el separador la coincidencia queda abierta, mientras que con él el nombre de la opción tiene que terminar justo ahí antes de que empiecen los argumentos.

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

La forma abierta también captura opciones que solo empiezan por las mismas letras, y así es como el comportamiento de enrutamiento no relacionado desaparece junto con la ruta que quería descartar. Copie la línea enviada del registro antes de escribir el filtro. Guarde una copia sin modificar del perfil junto al editado, porque revertir una coincidencia amplia es más fácil desde un archivo que de memoria.

El orden y la acción producen síntomas distintos

Las reglas se evalúan en orden y la primera coincidencia decide el resultado, así que una regla amplia colocada pronto hace inalcanzable cualquier regla específica posterior. La acción también cambia el fallo: ignorar una coincidencia descarta la opción y la sesión continúa, mientras que rechazar genera un error que reinicia la conexión. Por eso una línea enviada repetidamente combinada con la acción de rechazo produce un ciclo de reconexión. Ese ciclo se lee fácilmente como un fallo de red, y la línea del registro que nombra la opción coincidente es lo que separa ambos casos.

Anote qué línea coincidió y qué acción se ejecutó. Una ruta descartada y un bucle de reinicio necesitan reparaciones distintas, y la nota debe decir cuál de las dos ocurrió en lugar de dejar ambas abiertas.

Compruebe qué instaló el host

Lea las rutas aplicadas tras reconectar y pruebe el destino que quería conservar así como el que quería quitar. Descartar una ruta enviada no aporta ningún reemplazo, así que un recurso puede quedar inalcanzable por otra vía mientras la ruta no deseada ya no está. Si un nombre ahora se resuelve en otro sitio, compruebe si la opción de resolución enviada fue capturada por el mismo prefijo amplio. Un cambio que pasa la prueba que ejecutó y falla la que pretendía es el resultado normal aquí.

Conserve esa diferencia en el ticket: la ruta que quitó, la ruta que esperaba mantener y lo que muestra la tabla ahora. El próximo cambio se juzgará contra ese registro.

No lo trate como un límite de confianza

Un filtro sobre texto es una comodidad de configuración, no un control contra un servidor en el que no confía. Solo las variaciones de formato lo derrotan, y por eso el manual limita esa afirmación. Cuando el servidor pertenece a su organización, corregir la política de envío es más claro que acumular excepciones locales.

Escriba por qué existe el filtro local, para que la siguiente persona pueda decidir si todavía hace falta. Los filtros se acumulan mucho después de que la razón haya desaparecido.