Lista De Prefixos

O que é e quando usar

Uma lista de prefixos é uma estrutura de filtragem que permite admitir ou negar faixas de endereçamento com base no comprimento do prefixo. Ao contrário das access lists tradicionais, que só olham o endereço em si, a lista de prefixos também valida o mask length. Isso muda bastante a forma como você configura redistribuição, route-maps e distribuição de rotas em protocolos como OSPF, EIGRP e BGP. No Cisco IOS, a sintaxe básica segue esse padrão: ip prefix-list NOME seq SEQ permit NETWORK/MASK ge GE le LE. Os parâmetros ge e le definem o intervalo de comprimentos de máscara permitidos. Se você não especificar ge e le, o filtro só aceita exatamente aquele prefixo com aquela máscara. Parece simples, mas a maior parte dos erros que vejo em produção vem justamente dessa confusão.

Como montar uma lista de prefixos na prática

Vou mostrar com um exemplo real que usei na semana passada. Tinha um cliente que precisava redistribuir rotas de um link ponto a ponto /30 dentro do OSPF, mas queria descartar todos os /30 de outros links e manter apenas as /24 e /16 da rede principal. A solução foi uma lista assim: ip prefix-list REDIST-ROTAS seq 5 permit 10.0.0.0/16 ge 16 le 16
ip prefix-list REDIST-ROTAS seq 10 permit 172.16.0.0/12 ge 12 le 12
ip prefix-list REDIST-ROTAS seq 15 deny 0.0.0.0/0 ge 30 le 30
ip prefix-list REDIST-ROTAS seq 20 permit 0.0.0.0/0 le 32

A linha 15 é o truque. Ela rejeita explicitamente qualquer rota com máscara /30 antes da captura final. Sem ela, o deny implícito no final da lista pegaria essas rotas também, mas o comportamento ficava menos explícito e mais difícil de depurar. Colocar a negação de forma clara ajuda muito quando alguém vai revisar a configuração meses depois. Depois de criar a lista, você a aplica no contexto certo. Em OSPF, usa-se com o comando distribute-list prefix NOME out dentro do processo de roteamento. Em BGP, usa-se com neighbor X.X.X.X prefix-list NOME out/in. A diferença é que no BGP a lista de prefixos é aplicada por vizinho, enquanto no OSPF é aplicada ao processo inteiro por direção.

Pegadinhas que ninguém conta

A primeira coisa que causa confusão é a hierarquia de avaliação. A lista de prefixos é processada sequencialmente, na ordem das sequências, e para no primeiro match. Se você colocar uma permissão genérica antes de uma específica, a específica nunca vai ser avaliada. Isso é igual a access-list, mas muita gente esquece porque acha que o prefixo com máscara mais longa sempre "vence". Não vence. Ordem importa. Outro ponto: o comando ge 0 e le 32 são defaults se você não declarar nada. Ou seja, permit 10.0.0.0/8 sozinho é equivalente a permit 10.0.0.0/8 ge 0 le 32. Ele permite qualquer rota que tenha o bits mais significativos correspondentes ao /8, independentemente do mask length. Muita gente acha que isso limita a /8 exatamente, e acaba deixando entrar rotas de /24, /32 e tudo mais que começar com 10.

Quando foquei em como fazer uma lista de prefixos eficiente, percebi que a maioria dos administradores subestima o impacto do deny implícito. Todo prefix-list tem um deny any no final, equivalente a deny 0.0.0.0/0 le 32. Se você precisa permitir algo que não se encaixa nas linhas explícitas, tem que adicionar uma linha de permit no final. Caso contrário, a rota é silently dropped e você gasta duas horas olhando show commands sem entender por que a rota não aparece. Um detalhe técnico importante: a comparação de bits é feita do mais significativo para o menos significativo, conforme a máscara declarada. Se você colocar permit 192.168.0.0/16 ge 24 le 24, o dispositivo verifica se os primeiros 16 bits correspondem a 192.168 e se o comprimento da rota é exatamente 24. Rotas como 192.168.1.0/24 são permitidas. Rotas como 10.0.0.0/24 são negadas. Isso é óbvio para quem lê a documentação, mas na prática as pessoas costumam misturar o endereço base com o ge/le e acabam criando filtros que permitem coisas que não deveriam.

Dica rápida de depuração

Use show ip prefix-list NOME detail para ver quantos prefixos correspondem a cada entrada. O comando show route-map NOME hit-contents também mostra quantas vezes cada sequência foi acionada. Isso é útil para saber se uma lista está funcionando como esperado ou se há rotas que estão caindo no deny implícito sem que você perceba.

Limitações e onde ela não serve

Lista de prefixos não substitui route-map. Ela não altera métrica, não muda community, não seta weight ou local-preference. Se você precisa modificar atributos durante a redistribuição, tem que usar route-map com match prefix-list. A diferença é que route-map permite múltiplos matches e ações, enquanto prefix-list é apenas um filtro binário de permit/deny. Em BGP, existe um limite prático de cerca de 2000 entradas por prefix-list em alguns platforms mais antigos. Em routers mais novos, esse limite sobe para 8000 ou mais. Antes de confiar que sua lista enorme vai rodar, verifique a documentação do hardware específico. Colocar 5000 linhas em um router que suporta apenas 2000 pode fazer o processo de roteamento travar ou recusar a configuração silenciosamente.

Também não use lista de prefixos quando precisar de correspondência baseada em AS-path ou community. Nesse caso, use route-map com match as-path ou match community. Misturar os dois tipos de filtro na mesma configuração só gera confusão e dificulta a manutenção. Se o seu cenário envolve filtragem muito dinâmica, com regras que mudam frequentemente, considere usar um script Python ou Ansible para gerar a lista automaticamente. Manutenção manual de listas grandes com dezenas de entradas leva tempo e propicia erro humano. Eu já vi configurar tudo certinho e depois perder três dias porque uma linha foi inserida na ordem errada e uma faixa inteira de rotas caiu no deny implícito.