[GTER] RES: Quagga

[Patrick Tracanelli]

Luiz Otavio O Souza escreveu:
>> Olha, acho que ha uma interpretacao erronea do seu amigo...
>>
>> O OpenBGP nao e' "nativo" do OpenBSD, nao no sentido que "funciona 
>> melhor" neste
>> sistema.
> 
> Hmm. Tenho minhas dúvidas...
> 
> A integração com firewall por exemplo, funciona muito melhor no openbsd. 
> Nem o FreeBSD consegue manter o pf atualizado da mesma forma que 
> acontece no openbsd. Nem sempre o delay para portar uma nova versão do 
> pf é tão pequena.
> 
> E não tenho duvidas que existem (varios outros) pequenos detalhes que se 
> encaixam melhor no openbsd (nem me parece tão dificil imaginar o porque).
> 
> O pessoal do OpenBSD parece que encontrou seu caminho (e que caminho), o 
> openbsd como roteador é duro de bater.

Isso da um boa conversa, sem duvidas.

Eu costumo dizer, o FreeBSD tem um suporte a threading muito evoluido, 
talvez um dos mais evoluidos, passou por fases de M:N, KSE, por fases de 
1:1 e 1:N até chegar no modelo atual que tenta tirar melhor proveito do 
que se aprendeu com a aventura chamada "KSE" e com o que se obteve de 
resultados concretos.

A maior parte do kernel, incluindo pilha IP e roteamento, e, incluindo o 
firewall PF, é Giant-free (portanto tira proveito de verdade, de 
ambiente SMP). Enfim, tem tudo que um SO moderno tem que ter no que 
tange a MT e SMP.

Além disso tem um escalonador (ULE) que torna o uso disso tudo, bem mais 
eficiente, gerando resultados que a gente conhece por ai nos benchs 
divulgados e que a gente sente quando vira de scheduler em um ambiente 
com alta demanda de CPU e interatividade (mixto de IO bound VS CPU bound).

Com base nisso, e olhando o suporte limitadissimo a SMP do OpenBSD, 
olhando o praticamente nulo suporte a MT do mesmo, como pode a pilha IP, 
tabela de roteamento, firewall, etc, ser se quer, similar, ao do FreeBSD?

Concordo, pf, carp, não é mantido em sync, leva tempo portar tudo. Mas 
se o FreeBSD tivesse uma arquitetura simples como do Open seria mais 
facil e rapido portar. Como é diferente, leva tempo, esforço e recurso 
humano. O proprio IPFW levou bons releases pra ficar giant-free.

Mas não há nada no OpenBGP que seja contemplado na integração com PF ou 
carp que não esteja 100% no FreeBSD. Alias pelo ports so o md5password 
não funciona, até IPSec+OpenBGP funciona. O md5password porem, tem patch 
online pra corrigir, se for imperativo ativa-lo.

Com base nisso a comparação de uso, seja Quagga, OpenBGP, o que for, não 
pode ficar só nessa de "roda em X, roda em Y". Precisamos considerar que 
o serviço do daemon em tese, é limitado. Uma vez a tabela de rota 
carregada, quem vai rotear é o S.O. E isso pode fazer a diferença de 
alguns ms de latência em cada pacote.

Agora se performance, escalabilidade, latencia e vazão não estiverem em 
conta, e formos considerar apenas features, OpenBGP em qualquer sistema 
com PF e CARP é equivalente. Nesse cenário Quagga em qualquer sistema da 
na mesma também, e ai concordarei com os demais quando dizem, "use o que 
voce tem mais facilidade".

Eu so uso Quagga quando quem solicita, faz questão. De resto, sempre 
OpenBGP. A curva de aprendizado é mínima, a pessoa não tem que aprender 
Cisco ou Juniper pq tem "sintaxes similares". É unix, blocos 
espartânicos, convencional. Não tem mágina ou "manha", pra fazer 
route-map OUT e colocar "aquele tchan" pra fazer funcionar. Alias o 
unico pre-requisito é conhecer a essencia por tras do BGP. Não precisa 
conhecer a ferramenta, de tao user-friendly que é. So precisa conhecer BGP.

Fora isso, a facilidade pra soluções que não tem a ver com BGP, como 
fazer PBR, balancear sem ficar jogando uma parte pra um lado, outra pro 
outro, etc, recursos que Cisco e Juniper vendem separado, e que a pessoa 
vai procurar com Quagga e vai ter q fazer mil "workarounds", se não 
desistir, me faz tambem preferir OpenBGP.

Por ultimo, estabilidade. Em uma situação específica, pra ser honesto 
num ambiente com mais de 1.3M de prefixes (5x270000+), com quagga 
alocando quase 200M de memoria pra cada tabela RIB (nao sei porque, hj 
no mesmo cenario OpenBGP nao aloca mais de 50M por RIB full pra cada 
peer), quagga morria com, ora error code 6, ora 11 (debian, se é que 
conta). Na lista quagga-users vi que em cenário parecido o problema não 
era exclusividade minha, ou do debian. Mas deixei de me acompanhar 
depois que adiatamos o processo de migração pra OBGP+FBSD junto ao cliente

-- 
Patrick Tracanelli