On 18-09-2015 15:02, Vinícius Zavam wrote:
2015-09-18 11:52 GMT-03:00 Marcelo Gondim <gon...@bsdinfo.com.br>:
On 18-09-2015 11:06, Vinícius Zavam wrote:
2015-09-17 19:20 GMT-03:00 Marcelo Gondim <gon...@bsdinfo.com.br>:
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 <gon...@bsdinfo.com.br>:
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&revision=287723
Abrs,
Gondim
É não adiantou. Coloquei a stable mais recente e deu problema. O
problema
é tão sinistro que reparei o seguinte:
Quando está carregando as minhas sessões BGP com o 10.2-STABLE de
ontem,
o
load fica em 14.x 15.x e com o pico de tráfego o load chega em 40.x
53.x
Com o 10.1-STABLE r281235 o load na carga do BGP fica em 4.x e no pico
de
tráfego fica em 8.x e 12.x. Teve alguma mudança que afetou
absurdamente a
performance do sistema. Agora o que mudou que degradou tanto isso é que
não
faço a menor ideia. :(
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200169
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189471
Ih Egypcio to desde o 10.0 acompanhando esse bug, sempre vai sair uma
nova release mando e-mail pra freebsd-stable. hahahah acho que só vai ser
consertado o dia que o 11.x virar release.
Que por sinal o ipfw no 11.x ficou bem interessante mesmo.
[]'s
Gondim
respondi vc com o link do commit feito pelo melifaro@ a poucos minutos
lá
na outra thread, sobre o ipfw.
voltando às dificuldades que tu tens com lagg, também escovou as
configurações do switch? parâmetros do ifconfig, para o lagg+interfaces?
isso é importante.
Então, essa lagg que tá dando esses paus mas que já to achando que pode
ser em outro lugar, é feita direto com um Juniper MX5. Lá eles tem outras
laggs com outras empresas e estão todas funcionando redondo. Só a nossa que
deu esse pau.
Uma outra coisa que reparei; mas que acontece com a versão sem problemas e
com a versão problemática é o seguinte:
Quando habilito sysctl net.link.lagg.lacp.debug=1 e olho no messages
pipocam e segundo em segundo isso aqui:
Sep 18 15:15:10 rt01 kernel: igb4: lacpdu transmit
Sep 18 15:15:10 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
Sep 18 15:15:10 rt01 kernel:
actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:10 rt01 kernel:
partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
Sep 18 15:15:10 rt01 kernel:
partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:10 rt01 kernel: maxdelay=0
Sep 18 15:15:11 rt01 kernel: igb5: lacpdu transmit
Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006)
Sep 18 15:15:11 rt01 kernel:
actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:11 rt01 kernel:
partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004)
Sep 18 15:15:11 rt01 kernel:
partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:11 rt01 kernel: maxdelay=0
Sep 18 15:15:11 rt01 kernel: igb4: lacpdu transmit
Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
Sep 18 15:15:11 rt01 kernel:
actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:11 rt01 kernel:
partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
Sep 18 15:15:11 rt01 kernel:
partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:11 rt01 kernel: maxdelay=0
Sep 18 15:15:12 rt01 kernel: igb5: lacpdu transmit
Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006)
Sep 18 15:15:12 rt01 kernel:
actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:12 rt01 kernel:
partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004)
Sep 18 15:15:12 rt01 kernel:
partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:12 rt01 kernel: maxdelay=0
Sep 18 15:15:12 rt01 kernel: igb4: lacpdu transmit
Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
Sep 18 15:15:12 rt01 kernel:
actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:12 rt01 kernel:
partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
Sep 18 15:15:12 rt01 kernel:
partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
Sep 18 15:15:12 rt01 kernel: maxdelay=0
Com a lagg que tenho com o PTT, que usa a igb6 e igb7, isso não acontece
ou acontece raramente. Poderia isso estar causando o load alto e o problema
na lagg quando usando o 10.2-release e o 10.2-stable?
