Em 1 de julho de 2013 15:54, Samuel Peres <samuelpe...@migtelecom.com.br>escreveu:
> 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, Isso é apenas uma proteção do FreeBSD contra flood. Note que o assunto dessa thread é: "Limitação de mac address por interface", ou seja, estamos falando de endereços MAC... e não de pacotes ICMP. Att, -- Eduardo Schoedler ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
