Em 11/04/14 22:25, Patrick Tracanelli escreveu: > On 11/04/2014, at 21:34, Marcelo Gondim <gon...@bsdinfo.com.br> wrote: > >> Em 11/04/14 16:48, Luiz Otavio O Souza escreveu: >>> 2014-04-11 10:32 GMT-03:00 Luiz Otavio O Souza: >>>> 2014-04-10 15:58 GMT-03:00 Marcelo Gondim: >>>> >>>>> rede 192.168.0.0/24 <----> Router Local iBGP <----> Router Público BGP >>>>> <----> Internet >>>>> >>>>> O Router Local anuncia o prefixo 192.168.0.0/24 para o Router Público >>>>> BGP. Quando eu crio a vlan no Router Público BGP, a rede 192.168.0.0/24 >>>>> não chega e não passa mais pelo Router Público BGP. Mas do Router >>>>> Público eu pingo o Router Local e vice-versa. >>>> Gondim, >>>> >>>> Meu teste aqui foi o seguinte: >>>> >>>> Router teste <---> Router iBGP <---> Router Borda (eBGP) >>>> >>>> No seu ambiente e pela sua descrição você podia verificar se os >>>> anúncios do seu Router Local estão chegando no Router Publico e se as >>>> rotas necessárias para acesso da rede 192.168.0.0/24 ainda estão na >>>> fib. Imagino que no seu Router Local tudo funcione. >>>> >>>> Não há nenhuma configuração perdida no seu rc.local para essa >>>> interface ? Quando você cria a vlan ela aparece sem nenhuma >>>> configuração ? Enquanto ela não esta associada a nenhuma interface >>>> física seria muito dificil ela gerar algum problema: >>>> >>>> # ifconfig vlan666 create >>>> # ifconfig vlan666 >>>> vlan666: flags=8002<BROADCAST,MULTICAST> metric 0 mtu 1500 >>>> ether 00:00:00:00:00:00 >>>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >>>> vlan: 0 parent interface: <none> >>>> >>>> >>>> A tarde vou refazer os testes aqui com lagg. >>>> >>> Gondim, >>> >>> Sem novidades, mesmo com o lagg consigo criar as vlans aqui sem afetar >>> o funcionamento do sistema :/ >>> >> LooS, então eu fico aliviado e agora podemos praticamente ter certeza >> que o problema está no meu ambiente. To achando que pode ser por causa >> do problema com mac address com a operadora. >> Vou continuar testando e aviso à todos. >> >> Mas valeu pelo teste!!!! > Gondim, > > Fechei mais um BGP num ambiente pre operacao que deu pra testar muito, e > também não reproduzi o erro. Com lagg pra 3 eBGP, sem lagg com 1 iBGP, eBGP > sem lag com PTT CAS e PTT SP, taggeado em todas as portas. > > Fiz testes simples e sem erro. > > Fiz um shell script loopando “ifconfig vlanX create up" e destroy em 10 vlan > diferentes das em uso, e nada, so o consumo de CPU do bgpd ficando alto > enquanto rodava o shell e o "bgpctl sh int” variando entra valid e invalid > conforme as interfaces surgiam, ficavam up e eram destruidas. Sem afetar > nenhuma sessao BGP estabelecida, sem gerar perda de pacote, sem consumo > excessivo de CPU no Sys ou Interrupt, so mesmo CPU do user com o bgpd > sofrendo pra validar as interfaces “highlander” surgindo e sumindo. > > Ou seja tem alguma particularidade a mais no seu cenário, voce comentou > alguma coisa de mac address o que tem de diferente no mac? Quando voce da > vlan create altera alguma coisa no seu llinfo na sua tabela arp, voce > comparou? Seu kernel é generic, esta com debug? Nada estranho no dmesg, > debug.log, quando cria essas vlan? > > Fogo que é produção ne dificil testar… > > Quais as interfaces? em? igb? exgb? ou outra coisa? Aqui foram igb. > > Por acaso voce nao tem redundância desse bgp não ne? Com mesmo hardware, pra > poder fazer mais testes sem impactar na produção. > > Algum tuning diferente? > > Antes todos meus testes com FreeBSD 10 tinham sido em ambiente direto no fio, > sem vlan e sem lag. Criar vlan n impactava em nada. Mas agora fechando BGP em > vlan e em lagg tbm n impacto ou seja n sei… a única coisa que eu fiz foi > tirar virtio do kernel, pq apesar de pre-operacao jaja entra em produção e > foi customizado alguma coisa. > E aí mestre Patrick. :)
Então, esse lance de mac é o seguinte: de outubro/2013 pra cá nenhum mac address passa direito pelo Datacom que está entre eu e a operadora de clear channel que me transporta até as cidades que atendo. Olha o que acontece com faço um arping: # arping -i em3 186.xxx.x.149 ARPING 186.xxx.x.149 Timeout Timeout Timeout Timeout Timeout Timeout Timeout Timeout Timeout 60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=0 time=609.552 usec Timeout 60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=1 time=496.451 usec Timeout 60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=2 time=641.974 usec Timeout Timeout Timeout 60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=3 time=575.442 usec Timeout Timeout Timeout ^C --- 186.xxx.x.149 statistics --- 22 packets transmitted, 4 packets received, 82% unanswered (0 extra) rtt min/avg/max/std-dev = 0.496/0.581/0.642/0.054 ms Essa interface em3 também está ligada nesse Datacom na porta 3. As interfaces do lagg estão ligadas nas portas 1 e 2 do Datacom. Todo mundo que passa por esse Datacom está fazendo isso. Aí sou obrigado à fixar o mac address das interfaces de cada cidade na minha tabela arp do router pra que funcione tudo certinho. Todas as interfaces são em(4) Intel PRO/1000 PT Dual Port PCI-e. Tentei ver no momento do problema como estavam a fib e a rib no bgp e pareciam normais. Nos logs não vi erro. Tentei rodar o /etc/rc e também o /etc/netstart para ver se voltava à funcionar, fiz tanta coisa, matei o serviço e tudo e teve um momento que eu reiniciei o ibgp em cada cidade e voltou à funcionar mas não consegui reproduzir a façanha. HaHaHaHaHA Patrick, pode ser aquele problema que você comentou sobre alguns chipsets em(4)? Grande abraço, Gondim ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
