[GTER] Controle de banda no JUNOS
Gustavo Santos
gustkiller at gmail.com
Sat Oct 6 18:54:03 -03 2012
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