Monitoring switchov - praktické skúsenosti

[matuscak]

Zaujímali by ma praktické skúsenosti s monitoringom sieťových switchov cez SNMP, napríklad prostredníctvom Zabbixu.

Aké všetky parametre sledujete? A iba z nich robíte záznam, z ktorého môžete neskôr "kresliť grafy" v prípade potreby, alebo aj generujete nejaké automatické alerty? Aké?

Ktoré zo sledovaných parametrov/triggerov/alertov sa vám v praxi javia ako najužitočnejšie a pri akých situáciach vám reálne pomohli?

Môj prístup k tomuto bol doteraz pomerne "minimalistický", v podstate som sledoval iba celkovú dostupnosť switchu na sieti (jeho IP odpovedá na ping) a prípadne tiež UP/DOWN status u niekoľko málo vybraných portov s dôležitými zariadeniami. Používam na to Icingu a zvažujem, čo by som získal, ak by som miesto toho prešiel na Zabbix a sledoval väčšie množstvo parametrov.

Teoreticky si na to odpovedať viem, ale či to má aj reálny praktický význam, to netuším. Tiež sa tak trochu obávam, či sledovanie desiatok/stoviek parametrov namiesto niekoľko podstatných nevedie k "informačnému zahlteniu" a síce, že systém potom vytvára veľa "nepodstatných" alertov vďaka čomu sa ich človek naučí podvedome ignorovať a vystavuje sa tým riziku, že prehliadne tie podstatné.

Vopred vďaka každému, kto sa podelí o svoje skúsenosti!

[Reklama]

[Foreigner]

Popisu jen co monitoruju a mam nastaveno "navic".
 - v core: stav linek kde mam i alarmy na odpojeni
 - accessove stav linek me nezajima ale zajima me pocet mac na port kde je taky alarm na velke mnozstvi mac (i pres to ze vse hlida source guard s dhcp snoopingem a port security). bohuzel vsichni jsme jen lide a stalo se ze port zustal nenastaven, pomocí dohledu se o tom dozvíme 
 - celkove mnostvi mac v cam a pokud dojde k velke zmene alarm
 - kde je mozne monitoruju cpu load a alarm na velky cpu load
kombinuji vytezovani pres snmp a pres ssh/telnet

[FKoudelka]

Popisu jen co monitoruju a mam nastaveno "navic".
 - v core: stav linek kde mam i alarmy na odpojeni
 - accessove stav linek me nezajima ale zajima me pocet mac na port kde je taky alarm na velke mnozstvi mac (i pres to ze vse hlida source guard s dhcp snoopingem a port security). bohuzel vsichni jsme jen lide a stalo se ze port zustal nenastaven, pomocí dohledu se o tom dozvíme 
 - celkove mnostvi mac v cam a pokud dojde k velke zmene alarm
 - kde je mozne monitoruju cpu load a alarm na velky cpu load
kombinuji vytezovani pres snmp a pres ssh/telnet

Hezky. A co na to používáš za SW?

[Foreigner]

Popisu jen co monitoruju a mam nastaveno "navic".
 - v core: stav linek kde mam i alarmy na odpojeni
 - accessove stav linek me nezajima ale zajima me pocet mac na port kde je taky alarm na velke mnozstvi mac (i pres to ze vse hlida source guard s dhcp snoopingem a port security). bohuzel vsichni jsme jen lide a stalo se ze port zustal nenastaven, pomocí dohledu se o tom dozvíme 
 - celkove mnostvi mac v cam a pokud dojde k velke zmene alarm
 - kde je mozne monitoruju cpu load a alarm na velky cpu load
kombinuji vytezovani pres snmp a pres ssh/telnet

Hezky. A co na to používáš za SW?

zabbix

[Jindru]

Doporučuji:

check_mk

nadstavba Nagiosu, kterej ani není vidět :-)
zcela použitelná free verze ( RAW =  CRE )
https://checkmk.com/download?edition=cre&version=stable
monitoroval jsme s tím 2000 zařízení ( Linuxe, Windos, APčka, switche ..)

narozdíl od ostatních (Zabbix, .. )  najde všecho sám, jenom se dá Apply a je to.
A taky míň HW náročnej.

Chybí mi tam správa IP/MAC/port ve switchi, udělal sám.

Vlastní plugin je poměrně snadný udělat.

Případně se ozvi

Jindru

[Reklama]

[LivingLegend]

narozdíl od ostatních (Zabbix, .. )  najde všecho sám, jenom se dá Apply a je to.
A taky míň HW náročnej.

Hele nějak nechápu tohle Zabbix umí taky. S většinou dnešních monitorovacích nástrojů se to podle mne má tak, že vesměs nějakým způsobem umí monitorovat vše. Jen to člověk musí umět. Ano někde je pohodlnější nastavit auto registraci, ale to neznamená že to jinde nejde.

[František Ryšánek]

Hm tyjo. Zrovna se tu o něco tím směrem snažím a všiml jsem si, že:

Nejstarší switche, co tu mám, podporují .1D bridge MIB = vracejí záznamy dot1dTpFdbPort, ovšem pouze po jednom, pomocí GET nebo spíš GET NEXT. GETNEXT je prakticky jediná možnost, protože tabulka je indexovaná MAC adresou po jednotlivých bajtech = šestirozměrný náhodný řídký index. A konkrétně GET BULK podporován není, takže mi musí stačit snmpwalk, který se ptá na každý záznam jednotlivě pomocí GET NEXT. A ke všemu mi i snmpwalk držkuje, že záznamy nejsou seřazené striktně vzestupně (tak jak je firmware switche servíruje). A CLI to samozřejmě nemá (že bych k tomu ohnul telnet/SSH).

Moje novější switche podporují .1Q bridge MIB = vracejí záznamy dot1qTpFdbPort. A podporují GET BULK, tzn. funguje snmpbulkwalk.

A taky pokud správně koukám, nevšiml jsem si, že by jedna či druhá varianta bridge MIB byla podporována od přírody v Linuxu - jako že sosat FDB ze soft bridgů, WiFi AP apod. Našel jsem jenom diplomku Štefana Sakalíka z r.2011, pod vedením Yenyi Kasprzaka, a k ní zřejmě i repo na sourceforgi. Laškuju s nápadem, zkusit to vmasírovat do aktuálního OpenWRT, ale spíš mi to časově spadne pod stůl. A nebo si pomůžu skrz telnet/ssh :-)

[knoxx]

Krome dostupnosti samotnych switchu, tak provoz na uplincich a jejich stav. Na vsech ostatnich portech upozorneni pouze pokud port spadne do err-disable stavu a jelikoz na core switchich routuji, tak i stav ospf.

[Džan]

Pokud se tím chceš zabývat detailněji, tak Zabbix, pokud chceš něco nahodit a používat, je zajímavý LibreNMS.
Pokud chceš řešit i analýzu logů, skončíš u něčeho jako ELK stack.

[snuff1987]

Mrkni na observium. Na monitoring sietovych prvkov brutalna vec.