Fala Gondim, > 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
Tem uma cara danada de buffer de arp em exaustão, por flapping cacheando ou por limite mesmo. > 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. Pois é ja vi isso acontecer (ou parecido) em um Datacom DM3000 mas não era flapping bem arp flood nem nada mais comum, eram excessos de frame de vlan, que depois descobrimos que era causado quando havia Q-in-Q (vlan sobre vlan), teoricamente sem qualquer justificativa mas qualquer Q-in-Q geravam frames excessivos e acabava recurso do DM3000 ele começava rejeitar atualização na tabela ARP como primeiro indicio e de tempos em tempos caia inteiro, parecia um reset, e ai voltava normalizado, contadores zerados, ARP funcionava por um tempo, depois começava de novo. > 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 bgpctl sh int na hora do problema, voce deu? as interfaces estava validas e ok? arp -an tinha o MAC dos seus peers bgp ok? Outra coisa as NIC conectadas na vlan tem IP? Ou não são endereçadas? Se não forem endereçadas voce deu up na mão ao recriar uma vlan, tanto na NIC quanto na vlan? Por acaso as flags da NIC com FreeBSD 10 ficam diferente do 9? > Patrick, pode ser aquele problema que você comentou sobre alguns > chipsets em(4)? Acho que não, de qq forma qual chipset? Hoje fiz os testes que comentei em uma maquina com chipset que apresenta esse problema se manter autoselect, por isso acho que não tem relação não. Não foram testes tão intensos pq essa esta em produção (ServerU) mas com lagg e com em(4) chip 82574L, 3 sessões eBGP. Nada de problema nos create/destroy de vlan na mão, nem lagg. Fora seu Datacom, que é o mesmo que não da problemas com FreeBSD 9, tem mais coisa ai no seu ambiente ainda diferente dos que eu consegui testar. Por desencargo tem Q-in-Q no seu ambiente? Mesmo que não na sua porta, alguma outra que chega no Datacom? > > 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
