NetFlow e Accouting Tools (was => RE: Netfow (era Re: [GTER] NAP Carrier Neutral))

Fri Apr 12 15:39:01 -03 2002

At 10:08 12/4/2002 -0700, you wrote:
>Dentro do tema de Accounting, ou determinação das características do 
>tráfego dentro da rede (composição, volume, origem/destino, distribuição 
>em função do tempo, etc) - o uso do NetFlow/cFlow é apenas uma das 
>ferramentas/técnicas disponíveis.
>
>Apesar de ser, creio, a técnica mais utilizada hoje (por "n" razões), não 
>é a única disponível, e apresenta certa restrições em alguns cenários, que 
>vem de:
>
>i. necessidade de exportar os bilhetes de CFlow para uma máquina externa

As exportações de fluxos evitam a necessidade de consolidar no roteador. 
Qualquer consolidação obrigatoriamente faz "perder"
informações. Dependendo da aplicação, a consolidação é desnecessária.
A consolidação envolve recursos de CPU e de memória do roteador, muitas 
vezes é melhor exportar para uma máquina
local (através de uma interface 100Mbps). Isso é um dos motivos do porque 
os equipamentos não implementam todos os RMONs...

Ou seja, na pratica o NetFlow é mais viável que o RMON..

>ii. bilhetes representam informação de alta granularidade (flow-level), 
>consequentemente o volume total de bilhetes a serem exportados é função da 
>velocidade das interfaces e características dos flows (principalmente duração)

Sim ! Algumas vezes a granularidade é extremamente necessária, ex: 
"detecção de ataques", avaliação de fluxos, comportamento
das conexões...
A granularidade só é dispensável quando se sabe exatamente o que se quer !
Veja alguns exemplos na minha tese no capítulo 8 utilizando BPF (Berkeley 
Packet Filter).
http://www.ravel.ufrj.br/publicacoes/teseClaus.pdf

>iii. para mapeamento de informações a nível de AS ou supernets é 
>necessário "consolidar" a informação dos bilhetes

Isso pode ser feito no próprio roteador utilizando aggregate do NetFlow V8 !
http://www.caida.org/tools/measurement/cflowd/configuration/configuration-9.html

>iv. existem certas restrições práticas (devido a necessidade de exportar 
>os bilhetes para uma máquina remota) de fazer a coleta em múltiplos pontos 
>dentro da rede (geralmente a máquina q recebe os bilhetes está em um ponto 
>central, etc)

Este problema não está relacionado ao NetFlow, e sim quando se quer 
granularidade na coleta do fluxos.
Para resolver basta criar uma estrutura de coleta, colocando máquinas nos 
nós principais da rede.

Só lembrando, o Netflow é apenas uma técnica "da Cisco" de se fazer cache 
de ACLs, e é aproveitado para ser exportado!
Por sinal uma grande idéia !
http://www.cisco.com/warp/public/732/Tech/netflow/docs/netflowacceleration.fm.pdf

>Assim, no espírito de ampliar o nosso "tool-kit" para análise de tráfego, 
>segue uma URL para técnicas alternativas de Accounting implementadas nas 
>plataformas Juniper. Algumas desta técnicas endereçam os pontos levantados 
>acima. Muitas delas também existem sobre outros nomes em outras plataformas:
>
>Juniper Networks Solutions for Network Accounting
>http://www.juniper.net/techcenter/techpapers/200010.html

Uma boa referencia "neutra" sempre é o CAIDA, exemplos:
http://www.caida.org/outreach/
http://www.caida.org/outreach/metricswg/faq.xml

>Numa apresentação para a audiência do GTER, podemos excluir referências 
>específicas a fabricantes, mas concentrarmo-nos em criar "Frameworks" e 
>definir qual o ferramental/tecnologia/abordagem adequado para extrair a 
>informação de tráfego em várias granularidades/topologias de rede.

Se o fabricante apresentar problemas, porque nao mostra-los na reunião ?
Afinal não é um forum de discussão de problemas de operação e engenharia de 
redes ?
Não é isso que queremos discutir ?

>= = = = = = = = =
>
>  >-----Original Message-----
>  >From: Fernando Krahe [mailto:fernando at optiglobe.net.br]
>  >Sent: Friday, April 12, 2002 10:24 AM
>  >To: gter at eng.registro.br
>  >Subject: Netfow (era Re: [GTER] NAP Carrier Neutral)
>  >
>  >
>  >-----BEGIN PGP SIGNED MESSAGE-----
>  >Hash: SHA1
>  >
>  >Agora que mencionaste, me lembrei que Netflow poderia ser
>  >um bom tutorial para um proximo evento. Recordo de um
>  >interessante tutorial em um Nanog recente que abordava "Basic ISP
>  >Traffic Engineering Tools and Practices". Esse tutorial abordava
>  >varias ferramentas uteis mas que poucos conhecem/implementam.
>  >Alem de Netflow, tinha Flowscan, Cflow, RRDTool, ...
>  >Esses temas poderiam constar da lista de sugestao de apresentacoes,
>  >se eh que ja nao estao.
>  >
>  >Fernando
>  >
>  >
>  >
>  >- ----- Original Message -----
>  >From: "Leandro Bertholdo" <berthold at penta.ufrgs.br>
>  >To: <gter at eng.registro.br>
>  >Sent: Thursday, April 11, 2002 3:39 PM
>  >Subject: Re: [GTER] NAP Carrier Neutral
>  >
>  >
>  >Oi Demi,
>  >
>  >>meta. Certamente concordo que não há muito espaço para inciativas
>  >>heróicas...
>  >
>  >
>  >Humm...
>  >Acho que muitas vezes a questao nao eh heroismo, mas sim necessidade
>  >e bom senso. Por exemplo, aqui no Rio Grande do Sul a distancia
>  >geodeseica
>  >entre o CPD da UFRGS (onde hoje esta o PTT) e provedores de
>  >informacoes
>  >como Terra, ClickRBS e Procergs (sendo os dois ultimos "peso pena" -
>  >nas palavras do Manta :-)  nao passa de 5Km. No entanto, a
>  >acessibilidade
>  >estadual depende da conectividade e custo de interligacao a Sao
>  >Paulo.
>  >
>  >O custo torna o PTT uma boa ideia (nao heroica). É matematica. Basta
>  >considerar uma matriz de trafego (regional x nacional) - essa mesma
>  >matriz, que ai em Sao Paulo faz pouco sentido.
>  >
>  >Por aqui os "peso pena" juntos tem uma representacao bem
>  >significativa no
>  >trafego total. Embora alguns ainda nao tenham se dado conta, ou seja,
>  >não
>  >fizeram o dever de casa instalando um netflow e analisando o
>  >trafego....
>  >
>  >Acredito firmemente que esse mesmo argumento sirva para duas outras
>  >cidades como Rio de Janeiro e Belo Horizonte. É so as instituicoes
>  >com
>  >representabilidade em cada cidade tentarem se organizar. A
>  >viabilidade
>  >economica é totalmente mensuravel (custo/Mb_SP X custo/Mb_regional),
>  >embora a decisao seja politica/estrategica.
>  >
>  >
>  >Atenciosamente
>  >Leandro Marcio Bertholdo
>  >
>  >- --
>  >GTER list    http://eng.registro.br/mailman/listinfo/gter
>  >
>  >
>  >-----BEGIN PGP SIGNATURE-----
>  >Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>  >
>  >iQA/AwUBPLbfIRI8nj9lgleaEQJIJQCglgbVgZ+OfHks4Wtsf0yaaT4MHDQAnAj9
>  >RQzRW51U6rnQxLXurV7Brwbr
>  >=/8Hx
>  >-----END PGP SIGNATURE-----
>  >
>  >
>  >--
>  >GTER list    http://eng.registro.br/mailman/listinfo/gter
>  >
>--
>GTER list    http://eng.registro.br/mailman/listinfo/gter