Kassinipedia

Herramientas de filtrado - Troubleshooting

Se lee en 3 min

Herramientas de filtrado - Troubleshooting

Método general (de lo mínimo a lo complejo)

  1. ¿La prefix-list coincide con los prefijos que crees? Revisa ge/le.
  2. ¿El route-map tiene un permit final para el resto, o el deny implícito bloquea todo?
  3. ¿El orden de las secuencias es el correcto?
  4. ¿El filtro está aplicado en la dirección correcta (in/out)?
  5. ¿Suben los hit counts / matches?

Comando base:

Router# show ip prefix-list NOMBRE
Router# show route-map NOMBRE

Caso 1 — La prefix-list no coincide con lo esperado (ge/le mal)

Síntoma: una ruta que debería filtrarse pasa, o al revés.

Causa: la lógica ge/le está mal. Recuerda: longitud_red < ge <= le <= 32, y sin ge/le la coincidencia es exacta.

Diagnóstico:

Router# show ip prefix-list NOMBRE 10.10.10.0/24    ! ¿qué entrada casa?
Router# show ip prefix-list NOMBRE                  ! hit counts

Solución: ajustar el rango. Ejemplos:

! Exactamente 10.0.0.0/8
Router(config)# ip prefix-list P seq 5 permit 10.0.0.0/8
! Cualquier subred de 10.0.0.0/8 hasta /24
Router(config)# ip prefix-list P seq 5 permit 10.0.0.0/8 le 24
! Solo las /32 (hosts) de 10.0.0.0/8
Router(config)# ip prefix-list P seq 5 permit 10.0.0.0/8 ge 32

Caso 2 — El route-map bloquea TODO

Síntoma: tras aplicar el route-map, no pasa ninguna ruta.

Causa: falta un permit final sin match. Al haber solo entradas de filtrado, el deny implícito descarta el resto.

Diagnóstico:

Router# show route-map NOMBRE     ! ¿hay una última secuencia permit sin match?

Solución: agregar una secuencia permit final que deje pasar el resto.

Router(config)# route-map NOMBRE permit 100

Caso 3 — Una entrada deny del route-map no hace lo que espero

Síntoma: una ruta que “denegué” en el route-map se comporta raro.

Causa: en un route-map, deny significa “esta coincidencia NO se procesa por esta herramienta” (no se redistribuye / no se acepta), no “descartar el paquete”. El efecto depende de dónde se aplique (redistribución, distribute-list, BGP).

Diagnóstico:

Router# show route-map NOMBRE
Router# show ip protocols            ! ¿dónde está aplicado?

Solución: ordenar las secuencias para que cada red caiga en la entrada (permit/deny) correcta.

Caso 4 — El orden de las secuencias está mal

Síntoma: una red coincide con una entrada anterior a la que esperabas.

Causa: las prefix-lists y route-maps se evalúan de menor a mayor seq, y se detienen en la primera coincidencia.

Diagnóstico:

Router# show ip prefix-list NOMBRE   ! revisar seq y hit counts

Solución: reordenar (borrar y recrear la entrada con otra seq). Deja huecos (5, 10, 15) para poder insertar después.

Caso 5 — El filtro está en la dirección equivocada (distribute-list)

Síntoma: filtras out pero querías filtrar lo que se aprende (o al revés).

Causa: in filtra lo aprendido; out filtra lo anunciado.

Diagnóstico:

Router# show ip protocols            ! ver in/out de las distribute-list

Solución: aplicar en la dirección correcta.

Router(config)# router ospf 1
Router(config-router)# distribute-list prefix NOMBRE in

Caso 6 — Los hit counts no suben

Síntoma: la lista está aplicada pero su contador no aumenta.

Causas:

  • El filtro no está referenciado por ningún protocolo/route-map.
  • El protocolo que debía usarlo está en pausa/no configurado.

Diagnóstico:

Router# show ip prefix-list NOMBRE
Router# show ip protocols

Solución: referenciar la prefix-list desde un route-map o distribute-list y aplicarla al protocolo.

Recuerda el orden: valida la lógica ge/le de la prefix-list, incluye siempre un permit final en el route-map para el resto, cuida el orden de las seq (primera coincidencia gana), y aplica el filtro en la dirección correcta (in/out). Para ver qué casa con un prefijo, usa show ip prefix-list NOMBRE <red>/<long>.

Vista Gráfica

Retroenlaces