[GTER] BGP: Ajuda com filtro de prefixo por origem básico (nem tanto) no Quagga

Sat Aug 14 15:42:06 -03 2021

Pessoal, obrigado a todos pelo feedback. FUNCIONOU !!!

Motivo de não funcionar antes: eu estava fazendo uma configuração que o
Quagga não suporta. Na verdade gostaria de saber de vocês se eu fiz uma
configuração sabidamente não suportada pelo Quagga (não encontrei
informação sobre isso), se errei no conceito, se é bug do Quagga (versão
1.4.2) ou outra limitação qualquer.

A maioria das sugestões (Fabiano, Evandro, Edinilson e Danton) seguiam na
linha de usar "route-map" com "as-path" e "ip prefix-list". Essa era a
abordagem que eu estava usando desde o início, a não ser pelo fato de que
eu estava usando "access-list" (IP zebra access-list) e não "ip
prefix-list". Isso fez toda diferença no final. O Rubens até sugeriu usar
"goto" no route-map, mas na abordagem que eu estava usando também não
resolveu.

Vejam um exemplo do que eu estava fazendo e o problema que isso gerou:

Configuração do AS 65001:

# permitir apenas o prefix 30.0.0.0/24 e bloquear qualquer outro prefixo

*access-list AL permit 30.0.0.0/24 <http://30.0.0.0/24>
exact-matchaccess-list AL deny any*

# permitir que apenas paths que tenham o AS 65003 como origem

*ip as-path access-list AP permit _65003$ip as-path access-list AP deny .**
# incluindo o as-path e access-list no route-map (deve fazer match nas duas
rules para aceitar o anúncio BGP)

*route-map RM permit 1match ip address ALmatch as-path AP*
# configurando o route-map no "in" com o peer

*router bgp 65001neighbor 1.0.2.165 route-map RM in*

Até aí tudo bem, isso funciona, porém no meu ambiente eu reconfiguro as
ACLs em tempo de execução, incluindo e excluindo novos prefixos com
"permit" conforme a rede vai mudando. Para isso, eu estava fazendo assim:

*no access-list AL deny any*                                     # tirando
a regra de cleanup da ACL
*access-list AL permit 20.0.0.0/24 <http://20.0.0.0/24> exact-match*
 # incluindo o novo prefixo permitido
*access-list AL deny any*                                          #
forçando o cleanup novamente

E imaginava que este procedimento mudaria minha ACL disso:

*access-list AL permit 30.0.0.0/24 <http://30.0.0.0/24>
exact-matchaccess-list AL deny any*
para isso:

*access-list AL permit 30.0.0.0/24 <http://30.0.0.0/24>
exact-matchaccess-list AL permit 20.0.0.0/24 <http://20.0.0.0/24>
exact-matchaccess-list AL deny any*
O que eu queria era só excluir a regra de cleanup, incluir o novo prefixo
com permit e fechar com cleanup novamente.

Porém, para minha surpresa o Quagga não suportou esse procedimento. Até
lembrei de quando trabalhava com Cisco quase 20 anos atrás, em que não era
possível editar standard ACLs... você tinha que apagar a ACL e criar ela
inteira novamente (não sei se isso mudou).

Ao executar o comando "no access-list AL deny any", apesar de eu ter
informado uma linha específica daquela ACL, ele entendeu como se eu
estivesse apagando a ACL inteira. Não imaginei que o Quagga faria isso, já
que estou trabalhando com IP Zebra access-list, e não standard access-list.
O pior é que ele mantém as linhas da ACL na configuração (a ACL aparece no
"show run"), mas o router passa a não enxergar mais esta configuração como
válida (a ACL não aparece no comando "show ip access-list"). Resumindo, a
config está lá, mas o Quagga desconsidera. Pior ainda é que ela fica com um
identificador "(null)" e você nem consegue mais apagar a ACL da config.

A partir desse problema o route-map fica bagunçado, pois ele tem a
configuração de match na ACL, mas a ACL não existe no router, então o
comportamento do filtro muda completamente.

Resumindo, para resolver minha necessidade, segui fielmente a sugestão de
vocês e estou usando ip prefix-list (ele suporta edição). Exemplo:

Configuração do AS 65001:

# permitir apenas o prefix 30.0.0.0/24 e bloquear qualquer outro prefixo

*ip prefix-list PL permit 30.0.0.0/24 <http://30.0.0.0/24>ip prefix-list PL
deny any*

# permitir que apenas paths que tenham o AS 65003 como origem

*ip as-path access-list AP permit _65003$ip as-path access-list AP deny .**
# incluindo o as-path e access-list no route-map (deve fazer match nas duas
condições para aceitar o anúncio BGP)

*route-map RM permit 1match ip address prefix-list PLmatch as-path AP*
# configurando o route-map no "in" com o peer

*router bgp 65001neighbor 1.0.2.165 route-map RM in*

Assim consigo editar normalmente o ip prefix-list do meu filtro para
incluir novos prefixos no permit da seguinte forma:

*no ip prefix-list PL deny any # tirando a regra de cleanup do
prefix-listip prefix-list PL permit 20.0.0.0/24 <http://20.0.0.0/24> #
incluindo o novo prefixo permitidoip prefix-list PL deny any # forçando o
cleanup novamente*

Obrigado a todos pela ajuda.

Emerson

Em qui., 12 de ago. de 2021 às 09:22, Edinilson J. Santos <
edinilson at atinet.com.br> escreveu:

> Experimente:
>
>
> neighbor IP-DO-SEU-NEIGHBOR route-map valida_path_in in
>
>
> ip as-path access-list VALIDAPATH permit _65001_ _65002_ _65003_
> ip as-path access-list VALIDAPATH deny .*
> ip prefix-list MEUPREFIXO seq 5 permit 200.200.200.0/24
>
> route-map valida_path_in permit 5
>   description VERIFICA PATH CORRETO
>   match as-path VALIDAPATH
>   match ip address prefix-list MEUPREFIXO
>
> Obs: Os números das regras e route-maps são exemplos, precisa ajustar para
> o seu ambiente aí
>
> Edinilson
>
> Em 11/08/2021 22:42, Fabiano Roberto Linhares escreveu:
> > Opa boa noite.
> >
> > Tentou algo do tipo ?
> >
> > ip as-path access-list 1 permit 65001 65002 65003
> > ip prefix-list FILTRO seq 5 permit 200.200.200.0/24
> >
> > route-map FILTRA deny 5
> > match ip address prefix-list FILTRO
> > match as-path 1
> >
> >
> > []´s
> >
> > Fabiano
> >
> >
> > Em qua., 11 de ago. de 2021 às 22:26, Emerson Barea <
> emerson.barea at gmail.com>
> > escreveu:
> >
> >> Olá pessoal, boa noite.
> >>
> >> O que posso fazer para que meu router BGP verifique e valide se o path
> de
> >> um prefixo é o esperado? É como se eu recebesse o anúncio do prefixo
> >> 200.200.200.0/24 e só aceitasse ele se o path for 65001 -- 65002 --
> 65003.
> >> Qualquer outro path para esse prefixo deve ser considerado como anúncio
> >> inválido e desconsiderado.
> >>
> >> O router é um Quagga e não posso usar BGP Origin Validation. Só posso
> usar
> >> route maps, distribute filters, AS Path filter, prefix filter e ACLs.
> >>
> >> Não consigo imaginar uma forma de fazer isso, pois preciso juntar a
> >> verificação de prefixo e as-path na mesma rule. Alguém pode me dar uma
> >> dica?
> >>
> >> Emerson
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>