[GTER] BGP4 Communities e ASN32

Henrique de Moraes Holschuh henrique.holschuh at ima.sp.gov.br
Tue Mar 1 13:50:59 -03 2011


On 01-03-2011 12:39, Rubens Kuhl wrote:
>>> Ele publica meu AS de 32 bits... o problema é com os filtros...
>>
>> Communities são 16bits:16bits.  Não servem para ASN32, a menos que você
>> trapaceie (e, portanto, arrisque colisões).
>>
>> Claro que tem conserto: RFC 5668.  Mas para isso precisa que os
>> roteadores que tem que processar a extended community implementem este
>> RFC, e que os route-maps/filtros funcionem nesse caso.  Note que é um
>> RFC relativamente recente.
>
> O http://tools.ietf.org/id/draft-rekhter-as4octet-ext-community-01.txt
> é um draft já bem antigo, mas realmente demorou para se tornar RFC.

Aí entra a Juniper "só se for RFC e houver demanda comercial" Networks e 
outros que se valem das mesmas desculpas... se bem que não faço ideia se 
no caso do RFC 5668 a Juniper não se antecipou.

>> Não tenho ideia se houve bom senso por parte dos implementadores de
>> pilha BGP4 de automaticamente implementar busca em comunidades RFC5668
>> sem precisar incluir um novo comando de match.
>
> Quagga já tinha suporte ao draft, deve implementar RFC 5668.

A minha colocação está mais em como _utilizar_ as communities RFC 
5668... o certo seria ser 100% transparente:  Se a configuração informa 
uma community em um filtro ou ação, cujo o primeiro campo requer 32 
bits, usar a RFC 5668.  Se informar um filtro com máscara/wildcard, 
fazer os testes de match tanto nas communities tradicionais quanto nas 
RFC 5668 (precisaria fazer o sign-extend da máscara nesse caso) de cada 
rota.

Ou seja, seria inteiramente transparente para o usuário.

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.



More information about the gter mailing list