Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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
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
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] ipfw table list reportando endereçamento errado. // era "Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE"
novidades? seria interessante reportar o status do ipfw(8) atual na 10.2-STABLE. chegou a atualizar a máquina do blog (bsdinfo) , como vc falou? -- 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] ipfw table list reportando endereçamento errado. // era "Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE"
On 21-09-2015 15:28, Vinícius Zavam wrote: novidades? seria interessante reportar o status do ipfw(8) atual na 10.2-STABLE. chegou a atualizar a máquina do blog (bsdinfo) , como vc falou? Sim e reportei no PR no mesmo dia que testei. Inclusive nos 2 PR sobre o mesmo assunto do ipfw. Mas estranhamente meus comentários sumiram dos 2 reports. Aff. Ficou 100% o ipfw. :) Vou lá novamente comentar [1] e [2]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200169 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189471 Quanto ao problema do lagg continuo na mesma. O lado do Juniper fez uma nova configuração de periodic slow e deu uma melhorada nas mensagens do lacp. Agora eu vejo os transmit e receive dos laggs de 30 em 30 segundos normalmente. Mas quarta ou quinta vou migrar os 2 laggs que tenho para uma Intel X520-SR2 que tem 2 portas de 10GbE e aí não vou mais usar o lagg. Uma pena porque não vou conseguir mais fazer os testes. É torcer para que outra pessoa com um tráfego como o meu de 4.5Gbps, usando lagg e tenha o mesmo problema pra poder dar continuidade. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
