[GTER] Controle de banda no JUNOS

[Gustavo Santos]

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
>