On 01/07/2013 15:25, Eduardo Schoedler wrote: > Em 1 de julho de 2013 15:23, Marcelo Gondim <gon...@bsdinfo.com.br>escreveu: > >> Em 01/07/13 14:45, Samuel Peres escreveu: >>> On 01/07/2013 13:12, Renato Frederick wrote: >>>> Em 01/07/13 10:22, Eduardo Schoedler escreveu: >>>>> Em 1 de julho de 2013 09:37, Francisco Cardoso <frica...@bsd.com.br >>> escreveu: >>>>>> Em 28 de junho de 2013 18:00, Marcelo Gondim <gon...@bsdinfo.com.br> >>>>>> escreveu: >>>>>>> Pessoal, >>>>>>> >>>>>>> Um amigo meu está com um router FreeBSD usando quagga e fechando BGP >> com >>>>>>> um PTT. Sendo que o pessoal do PTT está alegando que o sistema >> FreeBSD >>>>>>> dele não está aceitando receber mais de 500 mac address na interface >> e >>>>>>> por isso está dando problemas com o roteamento. >>>>>>> >>>>>>> Alguém sabe ou já passou por um problema desses? Existe alguma sysctl >>>>>>> que limita isso? Essa pra mim foi novidade. >>>>>>> >>>>>>> Grande abraço pessoal, >>>>>>> >>>>>>> Gondim >>>>>> O problema foi resolvido? Pra mim isso também é novidade. Além disso, >>>>>> qual a lógica de existir um limite tão baixo? >>>>>> >>>>> Imagine que você quer prover trânsito "clear channel" (lan-2-lan) entre >>>>> duas redes, por dentro da sua rede metro. >>>>> Você vai lá, cria uma VLAN, entrega uma porta de cada lado para seu >> cliente >>>>> e está feito, certo? >>>>> >>>>> Sim e não. >>>>> Imagine que seu cliente tem muitos equipamentos dos dois lados. >>>>> Multiplique isso pela quantidade de clientes que você tem. >>>>> >>>>> Logo logo a tabela MAC dos seus switches da sua rede metro irão >> estourar. >>>>> O correto é você isolar esse tráfego, com Q-in-Q por exemplo. >>>>> VPLS/VPWS também é uma ótima saída. >>>>> >>>>> Abs, >>>> Isto aí.... tem que parametrizar estas configurações em todo o segmento >>>> de rede, de modo a permitir que o PTT funcione adequadamente! É bom >>>> limitar o número de MACs aprendidos, por segurança, mas devemos calcular >>>> no caso do PTT quantos virão, já que tem gente que tem redundância >>>> usando CARP ou algo assim. >>>> >>>> >>> Marcelo, >>> >>> Acredito que o problema esteja na sysctl net.inet.icmp.icmplim. Durante >>> o período de testes do PTT, eles fazem muitas requisições ICMP >>> simultâneas com IP de origem dos participantes, se essa sysctl estiver >>> com um valor baixo, vai dar problema, visto que os mac-address dos >>> participantes não serão adicionados a tabela arp. Não tem nada haver com >>> limite de mac-address no FreeBSD. Acho que é isso, testa ai. >>> >> Boa Samuel, >> >> Vou passar pra ele isso. Vamos ver se vai resolver e aí resolvendo eu >> posto aqui. > > > Esse parâmetro não tem nada a ver com o sintoma que estão falando. > É meramente um rate-limit de ICMP, não limita em nada a quantidade de > endereços de hardware na tabela ARP. > Eduardo,
O limite não está relacionado a tabela ARP e sim a pacotes ICMP. Se o FreeBSD estiver limitando a quantidade de requisições ICMP a 100 por segundo por exemplo, durante os testes do PTT, se eles enviarem 1000 requisições ICMP partindo de 1000 IPs distintos, vai ter drop de pacotes ICMP. Consequentemente, se o cara que administra o FreeBSD rodar um arp -a no momento do teste, não vai ver os 1000 ip/mac-address, vai ver no máximo 100. Qual a conclusão dos caras do PTT? Limite de mac-address do roteador, switch do transporte, etc. Ok? Samuel Peres ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd