3com 4200 Crasht geregeld

[Yalopa]

hello.

om maar meteem met de situatie in huis te vallen:

4x 3com 4200 switches in 1 stack, verbonden door de gigabit up/down poorten
Daaraan hangen een 10 tal servers(allen met 2 nic in load ballancing) (1 windows file, 2 citrix, 1 novell, 1unix, 1 ISAproxy 1 W2K printserver, 1 NT4 ) en nog wat hubs

de stack op zijn geheel is nu reeds een paar maal gecrasht, waardoor er geen enkele server meer berijkbaar is. de stack is niet meer pingbaar, en het enige wat helpt is de stroom van de switches halen om ze zo hard te resetten. Ondertussen hebben we reeds contact gehad met 3com, daar denkt men dat we de switch gewoon overbelasten.

Nu hadden we het volgende bedacht. als we ipv de servers allemaal met hun 2 nic's op dezelfde switch te stoppen, ze verdelen over 2 switches zodat elke server in aan 2 switches hangt. Dan mag er een switch crashen de andere moet het overnemen (setting van het compaq team op de servers: fault tollerance) alleen: als er een switch crasht sleept ie de ganse stack mee naar de verdommenis

De 4200 configureerd zichzelf, hij vind op de gigabit poorten een connectie naar een andere 4200 en zo bouwd hij zelf zn stack op, maar dat willen we net niet, ze moetten onafhankelijk van elkaar kunnen werken, zodat als er eentje down gaat, de andere kan overnemen. mijn vraag is dus: is er een manier om de switch niet te laten stacken ze onderling toch te verbinden via de gigabit poorten?

De manuals reppen hier met geen woord over
search @ got/google bevatten niet echt relevante results
De cli of webinterface bevatten geen config mogelijkheden naar de stack toe (niets gevonden iig)
Elke device heeft reeds een eigen management IP gekregen
Laatste versie van software is naar de switch gestuurd 2.03

volgens mij moet het mogelijk zijn om dit via de gbic ports te doen, alleen is die upgrade pas voorzien voor volgend jaar (bekabelingsproject fiber) en heb ik nu een oplossing nodig (downtime is niet leuk) . Ook is het waarschijnlijk mogelijk om de links tussen de switches op 100 Mbps ipv 1000 mbps te doen, maar dan verliezen we nog meer snelheid, terwijl we door de verdeling over de switches al een snelheidsverlies konden vaststellen

concreet heb ik 3 vragen:

* Wie weet wat eventuele ander oorzaken zuden kunnen zijn van de crashes van de 3com (google gaf niet veel bruikbaars, site van 3com niets)
* Wie weet als er een mogelijkhijd is om de 4 switches als losse units te hebben ipv een stack, zonder de 1Gbps connectie op te geven
* is de 4200 eigenlijk wel geschikt om een dergelijke taak te vervullen (belangrijkste switch in een netwerk met ong 170 devices of zou een 4400 het beter doen (voor onze servers)

Op de switch zelf hebben we niets ingesteld, alles laten we automatish staan, ook hebben we de loops er reeds uitgehaald (hoewel dat mag, want Spanning tree stat default aan en doet zen werk goed.

Het is een hele lap geworden maar wie me nuttige tips kan geven wil ik nu reeds bedanken

[leon1e]

Ik heb hetzelfde probleem gehad met deze switch (niet in stack), de oplossing was uiteindelijk stormbroadcast control uitzetten.

[Fairy]

Hoe heb je ze verbonden ? Wij hebben zelf de 3300 series, daar heb ik in de masterswitch, de eerste switch een module ingebouwd met 4 interconnect aansluitingen en daar zitten ze met z'n 4en aan elkaar door een soort SCSI kabels.

Heb je ze via UTP in de uplink lopen?

Als dit zo is, zou je eens moeten kijken naar een module om de switches op een andere manier te koppelen.

Wat je ook kunt doen is de 4 switches splitsen, dus per 2 aan elkaar en dan de 2 sets met een normale UTP verbinden. Als het dan weer vastloopt moet je kijken welke van de 2 sets vastloopt. Als je daar achter bent splits je die 2 ook weer op en kijk je daarna welke switch er overblijft. Deze zou ik dan retour 3Com doen.

Wij hebben zelf nooit een probleem als dit gehad, wel is bij ons een keer een switch kapot gegaan doordat de voeding defect raakte. Deze is dus meteen vervangen.

We hebben zelf 2x de 3300 en 2x de 3300XM (Dezelfde maar dan 1u hoogte ipv 2).

[Fairy]

leon1 schreef op 30 September 2003 @ 23:37:
Ik heb hetzelfde probleem gehad met deze switch (niet in stack), de oplossing was uiteindelijk stormbroadcast control uitzetten.

Als dat zo is dan lijkt het me dus wel een softwarefout want daardoor zou ie NOOIT vast mogen lopen/

[leon1e]

Fairy schreef op 30 September 2003 @ 23:41:
[...]


Als dat zo is dan lijkt het me dus wel een softwarefout want daardoor zou ie NOOIT vast mogen lopen/

Ja, zover was ik ook. Ik heb dit ook gemeld aan 3com, en de hele structuur uitgelegd. Hun antwoord was toen "we weten voor 95% zeker dat de mac's de veroorzakers van het probleem zijn" vreemd maar goed. Mijn probleem was wel verholpen, en ik heb altijd nog zitten wachten op een firmware update.
Maar nadat de switch stable was er geen klachten meer waren en de performance is zeker goed, heb ik ervoor het te laten rusten.

Btw. Wij hebben ook 3300's in stack hangen via die soort van scsi kabels, zonder master switch en daar heb ik nog nooit problemen mee gehad in combinatie met mijn mac's & pc's.

[ Voor 14% gewijzigd door leon1e op 30-09-2003 23:52 ]

[Yalopa]

Bedankt voor de reakties zover:

Ze zijn verbonden via de up/down poorten die zijn 1gbps en de GBIC's zijn niet gevuld, daar komt in de middelverre toekomst fiber in.

Ik zou niet liever willen dan ze splitsen, dat is net mn vraag, hoe doe ik het Vervelend detail: de enige momenten waar het een beetje lukt om experimenten te doen zijn: luchpause (half uurtje) en na de kantooruren, de switches zitten uiteraard in een duk netwerk en dat kan ik niet zomaar plat gooien

Moet een functie als broadcast storm control uiteindelijk niet zorgen dat de switch net niet crasht tijdens zware belasting (een strom lijkt me toch erg zware belating)

add-on
leon1: ik ben op mn zoektocht iets tegengekomen over problemen met mac's (meer bepaald het protocol dat ze gebruiken), als ik het nog eens tegenkom post ik het hier voor je, wij hebben echter geen enkele mac.

voordien hadden we ook 1 x 3300 maar die heeft nooit deze problemen gehad..

[ Voor 20% gewijzigd door Yalopa op 30-09-2003 23:59 ]

[leon1e]

leffe_blond schreef op 30 September 2003 @ 23:34:

de stack op zijn geheel is nu reeds een paar maal gecrasht, waardoor er geen enkele server meer berijkbaar is.

Zit er regelmaat in het uitvallen van de switches?

[SED]

De 4200 heeft een erg brak v2 firmware versie. Zo is met de origineel uitgeleverde firmware van v2 geen multicasting mogelijk en moet je uitwijken naar de v1 firmware. Die daarnaast ook niet kan stacken via de 1 gig poorten. Dus feitelijk is dat meteen de oplossing voor je vraag. Downgraden naar het v1 firmware en je problemen zijn opgelost.
Wel lever je dan een groot deel van de advanced mogleijkheden van je 3com in maar het werkt tenminste.
Hebben al diverse contacten met 3com hierover gehad en worden verwezen naar slecht functionerende updates voor v2 firmware.
Conclusie terug naar v1 todat 3com zijn problemen opgelost heeft.

[Yalopa]

Neen niet echt, paar maal overdag gebeurd, week er tussen: niet zo erg hoop gebruikers paar mins down.
Nu 2 x snachts gebeurd 2 dagen na elkaar, wel erg, minder gebruikers urenlang down.. ik kan er iig geen lijn in vinden. Het is wel een probleem van de laatste maand.

SED: erg interessant, wordt deze oplossing gesupporteerd door 3com of ben je op dat moment op eigen risico bezig (3com geeft geen support als je de laatste firmware niet hebt, staat in manual) kan je firmware wel downgraden?? Ik ga maar weer ff googelen

welke mogelijkheden zou ik inlevren? we doen niet aan vlans dus dat zou iig geen probleem zijn

update: de firmware uit de V1 reeks ondersteund mn switches niet

The version 1.05 agent contains no new features. This agent provides support
for the following:
SuperStack 3 Switch 4226T (3C17300)
SuperStack 3 Switch 4250T (3C17302)

wil ik nu net de 3C17304 hebben, dus no support

[ Voor 65% gewijzigd door Yalopa op 01-10-2003 00:59 ]

[SED]

Downgrade met de t versie ( koper gigabit) werkt prima en loste de problemen op.
Is niet aangeraden door 3com die ons aan het lijntje hield. AAngezien een firmware redelijk makkelijk terug te zetten is hebben we het risico genomen en alles werkt nu tenminste.
Wel staan er in diverse documenten stukken over de firmware die wijzen op veel packet problemen en zelfs vastlopende switches.
Waarschijnlijk een van de slechtste firmwares ooit.

ik haal er een paar aan

- Priority tagged multicast packets could cause resets to occur. This has been
fixed.

- 802.1d BPDU packets within the range 01-80-c2-00-00-10 to 01-80-c2-00-00-FF
were transmitted out of a port blocked by spanning tree. This has been fixed
so that these packets are not transmitted out of a port blocked by spanning
tree.

- There is a short delay between a port activating its link status and passing
network traffic. Users of Apple networks, which may transmit initialization
packets during this time, may not have been able to see some network devices.
The delay between a port activating its link status and passing network traffic
has been reduced and the fault fixed.

- When a multicast group has ports on more than one VLAN, if all ports on one
VLAN are removed, when a port is re-added to the multicast group on that
VLAN, there will be a delay before the port receives traffic for that group.
This has been fixed so that there is no longer a delay.

- The switch in a stack would, in certain circumstances, reset after a period
of 49 days of continuous operation.

- Web interface command Physical Interface / Ethernet / History / History-48
Hours only displayed the port statistics over 1 hour. This has been fixed to
display the history over 48 hours.

en deze ijv:

Known problems with this release

- The Switch has problems passing window sizes above 32kBytes with ingress to
egress ratio of 10:1. This is seen with large window size protocols such as NFS.
If the ingress to egress ratio is 100:1 (1000Meg to 10Meg) problems can be
seen with window sizes less than 32kBytes.
The solution is to reduce the window size of any effected protocols.

- If you have IGMP snooping enabled and then disable it, endstation may not
receive Multicast streams. Rebooting the Switch will resolve the problem.

- When setting up a SLIP IP address and an IP address for the unit you must
ensure that the assigned IP addresses are different.

- If you use Netscape to manage your Switch you may experience problems when
trying to change the user password. 3Com recommends that if you use Netscape
and you need to change the password you do so via the CLI command. To do this,
from the Web interface Device View, use the System > Telnet > Connect
operation to start a Telnet connection and then use the
"security device user modify" CLI command.

- If the error, "The previous command window is still active" is displayed
when using the Web interface, you must close that window before you can
select another operation. You should then press Reload (Netscape) or
Refresh (Internet Explorer) in your Web browser.

- The Switch 4200 Web interface can only be accessed by one of the following
Web browsers:
- Microsoft Internet Explorer v4.0, v5.0 and v5.5
- Netscape Communicator v4.5, v4.6 and v4.7

- The Switch 4200 Web interface can be accessed on any of the following PC
operating systems:
- Microsoft Windows 95
- Microsoft Windows 98
- Microsoft Windows NT v4.0
- Microsoft Windows 2000

- Flow control using RTS/CTS signals on the serial port is not functional
and in some situations may result in loss of data over modem connections.

- The switch does not display an error message if inappropriate, but
otherwise legal, IP addresses are used for certain configurations. For example,
the IP address of the switch can be supplied as the tftp server address.
No error is displayed to warn of the mistake. The solution is to supply a more
appropriate IP address.

- An incompatibility exists in the default settings for Link Aggregation
between the Switch 4200 and the following 3Com products:
- Switch 4007
- Switch 3900
- Switch 9300
- CoreBuilder 9000 family
- CoreBuilder 9400
- CoreBuilder 3500

- The products listed above disable auto-negotiation when a port is added to
an aggregated link (trunk).
In order for link aggregation (trunking) to work, ports at either end of
an aggregated link (trunk) must be identically configured. To resolve the
incompatibility, you must complete the following steps:

1. On any of the switches listed, you must disable TCMP on a trunk
(aggregated link) that connects to a Switch 4200, as TCMP is not
supported on the Switch 4200 Series.

2. You must disable auto-negotiation on all ports on the Switch 4200 that
you want to place in an aggregated link before you place them in the
aggregated link.
Refer to the Management Interface Reference Guide on the CD-ROM that
accompanies the Switch 4200 Series for more information about configuring
aggregated links.

NOTE: On the Switch 4200 Series, aggregated links are only supported on
the 10/100/1000 Mbps ports.

- The ifOutUcastPkt and ifInUcastPkt MIB objects from the interfaces MIB group
can occasionally appear to increment by one and then decrement by 1 if no
unicast traffic is received and/or transmitted over a refresh period.
________________________________________________________________________________

[Verwijderd]

Ik heb zelf ook een aantal 4228G's.
Mocht je via gigabit over koper deze switches willen linken moet je gewoon je koper kabel in de " up " poort van switch 1 en de "up " poort van switch 2 stoppen. Dan maakt hij er geen stack van.

Verder werk ik met V2.03 en heb ik nog geen noemenswaardige problemen ondervonden.
Op campzone had ik slechts een vage vastloper. Een harde reset werkte, maar ik vermoede dat dit iets met mijn SNMP settings te maken had maar dat is een lang verhaal. Maar ik moet wel toegeven dat ik alleen mijn GBIC poorten gebruik om de switches via fiber te linken, dat werkt prima.

[Yalopa]

heel wat van de dingen die SED aanhaald was ik ook al tegengekomen op internet. Tresco zijn tip ga ik morgen proberen, ik had er zelf al ff aan gedacht alleen durfde ik de zaak niet plat te gooien, naja morgen dan toch maar ff doen... op hoop van zegen, morgen volgt verslag, iig heeft de switch het iig wel volgehouden. bedankt voor het meedenken

[ Voor 6% gewijzigd door Yalopa op 01-10-2003 20:33 ]

[SED]

Tresco, kun jij multicasten over die switches?

Ik heb hier twee locaties met 4200 series die geen van allen met de v2 firmware kunnen multicasten.
Was ook een erkend 3com probleem aldus support die vervolgens een nieuwe firmware stuurde die ook niet werkte.
( ben exacte revisie even kwijt, zoek ik op)
De v1 werkte wel en mist weliswaar de advanced opties maar dat is beter dan niet multicasten in een omgeving waar je regelmatig tientallen desktops moet verversen.

[Verwijderd]

Mocht het upgraden mislukken dan kan je het meestal met de SUU (Serial Upgrade Utility) wel weer rechtzetten. Zo heb ik mijn 3300 een keer gered toen ik zo slim was om midden in de firmwareupgrade de stekker eruit te trekken. (Na 20minuten...) met SUU even de firmware erin gezet en voila, mijn switch bootte weer

[Predator]

Heb je nog andere 3com switches die hetzelfde gedrag vertonen (die op hetzelfde stroomnet zitten) ?

Een slechte voeding, of onzuivere stroom kan een switch wel es laten vastlopen, en sommige 3com types durven daar wel es gevoelig aan zijn, heb ik me laten vertellen.

Indien software upgrades niets uithalen kan je daar misschien ook eens naar kijken.

[ Voor 14% gewijzigd door Predator op 02-10-2003 10:09 ]

[--Mulder--]

Sommige 3Com switches zijn inderdaad heel gevoelig voor spannings verschillen. Een mooi voorbeeld was een Lan-Party dat vorig jaar werd georganiseerd waar men ook alleen maar 3Com apparatuur gebruikte.

Het netwerk was ontzettend traag en switches vielen uit. Men heeft toen contact gehad met 3Com en als oplossing werd aangedragen om alle switches op een UPS aan te sluiten, zodat de spanningsverschillen werden opgevangen door de UPS'en.

Dus misschien ook voor jou een optie om de switches op een UPS aan te sluiten.

[Yalopa]

Neen, onze andere switch 3com 3300 heeft dit gedrag niet. Bedoel je met spanningsverschillen trouwens piek en dal in de stroomvoorzienning of bedoel je potentiaal verschillen tussen de devices onderling?

Ondertussen hebben we alweer wat veranderd: doordat we de 2 nics van elke server op load ballancing hadden ipv trunk was de windowsfileserver irritant traag geworden, dus hebben we elke server toch maar weer op 1 switch gehouden, het "serverpark" werd echter wel verdeeld over 2 switches. Ook is de stack "gebroken".

Actie die nu nog ondernomen wordt:
Een week lang een workstation alles laten Rmon'en om te zien waar de pijnpunten liggen (en daarnaa laat ik hem lekker staan )
Aan de hand daarvan het newerk wat beter verdelen waar mogelijk.
Eventueel nadenken over de topologie / waar nodig agregated/backup links toevoeggen

Zaderdag zal ik daar de ganse voomiddag zijn omdat men een patchkast gaat verhuizen, ondertussen kan ik wat testen gaan doen zonder veel gebruikers te storen.

Nog een sidevraag:
Is het verstandig om Rmon software te laten lopen op een NT4 server? (hij heeft momenteel niet zoveel werk meer) of is dit om de een of andere reden af te raden??

zoals je merkt ben ik momneteel de pist aan het opgaan van crash door overbelasting, hoop dat het de juiste gok is. Zolang er niets meer crasht weet ik ook niets....

[Predator]

leffe_blond schreef op 02 October 2003 @ 19:33:
Neen, onze andere switch 3com 3300 heeft dit gedrag niet. Bedoel je met spanningsverschillen trouwens piek en dal in de stroomvoorzienning of bedoel je potentiaal verschillen tussen de devices onderling?

pieken en dalen

[Yalopa]

Ondertussen zijn we een weekje verder en ben ik niets wijzer geworden wat de oorzaak betreft. Dit is positief in de zin dat de boel nu weer stabiel draait, waarschijnlijk overbelasting dus.
Ondertussen ben ik wat gaan nadenken over de topololigie in het algemeen dus. Nu kunnen we 2 richtingen uit:

1: Een ring maken 1-2-3-4-5 en 5 hangt weer aan 1. met spanning tree worden loops voorkomen
Pro: waneer er nog eens device wegvalt zullen daar minder clients last van hebben, er is ook geen single point of failure
Con: doordat een client meer switches zal moeten overbruggen wordt de latency verhoogd, sommige printers verdragen dat niet zo goed, ook access databases lijken dat niet bepaald fijn te vinden

2: Extended start topoligie: alle switches laten arriveren op 1 centrale switch
Pro: er moetten minder switches overbrugd worden, wat dus beter is voor latency
Con: er is een singele point of failure, nl die centrale switch, als die uitvalt is alles weg

-->Verbinding gaat in beide gevallen over 1 Gbps link

Voor beide situaties valt dus wat te zeggen

Naar de toekomst komen er waarschijnlijk nog 2 switches bij (project iedereen op 100) dit moet ook meegenomen worden in de overweging

Persoonlijk ben ik meer voorstander van de extended star topologie maar toch had ik graag extra opinies gehad

[Verwijderd]

Misschien is het wat om na te denken over een Nortel of Intel Coreswitch? Of een andere zware 3com Coreswitch, daarmee bedoel ik meer in de richting van modulaire switches. Dan kun je tenminste delen upgraden/vervangen als ze niet goed werken en niet meteen de gehele switch. Dan heb je ook wat meer uitbreidingsmogelijkheden in de toekomst. (7700 serie van 3com)

[Yalopa]

Is zoiets niet overdreven?? ik bedoel we praten hier over 170 - 200 devices (servers, workstations en printers) en we doen geen echt speciale dingen met die switches, ze moetten gewoon switchen, dus geen vlans, qos of wat dan ook...

[Verwijderd]

Je hoeft ook geen volledig bezette switch te nemen. Er bestaan ook wel van die chassis van HP die niet zo groot zijn. Daar kun je bijvoorbeeld 10x 1gbit-modules in doen. Zijn al goed genoeg denk ik. Als er 1 onderuit gaat gaat tenminste niet je hele switch onderuit. (Heb het meegemaakt met die compaq-switches, ging een 8-poorts 100mbit-module kapot, en alleen dat ding, en niet de complete switch)

Edit:

Ik had het dus over bijvoorbeeld een HP ProCurve 8000m of een 4000m (bij de 4000m krijg je 5x 8 ports 100mbit modules bij).

[ Voor 15% gewijzigd door Verwijderd op 13-10-2003 21:32 ]

[Arfman]

Alhoewel je een goede optie aandraagt Rippie, is het natuurlijk van de zotta dat TS nieuwe switches aan moet schaffen omdat de oude niet werken. Ik bedoel, als je nu echt Layer3 of zelfs 4 gaat werken, icm. VLAN's en QoS, okee, maar deze dingen moeten gewoon ... switchen. Niet meer, niet minder. Dat moeten zelfs low-budget 2950's van Cisco probleemloos kunnen (en zelfs nog meer).

[Verwijderd]

De TS had het er over om een ster-topologie te nemen. Met ongeveer 200 devices, een lage latency en een hoge beschikbaarheid is het niet eens een gekke optie om een fatsoenlijke coreswitch te nemen lijkt me. Ik kan me hierin vergissen, maar een goede switch lijkt me dan niet meer dan redelijk. En zo veel hoger dan een Cisco 2950 zit je ook niet bij de aanschaf van een HP 4000m als je de specificaties vergelijkt.

Edit:

Maar misschien past de 4100gl of de 5300xl serie beter in hun beleid. Daar kun je modules in zetten met meerdere GBit-poorten. Kun je gaan truncken naar je switches toe of naar je servers. Tis maar een ideetje.

[ Voor 22% gewijzigd door Verwijderd op 14-10-2003 09:52 ]

[Predator]

leffe_blond schreef op 11 oktober 2003 @ 15:02:
1: Een ring maken 1-2-3-4-5 en 5 hangt weer aan 1. met spanning tree worden loops voorkomen
Pro: waneer er nog eens device wegvalt zullen daar minder clients last van hebben, er is ook geen single point of failure
Con: doordat een client meer switches zal moeten overbruggen wordt de latency verhoogd, sommige printers verdragen dat niet zo goed, ook access databases lijken dat niet bepaald fijn te vinden

Heb je dat ook al effectief getest, want ik kan zeer moeilijk geloven dat jij al last hebt van 4 switch hops.

2: Extended start topoligie: alle switches laten arriveren op 1 centrale switch
Pro: er moetten minder switches overbrugd worden, wat dus beter is voor latency
Con: er is een singele point of failure, nl die centrale switch, als die uitvalt is alles weg

-->Verbinding gaat in beide gevallen over 1 Gbps link

Maar de 2de is wel een stuk performanter. De 1Gbps links centraal (het verst van de poort in blocking mode) zullen meer data te verwerken krijgen.

Persoonlijk ben ik meer voorstander van de extended star topologie maar toch had ik graag extra opinies gehad

Coreswitches zijn redelijk fail-safe. Dubbele voeding & dubbele sturings/controle-modules als je dat wenst. Als een gewone module defect gaat kan je die snel vervangen.

Het chasis van modulaire switches is niet duur. Maar dan heb je ook niets.
De hoge prijs ligt vooral in de sturings/controle-modules.

Arfman schreef op 13 oktober 2003 @ 23:07:
Alhoewel je een goede optie aandraagt Rippie, is het natuurlijk van de zotta dat TS nieuwe switches aan moet schaffen omdat de oude niet werken. Ik bedoel, als je nu echt Layer3 of zelfs 4 gaat werken, icm. VLAN's en QoS, okee, maar deze dingen moeten gewoon ... switchen. Niet meer, niet minder. Dat moeten zelfs low-budget 2950's van Cisco probleemloos kunnen (en zelfs nog meer).

Natuurlijk, maar de topicstarter is gewoon even aan het nadenken over mogelijke andere oplossingen

[Yalopa]

naja ik sta open voor elk alternatief maar tenzij ik echt keihard ga kunnen maken dat nog nieuwe apparatuur nodig is om de problemen op te lossen ga ik niets krijgen, het idee van corebuilders kan ik waarschijnlijk wel vergeten. Het is waar dat ik denk over andere oplossingen, maar dan wel met deze apparatuur

over die latency:
De switches staan niet op dezelfde lokatie, er zit telkens 100m (soms zelfs een beetje meer) UTP kabel tussen. dus, dat doet er ook wel zijn schepje bij. Er komt volgend jaar glas

ik heb ondertussen wat zitten tekenen:



1: een combinatie van de 2: lijkt wat vreemd maar moet mogelijk zijn max 4 switch hops dus dat blijft beperkt, nadeel: er zijn 3 kritieke punten (en kast 4 volgt vroeg of laat)

2 de ring in zn puurste vorm pro: uitval is "geen probleem" nadeel veel switchhops

3 extended star, vereist een switch die ik niet zal loskrijgen tenzij ik dit doe met een type zoals ik nu reeds gebruik, maar daar is ie niet geschikt voor..

4 ook extended star maar dan met slechts 4 punten die arriveren op 1 centraal punt dit moet doenbaar zijn, de 2 Gb poorten zitten dan vol en er ook de gbic poorten worden gevuld. als ik hier verder niet al te veel op plaats (wat printers ofzo) dan overleeft die switch dat volgens mij ook wel. Ook 3 critike switches

De opties zijn dus 1 2 4. Tenzij er een niet al te dure switch in het assortiment van 3com zit die 3 wil doen. (ga ik nu opzoekken)

offtopic:
oef, posten in PNS neemt heel wat meer tijd in beslag dan ergens anders, naja julie helpen ook goed, dus het is het wel waard

[Verwijderd]

Bij optie 3 (extended star), wat voor poorten wil je dan naar die andere switches hebben? Bijvoorbeeld 2Gbps trunks, of 1gpbs lijntjes. Als je dan lijntjes gaat nemen van die coreswitch naar je andere switches en op die "uitlopers" zitten ook nog es je switches krijg je denk ik performanceproblemen. Dan wil je zeg maar 10Gb (1Gbit per server) over een 2Gbit trunk gooien. Dus een reëele optie zou dan zijn de servers direct op de coreswitch of op een andere switch met een grote bandbreedte richting de rest (Coreswitch dus).

Wat betreft het nadeel van 2 dat er veel hops nodig zijn: als je telt zijn er ook maar maximaal 4 hops nodig (worst case 7 hops als er een interlink wegvalt of 6 als er een complete switch mee ophoudt, maar daar gaan we niet van uit ).
Met dan op elke switch misschien een server of 2, zodat de gemiddelde load per switch wordt verdeeld over de gehele ring. Maar ook dan krijg je wellicht performaceproblemen.

Ik weet niet of de switches dit bij elkaar genoeg staan om van de matrix-kabels gebruik te kunnen maken zodat je de boel kan stacken. Of misschien een deel ervan zodat de ring wat kleiner wordt.

Wat betreft een andere switch van 3com (en aangezien de 7700 niet in aanmerking komt) is de 4005 misschien iets om naar te kijken (geen core, maar een workgroup-switch en bovendien modulair). Maar ik denk dat die misschien iets te weinig capaciteit heeft, maar dat moet je zelf misschien beoordelen.

offtopic:
Inderdaad man, dit is heel wat uitgebreider dan de overige topics, maar wel veel leuker!

[Yalopa]

In kast A hangen alle servers. alle andere kasten hebben enkel workstations, dus daar hoeft geen 1000 Mbit naartoe (geen vereiste, mag wel natuurlijk). Met optie 2 is dat overgens wel mogelijk want er zijn per switch slechts 2 poorten nodig. Stacken hebben we gedaan maar zijn we net vanaf gestapt omdat waneer er 1 switch crashte hij het ganse netwerk meesleepte (4 devices in stack) en haast iedereen zat op die stack

of 6 als er een complete switch mee ophoudt, maar daar gaan we niet van uit ).

Moet ik wel van uitgaan, het is de reden waarom ik dit topic gestart ben.

Mischien 2 switchen stacken, daarover de servers verdelen en de GBIC poorten gebruiken om met naar de nadere kasten te gaan? Vervolgens de overgebleven GBIC poorten in B, C,D gebruiken om deze kasten onderling ook te verbinden (redundante links)
... In een ring krijg je op het laatste segment toch veel minder BB naar de servers aangezien hij steeds meer moet delen met andere switches

* Yalopa denkt slechts hardop

[SED]

Misschien is deze iets?
3Com 3C17700 SuperStack3 4900, 12p Switch 100/1000 € 3200,00

[ Voor 5% gewijzigd door SED op 15-10-2003 18:57 ]