Cisco Netflow om inzicht te krijgen in verkeer ?

[Verwijderd]

Ik ben momenteel werkzaam bij een groot bedrijf die een groot netwerk heeft wereldwijd. Zij hebben een ATM backbone tussen America, Europa en Azie. Momenteel kunnen ze met Concord E-Health zien hoeveel verkeer er over de lijn gaat, maar ze kunnen niet zien wat voor een verkeer het is en waar het heen gaat.

Nu is men aan het denken om het pakket Netflow van Cisco te installeren op verschillende sites, zodat er informatie van de 150 routers in hun network uitgelezen kan worden. Het doel is om inzicht te krijgen wat voor een verkeer er over de backbone gaat en hoeveel site-to-site verkeer er is.

Nu is mijn vraag -> Wie heeft er ervaring met het Netflow pakket ?

Ik heb zelf al verschillende sites bekeken bij cisco over netflow en kwam een stuk tegen over de cpu belasting van netflow. Zie hier .
Ik zie dat er bij een 2600 router, de cpu bijna 50% meer belast wordt als men Netflow activeert bij 45000 flows.

Een andere simpele vraag is : Wat verstaan jullie onder een flow in een router en hoeveel flows zijn er meestal per minuut of per uur ?

Hopelijk kan iemand mij hiermee verder helpen.

[Verwijderd]

Is misschien niet helemaal ontopic. omdat het over een cisco oplossing gaat.

packeteer heeft een hardware oplossing daarvoor. je kunt een analyze uitvoeren en later zou je het apparaat kunnen laten staan om bepaalde protocollen voorrang te geven.

Kijk even op http://www.packeteer.com/

[ijdod]

Een flow is doorgaans een sessie tussen twee hosts, over bepaalde poorten. Dus een telnetsessie naar een server is een flow (een in elke richting). In de test hebben ze het wel over min-of-meer gelijktijdige flows. Of dat veel is of weinig hangt natuurlijk nogal van je netwerk af. Gevoelsmatig zeg ik dat 45000 flows best een hoop is.

[ Voor 4% gewijzigd door ijdod op 04-02-2004 15:14 ]

[Verwijderd]

javah: Leuk dat je begint over packeteer, want wij hebben momenteel 2 packeteers (redundant) op een belangrijk knoop punt aangesloten. Maar het probleem is dat de aanschaf voor zo'n apparaat best prijzig is. Voor het monitoren en eventueel shapen van het backbone verkeer is dat natuurlijk ideaal, maar voor site verkeer zijn ze net iets te duur.

ijdod : Die definitie had ik zelf ook in gedachten.. maar hoe zie je nu het aantal flows ? Of kun je die ergens van afleiden ?

[Verwijderd]

Ik heb inmiddels een listing gevonden van een router.

IP Flow Switching Cache, 4456704 bytes
133 active, 65403 inactive, 18936380 added
542417183 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
last clearing of statistics never

Dit is van een 72xx router. Enig idee of ik zoiets ook kan zien op een 26xx router ?
En weet iemand misschien hoeveel extra bandbreedte netflow genereert ?

[Verwijderd]

Hallo!

Aangezien je praat over best een groot netwerk neem ik aan dat jullie ook de grote jongens gebruiken zoal de Cisco 12000 series GSR of Juniper routers.

Vooral bij Cisco routers moet je even uitzoeken wat voor een engine-type lijnkaarten jullie gebruiken. Met het juiste engine type word de CPU van je routing engine nauwelijks tot niet belast.

Groeten

[regjit]

Netflow is niet helemaal een "pakket". Het is een methode waarbij een Cisco router die met Netflow switching pakketjes routeert van iedere gepasseerde ip flow een accounting record wegschrijft. Al die accounting records moet je verzamelen op een collector station, om er daarna wat nuttigs mee te doen. Mijn ervaring was dat dat een echt een enorme bak aan data blijkt te zijn, waar je ALLES uit kan halen wat je wilt, maar dat je er wel heel veel moeite voor moet doen.

Als je op google zoekt op "flowscan" krijg je wel een hoop nuttige info terug.

[Verwijderd]

Jootser : Nee helaas hebben wij alleen maar 72xx routers van kpn/infonet als ATM backbone. De site routers zijn meestal 26xx router. En de 26xx routers worden juist flink extra belast als netflow geactiveerd wordt.

regjit : De router verzameld de netflow informatie in zijn DRAM en verstuurd het daarna naar een collector. Aangezien de routers verspreid staan over de hele wereld, zullen er meerdere collector stations geinstalleerd moeten worden. Nu is de vraag. Hoe krijg ik de data van de collector station bijelkaar en in 1 overzicht voor de Netflow Analyser. Kunnen de collectors met elkaar communiceren ?

[DGTL_Magician]

Wij gebruiken Cisco Netflow op de WAN router in combinatie met het pakket ntop. (www.ntop.org)
Hiermee kun je duidelijke statistieken krijgen over de flows die over je netwerk gaan.

[Predator]

Verwijderd schreef op 04 februari 2004 @ 14:46:
Is misschien niet helemaal ontopic. omdat het over een cisco oplossing gaat.

packeteer heeft een hardware oplossing daarvoor. je kunt een analyze uitvoeren en later zou je het apparaat kunnen laten staan om bepaalde protocollen voorrang te geven.

Kijk even op http://www.packeteer.com/

Packeteer heeft 2 oplossingen.

Packetseeker & packetshaper.
De eerste doet traffic monitoring en de andere doet ook shaping.
Het is 1 en hetzelfde toestel, het hangt van je licentie af.

Dat zou inderdaad een goeie oplossing zijn, maar zijn misschien wel enkele problemen:
• De packetseeker zet net achter je router. Het is een ethernet <-> ethernet bridge. Probleem is dat hij het verkeer op je ATM interface die niet naar de ethernet kant gaat dan niet ziet.
• Packetshapers waren in ieder geval vrij prijzig. De packetseeker is wel goedkoper. Ik weet niet hoeveel. Maar een offerte vragen kan nooit kwaad.
Ze hebben iig packetseeker/shapers die genoeg performantie hebben.

Voordelen zijn natuurlijk dat je je router niet (extra) belast met dit systeem.

[ Voor 5% gewijzigd door Predator op 07-02-2004 13:31 ]

[regjit]

Verwijderd schreef op 07 februari 2004 @ 10:25:
regjit : De router verzameld de netflow informatie in zijn DRAM en verstuurd het daarna naar een collector. Aangezien de routers verspreid staan over de hele wereld, zullen er meerdere collector stations geinstalleerd moeten worden. Nu is de vraag. Hoe krijg ik de data van de collector station bijelkaar en in 1 overzicht voor de Netflow Analyser. Kunnen de collectors met elkaar communiceren ?

Dat is een beetje afhankelijk van welke collector je kiest. Ntop is bijvoorbeeld wel een mooie simpele. Installed lekker simpel, maar heeft niet features als communicerende collectors. De toolset die Cisco aanbiedt kan dat dacht ik wel.

De kunst van een succesvolle netflow implementatie is volgens mij dat je nadenkt over hoe je gaat summarizen. Uit je router komt namelijk een gigabak data, en die ga je ontvangen op een lokale collector. Op die collector filter je er de data uit die je *echt* wilt weten, en die stuur je dan pas weer door naar je centrale plek.
Tenzij je gewoon bandbreedte genoeg hebt... dan stuur je gewoon alles direct naar die centrale plek.

Als ik jou was zou ik er gewoon 's een beetje mee gaan spelen in een rustig hoekje van je netwerk. Ntop is een makkelijke en gratis collector, dus het enige wat het je kost zijn wat pruts-uurtjes

[joopv]

Een hele simpele methode met weinig impact en risico:
maar een access-list met alleen permit's voor diverse tcp-poorten en ip-netwerken. Met show access-lists zie je vervolgens matches op die rules (packets, geen bytes!).

Met een snmp-grapher zoals Getif kun je die matches weer uitlezen en grafisch weergeven. Of voor mijn part met sh access-lists ieder uur ;-)

Joop

[Adze]

Op het werk gebruiken we ook netflow, maar dan alleen maar op de 3600, 7200 en 7500 modellen. Wanneer je op iedere hoofd atm interface "ip route-cache flow" aanzet zal de impact te overzien zijn...

[ijdod]

Zelf nog even in onze oude project docu zitten graven. We hebben er destijds mee zitten spelen. De routers konden er tegen; er staat me ook bij dat Netflow en CEF met elkaar samenwerken, wat de load verbeterd.

Het grootste probleem was de te gebruiken tool. Er zijn er diversen, met diverse systeemeisen, en erg diverse output. Je zal van te voren moeten bedenken wat je wilt met die tool. De prijzen varieren ook nog al, van gratis tools tot tools die € 50000 en meer kosten.

Project is uiteindelijk doodgebloed doordat het management niet doorzette, en het benodige framework er niet kwam.

[ Voor 28% gewijzigd door ijdod op 09-02-2004 13:00 ]