[GTER] Controle de banda no JUNOS

Fri Oct 5 08:42:04 -03 2012

Diogo

Sei que não existe resposta única para o cálculo do burst. No CISCO também
utilizo uma forma diferente, que atende a minha necessidade específica e
para isso não uso o padrão do fabricante.

Gustavo

Na verdade o cliente utiliza a visualização com média de 5 minutos, eu é
que estou monitorando, nesse teste, com 5 segundos, mas tanto faz, em
nenhum dos dois modos eu consigo a "banda contratada".
Colocar uma gordurinha a mais na banda do cliente não é problema. O
problema é eu entender o porquê hehehe

Obrigado a todos, vou fazer mais uns testes e se eu conseguir algo
diferente volto para informá-los.

Fábio

Em 4 de outubro de 2012 16:33, Gustavo Santos <gustkiller at gmail.com>escreveu:

> Utilizo esta formula mesmo.
>
> Fabio medir tráfego com média de 5 segundos, é bem difícil o valor ficar
> exato. Seu cliente vai receber o gráfico com esta granularidade? Aqui
> utilizamos no Juniper,  gráficos no Cacti de com granularidade de 1 minuto
> e na média deste minuto a banda é praticamente 100%  do  configurado no
> policer.  Principalmente que para haver o "controle" a banda "tem" que ser
> excedida, exceto quando o limite é físico da interface.
>
> E tem o que o Diego falou. Se cliente não tiver noção nenhuma de como
> funciona banda, protocolos , tcp , janelamento , limites e controles, e se
> a dor de cabeça não vale a pena, coloque 1mbit a mais..  Vide a GVT que
> coloca de 2 a 3mbits a mais no ADSL, que independente das perdas do
> protocolo, sempre em testes de velocidade da uma velocidade maior que a
> contratada..
>
>
> [1] Um cliente pode usar mais banda que o outro: problema do ganha
> mais quem chora mais :-)
>
> Gustavo Santos
> Analista de Redes
> CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
>
>
>
> Em 4 de outubro de 2012 12:10, Diogo Montagner
> <diogo.montagner at gmail.com>escreveu:
>
> > Não existe uma resposta única para o cálculo do burst.
> >
> > Algumas informações para ajudar (ou complicar de vez :-) ):
> >
> > - todos os policer do JUNOS usam o algoritmo de token bucket
> > - considera o pacote e não o frame, isto é, os headers L1/L2 não são
> > incluídos no policiamento
> > - burst muito pequeno implica em não atingir a velocidade máxima
> policiada
> > - burst muito grande implica em problemas [1] quando o tráfego de
> > multiplos clientes são jogados em uma única fila de saída (em outras
> > palavras, quando não há qos aplicado)
> > - burst pequeno significa controle forçado do tráfego policiado (1M
> > passa só 1M e não 1.01M) - mas lembre do item anterior referente ao
> > problema de burst muito pequeno
> >
> > Existe a fórmula para calcular o melhor burst size. Eu costumo usar o
> > seguinte:
> >
> > - qualquer interface < 1G, eu uso a fórmula
> > - interface física de 1G: burst de 625k (independente da banda
> > policiada por vlan)
> > - interface física de 10G: burst de 6250k (independente da banda
> > policiada por vlan)
> >
> > A melhor resposta de todas: encontre o melhor burst-limit para a sua
> > aplicação. Como ? Fazendo testes.
> >
> > Você pode ajustar o burst para melhor atender o perfil de tráfego de
> > cada aplicação. Mas esse caso é quando você já está utilizando um
> > nível bem avançado de QoS. É quando você começa criar perfis de CoS
> > para diferentes tipos de aplição: voz, VoD, Video Real-Time,
> > transações financeiras, etc.
> >
> > [1] Um cliente pode usar mais banda que o outro: problema do ganha
> > mais quem chora mais :-)
> >
> > []s
> >
> > ./diogo -montagner
> > JNCIE-SP 0x41A
> >
> >
> > 2012/10/4 Gustavo Santos <gustkiller at gmail.com>:
> > > Segue o DOC.
> > >
> > >
> >
> http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/general/policer-guidelines-burst-size-calculating.html
> > >
> > >
> > > O burst é baseado na velocidade da interface física e não na velocidade
> > do
> > > rate limit.
> > >
> > >
> > > Gustavo Santos
> > > Analista de Redes
> > > CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
> > >
> > >
> > >
> > > Em 3 de outubro de 2012 14:06, Gustavo Santos <gustkiller at gmail.com
> > >escreveu:
> > >
> > >> Existe um documento do junos que explica como o burst deve ser
> > >> configurado. O que me lembro de cabeça eh que um burst muito baixo,
> não
> > vai
> > >> dar tempo de permitir o tcp da origem do tráfego se adaptar ao rate
> > limit.
> > >> Com isto, o valor fica sempre menor. mas utilizando o valor que
> > informei,
> > >> deve funcionar, pois eh baseado na mtu da interface vezes variável x.
> > >>
> > >> Já já envio o doc.
> > >>
> > >> Enviado via galaxy note.
> > >> Em 03/10/2012 13:56, "Gustavo Santos" <gustkiller at gmail.com>
> escreveu:
> > >>
> > >> Coloque o burst em 625k.
> > >>>
> > >>> Enviado via galaxy note.
> > >>> Em 03/10/2012 12:39, "Fábio - RJ Network" <fabio at rjnetwork.com.br>
> > >>> escreveu:
> > >>>
> > >>>> Tenho algumas dúvidas com relação ao controle de banda no JUNOS.
> > >>>>
> > >>>> Estou fazendo uns testes com uma configuração mais ou menos assim:
> > >>>> policer
> > >>>> e shaping.
> > >>>>
> > >>>> set groups CLIENTE
> > >>>> interfaces ae0 unit 10 family inet policer input 10m
> > >>>> interfaces ae0 unit 10 family inet6 policer input 10m
> > >>>> class-of-service interfaces ae0 unit 10 shaping-rate 10m
> > >>>> firewall policer 10m logical-interface-policer
> > >>>> firewall policer 10m if-exceeding bandwidth-limit 10m
> > >>>> firewall policer 10m if-exceeding burst-size-limit 64k
> > >>>> firewall policer 10m then discard
> > >>>>
> > >>>> Reparei que esse controle não está funcionando corretamente. Quando
> o
> > >>>> link
> > >>>> é pequeno, a diferença é pouca. Com 2Mbps, por exemplo, consigo
> chegar
> > >>>> até
> > >>>> 1.94Mbps. Se eu alterar o controle para 2.1Mbps, chego em 2Mbps.
> > >>>>
> > >>>> Mas aumentando o link para 150Mbps, não consigo utilizar mais que
> > >>>> 145Mbps.
> > >>>>
> > >>>> No exemplo, fiz uma alteração trocando 10m por 10000000, mas não
> notei
> > >>>> muita diferença.
> > >>>>
> > >>>> Alguém tem ideia do que pode estar ocorrendo? Alguém usa esse
> > controle de
> > >>>> maneira diferente?
> > >>>>
> > >>>> Dê repente estou fazendo alguma coisa errada, então quero primeiro
> > >>>> entender
> > >>>> os porquês antes de solicitar um apoio da Juniper.
> > >>>>
> > >>>> Qualquer experiência sobre o assunto é bem vinda.
> > >>>>
> > >>>> --
> > >>>> Fábio R. Hernandes
> > >>>> RJ Network - Tecnologia Integrada
> > >>>> Fone: (17) 3211 4211
> > >>>> www.rjnetwork.com.br
> > >>>> --
> > >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > >>>>
> > >>>
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>