Em 14/10/2015 12:19, Marcelo Gondim escreveu:
On 14-10-2015 06:07, Sergio Lopes wrote:
Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o
mesmo problema usando LACP
igb2: Interface stopped DISTRIBUTING, possible flapping
igb4: Interface stopped DISTRIBUTING, possible flapping
Cada vez que o problema ocorre o tráfego da interface de um sentido
comuta para outra interface, fazendo com que o usuário perceba uma
queda de 5 segundos.
Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch ai
fica normal.
Repara também no load como que sobe. Tenta usar o 10.1-stable que to
usando e vê se resolve seu problema:
10.1-STABLE r281235
Vinícius Zavam escreveu:
2015-10-04 9:59 GMT-03:00 Marcelo Gondim<gon...@bsdinfo.com.br>:
On 21-09-2015 09:23, Marcelo Gondim wrote:
On 21-09-2015 08:27, Antonio Modesto wrote:
On 09/21/15 08:23, Antonio Modesto wrote:
On 09/17/15 15:22, Marcelo Gondim wrote:
On 17-09-2015 11:51, Luiz Otavio O Souza wrote:
2015-09-15 11:59 GMT-03:00 Marcelo Gondim:
Opa Danilo,
Pois é e a única coisa que tenho é a revisão que funciona
perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as
versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu
cenário.
Outra recente também que descobri e que sofri por muito mas
muito
tempo. Não
sei se lembram dessa thread [1] que abri em abril do ano
passado.
Sabe qual era a solução desse problema?
Colocar um simples: gateway_enable="YES" no /etc/rc.conf
Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga
porque o
roteamento para de funcionar quando faço um ifconfig vlanX
create se
eu não
tiver o gateway_enable no rc.conf? Onde que isso está escrito?
Fiquei meses
com esse problema e agora não tenho mais.
Pior é que os caras que me responderam isso na lista acham
que isso
não é um
bug. Só teve 1 que achou que era um bug. Não faz sentido
algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2
interfaces
de rede
pra fazer o roteamento de um lado pra outro e setem umas
vlans. Sem o
parâmetro acima experimentem fazer um simples:
# ifconfig vlan200 create
Depois tentem pingar de uma rede pra outra. Não vai nem à
pau. Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar
vlans sem
problemas.
São essas coisas que matam a gente.
[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html
Opa Gondim,
Nós entendemos e sabemos o quanto é frustante aguardar (sem um
ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).
É sempre importante lembrar que o projeto trabalha com
voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou
para ser
responsável por determinada area, então mesmo com toda
frustração é
importante manter uma atitude positiva.
Pessoas com a atitude positiva se relacionam melhor com a
comunidade e
se relacionando bem as pessoas vão se lembrar de você.
Lembre-se, é
tudo uma questão de como você interage com o projeto. O
projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.
Mesmo com todos esses problemas, eu aposto que você ainda tem
muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos),
reporte um
problema lá e depois me diga quando foram resolvidos ;-)
Bom, quanto a esse problema do gateway_enable, esta correto,
apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para
que o
sistema funcione, existem casos onde os scripts rc vão
reescrever essa
sysctl e a única forma de você instruir os scripts para fazer
a coisa
certa é através da variável gateway_enable.
O roteamento para de funcionar porque quando você cria a vlan
ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.
Contribua com a documentação do projeto, deixe isso escrito e
claro
para que outras pessoas não tenham a mesma dificuldade.
Grande LooS :)
Só desanima mas continuo na guerra rsrsrsrs
Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo
setando pra 1
não voltava à funcionar. Uma doideira mesmo. Só voltava o
sistema quando
reiniciado e como estava em produção não deu pra fazer mais
testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de
parar.
Fala Gondim. Essa questão do sysctl realmente não acho que seja um
comportamento exótico, já que não existe sentido em não ter o
gateway_enable="YES" no rc.conf se você não precisa de
roteamento. Agora
esses problemas com o lagg realmente devem ser osso. Mal lhe
pergunte, não
seria viável usar interfaces 10G diretamente? Digo isso pois
apesar de o
lagg ser um recurso muito útil, acredito que ter interfaces boas
com
drivers bem testados seja mais recomendado para um ambiente
crítico como o
seu.
Corrigindo: Se você precisa de roteamento. =)
Bom dia Modesto,
Sim essa semana eu vou passar os 3Gbps de IX-SP + 2Gbps Link IP
Internexa
para uma porta de 10GbE e um link de 2Gbps com a Level3 para a
outra porta
de 10GbE de uma Intel X520-SR2. Dessa forma eu mato 2 laggs que
tenho. Pena
que depois disso não vou mais saber se esse problema do lagg foi
resolvido
porque não terei mais nenhum lagg para checar. De qualquer forma
deixei
anotado a revisão do 10.1-stable que estava tudo funcionando, para
o caso
de algum dia eu voltar à precisar.
Bom dia pessoal,
Egypcio sabe se recentemente descobriram algum problema que afetava a
performance do FreeBSD 10.2? Porque conversando com outro amigo meu
ele
também estava tendo problemas de performance e quando falei pra ele
usar o
10.1-STABLE, que to usando, o problema dele acabou. Ou seja, to
achando que
esse meu problema está relacionado à performance geral do sistema.
Porque no último teste que fiz; quando eu ligava o servidor e
começava à
carregar o OpenBGP o load ia em 20.x até carregar tudo e depois ficava
dando problema com load alto. Com a versão 10.1-STABLE, que não
largo até
que isso seja resolvido, quando carrega o OpenBGP fica com load
baixo de no
máximo 4.x. Só aí já é claro um problema no sistema como um todo. Algo
mudou que afetou a performance dele.
Sabe se recentemente descobriram e corrigiram algo nesse sentido?
Porque
sinceramente isso é coisa pra sair inclusive nota avisando e
alteração no
releng.
[]'s
Gondim<https://www.fug.com.br/mailman/listinfo/freebsd>
gondim,
isso daí é algo que, assim como você, eu também teria de sentar com
tempo e
calma pra escovar com ajuda de ferramentas de stress, benchmark e
algumas
RFC; 2544, por exemplo (se não me engano).
"adota essa criança" e ajuda o projeto a identificar o que está ruim
pra
quem utiliza stable/10. quanto mais detalhes e informações forem
coletadas
e reportadas, melhor. certamente uma sugestão de correção com patches
também ajuda. infelizmente eu não chego nem perto de ter como
reproduzir o
cenário (não tenho máquinas, nem infraestrutura, que estejam
disponíveis
pra isso).
E ae pessoal,
Retornando com essa thread pois descobri coisas novas à respeito do
problema. O problema não está no LACP porque nós retiramos o LACP e
colocamos tudo em interface de 10GbE X520-SR2.
O que parece é que algo mudou em relação ao cpu affinity entre a versão
10.1-STABLE que estou usando e as versões atuais.
Na versão 10.1-STABLE estou com o cpu affinity assim:
/usr/bin/cpuset -l 11 -x 300
/usr/bin/cpuset -l 10 -x 301
/usr/bin/cpuset -l 9 -x 302
/usr/bin/cpuset -l 8 -x 303
/usr/bin/cpuset -l 7 -x 304
/usr/bin/cpuset -l 6 -x 305
/usr/bin/cpuset -l 0 -x 306
/usr/bin/cpuset -l 1 -x 307
/usr/bin/cpuset -l 9 -x 308
/usr/bin/cpuset -l 5 -x 355
/usr/bin/cpuset -l 4 -x 356
/usr/bin/cpuset -l 3 -x 357
/usr/bin/cpuset -l 2 -x 358
/usr/bin/cpuset -l 1 -x 359
/usr/bin/cpuset -l 0 -x 360
/usr/bin/cpuset -l 5 -x 361
/usr/bin/cpuset -l 4 -x 362
/usr/bin/cpuset -l 3 -x 363
/usr/bin/cpuset -l 5 -x 364
/usr/bin/cpuset -l 4 -x 365
/usr/bin/cpuset -l 3 -x 366
/usr/bin/cpuset -l 2 -x 367
/usr/bin/cpuset -l 1 -x 368
/usr/bin/cpuset -l 0 -x 369
/usr/bin/cpuset -l 5 -x 370
/usr/bin/cpuset -l 4 -x 371
/usr/bin/cpuset -l 3 -x 372
Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle dos
cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso tem
12 cores. Aí fiz uns testes e percebi o seguinte:
Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os
meus links para o router (+5Gbps de tráfego), os cores ficam totalmente
desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros
ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente
atualizando o sistema e mantendo todas as configurações. Egypcio sabe se
houve alguma mudança que poderia ter mudado esse comportamento no cpu
affinity?
Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui tentar
melhorar o balanceamento nos cores com o cpu affinity (cpuset) e quando
faço isso passo à ter perdas de pacotes nos links de dados. O que me
obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja mexeu
no cpu affinity, então reinicie porque senão pode dar zica e feia.
Doideira isso. Ou seja o problema não estava no link aggregation.
[]´s
Gondim
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
