[GTER] Quagga - otimização de rotas

[Henrique de Moraes Holschuh]

On 10-04-2012 22:31, Bruno Cabral wrote:
>>> Mas como o quagga poderia saber que nao ha nenhuma outra rota
>>> para aquele prefixo dentro do range maior, por outro peer e com
>>> AS-PATH-LENGTH diferente? Se não houvesse no momento da
>>> sumarização e ela aparecesse depois, qual o comportamento?
>>> Quebrar o range novamente?
>>
>> Mas aí que está, valem todos os critérios de melhor escolha de
>> rota que o BGP já utiliza.
>
> concordo, mas isso irá requerer a presença das rotas DESagregadas
> para a escolha (mais sobre isso abaixo), mesmo que fosse apenas na
> RIB

Para agregação na RIB do kernel (feita pelo Zebra, ou export do
protocolo kernel no BIRD, etc), que equivale mais ou menos à FIB de um
roteador por hardware, você só tem as seguintes informações
(simplificando um pouco: Linux por exemplo permite também definir na
rota atributos como "realm", source IP...)

          (prefixo, gateway)

Se você agrega, baseado apenas nesses atributos, as rotas que envia *pro
kernel*/FIB (e desagrega quando necessário ao instalar uma update que
mudou um gateway ou criou um buraco), o ganho em tamanho da FIB (para
full-routing) pode ser grande.

Mesmo que isso implique em manter cópia da FIB pré-agregação no
Zebra/BIRD, poderia haver algum ganho: a FIB real ou é fast-path e
precisa estar cache-hot o máximo possível, ou está em hardware com
limite de tamanho máximo.  Em ambos os casos, quanto menor a FIB, melhor.

Agora, o kernel pode já estar fazendo alguma agregação no route cache, e
isso pode não ser nada óbvio.  Aí só medindo para saber se há algum ganho.

No quagga, essa agregação seria interna ao Zebra.

-- 
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.