Gyűrűs hálózat (switch)

Hálózati eszközök

Gyűrűs hálózat (switch)

  • 2693 megtekintés

( Névtelen (nem ellenőrzött) | 2005. 12. 17., szo – 17:13 )

[quote:6a64e63a5f="Ice"]"Spanning Tree Protocol" :cry:

3COM hálókarikkal érdekes dolgokat tud művelni. Hol megy, hol nem megy.

Én Zágrábban cumiztam pár éve ez miatt. Megoldás az volt, hogy kikapcsoltam a pics@ba és akkor okés volt minden. Mire rájöttem elment 2 nap. Közben Intel hálókarikat rendeltem mert azzal nem volt gond ! Nem bírtam lemondani a rendelést. Maradtak az Intel hálókarik és kikapcsollva hagytam a Spanning Tree Protocolt hátha valaki ráugrik még egy 3COM-mal !!!

Egy Cisco mérnök Úr azt mondta biztos nem ez a probléma és ne nyúljak a swtichhez. No comment ... 8)

nesze neked magas rendelkezesre allas.... :(
mert ugyi nalam a kliensek nagy resze laptop, azok meg hiresek a noname illetve sis vagy rtl halokarolyokrol...

( STP | 2005. 12. 17., szo – 21:16 )

Még nem derült ki, hogy milyen switch-ekkel dolgozol...

(Gyűrű topológia: ARCnet, TokenRing, FDDI, ATM...)

( Névtelen (nem ellenőrzött) | 2005. 12. 17., szo – 21:18 )

[quote:e06988770a="STP"]Még nem derült ki, hogy milyen switch-ekkel dolgozol...

(Gyűrű topológia: ARCnet, TokenRing, FDDI, ATM...)

olcso kti es mercury switchek <20k huf / db

( Skuzzy | 2005. 12. 17., szo – 23:28 )

[quote:7cfaed8331="STP"]Még nem derült ki, hogy milyen switch-ekkel dolgozol...

(Gyűrű topológia: ARCnet, TokenRing, FDDI, ATM...)

OFF
Kis pontositas, az arcnet nem annyira gyuru, 75 ohmos koaxon sin, hasonloan a thin-ethernethez.

( STP | 2005. 12. 18., v – 18:49 )

[quote:4a26a9453c="Skuzzy"][quote:4a26a9453c="STP"]Még nem derült ki, hogy milyen switch-ekkel dolgozol...

(Gyűrű topológia: ARCnet, TokenRing, FDDI, ATM...)

OFF
Kis pontositas, az arcnet nem annyira gyuru, 75 ohmos koaxon sin, hasonloan a thin-ethernethez.

OFF OFF
Kis pontosítás, 93 ohmos koax (igaz a dzsunkások között volt 75 ohmos implementáció), de volt twisted-pair és fiber-optic megvalósítás is.
Aztán zavarba is jöttem az OFF-tól mert valóban, a fizikai megvalósítás star-bus volt, de logikailag akkor is gyűrű. :)
És a fentiek miatt csak látszólag hasonlít a 10Base2-hoz.

De rég is volt...

( STP | 2005. 12. 18., v – 18:51 )

[quote:68bdae41c8="Oregon"][quote:68bdae41c8="STP"]Még nem derült ki, hogy milyen switch-ekkel dolgozol...

(Gyűrű topológia: ARCnet, TokenRing, FDDI, ATM...)

olcso kti es mercury switchek <20k huf / db

Felejtő.
Vegyél/vegyenek normális switch-et ami tud trunk-ölni.
(Mint már feljebb leírták)

( Skuzzy | 2005. 12. 18., v – 20:09 )

[quote:30f9b636c4="STP"]
OFF
Kis pontosítás, 93 ohmos koax (igaz a dzsunkások között volt 75 ohmos implementáció), de volt twisted-pair és fiber-optic megvalósítás is.
Aztán zavarba is jöttem az OFF-tól mert valóban, a fizikai megvalósítás star-bus volt, de logikailag akkor is gyűrű. :)
És a fentiek miatt csak látszólag hasonlít a 10Base2-hoz.

De rég is volt...

UFF :-)
Tenyleg..., de reg volt.. :lol:

( jolle | 2005. 12. 19., h – 08:37 )

[quote:979de2852f="Skuzzy"]Komolyabb switcheket lehet tobb kabellell osszekotni, de akkor vagy trunk-nek konfigolod ezeket a portokat, akkor tobbszorozodik a sebesseg, vagy ha redundanciara mesz ra, akkor ahogy Nihilist irta..

Ha jol emlekszem, a trunk VLAN informaciok atvitelere szolgal, nem tobbszorozodik a sebesseg (cisco)! Ahhoz, hogy tobbszorozd, *etherchannelbe kell rakni az interface-eket mind a ket oldalon. Ez hott ziher. En is igy csinaltam.

( Mik v | 2005. 12. 19., h – 08:38 )

[quote:e9c819ff16="Oregon"][quote:e9c819ff16="ruczati"][quote:e9c819ff16="Oregon"]Sajnos nagyon nem tudok atkabelezni, mert egy "sin" mar vegig fut az epuleten. (inkabb kigyozik)

ahogy en ezt most elgondolom, az kb az, hogy van egy switch valahol, onnet egy cat5 elindul es nekimegy egy masik switch-nek valahol messze? vagy van kozben meg mas switch is?

Azt hiszem ezeken a switcheken nincs semmilyen kapcsolo.

ezt manapsag mar menedzsment interfeszen keresztul (soros konzol, webes jatek, miegymas) lehet kapcsolgatni, es a "menedzselheto" (neveben a lenyege) switch-ek tudjak, bar lehet, hogy van nem menedzselheto switch is, ami elbol tud STP-t (de nem hiszem). ha a switch-eken nincs soros port, akkor jo esellyel nem tudja.

Az irodak folyamatosan bovultek ahogy a ceg nott, igy switchek szama is. Most 4 switch van sorba kotve cca 30 meter a tavolsag 2 swicth kozott egymastol.

kerdes: eleg 1 db STP-t tudo switch ha karikaba kotom oket?

Üdv. Gyűrűt akkor szokás altalában használni ha sok 9-es rendelkezésreállás szükséges. Ahogy elnézem nálatok ez nem szempont, ha KTI, Mercury switchek vannak. Én azt mondom, hogy ha 30 m van a switchek között akkor dobjátok ki az összeset a kukába, és vegyetek 2 valami komolyabb switchet, ugyanakkor kábelezzétek újra az egészet úgy ahogy van. Persze ez pénz kérdés, de hosszútávon megtérül...

Mik

( Névtelen (nem ellenőrzött) | 2005. 12. 16., p – 23:45 )

Hi All!

Valoszinuleg eleg amator a kerdesem, de vagjunk bele:
- Kotott mar valaki gyurube belso halozati switcheket? Tapasztalat?
Jelenleg a switcheim sorba (sin?) vannak kotve, es szeretnek hurkolni egyet.

- Ket switchet kotott mar valaki ket utp kabellel ossze? Gyorsabb lett?

Ezt olvastam rola:
Gyűrűs : a csomópontokat közvetlenül egymáshoz csatlakoztattják, soros elrendezésben, így azok egy zárt hurkot alkotnak. Az üzenetek fogadása egy alkalmas csatoló eszköz segítségével történik. Előre történő huzalozása nehézkes, új csomópont hozzáadása, vagy elvétele megbonthatja a hálózatot. A biztonság kedvéért 2 kábellel is összeköthetik a gépeket. Az adatáramlásnak meghatározott iránya van. Amíg az adatot nem mentik le, addig a gyűrűben kering, tárolódik. Nagy a kockázat, az adatok sérülhetnek, elveszhetnek. Ezt elkerülendő a címzettnek mielőbb le kell menteni és nyugtázni, hogy ne keringjen a végtelenségig.

bye Oregon

( pete | 2005. 12. 19., h – 08:51 )

[quote:d00aeb6f09="jolle"][quote:d00aeb6f09="Skuzzy"]Komolyabb switcheket lehet tobb kabellell osszekotni, de akkor vagy trunk-nek konfigolod ezeket a portokat, akkor tobbszorozodik a sebesseg, vagy ha redundanciara mesz ra, akkor ahogy Nihilist irta..

Ha jol emlekszem, a trunk VLAN informaciok atvitelere szolgal, nem tobbszorozodik a sebesseg (cisco)! Ahhoz, hogy tobbszorozd, *etherchannelbe kell rakni az interface-eket mind a ket oldalon. Ez hott ziher. En is igy csinaltam.

megerositem, a tronk csak tobb vlan-t tud atvinni 1 interface-n, a tobbszoros savszelhez etherchannel (linuxon ether bonding, ha nem tevedek) kell. Hogy ezek mennek-e egyutt, nem tudom.

( ruczati | 2005. 12. 16., p – 23:56 )

[quote:f7d5d46c93="Oregon"]- Kotott mar valaki gyurube belso halozati switcheket? Tapasztalat?
Jelenleg a switcheim sorba (sin?) vannak kotve, es szeretnek hurkolni egyet.

a karikába kötöd őket, akkor azzal annyit javítasz, h ha az egyik elhullik, akkor nem omlik össze a hálód, csak a rajta lógó hostok. De alapvetően inkább fát csinálj, ha nem akarod körbe kötni őket (mert ha pl a középső elhullik, akkor a két szélső se látja majd egymást).

Amíg az adatot nem mentik le, addig a gyűrűben kering, tárolódik. Nagy a kockázat, az adatok sérülhetnek, elveszhetnek. Ezt elkerülendő a címzettnek mielőbb le kell menteni és nyugtázni, hogy ne keringjen a végtelenségig.

ez igaz a token ring típusú hálózatokra (token ring, fddi), de ott se kering a végtelenségig. Az ethernet kicsit másképp működik, az inkbb token bus, ott nem kering a csomag (token, de ez csúsztatás). Ha gyűrűbe akarod tenni az ethernet switch-jeidet, akkor kapcsold majd be rajtuk a spanning tree protokollt, különben minden kapcsoló tovább fogja hirdetni a már körbeért csomagot, és összeomlik a hálózatod.

( _Joel | 2005. 12. 16., p – 23:59 )

A google kulcsszó, amit keresel: "Spanning Tree Protocol"

Pl ezt olvasd vegig:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm

( Sea-you | 2005. 12. 19., h – 08:57 )

[quote:4c3f2d6369="Ice"]"Spanning Tree Protocol" :cry:

3COM hálókarikkal érdekes dolgokat tud művelni. Hol megy, hol nem megy.

Én Zágrábban cumiztam pár éve ez miatt. Megoldás az volt, hogy kikapcsoltam a pics@ba és akkor okés volt minden. Mire rájöttem elment 2 nap. Közben Intel hálókarikat rendeltem mert azzal nem volt gond ! Nem bírtam lemondani a rendelést. Maradtak az Intel hálókarik és kikapcsollva hagytam a Spanning Tree Protocolt hátha valaki ráugrik még egy 3COM-mal !!!

Egy Cisco mérnök Úr azt mondta biztos nem ez a probléma és ne nyúljak a swtichhez. No comment ... 8)

Ilyen esetekben a userportokon ki kell kapcsolni a spanning treet es megoldodik a problema.

( Névtelen (nem ellenőrzött) | 2005. 12. 17., szo – 00:00 )

[quote:e579684abb="ruczati"]a karikába kötöd őket, akkor azzal annyit javítasz, h ha az egyik elhullik, akkor nem omlik össze a hálód. De alapvetően inkább fát csinálj, ha nem akarod körbe kötni őket.

Sajnos nagyon nem tudok atkabelezni, mert egy "sin" mar vegig fut az epuleten. (inkabb kigyozik)

[quote:e579684abb="ruczati"]Ha gyűrűbe akarod tenni az ethernet switch-jeidet, akkor kapcsold majd be rajtuk a spanning tree protokollt, különben minden kapcsoló tovább fogja hirdetni a már körbeért csomagot, és összeomlik a hálózatod.

Azt hiszem ezeken a switcheken nincs semmilyen kapcsolo.

( ruczati | 2005. 12. 17., szo – 00:10 )

[quote:51f5f32af7="Oregon"]Sajnos nagyon nem tudok atkabelezni, mert egy "sin" mar vegig fut az epuleten. (inkabb kigyozik)

ahogy en ezt most elgondolom, az kb az, hogy van egy switch valahol, onnet egy cat5 elindul es nekimegy egy masik switch-nek valahol messze? vagy van kozben meg mas switch is?

Azt hiszem ezeken a switcheken nincs semmilyen kapcsolo.

ezt manapsag mar menedzsment interfeszen keresztul (soros konzol, webes jatek, miegymas) lehet kapcsolgatni, es a "menedzselheto" (neveben a lenyege) switch-ek tudjak, bar lehet, hogy van nem menedzselheto switch is, ami elbol tud STP-t (de nem hiszem). ha a switch-eken nincs soros port, akkor jo esellyel nem tudja.

( STP | 2005. 12. 19., h – 08:58 )

[quote:6f98f45273="pete"][quote:6f98f45273="jolle"][quote:6f98f45273="Skuzzy"]Komolyabb switcheket lehet tobb kabellell osszekotni, de akkor vagy trunk-nek konfigolod ezeket a portokat, akkor tobbszorozodik a sebesseg, vagy ha redundanciara mesz ra, akkor ahogy Nihilist irta..

Ha jol emlekszem, a trunk VLAN informaciok atvitelere szolgal, nem tobbszorozodik a sebesseg (cisco)! Ahhoz, hogy tobbszorozd, *etherchannelbe kell rakni az interface-eket mind a ket oldalon. Ez hott ziher. En is igy csinaltam.

megerositem, a tronk csak tobb vlan-t tud atvinni 1 interface-n, a tobbszoros savszelhez etherchannel (linuxon ether bonding, ha nem tevedek) kell. Hogy ezek mennek-e egyutt, nem tudom.

Ez (ha jól tudom) csak gyártó/definició kérdése.
Nem csak Cisco a világ! ( Buda biztos örül ennek :D :D )

( Névtelen (nem ellenőrzött) | 2005. 12. 17., szo – 00:14 )

[quote:c1b0d54f6c="ruczati"][quote:c1b0d54f6c="Oregon"]Sajnos nagyon nem tudok atkabelezni, mert egy "sin" mar vegig fut az epuleten. (inkabb kigyozik)

ahogy en ezt most elgondolom, az kb az, hogy van egy switch valahol, onnet egy cat5 elindul es nekimegy egy masik switch-nek valahol messze? vagy van kozben meg mas switch is?

Azt hiszem ezeken a switcheken nincs semmilyen kapcsolo.

ezt manapsag mar menedzsment interfeszen keresztul (soros konzol, webes jatek, miegymas) lehet kapcsolgatni, es a "menedzselheto" (neveben a lenyege) switch-ek tudjak, bar lehet, hogy van nem menedzselheto switch is, ami elbol tud STP-t (de nem hiszem). ha a switch-eken nincs soros port, akkor jo esellyel nem tudja.

Az irodak folyamatosan bovultek ahogy a ceg nott, igy switchek szama is. Most 4 switch van sorba kotve cca 30 meter a tavolsag 2 swicth kozott egymastol.

kerdes: eleg 1 db STP-t tudo switch ha karikaba kotom oket?

( Skuzzy | 2005. 12. 19., h – 09:06 )

[quote:f7435e5a06="pete"][quote:f7435e5a06="jolle"][quote:f7435e5a06="Skuzzy"]Komolyabb switcheket lehet tobb kabellell osszekotni, de akkor vagy trunk-nek konfigolod ezeket a portokat, akkor tobbszorozodik a sebesseg, vagy ha redundanciara mesz ra, akkor ahogy Nihilist irta..

Ha jol emlekszem, a trunk VLAN informaciok atvitelere szolgal, nem tobbszorozodik a sebesseg (cisco)! Ahhoz, hogy tobbszorozd, *etherchannelbe kell rakni az interface-eket mind a ket oldalon. Ez hott ziher. En is igy csinaltam.

megerositem, a tronk csak tobb vlan-t tud atvinni 1 interface-n, a tobbszoros savszelhez etherchannel (linuxon ether bonding, ha nem tevedek) kell. Hogy ezek mennek-e egyutt, nem tudom.

Igaz, Cisco-nal a trunk kifejezest nem ezt takarja, de mas (tobbi? :-) ) gyartonal ezt hasznjak. Legalabb is en ezzel talalkoztam. De a (nem egyertelmu) kifejezest leszamitva azert jol tudom, nem? :-)

( Névtelen (nem ellenőrzött) | 2005. 12. 17., szo – 00:23 )

talaltam kozben egy jo leirast:

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

( macroharddoors v | 2005. 12. 19., h – 09:16 )

Trunk nem igazán alkalmas sávszélesség növelésre inkább csak a fizikai redundanciára pl.: kábelszakadás stb., gyakorlatban az etherchannel sem viselkedik másképp "sajnos!", ami igazán növeli a portonként ill. linkenként a sebességet az a LACP Link Aggregation Control Protocol 802.3ad vagy pl.: FreeBSD alatt ng_one2many ami round-robin módszerrel egy csomag erre egy csomag arra alapon ki tudja használni az x link adta sávszélességet, stb..

( ruczati | 2005. 12. 17., szo – 00:23 )

Az irodak folyamatosan bovultek ahogy a ceg nott, igy switchek szama is. Most 4 switch van sorba kotve cca 30 meter a tavolsag 2 swicth kozott egymastol.

arra figyelj, hogy 3x30=90 ~ 100 meter, ami az ethernet hatara cat5-on.

kerdes: eleg 1 db STP-t tudo switch ha karikaba kotom oket?

na ezt en sem tudom, mikor csinaltam ilyet, akkor bekapcsoltam mindegyiken. szerintem kell, de majd ugyis kijavitanak :)

( nihilist | 2005. 12. 17., szo – 00:28 )

a switchek több kábellel való összekötése inkább redundancia szempontjából jó, nem sebességnövekedés miatt. de mivel így fizkai hurkok alakulnak ki és azokat nem szeretjük (broadcast stormok, instabil mac-address tábla, keretek többszöröződése) ezért logikailag hurokmentesíteni kell.

stp protokoll remek erre a célra, és igen, minden switchen kell futnia. utána szépen megbeszélik egymással a dolgokat, kitalálják, hogy melyikük lesz a root switch (innen számolja ki a legrövidebb utakat az stp). és végül azok a switchportok, amik hurkokat eredményeznének blokkolt állapotba kerülnek. aztán, ha esetleg kiesik a használt útvonal, akkor életbe lép a blokkolt rész.

( ruczati | 2005. 12. 17., szo – 00:39 )

bar ha ennyire fontos, hogy egyben legyen a halozat, akkor eloszor szereznek nemkeves penzt strukturalt kabelezesre, hogy legalabb a switch-ek egy helyen legyenek. Ha nem ennyire fontos, akkor felszabaditanek switchportot/vennek meg 1 switch-et es fava alakitanam az egeszet.

( Skuzzy | 2005. 12. 17., szo – 11:16 )

Mint ahogy Nihilist irta, normal (nem managel-heto) switch-eknel gyorsan felejtsd el a hurkot, mert az eredmeny az lesz, hogy meghal az egesz. Komolyabb switcheket lehet tobb kabellell osszekotni, de akkor vagy trunk-nek konfigolod ezeket a portokat, akkor tobbszorozodik a sebesseg, vagy ha redundanciara mesz ra, akkor ahogy Nihilist irta..

( Névtelen (nem ellenőrzött) | 2005. 12. 21., sze – 18:46 )

[quote:fef6f1a992="Mik"]Üdv. Gyűrűt akkor szokás altalában használni ha sok 9-es rendelkezésreállás szükséges. Ahogy elnézem nálatok ez nem szempont, ha KTI, Mercury switchek vannak. Én azt mondom, hogy ha 30 m van a switchek között akkor dobjátok ki az összeset a kukába, és vegyetek 2 valami komolyabb switchet, ugyanakkor kábelezzétek újra az egészet úgy ahogy van. Persze ez pénz kérdés, de hosszútávon megtérül...

Mik

Ez lesz. csak sajna ma nem iden, mert nincs a nagykerben a kliszemelt switch.
1gbit-es halot fogok felhuzni es kirakok minden sz4rt.

( Ice | 2005. 12. 17., szo – 15:04 )

"Spanning Tree Protocol" :cry:

3COM hálókarikkal érdekes dolgokat tud művelni. Hol megy, hol nem megy.

Én Zágrábban cumiztam pár éve ez miatt. Megoldás az volt, hogy kikapcsoltam a pics@ba és akkor okés volt minden. Mire rájöttem elment 2 nap. Közben Intel hálókarikat rendeltem mert azzal nem volt gond ! Nem bírtam lemondani a rendelést. Maradtak az Intel hálókarik és kikapcsollva hagytam a Spanning Tree Protocolt hátha valaki ráugrik még egy 3COM-mal !!!

Egy Cisco mérnök Úr azt mondta biztos nem ez a probléma és ne nyúljak a swtichhez. No comment ... 8)

Ez mit jelent?
Nekünk most sima fa szerkezető hálónk van.
És néha a nagios 600 ms pingeket ad helyi halon, vagy 28% packet loss...
Igazából nem tudok rájönni hogy mi lehet az oka.
STP engedélyezve van.
Vannak 3COM halókartyak a halóban..

Nekünk most sima fa szerkezető hálónk van.
És néha a nagios 600 ms pingeket ad helyi halon, vagy 28% packet loss...
Igazából nem tudok rájönni hogy mi lehet az oka.
STP engedélyezve van.

És próbáltál már?
Pl. próbáld meg egyszer, hogy fogsz két laptopod és a gerinchálód minden kapcsolatán végigmégy az alábbi szerint: fogod az egyik laptopot, bedugod a gerinckapcsolat egyik végén levő switchbe, fogod a másikat, bedugod a kapcsolat másik végén levő switchbe, és pingetsz, mérsz, stb. és megpróbálod megtalálni a nemjó linket.

Aztán, hogy hibás switchport, rosszul elkészített kábel (crosstalk a kábelen, vagy rossz árnyákolás, és emiatt sok zavar), vagy más az ok, azt már utána neki lehet állni kideríteni.

Ezt még nem!
A lényege a dolognak, hogy átlagosan óránként 1 -1 alkalommal fordul elő, de mindig másik eszközzel..
mérem a broadcastokat mrtg -vel (+ tehelést..), de semmi kirivó...
előzőleg másik eszközön volt a nagiosos gép ott is kb ugyan ezeket a jelekett mutatta...

az alábbi log hajnalban keletkezett amikor semmi sem indokolja, hogy terhelt lenne a hálózat...

nagios.log:
[2006-10-17 04:59:17] Auto-save of retention data completed successfully.
Service Ok[2006-10-17 04:53:47] SERVICE ALERT: p1-1-3;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 2.14 ms
Service Warning[2006-10-17 04:52:46] SERVICE ALERT: p1-1-3;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 28%, RTA = 3.06 ms
Informational Message[2006-10-17 04:49:16] Auto-save of retention data completed successfully.
Service Ok[2006-10-17 04:41:47] SERVICE ALERT: p23-1-1;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 1.76 ms
Service Warning[2006-10-17 04:40:47] SERVICE ALERT: p23-1-1;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 0%, RTA = 150.99 ms
Informational Message[2006-10-17 04:39:16] Auto-save of retention data completed successfully.
Informational Message[2006-10-17 04:29:17] Auto-save of retention data completed successfully.
Service Ok[2006-10-17 04:26:17] SERVICE ALERT: p39-1-3;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 5.29 ms
Service Warning[2006-10-17 04:25:17] SERVICE ALERT: p39-1-3;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 28%, RTA = 2.53 ms
Informational Message[2006-10-17 04:19:16] Auto-save of retention data completed successfully.
Service Ok[2006-10-17 04:18:17] SERVICE ALERT: c2;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 0.52 ms
Service Ok[2006-10-17 04:17:47] SERVICE ALERT: p1-1-3;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 1.70 ms
Service Warning[2006-10-17 04:16:46] SERVICE ALERT: c2;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 28%, RTA = 0.42 ms
Service Warning[2006-10-17 04:16:16] SERVICE ALERT: p1-1-3;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 0%, RTA = 212.15 ms
Informational Message[2006-10-17 04:09:17] Auto-save of retention data completed successfully.
Service Ok[2006-10-17 04:02:47] SERVICE ALERT: dg-1-1;PING;OK;SOFT;3;PING OK - Packet loss = 0%, RTA = 1.69 ms
Service Ok[2006-10-17 04:01:46] SERVICE ALERT: p39-1-2;PING;OK;SOFT;2;PING OK - Packet loss = 0%, RTA = 42.63 ms
Service Warning[2006-10-17 04:01:46] SERVICE ALERT: dg-1-1;PING;WARNING;SOFT;2;PING WARNING - Packet loss = 0%, RTA = 117.21 ms
Service Warning[2006-10-17 04:00:47] SERVICE ALERT: p39-1-2;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 0%, RTA = 112.62 ms
Service Warning[2006-10-17 04:00:47] SERVICE ALERT: dg-1-1;PING;WARNING;SOFT;1;PING WARNING - Packet loss = 0%, RTA = 112.93 ms

Én Zágrábban cumiztam pár éve ez miatt. Megoldás az volt, hogy kikapcsoltam a pics@ba és akkor okés volt minden. Mire rájöttem elment 2 nap. Közben Intel hálókarikat rendeltem mert azzal nem volt gond ! Nem bírtam lemondani a rendelést. Maradtak az Intel hálókarik és kikapcsollva hagytam a Spanning Tree Protocolt hátha valaki ráugrik még egy 3COM-mal !!!

Szerintem te valamit ott nagyon elkeféltél!
Van nálam nagyrakás 2950, 3750, kb. 7 hurok a két 3750-em közt, ezek közül az egyik egy két gigás összeköttetésből összejövő trunk, stb. Rengeteg fajta eszköz a portokon: bcm5700, rtl8129, rtl8029, 3c59x, és a csuda tudja milyen driverrel menők vannak még (a legjellemzőbb egyébként a 3Com 905 és a Broadcom 57xx chipes kártyák), és soha semmi gond nem volt... (Jah, ofkóz vegyesen jó sok linuxos és windozos kliens minden típusból...)
De lehet, hogy csak azért, mert Szegeden más a nap és a holdak állása, és ott nemhat a feketemágia...

olcso kti es mercury switchek <20k huf / db

Azok szerintem nem switchek akkor, hanem a szokasos switching-hub-nak csufolt eszkozok. Definicio szerint az a switch ami beszel STP-t. Az, hogy managelheto-e, meg hogy melyik portjanak mekkora pathcostja legyen, mekkora legyen a sajat prioritasa, hogy o lehessen az SpannTree Rootja, mar mas kerdeskorbe tartozik...