[caiu] É normal perder pacote usando juniper!

Domingo Março 11 15:43:20 BRT 2012

> 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.
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".
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...
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...

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