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

[Rubens Kuhl Jr.]

Vale mencionar também o sFlow:
http://www.foundrynet.com/technologies/sFlow/


Mas apesar de um certo Cisco-bias, o NetFlow tem algumas vantagens em
termos de um tutorial:
- Pode ser usado em ambientes não-BGP (Destination-Class-Usage-DCU-
usualmente requer BGP para ser prática) e não-MPLS (MPLS accounting)
- Disponível de roteadores de acesso a roteadores de core (mesmo que com
algumas deficiências em core/giga-edge)
- É util para redes de acesso por monitorar tráfego de entrada (DCU só é
útil para IDCs e portais)
- Disponível em mais de um vendor 
- É util para caracterização de protocolos, não apenas de origem/destino
IP/MPLS


Acredito que uma apresentação de nível mais avançado até devesse sim se
preocupar com aspectos mais genéricos de caracterização de tráfego,
problemas com tráfego >= 100 Mbps etc. Tutorial, porém, tem que ter como
alvo nivelar os participantes... Acho que o pessoal tem que começar
apanhando do NetFlow, para que entendendo tanto os conceitos de análise
de tráfego quanto os limites da ferramenta, passar para a fase
"iluminada" e questionar porque essa ou aquela solução.


Rubens




-----Original Message-----
From: gter-admin at eng.registro.br [mailto:gter-admin at eng.registro.br] On
Behalf Of Roosevelt Ferreira
Sent: Friday, April 12, 2002 2:09 PM
To: gter at eng.registro.br
Subject: NetFlow e Accouting Tools (was => RE: Netfow (era Re: [GTER]
NAP Carrier Neutral))


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
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)
iii. para mapeamento de informações a nível de AS ou supernets é
necessário "consolidar" a informação dos bilhetes
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)

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

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.


- Roosevelt

= = = = = = = = =  

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