Na verdade, na prática funciona(funcionava, já que faz 2 anos que não trabalho em ISPs não sei como anda a situação de fluxo nas wans) em 99% dos casos, já que a maior parte do fluxo é(era?) TCP que tem controle de fluxo. Deve funcionar ainda, senão os ISPs não fariam TS. Usando shaping no mínimo tu controla o fluxo TCP, UDP e outros aí é questão de sorte. Shaping não é feito somente por descarte, é feito também por retenção de pacotes na fila, se a fila encher, ele descarta, tanto que uma fila com tamanho errado pode dar a maior dor de cabeça.
IP ta ficando "barato". Claro que demais também não adianta, tem que ter bom senso. Sempre tentei manter os links no máximo em 80% de uso, ao chegar nesse valor pedia a ampliação, quando começava a passar de 90% ficava crítico, mas esse é um cenário ideal, nem sempre as condições financeiras permitem isso. Outra dica é usar a marcação DSCP. Se for um equipamento ATA, eles marcam os pacotes no com 0xb8, alguns dão a opção de escolher qual a marcação que tu deseja usar, o asterisk também permite escolher o DiffServ. Mas isto vale apenas para os pacotes dentro da sua rede, já que os "grandes"(embromatel & fOI), em tese, resetam o DSCP em seus roteadores. 2011/1/6 Fabiano Carlos Heringer <b...@grupoheringer.com.br> > Entendi... > > Entao resumindo, o negocio é ter link sobrando, ou de preferencia um > dedicado para o voip e mais nada... > > No caso de trabalhar nao com shapping, definindo limites, mas definindo > prioridades, onde o trafego voip passaria na frente de todos, isso pode > melhorar alguma coisa na qualidade? Meu problema é quando o link dá uma > saturada, mesmo que seja temporaria, naquela a ligacao vai pro saco... > > []´s > > Em 06/01/2011 18:07, Eduardo Schoedler escreveu: > > Na prática, não adianta fazer shaping de entrada (pass in na wan)... > > O pacote já chegou, já gastou seu link... fazer shaping seria descartar > > alguns pacotes para forçar o reenvio. > > O certo é ter link sobrando, ou fazer shaping no lado da operadora (pass > out > > dela). > > > > Se você mesmo assim fizer shaping de entrada, se você estiver com todo > seu > > link em uso (download), a ligação ficará bem ruim até seu firewall > descarte > > alguns pacotes das queues que não são de voip e aquele tráfego diminuir. > > > > Lembre-se: shaping é feito por descarte de pacotes. > > > > > > > >> -----Mensagem original----- > >> De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em > >> nome de Fabiano Carlos Heringer > >> Enviada em: quinta-feira, 6 de janeiro de 2011 19:01 > >> Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > >> Assunto: Re: [FUG-BR] Controlar Banda para voip > >> > >> Em 06/01/2011 09:54, Luiz Otavio O Souza escreveu: > >>> On Jan 6, 2011, at 1:29 AM, Fabiano Carlos Heringer wrote: > >>> > >>>> Cara, nao consigo entender... > >>>> > >>>> Voce poderia me dar um exemplo de um trafego http por exemplo, tendo > >> a > >>>> regra para download/upload ...em uma rede com NAT. > >>>> > >>>> Obrigado! > >>>> > >>>> Em 05/01/2011 21:00, Nenhum_de_Nos escreveu: > >>>>> On Wed, January 5, 2011 10:26, Fabiano Carlos Heringer wrote: > >>>>>> Deixa ver se entendi hehehehe... > >>>>>> > >>>>>> Na verdade o meu download entra na interface externa, processa no > >>>>>> firewall e sai pela interface interna. > >>>>>> o upload entra na interface interna e sai pela interface externa, > >> correto? > >>>>> correto > >>>>> > >>>>>> Eu nao poderia controlar somente o in/out da interface externa? > >>>>> não. só se pode fazer fila de saída. > >>>>> > >>>>> matheus > >>> Fabiano, > >>> > >>> Existe um pequeno detalhe na implementação do controle de banda que o > >> Matheus tentou te explicar acima... > >>> Não há como você controlar a entrada do seu link (se amanhã a > >> internet enlouquecer e achar que seu IP é o default gateway do mundo > >> você pode filtrar o que quiser, mas nunca vai conseguir receber nada > >> _util_ nesse link - você não tem controle do que enviam para você). > >>> Dessa maneira o openbsd implementou o controle apenas no envio (fila > >> só na saída, como disse o matheus). > >>> Entao você trata o download na saída da interface interna e o upload > >> na saída da interface externa, simples assim. > >>> O controle de entrada será feito com base nos próprios controles de > >> congestionamento do TCP, você escala sua janela de recepção de forma a > >> dizer: ei, você aí, não posso receber e processar esses dados tão > >> rapidamente, por favor reduza sua taxa de envio. O que 'deve' funcionar > >> bem quando todos os envolvidos aceitam e seguem essas sugestões. > >>> Já no caso de um ataque, você simplesmente ignora todas essas > >> sugestões e ajustes automáticos do protocolo e continua empurrando > >> tudo o que pode para o endereço alvo (que em outras palavras, quer > >> dizer: você _não_ tem controle da entrada do seu link). > >>> Ou seja, com esse controle apenas razoável do seu link e, se o seu > >> link esta muito pequeno para o VoIP + outros usos, não há controle de > >> banda que resolva ;) > >>> Todo link precisa de uma pequena folga para lidar com essa parte > >> 'fora do seu controle' (ao menos se você deseja garantir alguma > >> qualidade - OU - você tem controle absoluto das duas pontas...) > >>> Att., > >>> Luiz > >>> > >>> ------------------------- > >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >>> > >> Ola Luiz, obrigado pelas informações... > >> > >> So para fechar, > >> > >> quais entao seriam as reais diferenças nas sintaxes do PF, pass in e > >> pass out? Como voce mesmo explicou, eu so controlo saida, entao qual o > >> sentido do pass in ? > >> > >> Ja li varios topicos sobre o assunto, mas ainda nao consegui entender a > >> real diferenca... > >> > >> Em casos onde existam o NAT, isso muda alguma coisa? > >> > >> Desculpe a insistência.. > > ------------------------- > > 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 > -- /* * Klaus Schneider */ ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd