[GTER] Controle de banda no JUNOS

Fri Oct 5 12:53:09 -03 2012

É bem difícil para não dizer impossível, conseguir um controle de banda
perfeito em granularidade muito baixa, com rajada permitida baixa. Vamos
para o exemplo:

O cliente contratou 100Mbits com você e você entrega em uma interface de
1Gbps. A interface sempre estará transmitindo a 1Gbps o que chegar nela.
Entretanto, os algorótimos para controle e suavização de tráfego, vão
trabalhar para deixar mais ou menos na velocidade setada.

Dividido o em time slots de 100 ms, uma interface de 1Gbps, consegue
entregar 100mbis em 100ms, e para ter uma média de 100mbis por segundo
limitado, a interface ficaria 900ms sem transmitir, conseguindo uma média
de 100mbps por segundo. Outro detalhe é que para ativar o mecanismo de
controle, a banda tem ser excedida. Quando ela é excedida, é possível
chegar em 100milisegundos, tráfego de 1gbps para este cliente neste time
slot.

Então teoricamente  a "limitador" vai  dropar o tráfego pelos próximos
900ms, para que o transmissor ( downloads do seu cliente), reduzam a
velocidade de transmissão ao perceber que não receberam ack na velocidade
que esperavam.

Desculpe a forma resumida, mas é mais ou menos isto que acontece nos
controles de banda para velocidades menores que a interface conectada do
cliente.

Já fez um teste baixando vários arquivos ou torrents de grande
popularidade, ou está fazendo testes com um único fluxo? Temos roteadores
iguais ao seu e da forma que o Diego informou com burst de 625k, nas médias
de a partir de 1 minuto no Cacti, o gráfico fica praticamente perfeito com
o contratado.

Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER

Em 5 de outubro de 2012 08:42, Fábio - RJ Network
<fabio at rjnetwork.com.br>escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>