[GTER] Controle de banda no JUNOS

Fri Oct 5 22:50:16 -03 2012

Senhores,
O assunto é tão interessante, que acabei de comprar um livro sobre a nova
arquitetura Juniper MX (TRIO CHIPSET). A resposta para o problema do Fábio
é que esta linha de roteadores leva em consideração a camada 1, adicionando
20bytes de overhead para shaping e queues.

O trecho abaixo do livro, compara a arquitetura anterior e a atual.

ADPC line cards base their shaping and queue statistics on Layer 2, which
or untagged Ethernet equates to an additional 18 bytes of overhead per
packet
MAC addresses, Type code, and FCS). In contrast, Trio chip sets compute
queue
tatistics on Layer 1, which for Ethernet equates to an additional 20 bytes
in the
orm of the 8 byte preamble and the 12 byte inter-packet gap. Note that Trio
RED
rop statistics are based on Layer 2 as the Layer 1 overhead is not part of
the frame
nd is therefore not stored in any buffer.

Fonte: Juniper MX Series
A Comprehensive Guide to Trio Technologies on the MX

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

Em 5 de outubro de 2012 12:53, Gustavo Santos <gustkiller at gmail.com>escreveu:

> É 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
>>
>
>