[GTER] Combinação mais estavel para usar Quagga: CentOS ou Ubunto?

[Lista]

A questão que coloquei, não é sobre zona de conforto, e digo mais quem está
na area de T.I, e fica na zona de conforto, me desculpe está no lugar
errado.

Agora sim defendo a visão, de que se o cara manja mais de linux, por que
ele vai arriscar a rede dele no primeiro momento sendo que ele pode fazer
isso de maneira gradual, e sim migrando para BSD conforme ele se sentir
seguro em migrar.

Bom mas enfim, já estamos mudando o assunto da thread.

@Kalil,

A pergunta é você domina de BSD? Se sim vai sem medo, agora se não vai de
linux e faça a combinação perfeita de hardware + s.o, que isso vai lhe
garantir uma boa performance e estabilidade.
Entretanto um dos grandes causadores de problemas é quando se deixa NAT
habilitado no kernel, ou seja, remova isso da sua borda.


Em 19 de janeiro de 2015 08:41, Antonio Modesto <modesto at isimples.com.br>
escreveu:

>
>
> On 2015-01-16 9:10 pm, Evandro Nunes wrote:
>
> >>> Evandro, Não sei
> qual foi a última vez que você utilizou o
> >> Quagga, mas acho que está
> exagerando um pouco com relação ao Quagga, pelo menos com relação às
> versões atuais. Utilizamos o Quagga + FreeBSD ha mais de um ano e até
> hoje não sofremos com nenhum bug ou travamento.
> >
> > sempre que sofri
> com os bugs mais sérios, era linux ou BSDRP.
> > quando fui pra freebsd ja
> foi openbgp mas com bsdrp hoje mesmo tive 2
> > problemas.
> > mas mesmo com
> bsd vamos a lista de problemas só entre ontem e hoje:
> >
> > 1) acabei de
> ter que dar um cease em um anuncio vindo da Intelig porque
> > existiam
> "rotas presas".
> > 2) outro problema, em uma sessão com um cisco, ficou
> variando de OPEN pra
> > IDLE, um cease e tudo funcionou.
> > 3) uma rota
> com um AS de 4-byte fechando com 23456 com um cisco velho,
> > sessão
> estava de pe por semanas mas caiu, ao voltar parou de aceitar 23456
> > no
> OPEN, dizia AS inaceitável. reload, cease, tudo de direito foi feito
> mas
> > só voltou a funcionar quando matei o daemon e reiniciei. ou seja
> sem motivo
> > pra parar. sem motivo pra voltar com restart do daemon mas
> não voltar com
> > reload ou cease. só pode ser bug, por deus né rsss.
> >
>
> > todos esses erros foram em um bsdrp 1.52, ou seja quagga 0.99.22 e
> freebsd
> > 10-stable
> > sei que tem bsdrp 1.53 e 1.54 mas nesse escritório
> não tive a oportunidade
> > de migrar.
> > quando migrar não será pra outra
> coisa que não openbgp.
> >
> > infelizmente não é o caso de exageros nem
> experiência passada com algo
> > velho.
> > o trauma prévio persiste. meu
> quagga sempre da zebra (kkk acho que gostei
> > do trocadilho infame).
> >
>
> > o que noto claramente é que quagga sobre freebsd é muito mais estável
> no
> > que diz respeito entre interações RIB e FIB, por exemplo ter rota
> na RIB
> > mas não ir pra FIB ou continuar na FIB mesmo quando a rota já
> não existe
> > mais na RIB foram comportamentos que só tive em linux e
> nunca em freebsd.
> > ja outros bugs, estão ai.. (ou pelo menos estão
> aqui).
> >
> > <maldade>
> > vai me dizer que voce nunca deu um restart, um
> cease, sem razão de ser mas
> > depois de dar algo que não funcionava com
> reload voltou a funcionar no
> > quagga? rss se isso nunca aconteceu com
> você duvido que seja quagga kkkk
> > </maldade>
> >
> > Já tive um problema
> com consumo de cpu quando alterava um filtro em específico, mas desse
> jeito que você falou, nunca. Você não está se confundindo com o RouterOS
> não? hehehe (0.99.22.3)
> >
> >> Tudo bem que nosso cenário não é complexo,
> somos trânsito de alguns ASes e possuímos peering com alguns upstreams e
> PTT, nada demais. Outra coisa, realizei alguns testes com o Quagga, Bird
> e OpenBGPD que se baseava em receber uma tabela de rotas full (500K+),
> aplicar alguns filtros e injetar as rotas no kernel (FreeBSD). O consumo
> de cpu do bird se mostrou muito inferior ao OpenBGPD e ao Quagga,
> inserindo as rotas na FIB em tempo bastante aceitável, pelo menos para
> esse cenário.
> >
> > pois é.
> > ou seja comportamento exatamente oposto do
> que o lucas teve.
> > eu também sempre notei o bird mais rápido e mais
> eficiente em termos de cpu.
> > sem reclamação nesse sentido.
> > --
> > gter
> list https://eng.registro.br/mailman/listinfo/gter [1]
>
> --
>
>
>
>
> Links:
> ------
> [1] https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>