[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