Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE [PARECE QUE RESOLVEU]

[Marcelo Gondim]

Em 09/03/2016 12:47, Marcelo Gondim escreveu:

Em 04/03/2016 16:28, Vinícius Zavam escreveu:

2016-01-29 23:12 GMT-03:00, Marcelo Gondim :

Em 29/01/2016 15:16, Vinícius Zavam escreveu:

2016-01-29 13:58 GMT-03:00, Marcelo Gondim :

Em 29/01/2016 13:00, Vinícius Zavam escreveu:

2016-01-27 16:21 GMT-03:00, Marcelo Gondim :

Em 26/01/2016 19:57, Vinícius Zavam escreveu:
2016-01-24 11:18 GMT-03:00, Marcelo Gondim 
:

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:



[recorte]

 ...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235
como
10.1-STABLE. confere? os códigos do cpuset tu poderias 
verificar no

"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a 
revisão

específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes 
ver que

já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6
meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Em 04/03/2016 16:28, Vinícius Zavam escreveu:

2016-01-29 23:12 GMT-03:00, Marcelo Gondim :

Em 29/01/2016 15:16, Vinícius Zavam escreveu:

2016-01-29 13:58 GMT-03:00, Marcelo Gondim :

Em 29/01/2016 13:00, Vinícius Zavam escreveu:

2016-01-27 16:21 GMT-03:00, Marcelo Gondim :

Em 26/01/2016 19:57, Vinícius Zavam escreveu:

2016-01-24 11:18 GMT-03:00, Marcelo Gondim :

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:


[recorte]

 ...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235
como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6
meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2016-01-29 23:12 GMT-03:00, Marcelo Gondim :
> Em 29/01/2016 15:16, Vinícius Zavam escreveu:
>> 2016-01-29 13:58 GMT-03:00, Marcelo Gondim :
>>> Em 29/01/2016 13:00, Vinícius Zavam escreveu:
 2016-01-27 16:21 GMT-03:00, Marcelo Gondim :
> Em 26/01/2016 19:57, Vinícius Zavam escreveu:
>> 2016-01-24 11:18 GMT-03:00, Marcelo Gondim :
>>> 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:
>>
>> [recorte]
>>
>> ...
>>
>> [/recorte]
>>
>> 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 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2016-01-27 16:21 GMT-03:00, Marcelo Gondim :
> Em 26/01/2016 19:57, Vinícius Zavam escreveu:
>> 2016-01-24 11:18 GMT-03:00, Marcelo Gondim :
>>> 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:
>>
>> [recorte]
>>
>>   ...
>>
>> [/recorte]
>>
>> 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
>> gondim,
>> eahi. suavidade?
>>
>> catei aqui no histórico que tu estavas a relatar o uso da r281235 como
>> 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
>> "svnweb" do freebsd em https://svnweb.freebsd.org
>> (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
>> independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
>> específica. // também pode sair escovando via CLI, se quiser...
>>
>> em "stable/10", segundo o svnweb, não são feitas alterações nesse
>> cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
>> já houve alterações mais recentes (15 meses). finalmente, em
>> "releng/10.2", tu podes ver que o código foi alterado 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Em 29/01/2016 13:00, Vinícius Zavam escreveu:

2016-01-27 16:21 GMT-03:00, Marcelo Gondim :

Em 26/01/2016 19:57, Vinícius Zavam escreveu:

2016-01-24 11:18 GMT-03:00, Marcelo Gondim :

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:


[recorte]

   ...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235 como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
"releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera
MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3

valeu por reviver essa thread!

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2016-01-29 13:58 GMT-03:00, Marcelo Gondim :
> Em 29/01/2016 13:00, Vinícius Zavam escreveu:
>> 2016-01-27 16:21 GMT-03:00, Marcelo Gondim :
>>> Em 26/01/2016 19:57, Vinícius Zavam escreveu:
 2016-01-24 11:18 GMT-03:00, Marcelo Gondim :
> 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:

 [recorte]

...

 [/recorte]

 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
 gondim,
 eahi. suavidade?

 catei aqui no histórico que tu estavas a relatar o uso da r281235 como
 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
 "svnweb" do freebsd em https://svnweb.freebsd.org
 (base/stable/10/usr.bin/cpuset, se 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Em 29/01/2016 15:16, Vinícius Zavam escreveu:

2016-01-29 13:58 GMT-03:00, Marcelo Gondim :

Em 29/01/2016 13:00, Vinícius Zavam escreveu:

2016-01-27 16:21 GMT-03:00, Marcelo Gondim :

Em 26/01/2016 19:57, Vinícius Zavam escreveu:

2016-01-24 11:18 GMT-03:00, Marcelo Gondim :

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:


[recorte]

...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235 como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
"releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
CURRENT e escova; remove 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Em 26/01/2016 19:57, Vinícius Zavam escreveu:

2016-01-24 11:18 GMT-03:00, Marcelo Gondim :

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:


[recorte]

  ...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235 como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
"releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera
MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3

valeu por reviver essa thread!

[ ]


HhAhAh não codo em C não. Até rodo os make da vida rsrsrsrsrsrrs mas não 
codo. Bem que queria aprender C 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Em 26/01/2016 20:43, Paulo Henrique escreveu:

Em 26 de janeiro de 2016 19:57, Vinícius Zavam 
escreveu:


2016-01-24 11:18 GMT-03:00, Marcelo Gondim :

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:


[recorte]

  ...

[/recorte]


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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235 como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
"releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera
MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3

valeu por reviver essa thread!

[ ]


--
Vinícius Zavam

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2016-01-24 11:18 GMT-03:00, Marcelo Gondim :
> 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:


[recorte]

 ...

[/recorte]


 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

gondim,
eahi. suavidade?

catei aqui no histórico que tu estavas a relatar o uso da r281235 como
10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
"svnweb" do freebsd em https://svnweb.freebsd.org
(base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
específica. // também pode sair escovando via CLI, se quiser...

em "stable/10", segundo o svnweb, não são feitas alterações nesse
cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
já houve alterações mais recentes (15 meses). finalmente, em
"releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
atrás.

para qual desses branches essa tua máquina estavas/está a apontar?
chegou a escovar (testar) o comportamento apenas num dos branches?
fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
"releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
CURRENT e escova; remove 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Paulo Henrique]

Em 26 de janeiro de 2016 19:57, Vinícius Zavam 
escreveu:

> 2016-01-24 11:18 GMT-03:00, Marcelo Gondim :
> > 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:
> 
>
> [recorte]
>
>  ...
>
> [/recorte]
>
> 
>  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
>
> gondim,
> eahi. suavidade?
>
> catei aqui no histórico que tu estavas a relatar o uso da r281235 como
> 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
> "svnweb" do freebsd em https://svnweb.freebsd.org
> (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
> independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
> específica. // também pode sair escovando via CLI, se quiser...
>
> em "stable/10", segundo o svnweb, não são feitas alterações nesse
> cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
> já houve alterações mais recentes (15 meses). finalmente, em
> "releng/10.2", tu podes ver que o código foi alterado cerca de 6 meses
> atrás.
>
> para qual 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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:


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 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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:


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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Sergio Lopes]

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.







Vinícius Zavam escreveu:

2015-10-04 9:59 GMT-03:00 Marcelo Gondim:


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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Giovanni Tirloni]

On 10/14/2015 06:07 AM, 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.
> 

Veja se consegue relacionar as quedas com aumento de utilizacao da CPU.

Isso é (era?) um problema comum que eu tinha: a thread responsável por
responder os pings do LACP demorava para rodar e passava do tempo de
timeout do LACP. A solução no meu caso foi mudar o LACP de short para
long (30 segundos) no servidor e no switch.

(No meu caso acontecia durante a remoção de um snapshot grande no ZFS
que causava muita atividade de disco/CPU. Infelizmente é uma operação
que não podia deixar de fazer)

Giovanni

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2015-10-04 9:59 GMT-03:00 Marcelo Gondim :

> 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 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Antonio Modesto]

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. =)





Abrs,


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd




--

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Antonio Modesto]

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.





Abrs,


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


--

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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.


[]'s
Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 18-09-2015 15:02, Vinícius Zavam wrote:

2015-09-18 11:52 GMT-03:00 Marcelo Gondim :


On 18-09-2015 11:06, Vinícius Zavam wrote:


2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

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.

Abrs,

gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+

https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?


Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho
que
essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. Vou
testar hoje à 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 18-09-2015 15:30, Vinícius Zavam wrote:

2015-09-18 15:18 GMT-03:00 Marcelo Gondim :


On 18-09-2015 15:02, Vinícius Zavam wrote:


2015-09-18 11:52 GMT-03:00 Marcelo Gondim :

On 18-09-2015 11:06, Vinícius Zavam wrote:

2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


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.

Abrs,

gondim,


certamente tu já deves ter visto algum desses conteúdos, mas ...

+


https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2015-09-18 15:18 GMT-03:00 Marcelo Gondim :

> On 18-09-2015 15:02, Vinícius Zavam wrote:
>
>> 2015-09-18 11:52 GMT-03:00 Marcelo Gondim :
>>
>> On 18-09-2015 11:06, Vinícius Zavam wrote:
>>>
>>> 2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

 On 17-09-2015 16:54, Marcelo Gondim wrote:

> On 17-09-2015 16:44, Vinícius Zavam wrote:
>
>> 2015-09-17 15:22 GMT-03:00 Marcelo Gondim :
>>
>>> 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 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2015-09-18 11:52 GMT-03:00 Marcelo Gondim :

> On 18-09-2015 11:06, Vinícius Zavam wrote:
>
>> 2015-09-17 19:20 GMT-03:00 Marcelo Gondim :
>>
>> On 17-09-2015 16:54, Marcelo Gondim wrote:
>>>
>>> On 17-09-2015 16:44, Vinícius Zavam wrote:

 2015-09-17 15:22 GMT-03:00 Marcelo Gondim :
>
> 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.
>>
>> Abrs,
>>
>> gondim,
>
> certamente tu já deves ter visto algum desses conteúdos, mas ...
>
> +
>

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 18-09-2015 11:06, Vinícius Zavam wrote:

2015-09-17 19:20 GMT-03:00 Marcelo Gondim :


On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

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.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+
https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho que
essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. Vou
testar hoje à noite mas estou bem otimista em relação à isso.  :)

[1] https://svnweb.freebsd.org/base?view=revision=287723

Abrs,

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

> On 17-09-2015 16:54, Marcelo Gondim wrote:
>
>> On 17-09-2015 16:44, Vinícius Zavam wrote:
>>
>>> 2015-09-17 15:22 GMT-03:00 Marcelo Gondim :
>>>
>>> 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.

 Abrs,

>>>
>>> gondim,
>>>
>>> certamente tu já deves ter visto algum desses conteúdos, mas ...
>>>
>>> +
>>> https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
>>> + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967
>>>
>>> chegou a aplicar algumas das alterações sugeridas na thread da
>>> freebsd-net@,
>>> ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
>>> palavras do scottl@ na thread da lista freebsd-net:
>>>
>>> " The difference between FreeBSD 9.x and 10 is 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Luiz Otavio O Souza]

2015-09-15 6:28 GMT-03:00 Marcelo Gondim:
> Olá meus amigos,
>
> Não sei se sou azarado ou o que. Um ano atrás tive problemas com as
> interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que ficar
> dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano com esse
> problema. Tentei as listas e cheguei à fazer até um PR e nada. Um belo dia
> atualizei o router no STABLE e pronto, problema resolvido. O que foi feito
> não faço ideia mas resolveu depois de 1 ano de sofrimento de ter trocado
> todo o hardware e achando que era temperatura interna da X520-SR2.
>
> Patrick até tentou me ajudar nessa época mas o jeito foi deixar um script
> testando e levantando a interface sempre que caía. Pura gambiarra, coisa
> feia de se ver em um sistema.  rsrsrsrsrs
>
> Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí então
> resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às melhorias da
> 10.1 para a 10.2 e mais uma vez me decepcionei com o sistema.
>
> Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no
> horário de pico e subia o tráfego nesses laggs, simplesmente meu load subia
> pra 40.x à 53.x, minha sessão BGP de um desses laggs com a operadora caía e
> levantava de 5 em 5 minutos me gerando grande problema aqui no provedor.


A partir dessa revisão que você colocou (r281235) houveram apenas 3
commits no if_lagg.c:

https://svnweb.freebsd.org/base/stable/10/sys/net/if_lagg.c?view=log

Isso se o problema for realmente no lagg e não em algum outro ponto do
sistema (driver da placa de rede, etc, etc, etc).

Sei que é difícil testar em produção, mas se você pudesse verificar
qual desses commits introduziu o problema que esta vendo isso seria
ótimo!

[]'s
Luiz



>
> Nos logs ficavam aparecendo:
>
> /var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface stopped
> DISTRIBUTING, possible flapping
> /var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface stopped
> DISTRIBUTING, possible flapping
>
> Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo erro
> que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e pronto! Tudo
> voltou à funcionar como era antes. Assim fica difícil confiar na
> estabilidade e robustez de um sistema. Só Deus sabe agora quando que isso
> será resolvido no sistema. 1 ano? 2 anos? Bem, vou começar à pensar em algo
> como Juniper porque pelo menos vou poder cobrar de alguém quando isso
> acontecer. Uns anos atrás saí do Linux para FreeBSD porque este resolveu
> meus problemas, coisas que o Linux não me atendia mas que agora está me
> deixando chateado com essas coisas. Saí do problema do ksoftirq do Linux
> para outros problemas de instabilidade no FreeBSD.
>
> Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem PR, já
> comentei na freebsd-stable? Tudo bem que pode não afetar o sistema mas já
> acertaram na CURRENT faz tempo, pelo menos foi o que me disseram na lista. É
> uma coisa feia demais para um sistema tão bem trabalhado:
>
> Experimentem fazer:
>
> # ipfw table 100 add 0.0.0.0/8
>
> Agora o resultado:
>
>  # ipfw table 100 list
> ::/8 0
>
> iptables pode ser estranho ou difícil de aprender mas nunca vi algo assim
> nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e cá estamos no
> 10.2 e continua esse bug horrendo.
>
> Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando que isso
> vai ser resolvido porque ao meu ver isso é sério e muita gente usa lagg no
> sistema e com certeza é um problema porque voltei a versão e tudo
> normalizou. Fiquei 3 dias com esse problema me ferrando, para não dizer
> outra coisa, aqui no provedor.
>
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031
>
> Desculpem o desabafo mas puts essa me deixou chateado demais com o sistema,
> ainda mais pela importância que ele tem para o meu negócio hoje.
>
> Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Luiz Otavio O Souza]

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.

[]'s
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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.

Abrs,


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 17-09-2015 13:32, Luiz Otavio O Souza wrote:

2015-09-15 6:28 GMT-03:00 Marcelo Gondim:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que ficar
dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano com esse
problema. Tentei as listas e cheguei à fazer até um PR e nada. Um belo dia
atualizei o router no STABLE e pronto, problema resolvido. O que foi feito
não faço ideia mas resolveu depois de 1 ano de sofrimento de ter trocado
todo o hardware e achando que era temperatura interna da X520-SR2.

Patrick até tentou me ajudar nessa época mas o jeito foi deixar um script
testando e levantando a interface sempre que caía. Pura gambiarra, coisa
feia de se ver em um sistema.  rsrsrsrsrs

Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí então
resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às melhorias da
10.1 para a 10.2 e mais uma vez me decepcionei com o sistema.

Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no
horário de pico e subia o tráfego nesses laggs, simplesmente meu load subia
pra 40.x à 53.x, minha sessão BGP de um desses laggs com a operadora caía e
levantava de 5 em 5 minutos me gerando grande problema aqui no provedor.


A partir dessa revisão que você colocou (r281235) houveram apenas 3
commits no if_lagg.c:

https://svnweb.freebsd.org/base/stable/10/sys/net/if_lagg.c?view=log

Isso se o problema for realmente no lagg e não em algum outro ponto do
sistema (driver da placa de rede, etc, etc, etc).

Sei que é difícil testar em produção, mas se você pudesse verificar
qual desses commits introduziu o problema que esta vendo isso seria
ótimo!

[]'s
Luiz
Pois é eu mandei lacp porque essa mensagem de flapping está no fonte do 
sys/net/ieee8023ad_lacp.c mas é como você disse pode estar relacionado 
com outro problema.
Hoje vou bootar com o 10.2-STABLE, que baixei de ontem, para ver se já 
não foi corrigido nesse meio tempo.


Estou torcendo para que já esteja corrigido pelo menos no STABLE porque 
usar o CURRENT é doideira demais. :)


Agora essa do ipfw o Melifaro até hoje não fez uma MFC e isso tá desde o 
10.0. Só vejo 2 motivos para isso não ter ocorrido ainda: deve ser 
complexo de mudar na 10.2 ou vai afetar o POLA. Eu instalei o 11 aqui 
para ver e realmente o ipfw ficou bem legal porque inclusive não 
precisei mudar meus scripts de firewall e porque agora podemos dar nomes 
nas tables.  :)  Espero ver logo uma MFC do ipfw no stable. rsrsrsr


Abrs e darei notícias,






Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping

Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo erro
que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e pronto! Tudo
voltou à funcionar como era antes. Assim fica difícil confiar na
estabilidade e robustez de um sistema. Só Deus sabe agora quando que isso
será resolvido no sistema. 1 ano? 2 anos? Bem, vou começar à pensar em algo
como Juniper porque pelo menos vou poder cobrar de alguém quando isso
acontecer. Uns anos atrás saí do Linux para FreeBSD porque este resolveu
meus problemas, coisas que o Linux não me atendia mas que agora está me
deixando chateado com essas coisas. Saí do problema do ksoftirq do Linux
para outros problemas de instabilidade no FreeBSD.

Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem PR, já
comentei na freebsd-stable? Tudo bem que pode não afetar o sistema mas já
acertaram na CURRENT faz tempo, pelo menos foi o que me disseram na lista. É
uma coisa feia demais para um sistema tão bem trabalhado:

Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

  # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo assim
nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e cá estamos no
10.2 e continua esse bug horrendo.

Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando que isso
vai ser resolvido porque ao meu ver isso é sério e muita gente usa lagg no
sistema e com certeza é um problema porque voltei a versão e tudo
normalizou. Fiquei 3 dias com esse problema me 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


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.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+ https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive messages
from the switch, and only took a channel down if the link state went down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. " (sys/net/ieee8023ad_lacp.c)

[ ] ' s



Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho 
que essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. 
Vou testar hoje à noite mas estou bem otimista em relação à isso.  :)


[1] https://svnweb.freebsd.org/base?view=revision=287723

Abrs,
Gondim


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Vinícius Zavam]

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

> 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.
>
> Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+ https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive messages
from the switch, and only took a channel down if the link state went down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. " (sys/net/ieee8023ad_lacp.c)

[ ] ' s


-- 
Vinícius Zavam
keybase.io/egypcio/key.asc
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 17-09-2015 16:54, Marcelo Gondim wrote:

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


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.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+ 
https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html

+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da 
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, 
algumas

palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive 
messages
from the switch, and only took a channel down if the link state went 
down. "


" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. " 
(sys/net/ieee8023ad_lacp.c)


[ ] ' s



Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho 
que essa revisão [1] deve resolver o meu problema. Ela saiu esses 
dias. Vou testar hoje à noite mas estou bem otimista em relação à 
isso.  :)


[1] https://svnweb.freebsd.org/base?view=revision=287723

Abrs,
Gondim 
É não adiantou. Coloquei a stable mais recente e deu problema. O 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

Opa Eduardo,

On 16-09-2015 02:11, Eduardo Schoedler wrote:

Em quarta-feira, 16 de setembro de 2015, Marcelo Gondim <
gon...@bsdinfo.com.br> escreveu:


É complicado eu fazer isso pois o router segura a Internet de 4 cidades.
São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.


É muita loucura deixar todo esse tráfego somente em 1 router.

Devia ter, pelo menos, mais um... e cada um deles deve suportar sozinho
todo o tráfego, para caso um caia (ou você precise reiniciar).
Nós temos outro equipamento idêntico pronto para entrar, para o caso do 
principal apresentar algum problema.







- Investir uma grana em Juniper MX5.


No patamar de tráfego que você está, já devia estar no seu planejamento de
curto prazo, ainda mais se você é provedor.
Já está na minha planilha mas não para o momento, pois estamos 
terminando de construir nosso prédio sede onde teremos nosso HeadEnd de 
IPTV. Esperamos que fique pronto até dezembro e até o momento o 
equipamento tem suportado tranquilamente. se não fossem esses problemas 
que surgiram.




--
Eduardo Schoedler





-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Giovanni Tirloni]

On 09/16/2015 01:42 AM, Marcelo Gondim wrote:

On 15-09-2015 22:08, Giovanni Tirloni wrote:

On 09/15/2015 06:28 AM, Marcelo Gondim wrote:

Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no horário
de pico e subia o tráfego nesses laggs, simplesmente meu load subia pra 40.x à
53.x, minha sessão BGP de um desses laggs com a operadora caía e levantava de 5
em 5 minutos me gerando grande problema aqui no provedor.

Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping


Ola Marcelo,

 Não sei até que ponto você está disposto a investigar esse problema, mas se
puder voltar para o 10.2 e iniciar a maquina em verbose mode [1], pode ser que
outras mensagens ajudem a elucidar esse problema.

 Você poderia enviar a saída do ifconfig das interfaces ixb/lagg, a
configuração do link aggr switch, as informações físicas da interface (pciconf
-lv) e de boot (egrep ´(lagg|igb)' /var/run/dmesg.boot)?

 Desde a 10.1-RELEASE, o driver igb teve muitas mudanças. É difícil dizer
exatamente o que pode ter causado essa regressão sem mais detalhes.

[1] - https://www.freebsd.org/doc/handbook/boot-introduction.html#boot-init

Opa Giovanni,

É complicado eu fazer isso pois o router segura a Internet de 4 cidades. São
quase 4.5Gbps de tráfego e mais de 20.000 assinantes.
Se eu fizer isso vou ter muitos cancelamentos tendo em vista que já fiquei uns 3
dias apresentando esse problema e achando que era uma das Operadoras de
trânsito. Não posso colocar um ambiente desse em testes, infelizmente.


Faz sentido. Bom, essas informações que eu solicitei, se você puder colocar no 
PR, com certeza vai ser útil para quem olhar depois.



Por isso informei a revisão que estava usando sem problemas, para tentar ajudar
à descobrir o que foi alterado nesse espaço de tempo e que possa estar causando
isso.


O código do 10.1 foi colocado em freeze dia 5/Set/2014. Já o 10.2 entrou em 
freeze dia 3/Jul/2015. Teoricamente, tudo que foi comitado entre essas datas 
esta no 10.2-RELEASE.


https://www.freebsd.org/releases/10.1R/schedule.html
https://www.freebsd.org/releases/10.2R/schedule.html

Você pode ver os commits aqui: 
https://github.com/freebsd/freebsd/commits/0d9fe1a380ad3917e8371b95095da61774318853/sys/dev/e1000/if_igb.c


Fazer a investigação pelo código apenas com as mensagens de "stopped 
distributing" vai ser quase impossível.




Com relação ao fato de que o próprio pessoal do projeto usa o FreeBSD 11, eu
vejo isso como um grande erro. O current deveria ser testado sim mas antes de
mais nada deveria ser usado a versão de produção que é a 10.x e torná-la mais
estável e robusta ainda. Somente usando o sistema, é que se encontram as falhas.


Os desenvolvedores precisam estar na última versão. É lá que entram códigos 
novos, que vão ser testados, modificados e depois feito o backport para a STABLE.


Se o projeto usa CURRENT em alguns servidores de produção, tem alguém assumindo 
esse risco. Tem que ter muita fé que nada vai quebrar e/ou um sistema de testes 
robustos. Do contrário quando a sua máquina CURRENT pifar, não adianta ir chorar 
as pitangas nas listas :)


Eu não recomendo colocar CURRENT em produção apesar de todas as anedotas de que 
não dá problema que normalmente eu ouço. É melhor criar um ambiente de testes, 
rodar STABLE/RELEASE nele e tentar reproduzir o problema.


Já rodei CURRENT em produção? Já, na época do 5-CURRENT eu queria muito usar o 
pf porque ele tinha funcionalidades que eu precisava. Assumi o risco junto ao 
cliente e tive alguns panic's com certeza. Vai de cada caso... se você já está 
sofrendo com releases que são supostamente estáveis, pela lógica não tem como 
dizer que um codebase que sofre muito mais mudanças como o CURRENT vai te trazer 
mais previsibilidade. Semana que vem sai um patch de segurança e você vai 
aplicar ele e mais 200 milhões de linhas de código que você nem sabe pra que 
serve? Não recomendo...




Para mim os nomes deveriam ser diferentes então: STABLE deveria se chamar
TESTING, RELEASE de UNSTABLE e o CURRENT de RELEASE. Ouvi muito sobre a
organização em que é feito o sistema. A versão 8.x na qual comecei à ver FreeBSD
era excelente e me ajudou bastante. Mas sinceramente nesses últimos anos me
deparo com algumas coisas que parece coisa de "universitário" mesmo. Me lembra o
RouterOS da Mikrotik onde mexem em uma coisa e estraga outra e vai mexendo e
tentando acertar.


Entendo a frustração. Infelizmente é um problema universal da área de TI que a 
qualidade do que a gente faz parece coisa de voodoo as vezes. Acho que nesse 
caso o buraco é mais embaixo, e não é exclusividade do FreeBSD.



As versões de produção deveriam ser a mais rock solid possível, ainda lembro
dessa frase. No entanto cada vez que atualizo para uma release, algo acontece e
coisas param de funcionar ou passam à 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 15-09-2015 22:08, Giovanni Tirloni wrote:

On 09/15/2015 06:28 AM, Marcelo Gondim wrote:
Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário
de pico e subia o tráfego nesses laggs, simplesmente meu load subia 
pra 40.x à
53.x, minha sessão BGP de um desses laggs com a operadora caía e 
levantava de 5

em 5 minutos me gerando grande problema aqui no provedor.

Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping


Ola Marcelo,

 Não sei até que ponto você está disposto a investigar esse problema, 
mas se puder voltar para o 10.2 e iniciar a maquina em verbose mode 
[1], pode ser que outras mensagens ajudem a elucidar esse problema.


 Você poderia enviar a saída do ifconfig das interfaces ixb/lagg, a 
configuração do link aggr switch, as informações físicas da interface 
(pciconf -lv) e de boot (egrep ´(lagg|igb)' /var/run/dmesg.boot)?


 Desde a 10.1-RELEASE, o driver igb teve muitas mudanças. É difícil 
dizer exatamente o que pode ter causado essa regressão sem mais detalhes.


[1] - 
https://www.freebsd.org/doc/handbook/boot-introduction.html#boot-init

Opa Giovanni,

É complicado eu fazer isso pois o router segura a Internet de 4 cidades. 
São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.
Se eu fizer isso vou ter muitos cancelamentos tendo em vista que já 
fiquei uns 3 dias apresentando esse problema e achando que era uma das 
Operadoras de trânsito. Não posso colocar um ambiente desse em testes, 
infelizmente.


Por isso informei a revisão que estava usando sem problemas, para tentar 
ajudar à descobrir o que foi alterado nesse espaço de tempo e que possa 
estar causando isso.
Com relação ao fato de que o próprio pessoal do projeto usa o FreeBSD 
11, eu vejo isso como um grande erro. O current deveria ser testado sim 
mas antes de mais nada deveria ser usado a versão de produção que é a 
10.x e torná-la mais estável e robusta ainda. Somente usando o sistema, 
é que se encontram as falhas.


Para mim os nomes deveriam ser diferentes então: STABLE deveria se 
chamar TESTING, RELEASE de UNSTABLE e o CURRENT de RELEASE. Ouvi muito 
sobre a organização em que é feito o sistema. A versão 8.x na qual 
comecei à ver FreeBSD era excelente e me ajudou bastante. Mas 
sinceramente nesses últimos anos me deparo com algumas coisas que parece 
coisa de "universitário" mesmo. Me lembra o RouterOS da Mikrotik onde 
mexem em uma coisa e estraga outra e vai mexendo e tentando acertar.


As versões de produção deveriam ser a mais rock solid possível, ainda 
lembro dessa frase. No entanto cada vez que atualizo para uma release, 
algo acontece e coisas param de funcionar ou passam à funcionar meia 
boca. Mesmo acontecendo essas coisas faço a minha parte que é abrir um 
PR e mandar e-mail para as listas freebsd-stable ou freebsd-net mas sem 
evolução do problema.


Mesmo com todos esses problemas o FreeBSD ainda é o sistema que aguenta 
e segura o meu tráfego e gostaria de vê-lo melhorar cada vez mais. 
Continuar levantando essa bandeira mas é preciso que o pessoal do core 
ou alguém lá acorde para esses problemas. Hoje minha realidade é a seguinte:


- Ficar fazendo testes com o sistema em produção, derrubando os 
assinantes até descobrir onde está o problema.
- Esperar que alguém passe pelo mesmo problema e consiga reproduzir o 
erro para que seja corrigido em algum momento virando uma MFC.
- Mudar para STABLE e ficar atualizando o source de tempo em tempo, 
torcendo para que alguém descubra algo errado e corrija. Como foi meu 
caso com a X520-SR2.
- Mudar para o CURRENT e ficar correndo riscos mas pelo jeito é o que o 
Projeto FreeBSD está usando em produção.
- Aprender à programar em C, estudar o código do source, corrigir e 
disponibilizar o patch.

- Contratar um programador C para estudar o problema e resolver.
- Investir uma grana em Juniper MX5.

Não estou vendo muitas opções boas mas são essas aí.
Estou muito desanimado com o sistema mas agora tenho que manter até onde 
eu consiga.


[]'s
Gondim

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Eduardo Schoedler]

Em quarta-feira, 16 de setembro de 2015, Marcelo Gondim <
gon...@bsdinfo.com.br> escreveu:

>
> É complicado eu fazer isso pois o router segura a Internet de 4 cidades.
> São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.


É muita loucura deixar todo esse tráfego somente em 1 router.

Devia ter, pelo menos, mais um... e cada um deles deve suportar sozinho
todo o tráfego, para caso um caia (ou você precise reiniciar).



> - Investir uma grana em Juniper MX5.


No patamar de tráfego que você está, já devia estar no seu planejamento de
curto prazo, ainda mais se você é provedor.

--
Eduardo Schoedler


-- 
Eduardo Schoedler
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Giovanni Tirloni]

On 09/15/2015 06:28 AM, Marcelo Gondim wrote:

Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no horário
de pico e subia o tráfego nesses laggs, simplesmente meu load subia pra 40.x à
53.x, minha sessão BGP de um desses laggs com a operadora caía e levantava de 5
em 5 minutos me gerando grande problema aqui no provedor.

Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping


Ola Marcelo,

 Não sei até que ponto você está disposto a investigar esse problema, mas se 
puder voltar para o 10.2 e iniciar a maquina em verbose mode [1], pode ser que 
outras mensagens ajudem a elucidar esse problema.


 Você poderia enviar a saída do ifconfig das interfaces ixb/lagg, a 
configuração do link aggr switch, as informações físicas da interface (pciconf 
-lv) e de boot (egrep ´(lagg|igb)' /var/run/dmesg.boot)?


 Desde a 10.1-RELEASE, o driver igb teve muitas mudanças. É difícil dizer 
exatamente o que pode ter causado essa regressão sem mais detalhes.


[1] - https://www.freebsd.org/doc/handbook/boot-introduction.html#boot-init


Abraços,
Giovanni
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Ricardo Ferreira]

Em 15/09/2015 11:59, Marcelo Gondim escreveu:

On 15-09-2015 11:41, Danilo Egea Gondolfo wrote:

On 09/15/2015 06:28, Marcelo Gondim wrote:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que 
ficar dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano 
com esse problema. Tentei as listas e cheguei à fazer até um PR e 
nada. Um belo dia atualizei o router no STABLE e pronto, problema 
resolvido. O que foi feito não faço ideia mas resolveu depois de 1 
ano de sofrimento de ter trocado todo o hardware e achando que era 
temperatura interna da X520-SR2.


Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
script testando e levantando a interface sempre que caía. Pura 
gambiarra, coisa feia de se ver em um sistema. rsrsrsrsrs


Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí 
então resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido 
às melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o 
sistema.


Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário de pico e subia o tráfego nesses laggs, simplesmente meu 
load subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com 
a operadora caía e levantava de 5 em 5 minutos me gerando grande 
problema aqui no provedor.


Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping


Aí pensei comigo... estava tudo funcionando e não vou cometer o 
mesmo erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE 
r281235 e pronto! Tudo voltou à funcionar como era antes. Assim fica 
difícil confiar na estabilidade e robustez de um sistema. Só Deus 
sabe agora quando que isso será resolvido no sistema. 1 ano? 2 anos? 
Bem, vou começar à pensar em algo como Juniper porque pelo menos vou 
poder cobrar de alguém quando isso acontecer. Uns anos atrás saí do 
Linux para FreeBSD porque este resolveu meus problemas, coisas que o 
Linux não me atendia mas que agora está me deixando chateado com 
essas coisas. Saí do problema do ksoftirq do Linux para outros 
problemas de instabilidade no FreeBSD.


Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem 
PR, já comentei na freebsd-stable? Tudo bem que pode não afetar o 
sistema mas já acertaram na CURRENT faz tempo, pelo menos foi o que 
me disseram na lista. É uma coisa feia demais para um sistema tão 
bem trabalhado:


Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

 # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e 
cá estamos no 10.2 e continua esse bug horrendo.


Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando 
que isso vai ser resolvido porque ao meu ver isso é sério e muita 
gente usa lagg no sistema e com certeza é um problema porque voltei 
a versão e tudo normalizou. Fiquei 3 dias com esse problema me 
ferrando, para não dizer outra coisa, aqui no provedor.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031

Desculpem o desabafo mas puts essa me deixou chateado demais com o 
sistema, ainda mais pela importância que ele tem para o meu negócio 
hoje.


Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Fala Gondim,

esse tipo de problema é osso mesmo...

Pelo que leio e ouço, esses problemas nas releases se devem a pelo 
menos duas coisas: boa parte dos desenvolvedores não usam FreeBSD em 
seus computadores principais (Mac!) (ouçam o adrian@ desabafando no 
bsdnow 101 sobre comer sua própria comida de cachorro) e boa parte 
dos que usam FreeBSD usam o CURRENT (tipo eu :P). Então nós mesmos 
acabamos não vendo os problemas que saem nas releases e acabamos não 
tendo a mesma experiência que os usuário tem, e isso está muito 
errado...


Outra zica é que esses problemas as vezes são difíceis de se 
reproduzir, pelo pouco que olhei no google aqui parece que seu 
problema está relacionado com lagg + igb + condições de tráfego. As 
vezes se o cara não tiver 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

On 15-09-2015 11:41, Danilo Egea Gondolfo wrote:

On 09/15/2015 06:28, Marcelo Gondim wrote:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que 
ficar dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano 
com esse problema. Tentei as listas e cheguei à fazer até um PR e 
nada. Um belo dia atualizei o router no STABLE e pronto, problema 
resolvido. O que foi feito não faço ideia mas resolveu depois de 1 
ano de sofrimento de ter trocado todo o hardware e achando que era 
temperatura interna da X520-SR2.


Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
script testando e levantando a interface sempre que caía. Pura 
gambiarra, coisa feia de se ver em um sistema.  rsrsrsrsrs


Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí 
então resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às 
melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o 
sistema.


Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário de pico e subia o tráfego nesses laggs, simplesmente meu 
load subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com a 
operadora caía e levantava de 5 em 5 minutos me gerando grande 
problema aqui no provedor.


Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping


Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo 
erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e 
pronto! Tudo voltou à funcionar como era antes. Assim fica difícil 
confiar na estabilidade e robustez de um sistema. Só Deus sabe agora 
quando que isso será resolvido no sistema. 1 ano? 2 anos? Bem, vou 
começar à pensar em algo como Juniper porque pelo menos vou poder 
cobrar de alguém quando isso acontecer. Uns anos atrás saí do Linux 
para FreeBSD porque este resolveu meus problemas, coisas que o Linux 
não me atendia mas que agora está me deixando chateado com essas 
coisas. Saí do problema do ksoftirq do Linux para outros problemas de 
instabilidade no FreeBSD.


Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem 
PR, já comentei na freebsd-stable? Tudo bem que pode não afetar o 
sistema mas já acertaram na CURRENT faz tempo, pelo menos foi o que 
me disseram na lista. É uma coisa feia demais para um sistema tão bem 
trabalhado:


Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

 # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e 
cá estamos no 10.2 e continua esse bug horrendo.


Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando 
que isso vai ser resolvido porque ao meu ver isso é sério e muita 
gente usa lagg no sistema e com certeza é um problema porque voltei a 
versão e tudo normalizou. Fiquei 3 dias com esse problema me 
ferrando, para não dizer outra coisa, aqui no provedor.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031

Desculpem o desabafo mas puts essa me deixou chateado demais com o 
sistema, ainda mais pela importância que ele tem para o meu negócio 
hoje.


Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Fala Gondim,

esse tipo de problema é osso mesmo...

Pelo que leio e ouço, esses problemas nas releases se devem a pelo 
menos duas coisas: boa parte dos desenvolvedores não usam FreeBSD em 
seus computadores principais (Mac!) (ouçam o adrian@ desabafando no 
bsdnow 101 sobre comer sua própria comida de cachorro) e boa parte dos 
que usam FreeBSD usam o CURRENT (tipo eu :P). Então nós mesmos 
acabamos não vendo os problemas que saem nas releases e acabamos não 
tendo a mesma experiência que os usuário tem, e isso está muito errado...


Outra zica é que esses problemas as vezes são difíceis de se 
reproduzir, pelo pouco que olhei no google aqui parece que seu 
problema está relacionado com lagg + igb + condições de tráfego. As 
vezes se o cara não tiver acesso ao mesmo cenário fica foda achar o 

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Danilo Egea Gondolfo]

On 09/15/2015 06:28, Marcelo Gondim wrote:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que 
ficar dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano 
com esse problema. Tentei as listas e cheguei à fazer até um PR e 
nada. Um belo dia atualizei o router no STABLE e pronto, problema 
resolvido. O que foi feito não faço ideia mas resolveu depois de 1 ano 
de sofrimento de ter trocado todo o hardware e achando que era 
temperatura interna da X520-SR2.


Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
script testando e levantando a interface sempre que caía. Pura 
gambiarra, coisa feia de se ver em um sistema.  rsrsrsrsrs


Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí 
então resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às 
melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o 
sistema.


Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário de pico e subia o tráfego nesses laggs, simplesmente meu 
load subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com a 
operadora caía e levantava de 5 em 5 minutos me gerando grande 
problema aqui no provedor.


Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping


Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo 
erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e 
pronto! Tudo voltou à funcionar como era antes. Assim fica difícil 
confiar na estabilidade e robustez de um sistema. Só Deus sabe agora 
quando que isso será resolvido no sistema. 1 ano? 2 anos? Bem, vou 
começar à pensar em algo como Juniper porque pelo menos vou poder 
cobrar de alguém quando isso acontecer. Uns anos atrás saí do Linux 
para FreeBSD porque este resolveu meus problemas, coisas que o Linux 
não me atendia mas que agora está me deixando chateado com essas 
coisas. Saí do problema do ksoftirq do Linux para outros problemas de 
instabilidade no FreeBSD.


Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem 
PR, já comentei na freebsd-stable? Tudo bem que pode não afetar o 
sistema mas já acertaram na CURRENT faz tempo, pelo menos foi o que me 
disseram na lista. É uma coisa feia demais para um sistema tão bem 
trabalhado:


Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

 # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e 
cá estamos no 10.2 e continua esse bug horrendo.


Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando que 
isso vai ser resolvido porque ao meu ver isso é sério e muita gente 
usa lagg no sistema e com certeza é um problema porque voltei a versão 
e tudo normalizou. Fiquei 3 dias com esse problema me ferrando, para 
não dizer outra coisa, aqui no provedor.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031

Desculpem o desabafo mas puts essa me deixou chateado demais com o 
sistema, ainda mais pela importância que ele tem para o meu negócio hoje.


Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Fala Gondim,

esse tipo de problema é osso mesmo...

Pelo que leio e ouço, esses problemas nas releases se devem a pelo menos 
duas coisas: boa parte dos desenvolvedores não usam FreeBSD em seus 
computadores principais (Mac!) (ouçam o adrian@ desabafando no bsdnow 
101 sobre comer sua própria comida de cachorro) e boa parte dos que usam 
FreeBSD usam o CURRENT (tipo eu :P). Então nós mesmos acabamos não vendo 
os problemas que saem nas releases e acabamos não tendo a mesma 
experiência que os usuário tem, e isso está muito errado...


Outra zica é que esses problemas as vezes são difíceis de se reproduzir, 
pelo pouco que olhei no google aqui parece que seu problema está 
relacionado com lagg + igb + condições de tráfego. As vezes se o cara 
não tiver acesso ao mesmo cenário fica foda achar o problema.


Não sei qual é a sua política em relação a