[GTER] Medir Qualidade Link - Numero de retransmissões
Shine
eshine at gmail.com
Fri Dec 14 18:58:32 -02 2012
Douglas,
Pode ser uma idéia, mas apesar do NFlow passar todas as flags TCP, não me
ocorre que ele sinalize a retransmissão de uma forma prática.
Se fosse para obter essa informação, acho que seria mais fácil obter da
fonte (o servidor) por meio de um SNMP OID.
http://net-snmp.sourceforge.net/docs/mibs/tcp.html
Daí vc gera uma base de informação, manda para um servidor de gerenciamento
e faz a correlação da falha com outras medidas.
Tem essa ferramenta comercial:
http://www.infovista.com/solutions/application-performance-management
Em 14 de dezembro de 2012 13:34, Douglas Fischer
<fischerdouglas at gmail.com>escreveu:
> Entendi sua colocação.
> Como diz o caipira "Não paga a pena.".
>
> Mas como eu estava conversando pelo talk com o colega Lucas, que também
> participa da GTER, isso pode ser mais simples do que se imagina...
>
> Eu tenho que analisar as specs do NetFlowV9, mas eu desconfio que se
> consigase calcular
> esses índices de retransmissão a partir dos dados exportados pelo NetFlow.
>
> Se isso for verdade, é só trabalhar a ferramenta de análise do netflow...
>
>
> Em 14 de dezembro de 2012 12:51, Shine <eshine at gmail.com> escreveu:
>
> > Douglas, entendi sua proposição, mas na minha opinião fazer taxonomia na
> > rede usando apenas análise passiva do comportamento da aplicação não é a
> > melhor abordagem. A aplicação pode ter problemas que não necessariamente
> > implicam na necessidade de um aumento da banda ou um problema de
> qualidade
> > do link WAN/LAN.
> >
> > Nada impede de se fazer algo "tailor-made" nesse sentido quando vc
> conhece
> > as características do cliente e das suas aplicações, mas acho que não tem
> > um custo efetivo desenvolver isso para um cliente específico.
> >
> > Algo como o Cisco WAAS poderia estar mais dentro do que vc espera, mas a
> > proposição do WAAS não é somente monitorar a WAN.
> >
> > Tvz uma solução seja algo no meio do caminho como uma aplicação que
> > monitore o link com coisas como IPSLA (falando em linguagem Cisco q vc
> > parece ter familiaridade) em conjunção com um monitoramento complementar
> > (vc poderia usar um dos plugins do Zabbix ou Nagios para obter as infos
> das
> > aplicações, por exemplo).
> >
> >
> > Em 13 de dezembro de 2012 21:02, Douglas Fischer
> > <fischerdouglas at gmail.com>escreveu:
> >
> > > Shine, me desculpe se não me expressei adequadamente...
> > >
> > > Mas a idéia é monitorar a qualidade passivamente.
> > > Sem injetar trafego sintético...
> > >
> > >
> > > Um dos objetivos é ter um embasamento poder cobrar da operadora os
> níveis
> > > de qualidade necessários. Algo como:
> > > "Pelo link que tenho com vocês, os níveis de retransmissão com
> > > Sub-Redes/ASNs Nacionais são de X, e para Sub-Redes/ASNs Internacionais
> > são
> > > de 10X. Se virem em corrigir isso!"
> > >
> > > Outro objetivo é monitorar isso no firewall do cliente(pra dentro do
> > > controle de banda), e comparar os indices de retransmissões da rede
> dele
> > e
> > > com os mesmo índices do todo das minhas redes.
> > > 1 - "Veja seu Astrogildo, é nessas horas que eu digo por senhor que é
> > > necessário cntratar mais banda para sua estrutura..."
> > > 2 - "Não, não seu Ptolomeu. Eu posse lhe garantir que não há nenhum
> > > problema espcífico com sua rede, Os índices de retransmissão de sua
> > > estrutura são os memos de nossos outros clientes."
> > >
> > >
> > > Em 13 de dezembro de 2012 17:34, Shine <eshine at gmail.com> escreveu:
> > >
> > > > Douglas,
> > > >
> > > > As ferramentas usadas para medir a qualidade de um link em geral não
> se
> > > > baseiam em métricas de protocolos de alto nível. Isso não é
> necessário,
> > > vc
> > > > pode injetar um tráfego sabendo do padrão dele e do outro lado apenas
> > > > checar se o o stream de dados correspondente não foi alterado baseado
> > em
> > > > comparação binária pura.
> > > > Eu não mexi com muitos equipamentos que fazem isso, só mexi com um
> > > Agilent
> > > > e um Spirent.
> > > > Medir métricas de camada 3 acabam não sendo métricas exatamente de
> > link,
> > > > porque há interferência do host, vc não sabe se um pacote TCP sumiu
> ou
> > se
> > > > ele não conseguiu ser processado pelo host a tempo.
> > > >
> > > >
> > > >
> > > > Em 13 de dezembro de 2012 13:12, Douglas Fischer
> > > > <fischerdouglas at gmail.com>escreveu:
> > > >
> > > > > Talvez eu esteja reinventando a roda, então peço um norte para os
> > > > colegas.
> > > > >
> > > > >
> > > > > Algum dos colegas já utilizou alguma métrica baseada em número de
> > > > > retransmissões
> > > > > TCP, ou algo que se assemelhe, para medir a qualidade de um link?
> > > > >
> > > > > Como os senhores fazem isso?
> > > > > Meu interesse é especial em Cisco, mas tenho interesse também nas
> > > opções
> > > > o
> > > > > ferecida pelos outros Vendors e OpenSources.
> > > > >
> > > > > Indo além:
> > > > > Minha idéia é casar a informação dessas retransmisões com redes de
> > > > origem e
> > > > > destino(ASN também), protocolos e etc...
> > > > > (Análise do cubo de informações)
> > > > >
> > > > >
> > > > > --
> > > > > Douglas Fernando Fischer
> > > > > Engº de Controle e Automação
> > > > > --
> > > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > > --
> > > > gter list https://eng.registro.br/mailman/listinfo/gter
> > > >
> > >
> > >
> > >
> > > --
> > > Douglas Fernando Fischer
> > > Engº de Controle e Automação
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list