[GTER] Quagga - otimização de rotas

[Klaus Schneider]

Pois é, eu não acredito que sumarização seja o caminho, mesmo pq pode
gerar mais um problema:
Um simples update fazer com que toda a arvore tenha que ser
reconstruída, isso demanda muito processador e memória.

Quanto ao Virtual Aggregation, já li alguns textos e vi que alguns não
recomendam para ISPs que fornecem trânsito.

Mas é f***. Já passou das 400k rotas. Até o fim do ano vai estar próximo
das 500k.
Tem gente que nunca leu um manual de boas práticas e anuncia tudo /24
mesmo tendo só um updtream.... aí fica complicado...

Em 11/04/2012 19:10, Diogo Montagner escreveu:
> Eduardo,
>
> acredito que isto nao tenha sido implementado devido a grande demanda
> de recurso computacional para faze-lo.
>
> Quando consideramos um escopo pequeno (poucas rotas), a summarizacao
> pode parecer vantajosa pois reduz o numero de rotas e economiza
> memoria. Porem, quando vamos rodar a mesma sumarizacao em uma tabela
> grande (e.g. Internet IPv4 ou eventualmente a IPv6), a quantidade de
> memoria necessaria para construir a arvore do algortimo para
> sumarizacao serah gigantesca e nao compensarah.
>
> Abs
>
> On 4/12/12, Eduardo Schoedler <listas at esds.com.br> wrote:
>> Em 11 de abril de 2012 13:40, Henrique de Moraes Holschuh <
>> henrique.holschuh at ima.sp.gov.br> escreveu:
>>
>>> On 10-04-2012 18:36, Eduardo Schoedler wrote:
>>>
>>>  Alguém sabe se o Bird, OpenBGPd ou outro fazem esse tipo de
>>>> otimização?
>>>>
>>> BIRD não faz.  Aliás, que eu saiba BIRD não faz (ainda) nem sequer a
>>> agregação que o quagga faz no bgp (atomic-aggregate).  Está listado
>>> como TODO.
>>>
>>>
>> Uma pena que os desenvolvedores não tenham pensado nisso já no design do
>> programa.
>> Agora imagine um cenário de IPv6... que tal ?
>>
>> Eu acredito que seria uma feature bem interessante... ou sou só eu que vejo
>> dessa forma?
>>
>> Abs,
>>
>> --
>> Eduardo Schoedler
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>