Korábban íram már egy postot Netflow ügyben, az egyik MPLS-szolgáltatónk sok-sok vesződség után sem tudta felkonfigurálni a routerét úgy, hogy az a WAN interfészéről mind a bemenő mind a kijövő forgalomról tudjon információt adni. Mennyire bonyolult egy ilyen dolog? Hát, annyira azért nem... Teljes, jól működő beállításra példa:
router(config)#interface FastEthernet 0/0
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#interface FastEthernet 0/1
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#ip flow-export destination 10.10.10.10 9999
router(config)#ip flow-export source FastEthernet 0/0
router(config)#ip flow-export version 5
router(config)#ip flow-cache timeout active 1
router(config)#ip flow-cache timeout inactive 15
router(config)#snmp-server ifindex persist
Az interfészenkénti "ip route-cache flow" parancsot minden olyan interfészen ki kell adnunk, amelyen az általunk figyelni és elemezni kívánt forgalom át fog haladni. Mindegyiken. Ennek az az oka, hogy az alapértelmezett Netflow v5 csak a bejövő adatokról gyűjt és továbbít bizonyos időközönként összesített forgalmi információt (flow-t). Ha tehát a routeremben pl. csak az Fa0/0 és az Fa0/1 interfész forgalmaz, akkor az Fa0/1 bejövő adatairól alapból lesz információm, viszont az Fa0/1 kimenő adatokról csak akkor, ha engedélyezve van a Netflow az Fa0/0-n is, és az Fa0/0 bejövő adatait tudja majd a Netflow collector szoftverem az Fa0/1 kimenő forgalom adatainak előállításához felhasználni. Vagyis minden releváns, a forgalmunk által érintett interfészen engedélyeznünk kell a Netflow-t, különben nem azt fogjuk kapni, amire számítunk.
Az "ip flow-export destination" globális konfigurációs módbeli paranccsal állítható be a Netflow forgalom célja, itt kell megadni azt az IP-t vagy hostnevet és portszámot ahol a Netflow adatokat gyűjtő szoftverünk (collector) fülel. A collectornak küldött csomagokban a forrás IP cím annak az interfésznek az elsődleges IP-je lesz, amelyet az "ip flow-export source" után megadunk.
Az "ip flow-export version" egyértelmű, az általunk használni kívánt Netflow verziót adhatjuk meg vele, a két leggyakrabban használt verzió az 5-ös és a 9-es.
A következő két parancs a router által kezelt flow-cache ürítésére (a flow-k collectorhoz való elküldésére) vonatkozik. Az "ip flow-cache timeout active" egy aktív, azaz rendszeresen frissített flow-cache bejegyzés maximális élettartamát adja percekben. A cégünknél használt Netflow Analyzer nevű collector például a max. egy perces élettartamot preferálja, az IOS alapértelmezett érték egyébként 30. Az "ip flow-cache inactive timeout" az inaktív flow-kra vonatkozó időzítő, amely a nem frissített (befejeződött az adott típusú forgalom) flow-cache bejegyzések esetén megadja, hogy az inaktív státuszba lépés után még meddig maradhat az adott flow-cache bejegyzés a cache-ben.
Mivel a Netflow collectorok általában SNMP-s hozzáférést is igényelnek kiegészítő információk beszerzéséhez, pl. router adatok, hostnév, interfész adatok, ezért érdemes az SNMP-t úgy beállítanunk a routeren, hogy egy esetleges újraindulás után az interfészeink ugyanazokat az SNMP interfész indexeket kapják (snmp-server ifindex persist).
Persze még van egy-két kanyar. Itt van mindjárt az alinterfészek kérdése. A "ip route-cache flow" engedélyezi a flow-k gyűjtését egy adott fizikai interfészen és annak minden alinterfészén. Ha kizárólag egy alinterfész adataira vagyunk csak kíváncsiak, akkor azt az adott alinterfészen az "ip flow ingress" paranccsal aktiválhatjuk.
A Netflow v5 és v9 közötti egyik fontos különbség, hogy a v5 - ahogy arról már volt szó - csak ingress irányt támogat, míg a v9 használata esetén megnyílik a lehetőségünk az egress irányú flow-k gyűjtésére is, vagyis v9 esetén akár elfelejthetjük azt a v5-nél még obligát szabályt, hogy minden interfészen engedélyeznünk kell a Netflow-t. Az egress irányú flow gyűjtéséhez szükséges az "ip flow-export version 9", illetve az interfészen az "ip flow egress" parancs kiadása.
Nem árt továbbá, ha figyelünk az "ip flow-export source" interfész megadásánál. Ha fizikai interfészt adunk meg, számolnunk kell azzal az eshetőséggel, hogy az interfész (bármilyen okból) leesik. Ekkor a Netflow collectorunk hibaüzenetet küldhet, még akkor is, ha egyébként maga az eszköz elérhető marad alternatív útvonalon. Megoldás? Az ip flow-export source is elfogad loopback interfészt.
Végül pedig, visszatérve a szolgáltatónkra: körülbelül három hét levelezés és 5-6 telefonhívás után feladtam. Egy kivételével minden általuk adott routeren jól működik a Netflow, az az egy pedig, ami továbbra is csak az egyik forgalmi irányról ad flow-kat, úgyis csak egy backup router. Egyszerűen belefáradtam, csináltak ők mindent, volt router újraindítás, IOS frissítés, Netflow konfig törlés és újrakonfigurálás, másik mérnök újra ellenőrizte, majd egy harmadik, egyszer még egy fél órára jól is ment a Netflow még ezen az egy routeren is, de mire elért a szolgáltatóhoz a "most jó, ne keressétek tovább a hibát" üzenet, már továbbléptek. Az utolsó állapot az volt, hogy v9 használata mellett a router minden portjáról jön ingress és egress adat, kivéve azt a portot, amit tényleg figyelni szeretnék. Nem tudom, hogy mi lehet vele baj, nincs rálátásom a konfigurációjukra, lehet, hogy én sem tudnám megjavítani. Persze az emberben mindig ott motoszkál ilyenkor az a fura érzés, hogy esetleg nem is próbálták ezt annyira komolyan megoldani. Akárhogy is, nem számít már.
Nincsenek megjegyzések:
Megjegyzés küldése