[caiu] É normal perder pacote usando juniper!

Domingo Março 11 16:18:30 BRT 2012

Muito bom Tadeu, explanou muito bem o assunto, contudo um ponto a ser
analisado.

Em 11 de março de 2012 15:43, Marcos Tadeu <marcos at telecom.uff.br> escreveu:

> > Você tem de começar a ter monitoramento na casa dos segundos, é outra
> visão do negocio.
>
> E ai, neste caso de monitorar média de uso durante um segundo, você
> chegará a conclusão de que seus links tem que ser de (número de clientes
> simultâneos) * (capacidade da interface ethernet de cada um).
> Se quiser monitorar em segundos ou milesegundos, chegarás a conclusão
> que nenhum link menor que a capacidade de sua interface ethernet é
> suficiente, pois sempre chegarão a 100% (neurose pura).
> É necessário bom senso e ler os contratos com os clientes.
> Lembremo-nos:
> 1) Todo link opera na capacidade máxima, durante o período em que está
> transitando dados.
> 2) A ocupação percentual é SEMPRE uma média entre o tempo em que está
> transmitindo (sempre a 100% da capacidade) e o tempo total considerado
> para tirar a média.
> Então, no limite (engenharia/matemática), quando o tempo de medição em
> que se tira a média tende para zero, ou você vai ter 100% de ocupação,
> se o canal estiver transmitindo, ou vai ter 0%, no intervalo entre
> transmissões. E ai? Seu link está sempre saturado, ou sempre vazio? Os
> dois! Por isso se usa média.
>

A interface não terá sempre 100% de utilização, a velocidade de transmissão
será sim na maior velocidade da interface ( se considerarmos
1000Mbits/Segundo, será sempre 100% em condições operacionais adequadas),
porém precisará de 100Mbits de dados para enviar naquele segundo para
utilizar a interface em 100% no dado segundo, do contrario será usado a
velocidade toda de transferencia para transferir XMbits, em resumo se um
cliente tem 10Mbits de dados, para enviar esses 10Mbits será enviados em
uma velocidade de 100Mbits/Segundo, porem na medição demonstrará que ele de
fato utilizou apenas 10% do total da interface.

Espero que compreenda, acho que ficou meio confuso !!

> 3) Os pacotes chegam via ethernet a 100Mbps ou 1Gbps (ou mais). Então,
> durante o tempo decorrido desde a chegada do pacote no roteador e o
> término de sua transmissão pelo link, o canal estará "saturado", ocupado
> a 100%, até o buffer de transmissão ser esvaziado.
> 4) A perda de pacotes com canais fisicamente OK (sem perda no enlace
> físico) só ocorre se o tamanho da memória do buffer de transmissão não
> for suficiente para guardar os próximos pacotes que chegarem, seja por
> limitação de configuração ou pequena capacidade física em sistemas SOHO,
> ou grande divergência de banda devido a picos de tráfego. Nestes casos,
> pacotes são descartados. Configurações de QoS também podem alterar este
> quadro, colocando determinados tipos de pacotes em filas diferentes, com
> seu próprio buffer. Assim, é possível a um provedor mascarar a saturação
> para seus clientes, ao fazer pings passarem que é uma maravilha, devido
> à prioridade, enquanto a saturação só aparece para P2P, com fila pequena
> e banda limitada, ou outros, como TCP/80, na fila "normal".
>

Infelizmente tratamento de QoS pode vir a ser um tiro no Pé pois o que se
economiza de banda se perde em processamento, latencia adcional.
É valido para ambientes empresariais, contudo fazer isso em Provedor, e
esse provedor ter um crescimento exponencial de clientes em curto espaço de
tempo, tenderá a ter uma queda na qualidade do serviços devido ao alto
consumo de CPU dos roteadores que tratarão o QoS.

> 5) Por último: o que foi prometido para o cliente? Não é a toa que aDSLs
> garantem, em contrato, apenas 10% da banda. No caso de momentos de pico...
>

Por isso que venho me tornando fã da GVT, eles garante o contratado dentra
da rede deles.

> 6) A garantia, quando existe, é só no link última milha. Ninguém dá
> garantia fim a fim na internet.
>
> Então, 5 minutos de média está muito bom para estatística e avaliação de
> necessidade de aumentar a capacidade de seu link de dados. Mas tudo
> depende do que está nos contratos com seus clientes.
> Link para internet é uma coisa. Rede coporativa tipo MPLS é outra...
>

Mais todos abordam sistemas de telecomunicações com as mesmas
caracteristicas operacionais, o que muda realmente é o foco e criticidade
do serviços.
Não conheço realmente se hã MPLS entre Operadoras, para tanto elas estão
limitadas internamente na rede da instituição, enquanto que Internet mesmo,
passa da esfera técnica para a esfera politica e economica.

>
> Abcs,
> --
> Marcos Tadeu
>
> On 03/10/2012 02:22 AM, Eduardo Schoedler wrote:
> > Ter link sobrando leia-se: *nao* usar como parâmetro gráficos de Cacti
> onde apenas aparece a media de 5 minutos.
> >
> > Matemática básica: você tem 100Mbps de link.
> >
> > 1o minuto: 80 Mbps;
> > 2o minuto: 90 Mbps;
> > 3o minuto: 70 Mbps;
> > 4o minuto: 30 Mbps;
> > 5o minuto: 20 Mbps.
> >
> > Gráfico do cacti: primeiro instante, 58Mbps... e você acha que esta bem
> de link quando, na verdade, você deve ter perdido pacotes nos 3 primeiros
> minutos, porque cada minuto já é uma media (você esta medindo Mb/segundo)!
> >
> > Você tem de começar a ter monitoramento na casa dos segundos, é outra
> visão do negocio.
> >
> > Rolou uma thread bem grande sobre esse tipo de monitoramento faz pouco
> tempo na NANOG.
> >
> > --
> > Eduardo Schoedler
> > Enviado via iPhone
> >
> >
> > Em 09/03/2012, às 23:57, Eduardo Schoedler <listas at esds.com.br>
> escreveu:
> >
> >> - Você ter link sobrando;
> >> - Numerologia (rsrsrs).
> >>
> >> Abs.
> >>
> >> --
> >> Eduardo Schoedler
> >> Enviado via iPhone
> >>
> >> Em 09/03/2012, às 23:38, Lista <lista.gter at gmail.com> escreveu:
> >>
> >>> Aproveitando o gancho, qual seria o melhor jeito de se analisar perdas
> de
> >>> pacotes em nossos backbone, para ter certeza se está perdendo ou não?
> >>>
> >>> Em 9 de março de 2012 23:15, Eduardo Schoedler <listas at esds.com.br
> >escreveu:
> >>>
> >>>> Pode ser qualquer coisa que foi falado nessa thread:
> >>>> - roteador com ip sem rota na internet;
> >>>> - Ping bloqueado;
> >>>> - control-plane saturada;
> >>>> - flow-control (Ping flood);
> >>>> - restrição de banda para icmp de ip da control-plane;
> >>>> - link saturado (em qualquer ponto da ida ou volta dos pacotes);
> >>>>
> >>>> ... e por ai afora.
> >>>>
> >>>>
> >>>> --
> >>>> Eduardo Schoedler
> >>>> Enviado via iPhone
> >>>>
> >>>> Em 09/03/2012, às 23:09, Andrio Prestes Jasper <mascaraapj at gmail.com>
> >>>> escreveu:
> >>>>
> >>>>> Acabei de reler novamente o que o rapaz falou ao abrir o topico:
> >>>>>
> >>>>>> *Ao reclamar de perda de pacote, para determinados destinos, ao
> passar
> >>>>>> pela rede Tim, o suporte respondeu:*
> >>>>>> * "Essa rede 10.x da Tim é composta por equipamentos Juniper, esses
> >>>>>> equipamentos discartam pacotes ICMP, isso é normal usando
> Juniper!".*
> >>>>>>
> >>>>>
> >>>>> Ou seja, o problema nao é somente ao pingar o roteador, mas sim
> alguns
> >>>>> destinos.
> >>>>>
> >>>>> Em 9 de março de 2012 23:05, Eduardo Schoedler <listas at esds.com.br
> >>>>> escreveu:
> >>>>>
> >>>>>> O pessoal nao esta sabendo diferenciar pingar O ROTEADOR
> >>>> (control-plane) e
> >>>>>> pingar alguém que esta ATRAS dele.
> >>>>>>
> >>>>>> --
> >>>>>> Eduardo Schoedler
> >>>>>> Enviado via iPhone
> >>>>>>
> >>>>>> Em 09/03/2012, às 22:02, Antonio Carlos Pina <
> >>>> antoniocarlospina at gmail.com>
> >>>>>> escreveu:
> >>>>>>
> >>>>>>> Nao. Ele Bloqueia o ping para ele. É possivel bloquear adiante,
> mas Nao
> >>>>>> é um comportamento, é uma programacao.
> >>>>>>>
> >>>>>>> Abs
> >>>>>>>
> >>>>>>> Em 09/03/2012, às 21:59, Andrio Prestes Jasper <
> mascaraapj at gmail.com>
> >>>>>> escreveu:
> >>>>>>>
> >>>>>>>> aceitar ping ou nao é uma coisa....
> >>>>>>>>
> >>>>>>>> mas ele bloqueia ate os ping que passa por ele, mas com destino
> >>>>>> diferente???
> >>>>>>>> ex: vou pingar o site do google, ele ira bloquear?
> >>>>>>>>
> >>>>>>>> mas e ai como fica os sites de testes?
> >>>>>>>> o simet por exemplo?
> >>>>>>>> nao vai realizar o teste do ping e jitter, cliente vai encher o
> saco
> >>>> por
> >>>>>>>> isso heim...
> >>>>>>>>
> >>>>>>>> Em 9 de março de 2012 21:42, Antonio Carlos Pina <
> >>>>>>>> antoniocarlospina at gmail.com> escreveu:
> >>>>>>>>
> >>>>>>>>> Sobre essa parte:
> >>>>>>>>>
> >>>>>>>>> "significa NO MÍNIMO que o volume
> >>>>>>>>> está ALTO, já que o routers está fazendo descartes de qualquer
> >>>>>> natureza."
> >>>>>>>>>
> >>>>>>>>> Ou na verdade significa que o roteador chegou no limite
> programado.
> >>>> Ex:
> >>>>>>>>> 1mb/s para ICMP, o que não é alto.
> >>>>>>>>>
> >>>>>>>>> Afinal, por que eu quero meu roteador respondendo a ping, certo ?
> >>>>>>>>>
> >>>>>>>>> Abs
> >>>>>>>>>
> >>>>>>>>> Em 09/03/2012, às 18:34, Rinaldo Vaz <rinaldo at anid.com.br>
> escreveu:
> >>>>>>>>>
> >>>>>>>>>> significa NO MÍNIMO que o volume
> >>>>>>>>>> está ALTO, já que o routers está fazendo descartes de qualquer
> >>>>>> natureza.
> >>>>>>>>> _______________________________________________
> >>>>>>>>> caiu mailing list
> >>>>>>>>> caiu at eng.registro.br
> >>>>>>>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>>>>>>
> >>>>>>>>> https://eng.registro.br/mailman/options/caiu
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Andrio Prestes Jasper
> >>>>>>>> Celular: (65) 8160 9761 / 8444 0040
> >>>>>>>> email: andrio.jasper at lgmtecnologia.com.br
> >>>>>>>> msn: mascara_apj at hotmail.com
> >>>>>>>> _______________________________________________
> >>>>>>>> caiu mailing list
> >>>>>>>> caiu at eng.registro.br
> >>>>>>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>>>>>
> >>>>>>>> https://eng.registro.br/mailman/options/caiu
> >>>>>>> _______________________________________________
> >>>>>>> caiu mailing list
> >>>>>>> caiu at eng.registro.br
> >>>>>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>>>>
> >>>>>>>
> >>>>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>>>>
> >>>>>>> https://eng.registro.br/mailman/options/caiu
> >>>>>> _______________________________________________
> >>>>>> caiu mailing list
> >>>>>> caiu at eng.registro.br
> >>>>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>>>
> >>>>>>
> >>>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>>>
> >>>>>> https://eng.registro.br/mailman/options/caiu
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Andrio Prestes Jasper
> >>>>> Celular: (65) 8160 9761 / 8444 0040
> >>>>> email: andrio.jasper at lgmtecnologia.com.br
> >>>>> msn: mascara_apj at hotmail.com
> >>>>> _______________________________________________
> >>>>> caiu mailing list
> >>>>> caiu at eng.registro.br
> >>>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>>
> >>>>>
> >>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>>
> >>>>> https://eng.registro.br/mailman/options/caiu
> >>>> _______________________________________________
> >>>> caiu mailing list
> >>>> caiu at eng.registro.br
> >>>> https://eng.registro.br/mailman/listinfo/caiu
> >>>>
> >>>>
> >>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>>
> >>>> https://eng.registro.br/mailman/options/caiu
> >>>>
> >>> _______________________________________________
> >>> caiu mailing list
> >>> caiu at eng.registro.br
> >>> https://eng.registro.br/mailman/listinfo/caiu
> >>>
> >>>
> >>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >>>
> >>> https://eng.registro.br/mailman/options/caiu
> > _______________________________________________
> > caiu mailing list
> > caiu at eng.registro.br
> > https://eng.registro.br/mailman/listinfo/caiu
> >
> >
> > --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
> >
> > https://eng.registro.br/mailman/options/caiu
>
> _______________________________________________
> caiu mailing list
> caiu at eng.registro.br
> https://eng.registro.br/mailman/listinfo/caiu
>
>
> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>
> https://eng.registro.br/mailman/options/caiu
>

-- 
:=)>BattleMaster<(=:

Flamers > /dev/null !!!