[GTER] Controle de banda no JUNOS
Diogo Montagner
diogo.montagner at gmail.com
Sat Oct 6 02:03:30 -03 2012
Apenas lembre que há duas coisas diferentes neste tópico:
- policers
- shaping do CoS
Eles atuam de forma totalmente diferente. O shaping do CoS é mais TCP-friendly.
Você pode tentar manipular o accounting do shaping caso você esteja
utilizando hardware com funcionalidades de CoS avançada, tais como IQ
e DPC-EQ.
http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/traffic-control-profiles-edit-cos.html
http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/overhead-accounting-edit-cos.html
[]s
./diogo -montagner
JNCIE-SP 0x41A
2012/10/6 Gustavo Santos <gustkiller at gmail.com>:
> 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
>>>
>>
>>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list