Switch tesztelése hogyan

Hálózatok egyéb

Hogyan tudnék tesztelni switcheket? Van egy HP gigás backbone switch + jó pár 3com switch. Sokszor vannak hálózati kimaradások, de a switch logja nem mond semmit. Most már többször előfordult az is, hogy a fileszerveren nullás fájlok mentődnek illetve megsérülnek(több fileszerver is van és mindegyiken ezt csinálja).

  • 3043 megtekintés

( gbor | 2009. 03. 21., szo – 23:53 )

nagy fájlok másolása sokszor? éjszakán át tartó pingelés?

( lajbi | 2009. 03. 22., v – 00:04 )

Eleg erdekes jelenseg. Biztos, hogy a hibas switch okozza a 0-as fajlokat? Nem mondtad, milyen fileserver, de ha TCP-s, akkor pl CRC-nek nem kellene eszrevennie?

A halozati kimaradas mit jelent, milyen hosszuak?
Ha inditas pl mtr-t, es 15-20-50 mp-ek kiesesek vannak, akkor korulneznek SPT korul. Milyen a halozat topologiaja, van-e L2-ben redundans utvonal, stb...

-=Lajbi=-------

( csfeco | 2009. 03. 22., v – 08:02 )

Szia

Sajnos, azt nem tudom, hogyan lehet ezeket tesztelni, de évek óta HP switch-eket használok, és mostmár van több mint két tucat.
Az eddigi tapasztalatok:
A HP ProCurve switch-eknek diagnosztikai képességei azok nincsenek. Eddig egyszer láttam olyat, hogy hibát detektált egy ProCurve 5304xl, mégpedig azt, hogy a ProCurve 10-GbE X2-SC LRM transceiver nem támogatott (mert nem volt hozzá kedvük).
Amikor a ProCurve 5406zl-t (központi router swich) összedugtam a Cisco routerünkel, akkor a teljes hálózat meghalt. A jelenség ekvivalens volt azzal, mintha hurok lettvolna a hálózatban, tuti nem volt. A switch logjaiban erről nem volt egy sor sem. A Spanning Tree-t be kellet kapcsolni (amúgyis, mert csak elfelejtettem), de tényleg nem volt hurok.
Az első adag switch telepítésénél az egyik helyen hibásan működött az egyik 2650-es, bármelyiket raktuk oda, ott rosszúl müködöt bármelyik. A központi 5304 volt rossz, kicserélték és jó lett.
A koliban lecseréltem a múzeális hubokat 2650/2610-48-akra. Kb egy hónapig hol az egyik szakadt le, hol a másik aztán "bejáródtak" fél éve nincs hiba. És mondanom se kell, a log-okból soha nem derült ki semmi.
A rémtörténetek után egy két jótanács:
Mindíg tessék firware-t frissíteni.
Konfigurálás után, és ha fura dolgokat csinál tessék restartolni a switch-el.
Különböző gyártók termékei néha fura dolgokat csinálnak, ha összekötjük őket. Lehetőleg nem kutyulni a különböző gyártók switch-eit.
Nem elkeseredni, 6 év alat sok rémtörténetet össze lehet gyüjteni (többet, mint amit elmeséltem). A rendszer mindezek ellenére kielégítően mőködik.

Sziasztok,

A cisco es barmi mas switch keverese szinte mindig spanning tree protocol (SPT) problemakhoz vezet. Ennek legfobb oka az, hogy a cisco-k alapertelmezetten a PVST nevu valtozatot futtat: Ebben az esetben minden VLAN (802.1q) kulon SPT eletet el, tehat N vlan eseten N SPT mukodik.

Az osszes tobbi gyarto alapertelmezetten egyetlen hagyomanyos (802.1d) SPT-t tart fejben, VLAN-oktol fuggetlenul. Ebbol eleg sok gaz lehet, es ket megoldas letezik:

-kikapcsolni az SPT-t. Ez nem annyira rossz otlet, ha biztos, hogy nincs es nem is lesz L2 hurok a halozatban. Ha veletlenul megis keletkezik ilyen, az csunya :)

-Az osszes epkezlab halozati eszkoz tudja az u.n. MSPT-t (802.1s). Ebben az esetben N vlan eseten M SPT fut, ahol M < N. A configban meg kell mondani, hogy melyik VLAN topologiajat melyik SPT instance-ba keruljon.

Az MSTP es PVST azert is jo, mert a redundans linkek nem ulnek tetlenul. Meg lehet csinalni, hogy egyes VLAN-ok az egyik, masik VLAN-ok a masik linket hasznaljak. A redundancia megmarad, es nincs forgalom nelkuli link.

A SPT-vel azert vannak gondok. Az egyik legnagyobb a lassusag. Alapertelmezetten ilyen 15mp koruli timerekkel dolgozik, akar 50mp-es konvergencia idovel. Erre valaszul talaltak ki a rapid SPT-t (802.1w), ami nagysagrendekkel gyorsabb.

Ajanlott irodalom: http://splash.eik.bme.hu/papers/stp.pdf

Switchen hibakereses:
-megnezni az interface szamlalokat, hogy van-e hibas (crc-s, oversized, vagy mas okbol eldobott) frame
-megnezni, hogy amikor ep nem megy, milyen SPT allapotban van (ehhez sajnos ismerni kell az SPT allapotokat)
-betelhet a MAC tabla, bar ma a gagyik is tudnak 8k mac cimet, a hasznalhatok tobbnyire 32k-t. Hibas halokartya vagy tamado okozhat sok mac felbukanast
-Ha ez nem megy, akkor pl tcpdump-al nezni a BPDU-kat, hogy stapil-e a halozat, van-e topologia valtozas, stb. Cisco eszkozokben van u.n. root guard, mas gyartokat ennyire nem ismerem.

-ha L3 switchrol van szo, akkor hirtelen nagysagrendel bonyolodik a problema, de megmondom oszinten, en csak cisco L3 swithet hasznalok, Ilyen HP, SMC, 3com-okat csak teszteltem es nagyon rossz velemennyel vagyok roluk. L2-ben jok pl a HP eszkozok.

Udv,

Fura, de a HP-Cisco összekapcsolásakor nem az SPT ki, hanem a bekapcsolása volt a megoldás. VLAN csak egy volt a portokon, untagged. A Cisco-ba nem látok bele, az a szolgáltatóé. Persze most jutott eszembe, hogy a GVRP be van kapcsolva, és az esetleg bekavarhatott, bár én kétlem.

Vannak nagyon hasznos campus szintu szolgaltatasok, mint pl a CDP (cisco discovery protocoll), vagy SPT. Na, ezeket szolgaltatasi hatarpontokon nagyon javasolt kikapcsolni.

Cisco-n vannak erre megfelelo szolgaltatasok, pl BDPU filter. Sot, HU ellen van BPDU guard: ha access porton BPDU-t hall a switch, error-disable allapotba kerul a lab. Ez beallitastol fuggoen kezzel vagy X ido utan automatikusan visszaall normalba.

Van meg egy aprosag, amirol meg szoktak felejtkezni: az SPT default timerek kb 7-es atmeroju halozatig jo, utanna megfelelo kepletekkel ujra kellene szamolni. Tehat ha valaki dore modon egymasra lancolja a switcheket, akkor ott nagyon erdekes tunetek jonnek elo.

( gabori | 2009. 03. 22., v – 11:05 )

Hali!

Én ilyenkor az iperf nevű cuccot szoktam használni. Gyakorlatilag annyit kell csinálni vele, hogy belősz egy "szerver" a hálózatod valamelyik részén ráküldesz valamilyen típusú forgalmat. Persze szét szegmentálod őket (kábel kihúz). És addig játszatsz vele amíg ki nem bukik, hogy hol lehet a hiba oka.De vigyázz a dologgal nagyon széttudod spoofolni a hálózatod. Ráadásként nagyon sziszifuszi meló.
Persze lehet hozzá hívni egy hálózati mérnököt is, de arra az ember gatyája is rá megy...