2. Netflow Do's & Don'ts
Onderzoek naar Netflow en impact op
netwerknodes
stefan.deelen@os3.nl
3. Netwerk Monitoring met Netflow
Typische toepassing in Large Scale omgevingen
Om redenen van:
Security
Accountability
Planning
Traffic Engineering
...
of gewoon voor die extra "schwung" van je
netwerkmanagement..
4. Is per slot van rekening in potentie
pure kunst..!
5. Agenda
● Netflow kenmerken en achtergronden
● Varianten en standaardisering
● Componenten binnen de Netflow architectuur
● Netflow toevoegen in bestaand netwerk (?)
● Praktijkonderzoek! Jazeker.., performed het?
● Mijn performance-impact meet-methode
● Meetresultaten en conclusies
● Vragen en discussie
6. Kenmerken & Achtergronden
● Netflow is geen SNMP based “interface-counter
teller” zoals Cricket, Cacti, MRTG, etc.
=
7. Kenmerken & Achtergronden
● Dataflow vs. Flow data (of flow records)
– IP adres afzender
– IP adres bestemming
– Poort afz.
– Poort best.
– Laag 3, prot. Type
– TOS byte
– Logisch inkomende interface
● Flow data: De eigenschappen van de
dataflow..Layer 2 en hoger, verpakt in records
8. Kenmerken & Achtergronden
● Founded by Cisco Systems, Inc.
● Als toevoeging op routers en switches
● Huidige versie Netflow vs.9
● Een rfc3954 open -, maar geen Internet
standaard
● Flow informatie wordt lokaal geadministreerd
● Netflow voegt processing toe
● Vs. 9 is template based, records kunnen
gemakkelijk worden uitgebreid
9. Varianten en standaardisering
● sFlow, Foundry Networks
● Jflow, Juniper
● Netstream, Huawei Technologies
● .......
● Voornamelijk Netflow afgeleiden
● IPFIX: Open standaard! Rfc5101 (status: draft)
● Internet Protocol Flow Information eXport
● IPFIX is gebaseerd op Netflow v9.
11. Componenten
● Vaak UDP tussen Exporter en Collector
● IPFIX adviseert: SCTP (en anders UDP of TCP)
Ref, IBM: “Better networking with SCTP”
12. Netflow toevoegen
● Niet bepaald de eerste zorg, wordt als luxe, als
extra beschouwd
● Primaire zorg: Syslogging, SNMP, SSH,
backuppen, NTP, AAA, continuiteit van
connectiviteit (redundantie-optimalisatie)
● Kandidaat Netflow Netwerkomgevingen zijn
vaak al “volwassen”, en daarom soms al flink
“loaded”
● (Dure) dedicated hardware probes, of risico's
nemen?
13. Netflow toevoegen
● Info decentraal collecteren met dedicated (=
kostbaar) hardware probes?
● Geen totaaloverzicht van netwerkdomein!
● --> Schaalt slecht..
14. Netflow toevoegen
● Exporteer naar een centraal punt
● “Exporting IP flows using IPFIX”, University of
Oslo, Per Juvhaugen:
15. Netflow toevoegen
● Meest efficient: Bestaande nodes uitbreiden
met Netflow feature support
● Onzekerheid over impact extra processing!
● Netwerk-performance lastig te vatten:
afhankelijk vh gebruik, van dimensionering of
van toegepaste configuraties of..
● Bestaand praktijkonderzoek toont aan:
– Uiteraard vendor-afhankelijk en van device internals
– Onderzoek CPU impact vs. aantal dataflows
● Maar wat ervaren netwerkgebruikers?
19. Meetresultaat
root@Vigor159:~# iperf -c 100.0.0.158 -t 9000 -m -i 2
Client connecting to 100.0.0.158, TCP port 5001
TCP window size: 16.0 KByte (default)
[ 3] local 9.0.0.159 port 43875 connected with 100.0.0.158 port 5001
[ 3] 0.0- 2.0 sec 141 MBytes 593 Mbits/sec
[ 3] 2.0- 4.0 sec 141 MBytes 593 Mbits/sec
[ 3] 4.0- 6.0 sec 140 MBytes 587 Mbits/sec
[ 3] 6.0- 8.0 sec 128 MBytes 535 Mbits/sec
[ 3] 8.0-10.0 sec 123 MBytes 515 Mbits/sec
[ 3] 10.0-12.0 sec 123 MBytes 514 Mbits/sec
-22% Troughput met vs. zonder Netflow
16% extra pakketverlies (Iperf UDP meting)
20. Sampled Netflow
● Voor high performance omgevingen
● Of omgevingen die low performen..
● Mijn verzadigde CPU geeft indicatie v effect:
21. Future work
● Real-life testing met Harpoon
● Router/routing performance is enorm
dynamisch
22. Conclusies
● Security-, Cap. Planning-, Accountability tooling
nodig?
● Netflow en IPFIX beiden flexibel en
'multipurpose'
● Performance Impact is te overzien, common
sense
● Exporten out-of-band toepassen
● Pas op met NAT in core omgevingen ;-)
● Praktijk-dynamiek simuleren blijft een uitdaging
