[GTER] Controle de banda no JUNOS
Gustavo Santos
gustkiller at gmail.com
Sat Oct 6 21:29:14 -03 2012
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
>>
>
>
More information about the gter
mailing list