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

[Evandro Nunes]

opa,

2015-01-15 3:57 GMT-02:00 Lucas Willian Bocchi <lucas.bocchi at gmail.com>:

> Bom, vamos por partes:
>
> Dos bugs que você citou,  só enfrentei 2:


sorte sua :-)
ou característica de ambiente, vc eh transito pra mais de 2 ASN e repassa
pra mais de 2ASN?
por observacao esse e o cenario onde os problemas comecam
nao eh um cenario simples mas em cenarios ainda mais simples os problemas
nao sao menos frequentes mas sao menos variados


> o das rotas presas, que não
> era culpa do quagga, e sim do linux. Com kernels modernos nunca mais
> senti o mesmo problema.


desculpe, nao faz o menor sentido culpar o kernel base por uma anomalia num
daemon
nao num primeiro momento sem que haja um bug muito serio que justifique isso

ja vi esse papo de "é culpa do linux"  ate na lista oficial do quagga mas
convenhamos, essa versao XYZ do kernel quando vc da um "route del
<destino>" retorna 0 mas a rota continua la? provavelmente nao ja que nunca
soube de algo assim no linux, entao n faz sentido
o que o route.c faz e evocar a syscal que manipula a tabela de rotamento
se na tabela fib entram rotas e nao saem
entram e nao atualizam
e um route flush ou rote del funciona nao tem como ser qualquer problema no
kernel X que nao exista no kernel Y
mas sim apenas a incapacidade do quagga de se comportar de forma estavel e
esperada no kernel X mas se comportando bem no kernel Y
salvo claro algo realmente mais em baixo que afetava mais que o quagga mas
sim a userland toda do ecosistema desse kernel em questao...

De resto, sinceramente nunca bati a cabeça com
> nenhum desses problemas com as versões estáveis do mesmo.
>

como eu disse, sorte ou ambiente
a lista do quagga esta repleta de outras pessoas que nao deram a mesma sorte
eu era uma delas, tem historico meu la...

>desculpe mas esse argumento não tem nada a ver e pra mim não diz nada
> >qual a vantagem de um daemon de roteamento ser multithread?
>
> Evandro, compare por exemplo no nosso amigo ServerU com o seu
> processador atom. Pode fazer o mesmo teste de tempo para a carga da
> tabela de rotas entre o BIRD e o Quagga e vc verá a diferença. O Bird
> usa o ZEBRA (um processo) para carregar as tabelas de rota e
> manipulá-las no kernel e o BGPD (outro processo) para cuidar da parte
> do BGP.  Eu já tive casos em que a sessão simplesmente dava um freeze
> e derrubava a minha ponta pela demora de processamento do daemon do
> BIRD. Logicamente, faz muito tempo isso, não testei com versões mais
> novas. Porém era algo que realmente irritava.


qual o ponto?
ou melhor onde seu ponto diverge do meu?
como eu disse antes, qualquer anomalia ou demora excessiva pode problema no
daemon, ou vantagem no outro daemon
pode ser ambiente
pode ser maquina
pode ser a temperatura ou forca do vento sudoeste
mas o meu ponto e que ser multithread definitivamente nao e a razao,
vantagem, ou a falta da razao de boa performance

em nenhum cenario onde usei bird tive comportamento adverso nesse sentido
hoje rodo tudo openbgp, e tai o openbgp e juniper pra evidenciarem que o
daemon nao ser multithreaded não é desvantagem
portanto ser, nao é indicio nenhum de vantagem

 De
> resto, tudo que vc citou é verdade, o daemon  é apenas parte do
> universo do roteamento, mas é parte importante!
>

pois é
a intencao é ajudar, com minhas experiencias e frustracoes
eu sempre fui um cara "de linux", um linuxer tipico, que prefere postfix a
qmail, unbound a bind, vim vi/emacs/ee/pico, kde a gnome kkk

mas um belo dia mudei de emprego e fui coordenar um ambiente de maior porte
envolvendo firewall, ids, e bgp
defendi a unhas e dentes a adocao de software livre e commoditie hardware
minhas escolhas foram linux, snort, iptables, quagga
minha nao escolha foi rede 10GbE emulex pq era o melhor preco dentre os
fornecedores da empresa

foi quando minha vida mudou (comercial de shampoo kkkk)
sofri pra burro com quagga
sofri pra burro com softirq no talo do top do linux gastando toda CPU que
se podia dar pro linux

meu desgaste foi muito grande, mas alem de "faz tudo"  (coordenador,
sysadmin, devops, puppet-master, técnico, sysadmin, noc, cso) eu tambem
era/sou a pessoa que apoia as tomadas de decisao e a mais contestada foi
software livre, hardware commoditie... o diretor ja queria ir pra cisco,
sonicwall, fortinet ou qualquer coisa que o vendedor mais convincente
pudesse convence-lo primeiro...
foi quando resolvi testar freebsd
coloquei freebsd exatamente na mesma maquina que o linux pedia arrego com
800Mbit/s e acabou softirq, acabou starvation de CPU, acabaram metade dos
meus problemas
a outra metade acabou quando tirei quagga e coloquei openbgp
no meio do caminho testei vyatta community (n tinha vyos ainda), bird, etc
alguns lugares com menor complexidade mantive vyos, pfsense ou bsdrp, com
bird ou quagga no caso do bsdrp, mas depois fui tirando onde era possivel
a mesma maquina com freebsd chegou a 2Gbit/s mas quando precisamos crescer
mais que isso fomos pra L800 e hoje ta la tudo de boa...
antes disso um camarada do rio de janeiro me deu uma bao, aprendi bsd
depois fui na freebsd brasil, fiz curso de freebsd, fui melhorando meu
entendimento
fiz o FreeBSD FAR e fui entendendo o tamanho da besteira e pq sofria com
emulex...
comprei exatamente a rede 10GbE que o patrick recomendou no curso e tudo
mudou
quando fui pra L800 ja fui com modulo dela mesmo, as demais redes ficaram
com outras funcoes
a emulex deixou outro colega da emprea feliz da vida pq ele finalmente
conseguiu ter uma rede 10GbE no Samba que ele tanto queria e pedia, mas
nunca veio e a emulex que pra roteamento nao servia, pro Samba dele com
"pacotoes"  mas taxas de pps menores serve perfeitamente  e sobra, no final
mostrei pro diretor que SL gerava economia, retorno, tco, roi, que nenhum
hardware tinha sido comprado a toa ou desperdicado que tudo estava melhor
do que antes e a galera do samba (incluindo usuarios) felizes da vida com a
DELL que nao servia pra roteamento e a oce0 emulex que nao servia pra borda
tamem...

como gato escaldado tme medo de agua fria...
eu fujo como o diabo da cruz
e minha cruz pra roteamento/fw é quagga e linux
pro resto continuamos usando linux em boa parte da infra, e bsd fica nas
bordas, seja roteando, seja filtrando
cada coisa tem seu lugar
e por isso dei minha opiniao

openbsd tem seu lugar
mas certamente nao é na borda e não é como router
linux tem seus diversos lugares, mas pra mim e pra quem me perguntar,
roteando tambem não é o lugar dele, exceto ambientes pequenos claro (aka,
até 1Gbit/s)

quagga deve ter o seu lugar hehehe
na sua empresa por exemplo
vc parece feliz com ele...
mas onde eu trabalho tbm nao serve
e convenhamos, mais ou menos bugs, todo usuario de quagga tem suas
historias e suas colecoes

ao recomendar pro colega as opcoes que eu coloquei, na ordem de preferencia
que eu coloquei, minha melhor intecao é que o colega não precise colecionar
historias de problemas, bugs e frustracoes, então recomendei oq eu
considero ser as melhores opcoes

quagga está la nas indicacoes
so esta abaixo de outras opcoes melhores hehehe
e acima dos mikrotik da vida kkk


> >netflix certamente n usa bird a toa, limelight também não, ISC não está
> >indo sua redundância pra BIRD a toa
> O foco deles não é roteamento, e sim entrega de conteúdo. Concordo que
> para esse fim o BIRD é superior pela simplicidade.


sobre netflix/openconnect concordo, bird é uma escolha naturalmente melhor
mas limelight e ISC roteam, sao transito, sao anycast, sao mais que entrega
de conteudo
e certamente e um ambiente bgp de complexidade maior que da maioria dos
provedores parte aqui da lista operando seus bgp
acho que a questão é mais de adaptacao...
se a pessoa não tem vontade de se matar toda vez que faz um filtro ou, como
é o seu caso, um route map no BIRD... então IMHO, ela está melhor servida
com BIRD que com quagga... me parece ser o caso...

Também acredito que
> o Vyatta não usa quagga a toa, o Edgerouter não usa quagga a toa,
> sophos não usa quagga a toa...
>

não, nenhum deles usam quagga
eles derivaram do quagga, tem algo baseado no quagga, algo que um dia foi
um quagga
hoje é algo derivado, melhor, mais bem trabalhado e com bem menos bugs...
não é o quagga
em especial o pessoal do vyatta que submetia correcoes de bugs, tentava
implementar melhorias
onde o quagga (enquanto projeto) divergiu com a intencao de quem fazia o
vyatta antes de ser um produto comercial e antes de ser VyOS, nesse momento
comecaram as diferencas do que tinha no vyatta e nao tinha ou nao
funcionava igual (ou apenas nao funcionava) no quagga

é a mesma coisa dizer que o juniper usa gated
um dia, foi gated, hoje é outra coisa...
ou que juniper = freebsd/mips
é baseado, é derivado, mas não é a mesma coisa
ao contrario a maior parte do que é o freebsd/mips hoje veio de volta como
contribuicao da juniper, nao ao contrario

se não me engano até mikrotik usava quagga, num passado remoto
dizem que usava xorp tambem, sei la
seja como for desistiram e parecem ter jogado fora e comecado do zero a ter
seu proprio bgp/ospf/etc

por isso recomendei o vyos como uma opcao viavel, sim
se por algum motivo (tem gente que é cheio disso... preciosismos, preguica,
preconceito, ou apenas quer continuar na zona de conforto com o que
conhece) o cara simpatiza com linux mas nao quer experimentar um freebsd...
vai de vyatta... (vyos) que em linhas gerais funciona sim muito bem, nao
frustra expectativas, e é sim baseado/derivado de quagga, mas não é a mesma
coisa e não espere ter a mesma estabilidade e qualidade se enfiar um quagga
num centos/debian/ubuntu/slackware...



> Te dou razão em uma coisa: o OpenBGP é muito mais maduro e estável, e
> uma opção bem mais feliz se puder utilizá-lo.
>

uhuu
enfim concordamos!
:-D

--
> gter list    https://eng.registro.br/mailman/listinfo/gter
>