hálózati hiba, a túl sok broadcast csomag miatt / RARP

Debian GNU/Linux

A következő probléma adódott, amit valahogyan orvosolnom kellene:

Időnként előfordul egy olyan hibajelenség, hogy egy hibás hálózati kártya (vagy a DHCP kliens szolgáltatás hibája...) miatt egy adott gép teleküldi a hálózatot broadcast üzenetekkel. Valószínűleg IP-t kér a gép a DHCP szervertől, de azt folyamatosan...
Szóval erre úgy reagálnak a switchek, hogy a sok broadcast üzenet miatt újra elkezdik felépíteni a feszítőfát,
amitől eléggé lehal minden, kiesnek csomagok az egész hálózaton.

Mivel broadcast címmel mennek el a csomagok, ezért minden gép megkapja őket, tehát bárhol fel kellene tudnom fedezni őket.
A kérdés az, hogy hogyan lehetne megtudni azt, hogy ha van egy ilyen jelenség, akkor milyen IP címről jönnek a csomagok?

Windows alatt van erre program, de szeretnék valamilyen ellenőrzést beépíteni a Zabbixba, tehát valamilyen Linuxos megoldásra volna szükségem.

Előre is köszi a segítséget!

  • 9129 megtekintés

HP procurve 2610, 2510 ill. 4208vl switchek vannak.
Köszi a linket, nagyjából ismertem a hiba kialakulásának az okát. Sajnos mindenhol csak switcheket használunk, VLAN-t lehetne állítani, de igazából nem volna szerencsés dolog leválasztani valamelyik switchet a többitől.
És a leírásban is úgy olvastam (ha jól értettem), hogy a VLAN sem oldja meg a problémát...
Szerintem elég volna ha tudnánk hogy broadcast vihar van, és tudnánk azt hogy melyik MAC címről jönnek a broadcast keretek...
A MAC-et már át lehet fordítani IP-re, IP címből pedig meg lehet mondani a gépnevet.
Tehát ha meg van a MAC akkor néhány másodperc alatt meg lesz a gépnév is ami küldi a kereteket.
De honnan tudhatom, hogy honnan jött a broadcast keret?
Csak van rá valamilyen alkalmazás, ami logolja a broadcast kereteket a hálózaton, és feljegyzi hogy honnan jöttek...

iptraf-ot nézegetem, de arra még nem jöttem rá, hogy hogyan lehet vele statisztikát küldeni log fájlba,
mert alapból a logba nem írja bele azt, hogy melyik IP-címről hány darab csomag érkezett.
márpedig itt az volna a lényeg, hogy honnan szemetelnek leginkább

jó persze ha belenézek a logba láthatom azt, hogy 500x annyi bejegyzés van egy adott címről, de ezt valahogy automatizálni kellene

amúgy SNMP-vel nem lehet kiolvastatni switchből azt, hogy épp újra felépíti-e a spanning tree-t?

snmp

általában mindent le lehet kérdezni snmp -vel, néha pilótavizsgás a feladat :-)

ha jól rémlik, az általad említett switchek hajlandóak távoli gép syslogba loggolni. logbejegyzést tuti mondanak rá.

Kérdés persze, hogy a hálózat lehalásakor hogyan jut el akár a syslog entry akár az snmp trap vagy query a céjához...

( kreszan | 2012. 11. 13., k – 19:22 )

Lehet, hogy csak workaround de broadcast limit opció esetleg?
--
Kreszán K.
--

( nephilim | 2012. 11. 13., k – 20:00 )

"Szóval erre úgy reagálnak a switchek, hogy a sok broadcast üzenet miatt újra elkezdik felépíteni a feszítőfát"

Attól hogy sok a broadcast még nem fogja a switch újraszámolni a spanningtree-t. Én inkább kettészedném a problémát:
1: redundáns linkeket ellenőriz/megszüntet (és STP beállítások átnézése) szerk.: + nem kívánt redundáns kapcsolatok eltávolítása
2: wireshark-> megkeresném ki küldi a broadcastot és megkeresném hogy miért...

Üdv.

semper fidelis

ha a broadcast flood miatt elveszik egy-ket-sok stp csomag, akkor igenis ujraszamoljak a feszitofat. Az az igazi, amikor ezt ciklusban csinaljak, mert masodpercek alatt megint szetesik a halozat. Mondjuk a switchport az portfast (az stp egyutt megy a normal forgalommal) vagy valamelyik switch buffer megteles eseten eldobja a linket stb.

Multi halokartyas gepek hajlamosak igy megboritani dolgokat. Az univerzalis megoldas ha megborult az egesz halo es mar ugyis minden mind1:
admin down minden port kiveve a switchek kozotti linkek, majd egyesevel enable oket. Ha gyorsitani kell akkor lehet switchenkent enable, igy kiszurni, hogy hol lehet a problemas gep.

A dolog pedig valoszinu, hogy nem azert borul meg, mert elvesznek a BPDU-k hanem valoszinu azert, mert a switchek CPU-ja felszalad 100% kornyekere mivel a sima unicast forgalommal ellentetben a broadcast forgalmat meg kell vizsgalni, hogy neki szol-e valamint replikalni kell parfele:).

( spider | 2012. 11. 14., sze – 10:41 )

Igazából egy olyan alkalmazásra volna szükségem, ami képes összeszámolni, hogy melyik IP címről hány db. broadcast csomagot küldtek.
Valamilyen kis egyszerű konzolos program lenne a legideálisabb, ami jól paraméterezhető, és eredményül már csak azt adja ami kell.
(IP + darabszám)

Alap parancsokkal nem lehet valahogy megszámolni az eth0-ra érkező broadcast csomagokat?

Működik! Köszi! :)

Annyival egészítettem csak ki az egészet, hogy küldött csomag szerint sorba rendezem a listát, és az utolsó értéket íratom ki,
Mert igazából ez a lényeges (nekem):)

már csak át kell fordítanom a MAC címet IP-re
aztán a zabbixban beállítok egy határértéket, ami fölött riaszt majd a rendszer, hogy az XY MAC és IP című eszköz túl sok broadcast üzenetet küld :)

sajnos egyelőre nem találom a megfelelő OID-ot, nem tudom lekérdezni a switchre csatlakoztatott összes eszköz MAC címét

az "1.3.6.1.2.1.3.1.1.2" visszaad néhány IP-t ill. MAC címet, de fura módon csak szervereket...

jó volna tudni hogy melyik OID adja vissza a portokhoz kapcsolódó eszköz MAC vagy IP címét

Upsz, én úgy gondoltam, hogy belépsz a switch-re (talán ssh) és kilistázod a MAC címeket.
Lehet, hogy mellélövök (gugli mondta a címet), de hátha ez segít :)
http://evilrouters.net/2010/04/06/hidden-procurve-commands/
Amit te írsz, az ARP tábla e szerint:
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=hu&c…

mivel a leirt problema alapvetoen ethernet szintu, es nem IP szintu, igy elsosorban ethernet cimeket kapsz. Ha annak az ethernet cimhez tartozik IP cim, akkor azt is megkaphatod

arp -n

parancs hatasara, azonban nem biztos, hogy tartozik hozza.
Mindenesetre a MAC address az egyertelmu, az alapjan is meg lehet talalni a kerdeses gepet.

ha van dhcp, ott is keresgélj MAC-IP összerendelés után:

/var/lib/dhcp/dhcpd.leases

vagy valami nagyobb gép, router, központi szerverben az arp táblában.

Ha sehol sincs (ami könnyen lehet (*)) akkor nem kicsit nehezebb a kérdés.

Kellene egyébként is egy olyan tábla, hogy
MAC - IP - ki használja (ember) - oprendszer - beszerzési év - géptípus.
Sok helyzetben nagy segítség :-)

Vannak olyan MAC címek, amiket igazából nem használsz, nem konfiguráltál, nem ismerhetsz pl. szerverek BMC -jei, valami beépített kütyü (nyomtató stb)

Ha egyáltalán fel van konfigurálva a switchek management felülete, akkor mindegyik switch elmondja, hogy melyik MAC melyik interface felé néz. Ha az az interface egy másik switch felé néz, akkor abban a másik switchben is körbe kell nézni, hogy melyik végponthoz tartozik ez a MAC.

elvileg vannak mindenféle tool-ok, amik képesek a switchek hálózatában snmp -vel lekérdezni, hogy melyik MAC melyik switch melyik interface-jén van, nem dolgoztam még ilyennel, nem tudok segíteni.

szia,

minden IP stackben van ARP tabla (mert az IP igy mukodik) win/lin/msdos.

de ezek nem feltetlenul tartalmazzak a teljes halozatot, csak eppen azt, amit az adott gep el akart erni az elmult par percben.
Ennelfogva ha nem tul nagy a halozat (500 gep peldaul) akkor ha mindegyiket megpingeted az egyik linuxrol, akkor az arp tablaba bele kell kerulnie az osszerendeleseknek. Akar valaszol a pingre, akar nem :-)

a dhcp szerveren nem az arp tabla az igazan erdekes, hanem a dhcp leasing tabla; de hogy az a windowson hol van, nem tudom.

Egyebkent, kitartanek azon gondolatom mellett, hogy igazabol nincs szukseged az IP cimre, neked a valodi gepre van szukseged... vagy legalabbis arra a switchportra, ahova a gyanus gep be van dugva. Ez pedig a switchekbol lekerdezheto.

A DHCP UDP-t hasznal, amit IP szallit, szoval nyilvan IP cim is van benne. Ipv4 eseten 0.0.0.0 a forras, 255.255.255.255 a celcim. Emellett meg layer2 szintjen is broadcast a celcim, igy minden gep latja a csomagokat az adott szegmensen. Innentol meglehetosen egyszeru szamolni a csomagokat, a forras MAC alapjan pedig mar nem nagy kaland megtalalni, melyik switch porton van a delikvens.

Szia,

CISCO-n.
debug arp

és így néznek ki a sorok:
003826: Nov 14 14:16:27.729: IP ARP: rcvd req src 192.168.2.167 d067.e54d.a764, dst 192.168.2.8 Vlan10
003827: Nov 14 14:16:27.729: IP ARP: sent rep src 192.168.2.8 d4d7.48f6.6fc1, dst 192.168.2.167 d067.e54d.a764 Vlan10
003828: Nov 14 14:16:27.939: IP ARP: rcvd req src 192.168.2.240 0014.2223.c0df, dst 192.168.2.78 Vlan10
003829: Nov 14 14:16:27.939: IP ARP: rcvd req src 192.168.2.240 0014.2223.c0df, dst 192.168.2.89 Vlan10
003830: Nov 14 14:16:28.306: IP ARP: rcvd req src 192.168.2.118 bcae.c592.83de, dst 192.168.2.16 Vlan10
003831: Nov 14 14:16:28.306: IP ARP: ignored gratuitous arp src 192.168.2.118 bcae.c592.83de, dst 192.168.2.16 d4d7.48f6.6fc1, interface Vlan10

Innen meg már sínen vagy mint józsef attila...

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c0256414…

Ebbe konkrétan leírja, hogy 2610-esen globál konfig módbol van ilyen, olvasd el mit csinál. (keress a "broadcast limit"-re)

Amúgy az mennyire biztos, hogy ez a problémát a broadcastok okozzák? Eddig nem láttam rá semmilyen bizonyítékot.
--
Kreszán K.
--

incoming broadcast counter nem jo neked? cacti vagy ha nagyon gyakori poll kell (<1 perc) akkor collectd aztan szep garfokon latod, hogy melyik portrol jon jo sok broadcast. Ha szerencsed van akkor csak egyrol.

amugy egy egyszeru perl 1 liner (nincs most elottem console amin ki tudnam probalni szoval ez elegge papir interface de kiindulasi pontnak jo lehet); 


tcpdump -i eth0 ether broadcast | perl '{
%broadcast_per_ip;
while (<>) {
     @line=split(" ",$_);
     $source_ip=$line[source_ip_cimedik_elem];
     if (defined($broadcast_per_ip{$source_ip})){
         $broadcast_per_ip{$source_ip}++;
     } else {
         $broadcast_per_ip{$source_ip}=1;
     }
     #clear sceen ez alapjan: http://stackoverflow.com/questions/197933/whats-the-best-way-to-clear-the-screen-in-perl
     print "\033[2J";
     for $ip ( keys %broadcast_per_ip ) {
        print "$ip :\t".$broadcast_per_ip{$ip}."\n";
     }
}'

( egeresz | 2012. 11. 14., sze – 10:51 )

Miután várhatóan megoldod ezt a konkrét problémát, megjegyezném, hogy a broadcast vihar nem mai dolog. nagyjából 15 évvel ezelött bosszantott először, várhatóan azért, mert 15 éve vagyok a szakmában :-)

Ugyan úgy tünik, hogy egy hibás hálókártya/kliens/ipstack okozza a problémát, de nem, valójában a probléma a hálózat tervezése miatt van. Egyszerűen nem szabad nagy broadcast domaint használni.
(broadcast domain = azon interfészek összessége, amik kölcsönösen látják egymás broadcast-jait)
A konkrét technológiától persze függ, hogy mekkora a kritikus nagyság. 50ohm koax 10mbit esetén (15 éve) olyan 50 gépnél volt a határ, egy mai full switchelt ethernet hálózatban talan 100 gép is lehet...

Értelemszereűen egy broadcast domain egy IP subnet, vagyis a jól tervezett ethernet/ip hálózatban a bradcast domainek és az IP subnetek kölcsönösen megfeleltethetők egymásnak. Ennek megfelelően, ha egy jó nagy broadcast domaint szétvágsz kisebbekre, - például a meglévő hardvereszközökkel vlan konfigurációval - akkor az ip konfigurációt is át kell tervezni, és be kell illeszteni egy routert valahova.

Ez a munka akár kimagaslóan is nagy lehet, pl. dhcp forwardereket beállítani, routert konfigurálni, többszáz kliens ip konfigurációját módosítani azonban hosszabb távon általában megéri.

a vlan az broadcast domain.

Hogyan van összekapcsolva, az a kérdés.

Ha van egy switched, és azon néhány port az egyik vlan-ban, néhány a másikban, akkor a különböző vlan-hoz tartozó portok között nem terjed a broadcast csomag.

Ha van egy switch hálózatod, ami megfelel a következő feltételeknek:

- a switchek közötti kapcsolat mindenhol trunk (802.1q)
- a végponti berendezéskhez nem megy trunk, legfeljebb az általad managelt routerhez/tűzfalhoz
- a végponti berendezéseknél a switchport 'acccess', tehát a switch lekapcsolja a portot, ha valaki egy pirate switchet oda feldug
- a vlan kiosztás közös (pl egy darab 3-as vlan van az egész rendszerben, és azt te állítottad be)

akkor a vlan szeparálja a rendszert broadcast szempontjából, tehát a vlan = broadcast domain. Ekkor szükséged lesz routerre, vagy router funkcionalitású tűzfalra, proxyra, natboxra stb.

Ha két különböző vlan -hoz tartozó portot összedugsz egy ethernet dróttal, akkor ott át fog menni a broadcast csomag.
A routeren nem megy át.

Van egy másik technika is, "port security" néven futott régen a Cisconál, ami azt tudja, hogy meg lehet adni mondjuk 1-5 között egy számot, és max. ennyi különböző MAC címet enged azon a porton, ráadásul ezeket meg is jegyzi. Megoldástól függően a limit fölötti MAC címeket leszarja, vagy az egész portot letiltja a picsába.

elvileg ugyan lehetseges, hogy egy switch ignoraljon minden stp jellegu megszolitast, es ne is kuldjon olyat, de ugy erzem, hogy ez mar csak kotozkodes.

igen, tudjuk, hogy elvileg nem lehet rajonni, hogy a kabel tuloldalan switch van-e vagy sem, de gyakorlatilag ez az 'switchport access' tokjol mukodik. (nem security feature, hanem uzembiztonsagi)

Fenéket, ne beszélj zöldségeket. Ha egy port access, az csak annyi, hogy kifelé leszedi a dot1q tag-et, befelé meg rárakja. A trunk meg nem nyúl hozzá.
A legtöbb szappantartó-switch meg egyáltalán nem ismer STP-t, okosabb eszközökben meg egyáltalán nem ritka a szándékosan/megszokásból/hozzánemértésből rákonfigolt bpdufilter. (vagy globálban ki van kapcsolva, defaultból)
Ne értsd félre, nem kötözködök, csak ennek a dolognak még halvány köze sincs sem az üzembiztonsághoz sem a securityhoz.

( egeresz | 2012. 11. 14., sze – 11:12 )

Az viszonylag ritka, hogy egy megzakkant kliens túl sok broadcast csomagot nyom ki magából.

Az gyakoribb, hogy két megzakkant kliens van, és az egyik broadcastjára a másik broadcasttal reagál és viszont.

( sibike | 2012. 11. 14., sze – 12:47 )

Nézd meg, hogy a switched tud-e storm control szerű feature-t, és kapcsold be. Ha nem, akkor kell írni egy scriptet, ami SNMP-n keresztül megcsinálja ezt szoftverből (figyeli a broadcast forgalmat és lekapcsolja a megfelelő portot).

sajnos nem tud a switch storm controlt
viszont figyelem a RAM és a CPU terheltséget
így legalább azt tudhatjuk, hogy valószínűleg hálózati vihar van
aztán ha ez bekövetkezik akkor kézzel indítom a tcpdump-ot vagy az omnipeek-et
ezzel remélhetőleg ki tudom szűrni hogy melyik gépről jön a broadcast özön :)

sajnos azt még mindig nem találtam meg, hogy melyik OID vagy OID-ok adják vissza a switchre kapcsolódott hosztok IP címeit
találtam IP címeket, de csak szerverek IP címeit, dhcp-vel osztott címeket nem

melyik OID vagy OID-ok adják vissza a switchre kapcsolódott hosztok IP címeit

Semelyik. A switch layer2 készülék, ergó fingja sincs a gépek IP címeiről, ő azokkal nem foglalkozik, ő csak MAC címeket lát. Azokból meg úgy lehet IP címekhez jutni, hogy a gépek által használt next hop router ARP táblájában nézelődsz.

azért bizonyos oidjai adnak vissza IP címeket

én úgy tudom hogy vannak olyan switchek amik már layer 3 szinten is ténykednek :)
legalábbis annó mondtak PTE-n ilyen okosságokat :)

az a baj hogy a MAC címeket sem tudom switch-portonként lekérdezni (csak a switch saját MAC címeit)
de azzal sajnos nem megyek sokra
az már jó lenne ha a switch legalább a rá kapcsolódó gépek MAC címeit visszaadná portonként

persze akkor még mindig nem oldódik meg a címfordítás kérdése

gondolom a DHCP szervernek kellene rendelkeznie a legpontosabb és legaktuálisabb ARP táblával, tehát őt kellene megkérni a címfordításra

Miért nem jó neked a MAC cím?

"én úgy tudom hogy vannak olyan switchek amik már layer 3 szinten is ténykednek :)"

DHCP snooping esetén a swtich gyűjti a mac-ip összerendeléseket, természetesen akkor ha a kliens dhcp-t használ. Bár ha storm control-t nem tud a cucc, akkor ezt sem fogja tudni.

"az a baj hogy a MAC címeket sem tudom switch-portonként lekérdezni (csak a switch saját MAC címeit)"

RARP-pal meg tudod kérdezni a host IP címét.

"az a baj hogy a MAC címeket sem tudom switch-portonként lekérdezni (csak a switch saját MAC címeit)"

Ilyenen próbáltam:
ProCurve J4899B Switch 2650
Firmware revision H.08.86

sw1# sh mac-address ?
[ethernet] PORT-LIST Show MAC addresses learned on the specified ports.
MAC-ADDR Show port the specified MAC address is located on.
vlan Show MAC addresses learned on the specified VLAN.

sw1# sh mac-address [enter]
kíírja az hogy melyik interfacehoz meilyen MAC tartozik

sw1# sh mac-address 50
kíírja hogy az 50-es interfacéhoz milyen MAC-ek tartoznak.

Majd ahogy fentebb írták, a routeren agy arp-táblát kell megnézni hogy a mac-hez milyen IP tartozik.

azért bizonyos oidjai adnak vissza IP címeket

Persze. Annak a pár gépnek a címét láthatod az ARP táblájában, aki az utóbbi pár percben IP szinten megszólította a switchet. Ez kb. a router meg a menedzselését végző gép lehetett...

én úgy tudom hogy vannak olyan switchek amik már layer 3 szinten is ténykednek :)
legalábbis annó mondtak PTE-n ilyen okosságokat :)

Nem az a kérdés, hanem hogy neked ilyen van-e, és így is van-e bekonfigurálva...

az a baj hogy a MAC címeket sem tudom switch-portonként lekérdezni (csak a switch saját MAC címeit)
de azzal sajnos nem megyek sokra
az már jó lenne ha a switch legalább a rá kapcsolódó gépek MAC címeit visszaadná portonként

Megteszi. Minden switch nyilvántartja, hogy melyik portján milyen MAC címek laknak.

persze akkor még mindig nem oldódik meg a címfordítás kérdése

gondolom a DHCP szervernek kellene rendelkeznie a legpontosabb és legaktuálisabb ARP táblával, tehát őt kellene megkérni a címfordításra

Van egy rossz hírem: az ARP tábla timeout-tal rendelkezik, mégpedig pár perces timeout-tal! Ergó ARP táblában csak akkor találsz aktuális infót, ha azzal a valakivel a kívánt gép beszélgetett IP szinten az elmúlt pár percben. Ez a gyakorlatban általában csak a default router esetén áll fenn minden gépre (és amelyik gép nem beszélget senkivel, az esetleg a default routernél sem lesz meg az ARP táblában).
Ha írsz egy programot, ami 1-2 percenként kiolvassa a default routerből az ARP táblát, és épít belőle egy adatbázist, akkor előrébb lehetsz.
Vagy a DHCP daemont ráveszed, hogy adja oda az ő MAC - IP adatbázisát, azaz kinek mit osztott ki. Az ARP azért nem jó, mert az csak a kiosztás/frissítés után pár percben tartalmazza az adott gépet.

A Linuxomon az ARP timeoutot be tudom állítani?
Mert ha igen, akkor azt is meg lehetne csinálni, hogy végigpingelem a változó címtartományt (mondjuk óránként minden elérhető hosztnak küldök 1 ping csomagot.)
Ettől az ARP tábla legalább viszonylag friss lenne.

Vagy ami még ennél is jobb megoldás lehetne, ha egy zabbix ügynök olvasná ki a MAC címeket hosztonként.
Mivel ez adatbázisba kerül, így már csak egy SQL lekérdezés kellene ahhoz, hogy megtaláljam a vétkest. :)
(és így nincs szükség MAC - IP fordításra sem)