2015-09-18 15:18 GMT-03:00 Marcelo Gondim <gon...@bsdinfo.com.br>: > 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?
salvo engano, naquelas mesmas threads que enviei aqui já tinha um exemplo de config utilizado juniper. // tu estás a usar fastforwarding? seguiu algum manual para tuning adicional? páginas e manuais da juniper recomendam que tipo de configuração com freebsd/lagg? " 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 receivemessagesfrom the switch, and only took a channel down if the link state wentdown. " :-) -- 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
