sFlow beállítása régebbi HP Procurve típusokon

Bizonyára nem én vagyok az egyetlen, aki beleszaladt már abba a problémába, hogy némelyik régebbi Layer3-as HP Procurve típuson jól láthatóan van sFlow támogatás az OS-ben, létezik például a "show sflow all" parancs is, ám konfig módban mégsincs semmilyen sflow kezdetű parancsunk. Azaz: CLI-ből lekérdezni ugyan le tudjuk az sFlow agent állapotát, beállítani viszont nem. A teljesség igénye nélkül, ilyen tudomásom szerint az összes 2800-as sorozatú eszköz, pl. a 2824-es, illetve rémlik, mintha a 2610-esen is tapasztaltam volna ugyanezt.

Szerencsére minden beállítható, de kizárólag SNMP-n keresztül, a konfiguráláshoz szükség lesz SNMP írási jogra az eszközünkhöz. Ez már önmagában is elég érdekes koncepció, tulajdonképpen olyan, mintha valaki valamit elfelejtett volna az OS fejlesztése alatt, de a dologba sikerült még egy csavart is tenniük a fejlesztőknek: ha bekonfiguráltuk a megfelelő SNMP OID-eken keresztül az sFlow-t, az akkor sem fog örökké futni, van ugyanis az sFlow destination értékek között egy folyamatosan csökkenő "Timeout" paraméter is, ami azt mutatja, hogy hány másodpercig fog még az OS adatokat küldeni az adott sFlow collector számára. A Timeout maximális értéke "10000000" szekundum, vagyis legkésőbb 115 naponként újra be kell állítani a switchet, különben befejezi a collectorral a kommunikációt. Azon pedig igazán nem érdemes csodálkozni, hogy a beállításokat a switch elfelejti újrainduláskor: lehet hozzá barkácsolni mindenféle szkripteket, nyilván célszerű ezt a feladatot ízlés szerint egy napi/heti/havi cronjobbal megoldani, és rendszeres időközönként megnövelni a "Timeout" értéket is.

Ennyi bevezető után pedig következzen egy egyszerű shellszkript, ami egy I.10.101-es OS verziót futtató HP 2824-es 20-as portján beállítja az sFlow-t a 10.10.10.10:9996-os collectorhoz:

#!/bin/sh
 
# collector: IP hexában
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.6.1 x 0a0a0a0a
sleep 1

# collector: port decimálisan
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.7.1 i 9996
sleep 1

# collector owner info
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.2.1 s sFlow_collector
sleep 1

# hány mp-ig fusson az sflow agent a switchen (ez a max ~115 nap)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.4.1.3.1 i 10000000
sleep 1

# sampling: minden 4096. packet a 20-as porton (a .1 előtt az OID legvégén)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.5.1.4.11.1.3.6.1.2.1.2.2.1.1.20.1 i 4096
sleep 1

# polling: 20 mp a 20-as porton (a .1 előtt az OID legvégén)
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.6.1.4.11.1.3.6.1.2.1.2.2.1.1.20.1 i 20
sleep 1

# port sflow enable a 20-as porton
snmpset -v1 -cpublic 10.3.2.2 1.3.6.1.4.1.14706.1.1.5.1.3.11.1.3.6.1.2.1.2.2.1.1.20.1 i 1

exit

Ha minden klappol, akkor valami ilyesmi lesz a "show sflow all" kimenete:

HP2824# sh sflow all

 sflow agent

  Version       : 1.3;HP;I.10.101
  Agent Address : 10.11.12.13

 sflow destination

  sflow                     : Enabled
  Datagrams Sent            : 4935
  Destination Address       : 10.10.10.10
  Receiver Port             : 9996
  Owner                     : sFlow_collector
  Timeout (seconds)         : 9996908
  Max Datagram Size         : 1400
  Datagram Version Support  : 5

 sflow sampling-polling

 sflow destination Enabled

 Port  | Sampling                 Dropped    | Polling
       | Enabled  Rate     Header Samples    | Enabled Interval
 ----- + -------  -------- ------ ---------- + ------- --------
 1       No       0        128    0            Yes     20
 2       No       0        128    0            Yes     20
 3       No       0        128    0            Yes     20
 4       No       0        128    0            Yes     20
 5       No       0        128    0            Yes     20
 6       No       0        128    0            Yes     20
 7       No       0        128    0            Yes     20
 8       No       0        128    0            Yes     20
 9       No       0        128    0            Yes     20
 10      No       0        128    0            Yes     20
 11      No       0        128    0            Yes     20
 12      No       0        128    0            Yes     20
 13      No       0        128    0            Yes     20
 14      No       0        128    0            Yes     20
 15      No       0        128    0            Yes     20
 16      No       0        128    0            Yes     20
 17      No       0        128    0            Yes     20
 18      No       0        128    0            Yes     20
 19      No       0        128    0            Yes     20
 20      Yes      4096     128    0            Yes     20
 21      No       0        128    0            Yes     20
 22      No       0        128    0            Yes     20
 23      No       0        128    0            Yes     20
 24      No       0        128    0            Yes     20

Cisco IOS Netflow ingress, egress, v5, v9

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.

Netflow dekódolás Wiresharkban

Ki gondolta volna, hogy a Wiresharkban remek Netflow támogatás van? Egy pár napja szaladtam bele egy kis hülyeségbe és jól jött volna a ManageEngine Netflow Analyzert futtató szerverünkön egy másik Netflow szabványt értő program. Hát persze, hogy a Wiresharkhoz nyúltam először, és persze, hogy nem olvastam el előtte semmit, készítettem egy pár perces capture-t a vizsgálandó router forrás IP-jéről érkező csomagokról, utána meg lestem, hogy miért csak layer4-ig tudja dekódolni a Wireshark, micsoda disznóság már, hogy épp az engem érdeklő Netflow adatokat csak úgy, kódolatlanul jeleníti meg? Lehetséges, hogy nem ismeri a Netflow-t? Neeem, ilyesmit lazán tudnia kellene. Már néztem is a Help > Supported Protocols-ban, hm... nincs Netflow, nincs Nflow, bezzeg sFlow az van, de végül megtaláltam, CFLOW a protokoll dekóder neve (Cisco NetFlow/IPFIX).

Innen már csak egy lépés beállítani a megfelelő UDP portra: Analyze > Decode as... > Decode UDP source X port(s) as > CFLOW. Annyi csavar van még a dologban, hogy Netflow v9 esetén már template alapú a dekódolás, nálunk pedig történetesen épp a v9 van használatban, így nem feltétlenül elegendő csupán egy-két UDP datagram, érdmes kicsit tovább várni, amíg megjön a Netflow template-ünk is a forrástól. Ha már megjött a template, a Wireshark ügyesen kibontja a datagramokat, és böngészgethetünk is a router által küldött forgalmi adatokban kedvünkre.

Szűrés is állítható bármelyik Netflow mezőre, nálam például a "cflow.direction" volt az érdekes (0=ingress, 1=egress), van ugyanis egy szolgáltatói routerünk, amelyik egyszerűen nem hajlandó egyik interfészéről sem OUT adatokat szolgáltatni Netflow-n keresztül, következetesen csak IN adatokról küld információt bármiféle beállítás, rábeszélés, rugdosás ellenére, de erről majd később, ha már lezárult az ügy, jelenleg még mindig vizsgálják a szolgáltatónál a hiba okát.