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

Wed Jan 14 21:25:08 -02 2015

2015-01-14 14:52 GMT-02:00 Lucas Willian Bocchi <lucas.bocchi at gmail.com>:

> Evandro
>
> Qual seria o problema do quagga?? Pelo que vi, é superior ao bird em
> muita coisa...
>

sim, é
mas não em estabilidade e certamente não em segurança
quagga tem muito tempo de vida, um codebase herdado do zebra, dai o lado
positivo
é já ter muitas, muitas features, acho que é um dos mais feature-rich senão
o mais
dentre as opções livre

isso dito, IMHO, os pontos positivos do quagga acabam ai
apesar de feature-rich a quantidade de bugs horríveis e injustificáveis que
o quagga fazem dele pra mim a pior opção pra rotear bgp/ospf em budget
hardware

so pra citar os "bugs oficiais" ou seja os abertos no site do projeto, vou
elencar os que já me afetaram:

- rotas na tabela rib não vão pra fib
- anuncios ficam presos no router local e não vão pra frente sem clear
- rotas da rib vão pra frente diferente das eleitas e instaladas na fib
local
- rotas presas (hello mikrotik?), prefixos já invalidos continuam existindo
na rib
- rotas presas 2, prefixos ja inexistentes na rib ainda estão na fib
- ASN32, bugs e mais bugs com ASN32 anunciado como transito, daemon morre
do nada
- memory leak com updates de rotas com ASN32 no transito
- as-dot em peering direto, quase sempre não funciona se a outra ponta o AS
4-byte manda nesse formato
- as-dot no transito e community com AS de transição causam IDLE na sessão
- IDLE causado sem motivo aparente em momentos aleatórios
- crash em momentos aleatórios
- md5 password com cisco em senha de 16byte ou mais funcionam inicialmente
depois IDLE

todos esses bugs eu vivi
alguns desses bugs são muito recorrentes e discutidos frequentemente na
lista dev quagga
outros estão com bug aberto desde 2004, 2006, sem nunca ter uma correção
definitiva
o pior é que os que se mantém aberto a tantos anos, não são repetiríeis
os motivos são aleatórios e os momentos também
em especial as falhas de update de fib, os memory leak e as rotas presas
ingress ou no anuncio

mas pra ser bem honesto, o bird tem um ponto fraco que é o forte do quagga
(seria o forte, se funcionasse bem)
que é a maldita (no caso do bird) semantica alienígena de filtros
é irritante fazer filtros no bird
além de limitado, se comparado ao openbgp ou quagga
mas infelizmente as vantagens do quagga vão pro ralo por conta do volume de
bugs

Uma boa discussão, que o nosso amigo Eduardo aqui participou e eu já
> olhei uns tempos atrás quando me surgiu a mesma pergunta na cabeça foi
> essa aqui
> http://mailman.nanog.org/pipermail/nanog/2012-August/051127.html
>
>
acho essa discussão na nanog injusta hoje
considerando o chão e a kilometragem do bird (mais novo) vs quagga (zebra
esta ai desde antes de muitos de nós estarmos na internet), que dirá em 2012
num primeiro momento numa analise fria, poucos optariam entre bird e
quagga, pelo bird
mas na vida real, na hora de por em campo, se o ambiente não for complexo e
os filtros do bird não irritarem o usuário, ele se torna melhor opção
netflix certamente n usa bird a toa, limelight também não, ISC não está
indo sua redundância pra BIRD a toa

mas eu não estou defendendo o bird, prefiro OpenBGP 1000 vezes
só acho melhor opção que Quagga

O que me leva a gostar mais do quagga do quê dos outros é esse paper
>
> http://conference.apnic.net/__data/assets/pdf_file/0020/50771/osr_apnic34_1346132140.pdf
>
> Ao que me parece, o quagga possui muito mais segurança em relação ao
> código e estabilidade em relação ao daemon em si.

é exatamente o ponto que eu discordo dado os bugs citados

configuração a cada vez que precisa mexer em algo. Fora que o design
> monothread do bird não tira vantagem de cpu's múltiplas, e dependendo
> da configuração pode até fazer teu roteador sentar e flapar (já vi
> acontecer).
>

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?
a única tarefa pesada que o daemon pode fazer é processar os filtros
se demorar ou a CPU esgotar tem algo muito errado, ou no setup, ou nos
filtros, ou na máquina
ainda assim só no início de uma série de sessões simultâneas com N prefixos
full chegando a CPU poderia se elevar um pouco com muitos e muitos filtros,
mas nada que demanda multithread sem ser sintoma de algo muito mais sério
errado
o daemon de roteamento não faz nada...
openbgp é mono thread (ok são 3 processos independentes potencialmente em 3
CPUs, mas ainda assim só 1 thread roda a RDE inteira, que seria o pesado),
bird é monothread e não se engane com a coluna de threads do quagga, a
parte relevante dele que é o processamento de filtros por UPDATE continua
sendo monothread, inclusive [1] o maior trabalho de multithreading do
quagga foi financiado pelo Euro-IX, boa parte disso nunca foi feito merge
de volta no quagga, outra parte não mostraram benefício algum, e
estranhamento a parte que apresentou mais benefícios foram os mecanismos
IPC, a indexação e os event timers o que pra mim por si só é indício que os
"benefícios" vieram pra resolver problemas que sequer, deveriam existir,
mesmo em uma thread única;
veja os detalhes do que é multithreading no quagga, timers, eventos, signal
handlers, work queues... fala sério que vantagem maria leva em ter.. sei
la, signal handler multithread hehehe

além disso ou muito me enganam as saídas do juniper e do cisco, de info,
process, estatísticas de cpu, ou o daemon bgpd desses também é monothread
porque sinceramente vejo alocados na CPU tradicional, e não há indício
visual que nada mais rode no Trio ou instruções ASICS noutro chip qualquer
que não na CPU, com o número de threads (1/2) indicado nas saídas - posso
claro estar falando besteira, não conheço a arquitetura cisco/juniper a
fundo mas estou falando pelo que vejo nas saídas de estatísticas

ou seja, o ponto crucial de qualquer roteador é a capacidade de linerate,
encaminhamento, interrupções
é nesse ponto que o processamento é crítico, que deve ser multithread, que
tem que ter adaptive interrupt, que tem que ter affinity, e afins; o
trabalho pesado é feito pelo kernel, não pelo daemon de roteamento
exatamente por isso comentei sobre o quão SOHO é ter um OpenBSD atuando
como router, é ter só uma CPU pro trabalho pesado... não é um problema do
daemon, é do kernel; a vida do daemon de roteamento é mansa... quase tanto
quanto a de um senador brasileiro

[1]http://www.academia.edu/5754254/Introduction_to_the_Quagga_Routing_Suite
[2]
https://bugzilla.quagga.net/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=relevance%20desc&product=&query_format=specific

>
> Em 14 de janeiro de 2015 13:42, Evandro Nunes
> <evandronunes12 at gmail.com> escreveu:
> > sobre md5 no bird funciona muito bem mas tem que ter TCP MD5 no kernel do
> > FreeBSD e tunar algumas sysctl
> > porém colocar md5 em bgp é inútil, gera algum overhead e não agrega em
> nada
> > em segurança
> > nada mesmo
> > é tapar sol com a peneira
> > não vejo qualquer razão pra se insistir em md5
> >
> > segurança pouco melhor só com ipsec bgp ou s-bgp que infelizmente não é
> > comum ainda
> > md5 no bgp é psicológico, ilusão
> >
> > eu pessoalmente não usaria quagga com sistema nenhum
> > vai de openbgp ou bird em freebsd como diversos recomendaram
> > mas se quer mesmo linux por motivos xyz vai de bird
> >
> > o que o renato disse eu discordo por experiência própria
> > não faz qualquer sentido usar openbsd pra roteamento ou firewall
> > pelo simples fato que o openbsd é monothread
> > seu roteamento, suas interrupções, seu firewall sempre ficarão apenas na
> > CPU0
> > independente de quantas CPU você tenha
> >
> > ou seja OpenBSD é pra ambiente SOHO e Small
> > (muitos vão ter espasmos ao lerem isso mas fiquem a vontade pra me
> provar o
> > contrário)
> >
> > se for rotear mais de 500Mbit/s com filtro você terá apenas 1 CPU pra
> isso
> > e ai boa sorte... pros seus clientes principalmente rss rs
> > pfSense não é FreeBSD a toa...
> > s/|OpenBSD/FreeBSD/g pra qualquer situação de médio porte pelo amor de
> Deus
> >
> > o que o amigo disse é a mais pura verdade
> > se preocupe mais com hardware
> > e concordo com o amigo, vá de ServerU L-800
> >
> > eu recomendo, em ordem de preferencia pessoal e escalabilidade
> >
> > 1) FreeBSD + OpenBGP
> > 2) FreeBSD + BIRD
> > 3) VyOS
> > 4) pfSense + OpenBGP
> > 5) Linux (CentOS ou Debian) + BIRD
> > 6) BSDRP
> >
> > hardware
> >
> > 1) ServerU
> > 2) Supermicro
> > 3) Sinco (Ralph Vills)
> >
> > eu não desejo pra minha vida nem pra de ninguém que eu queira bem (dentro
> > do tópico):
> >
> > 1) Quagga
> > 2) OpenBSD
> > 3) RouterOS
> > 4) DELL
> > 5) IBM
> > 6) Hardware montado em casa
> >
> >
> >
> > 2015-01-14 12:39 GMT-02:00 Christian Lyra <lyra at pop-pr.rnp.br>:
> >
> >> Caros,
> >>
> >>
> >> 2015-01-14 11:57 GMT-02:00 Renato Frederick <renato at frederick.eti.br>:
> >>
> >> > Se precisar usar MD5 mesmo, use OpenBSD. Não vai funcionar no Free.
> >> > Todos os tutoriais que tem na NET eu testei, de usar IPSEC e etc...
> Não
> >> > fechou com caixa cisco nem juniper na outra ponta.
> >> > Mas, se há controle de next-hop, controle de MAC dos peers, acho que é
> >> > seguro o bastante para abrir mão do MD5.
> >> > Experimente o BSD com OPENBGPD, apesar da sintaxe diferente para quem
> é
> >> > cisco like, tem centenas de exemplos e você pode fazer algumas
> gracinhas
> >> > junto ao PF.
> >> > Mas como sempre digo, isto de usar caixa cisco/juniper ou máquina
> >> > Linux/BSD é igual discutir futebol, cada um usa o que mais convém e é
> >> > discussão perdida, a gente só dá a experiência profissional e deixa o
> >> > técnico usar o que conclui ser melhor.
> >> >
> >>
> >>
> >> O quagga + linux + md5 funciona direitinho. Estou estudando alternativas
> >> por uma questão de redundância (uma caixa com quagga+linux e outra com
> algo
> >> diferente) e md5 é pré-requisito.
> >>
> >>
> >> --
> >> Christian Lyra
> >> PoP-PR/RNP
> >> (41) 3361-3343
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>