[GTER] Controle de banda no JUNOS
Diogo Montagner
diogo.montagner at gmail.com
Sun Oct 7 08:17:21 -03 2012
Gustavo,
a sua informação está correta. A que eu passei para o Rubens no início
não está :-(
Rubens,
os headers L1/L2 são removidos (encap/decap) na entrada da MPC. A
diferença é que na MPC, a informação do tamanho do frame é preservada
durante o caminho (walkthrough) do pacote.
[]s,
./diogo -montagner
JNCIE-SP 0x41A
2012/10/7 Gustavo Santos <gustkiller at gmail.com>:
> Diego,
>
> Segue tabela dos linecards. Como a serie entry level ( MX 5 até 80) vem com
> line cards MCP (trio based), ele contabiliza o layer 1.
>
>
> http://imageshack.us/a/img842/8302/trioip.jpg
>
>
> Gustavo Santos
> Analista de Redes
> CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
>
>
>
> Em 6 de outubro de 2012 18:54, Gustavo Santos <gustkiller at gmail.com>escreveu:
>
>> Diego,
>>
>> Uma pessoa na lista Juniper-NSP , informou o seguinte, e passou o comando
>> para ajustar o overhead, bate com a informação do livro. Isto em relação as
>> PICs padrão da serie MX5 até MX80.
>>
>>
>> HI,
>>
>> I suspect that much of your problem is that the MX boxes by default count
>> L1 stuff like IFG-preamble (20 bytes in all).
>>
>> You can adjust the counting overhead for the PIC like so:
>>
>> grant at mx80a> show configuration chassis
>> fpc 0 {
>> pic 0 {
>> traffic-manager {
>> egress-shaping-overhead -20;
>> }
>> }
>> pic 1 {
>> traffic-manager {
>> egress-shaping-overhead -20;
>> }
>> }
>> }
>> network-services all-ethernet;
>>
>> There are ways to do it per IFL, but I don't have an example handy.
>> Hopefully Harry or Doug will chime in.
>>
>> --Duane
>>
>>
>>
>> http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/traffic-manager-edit-chassis.html
>>
>>
>> Gustavo Santos
>> Analista de Redes
>> CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
>>
>>
>>
>> Em 6 de outubro de 2012 02:03, Diogo Montagner <diogo.montagner at gmail.com>escreveu:
>>
>> 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
>>> --
>>> 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