Nieuw netwerk

[Azhrarn]

Ik ben momenteel bezig met een voorstudie van een nieuw netwerk voor het bedrijf waar ik werk. We zijn in totaal met een 700-tal mensen. Tegen midden volgend jaar, is ons nieuw gebouw af en gaan alle mensen hiernaar toe verhuizen. Ik heb dus nog wel even, en toch weer niet omdat er wel wat keuzes gemaakt moeten worden.
De directie heeft besloten om in 1 keer te vertrekken en een volledig nieuw netwerk en een nieuwe PBX. De keuze is na discussie met verschillende leveranciers, lastenboek,... waarschijnlijk Cisco Call Manager (IP-PBX).
Nu moet echter nog een nieuw netwerk hiervoor opgebouwd worden. Momenteel bestaat ons netwerk uit één Catalyst 6509 met 2*48poorts 10/100 en 1*48 poorts 10/100/1000, tevens een redundante Supervisor 2 met MFC en PFC. Hierop zijn alle servers en access-switches van de verdieping op aangesloten (Catalyst 2950T-24)
Dit is echter het oude systeem. In dit nieuwe systeem moet redundantie uiteraard zeer hoog in het vaandel staan. Daarom had ik gedacht aan 4 * 3750E-48TD en 20 * 3560-48PS. De 4 * 3750E-48TD zijn met elkaar verbonden via StackWise Plus kabels en vormen zo 1 virtuele cluster. Indien 1 switch hiervan uitvalt steek je er gewoon een nieuwe in en deze krijgt automagisch de configuratie van de uitgevallen switch. De 20 * 3560-48PS zijn rechtstreeks verbonden met elk 2 kabels op deze cluster en gebond in een Gigabit Ether Channel. Waarbij het de bedoeling is elk Channel opgebouwd is door connectie op 2 fysiek verschillende switches. Dit maakt dat een probleem in 1 Coreswitch geen impact kan hebben op de verdiepingen hun telefonie. Eveneens is er eigelijk geen echte Spanning-Tree nodig want je hebt geen loops. Het zijn allemaal GEC's.
Dit lijkt me een goede setup om onze Cisco 7961 phones power te kunnen geven. Ik zit nog wel in de knoop met onze UPS-en. Noch de Cisco 2300 of de Cisco 675 kunnen 3 PoE switches tegelijkertijd power geven. Ik vermoed dat ik zeker nog bij MGE of APC ofzo moet gaan rondloeren.
Tevens ben ik ook niet helemaal zeker van deze setup door het toedoen van een Consultant. Ik vertelde hem wat ik van plan was en hij vertelde mij: "Waarom ruil je je de Roll's Royce van de switches in, voor een Mercedes Benz". Ik begrijp wat hij wil zeggen. (6500-reeks is niet bepaald goedkoop), maar ik zie eigenlijk alleen maar voordelen aan deze 3750-reeks met de StackWise Plus. Ik ben namelijk niet geïnteresseerd in blades met WLAN-controller of Firewall of WAN-poorten rechtstreeks op de Core Switch. We hebben namelijk geen WLAN (bewust), tevens gebruiken we een geclusterde Checkpoint Firewall-1 en voor onze WAN hebben we # Cisco routers.

In bijlage heb ik nog een tekening toegevoegd van mijn eerste draft.



Wat denken jullie hiervan?

[TrailBlazer]

hulde voor TS
ik dacht eerst weer iemand zijn thuisnetwerk wil upgraden.
Verder ziet het design er best netjes uit. Je zou eventueel nog 2 Access switches aan elkaar kunnen koppelen en dan vanaf elke switch per paar maar 1 touwtje naar 1 van de 2 Distributie switches aanleggen. Ik weet niet of er SFP inziteen maar als je er daar een stuk of wat an kan besparen is dat best te overwegen

code:

distributie1      -     distributie2
    |                        |
    |                        |
accessswitch1     -     accessswitch2

[Azhrarn]

Op jouw manier bespaar ik toch geen enkele SFP hoor. Ik heb nog steeds 2 SFP's per access-switch nodig. Tevens gaat de Spanning Tree de verbinding tussen de 2 access-switches uitschakelen en is je uplink dus maar 1Gbps per access-switch.
Het liefst van al schakel ik de loops zo veel mogelijk uit om geen Spanning-Tree gefoefel te hebben. (Ingewikkeld en moeilijk voorspelbaar).
Er is wel iets te zeggen voor jouw idee als de 2 access-switches elk kabels krijgen van een aparte fysieke locatie. Dit is echter niet het geval, de kabels (10*CAT6 per verdiep) zullen allen dezelfde richting volgen. Wat een eventuele single point of failure is, als een technieker zijn slijpschijf wat zou misplaatsen...

PS : Wat bedoel je met TS?

[Verwijderd]

TS = topic-starter = degene die de thread/topic heeft geopend

[Azhrarn]

Bon het probleem, van de slijpschijf is opgelost. Na discussie met mijn technieker, zal hij proberen om 5 kabels verdiep aan de linkerkant en 5 kabels langs de rechterkant te plaatsen.
Tevens vertelde hij mij dat de technieker die met een slijpschijf daar in begint zonder dat ie er bij is persoonlijk vermoord word door hem. BTW: I Second that!

[TrailBlazer]

Azhrarn schreef op dinsdag 20 februari 2007 @ 11:21:
Op jouw manier bespaar ik toch geen enkele SFP hoor. Ik heb nog steeds 2 SFP's per access-switch nodig. Tevens gaat de Spanning Tree de verbinding tussen de 2 access-switches uitschakelen en is je uplink dus maar 1Gbps per access-switch.
Het liefst van al schakel ik de loops zo veel mogelijk uit om geen Spanning-Tree gefoefel te hebben. (Ingewikkeld en moeilijk voorspelbaar).
Er is wel iets te zeggen voor jouw idee als de 2 access-switches elk kabels krijgen van een aparte fysieke locatie. Dit is echter niet het geval, de kabels (10*CAT6 per verdiep) zullen allen dezelfde richting volgen. Wat een eventuele single point of failure is, als een technieker zijn slijpschijf wat zou misplaatsen...

PS : Wat bedoel je met TS?

Hmm je spaart geen SFP mischien wel wat lang glas. Wel kan je je links tussen de routers gewoon koper houden, maar als ik het zo lees ga je toch overal koper aanleggen.
Je wilt nu etherchannels maken tussen de access en distributie switches. Dan is jouw verhaal logischer en heb je geen gezeur met spanningtree inderdaad

[Azhrarn]

Tja, waarom zou ik fiber nu leggen. Koper is goedkoper en met Gigabit heb ik meer als genoeg. Mijn afstanden zijn ook in orde, en de kabels worden allemaal geverifieerd dus... Misschien dat we later fiber leggen tussen de verdiepingen voor 10G of 100G of zo?? Maar da's verre toekomstmuziek.
Wat me nog wel steeds dwarsligt is die opmerking van die consultant. Is er een goede reden om deze setup niet te gebruiken of was het alleen maar een snobistische opmerking?

[Qwerty-273]

Azhrarn schreef op dinsdag 20 februari 2007 @ 10:43:
Tevens ben ik ook niet helemaal zeker van deze setup door het toedoen van een Consultant. Ik vertelde hem wat ik van plan was en hij vertelde mij: "Waarom ruil je je de Roll's Royce van de switches in, voor een Mercedes Benz". Ik begrijp wat hij wil zeggen. (6500-reeks is niet bepaald goedkoop), maar ik zie eigenlijk alleen maar voordelen aan deze 3750-reeks met de StackWise Plus. Ik ben namelijk niet geïnteresseerd in blades met WLAN-controller of Firewall of WAN-poorten rechtstreeks op de Core Switch. We hebben namelijk geen WLAN (bewust), tevens gebruiken we een geclusterde Checkpoint Firewall-1 en voor onze WAN hebben we # Cisco routers.

Azhrarn schreef op dinsdag 20 februari 2007 @ 12:17:
Tja, waarom zou ik fiber nu leggen. Koper is goedkoper en met Gigabit heb ik meer als genoeg. Mijn afstanden zijn ook in orde, en de kabels worden allemaal geverifieerd dus... Misschien dat we later fiber leggen tussen de verdiepingen voor 10G of 100G of zo?? Maar da's verre toekomstmuziek.
Wat me nog wel steeds dwarsligt is die opmerking van die consultant. Is er een goede reden om deze setup niet te gebruiken of was het alleen maar een snobistische opmerking?

Lijkt mij, gekeken naar je totale plan, inderdaad dat de consultant je meer aanraad dan je nodig hebt. Natuurlijk zou je de 6500-reeks kunnen blijven gebruiken, maar je plan is zeer goed uitgewerkt en volgens mij voldoende voor de komende jaren. En als je verschillende opties van je 6500-reeks toch niet gebruikt, waarom zou je hem dan houden/kopen.

[McKaamos]

Lijkt me gewoon een snobistische opmerking dan... Jouw oplossing ziet er goed uit.
Daarnaast: Goedkoop is duurkoop.

[bartgabriels]

Ik zou gaan voor de Catalyst 3750 series met StackWise (is de StackWise Plus al uit?). Deze kan tot 9 switches in stack plaatsen, hetzelfde dus als de 4500/6500 (10 sledes - min 1 Processor unit) tenzij je voor the top of the bill gaat, diegene met 13 slots.

Ook aangezien Cisco nog steeds investeert in de 3750 serie (de nieuwe 3750-E) zijn deze switches zeker geen slechte beslissing.

[Azhrarn]

Dat was mijn idee dus ook hierover hé. Als ik voor de 6500 ga, dan zou ik er zo'n twee moeten hebben voor de redundantie natuurlijk. Probleem is natuurlijk de verbindingen dan hé. Hoe moet je die access-switches connecteren met die twee 6500 switches op een redundante manier. Ik had begrepen dat je dan L3 redundantie nastreeft. Nadat je nog eerst op L2 (spanning-tree vooral) alles zo fijn mogelijk hebt getuned. Soit, ik weet niet goed hoe ik met 2 6500 zou doen, maar ik heb een zwaar vermoeden, dat het een pak ingewikkelder zou zijn dan mijn huidig idee.
Wat ik me ook nog verder afvraag is hoeveel Etherchannels, een cluster van die nieuwe Catalyst 3750E switches kan trekken. Ik weet dat de "oude" 3750 er 48 af kon? Zou dit veranderd zijn? Ik hoop van wel. Want wat er over blijft zal gebruikt worden voor bedrijfskritische servers. Alleen vind iedereen in zijn eigen ploeg zijn server natuurlijk het belangrijkst...

[TrailBlazer]

met een 6500 zal je inderdaad afhankelijk zijn van SpanningTree voor redundantie. Eventueel zou je voor 2 6504's kunnen gaan. Je hoeft dan geen backup supervisors erin te stoppen omdat ze toch al elkaars backup zijn. Even een vette trunk van 4 gigabits aanleggen tussen die 2 devices en draaien maar.

[Azhrarn]

Tja, daar zit blijkbaar nog een extra punt voor de 3750 optie. Even een vette trunk aanleggen van 4Gbps tussen de twee Coreswitches (6504 bvb). Maar dat is echter helemaal niet vet vergeleken met de 64 Gbps die er tussen de 3750E is. Die 64 Gbps is zelfs meer dan wat ik nu heb in mijn oude 6509 (32Gbps want geen switch fabric). Ik kan me echt niet ontdoen van het idee dat de 3750E oplossing beter en vermoedelijk goedkoper is dan de 6504 oplossing. Ik zal waarschijnlijk eens een feature-to-feature comparison moeten doen, en zien wat ik mis zonder 2*650x.

[TrailBlazer]

De 6500 zal waarschijnlijk wat meer kunnen met QoS en dergelijke. Echter mijn ervaring is dat de beste QoS een overvloed aan bandbreedte is.

[ijdod]

Ik zie eigenlijk maar een probleem: Qua redundantie ben je afhankelijk van het functioneren van de stacklinks, en het achterliggende mechaniek. Welke waarde je daar aan hecht, in vergelijk met de enkel chassis/redundante sup die je nu hebt is een lastige. Ik zou denk ik voor de 6500 gaan. De 6500 is een beter platform; maar dat komt met een prijs. Ik denk eerder dat een dergelijke 3750 oplossing een forse hap neemt uit situaties waar nu een 4500 zou staan. Dat gezegd, is het een leuke oplossing .

Glas voor de verbindingen naar de SERs is een sterke aanrader in verband met galvanische scheiding. Er kunnen in een pand behoorlijke potentiaal verschillen ontstaan, die er voor zouden kunnen zorgen dat er ergens rook uit gaat komen.

STP vs etherchannel: STP is inderdaad complex, maar juist uiterst voorspelbaar. Daar zit hem juist de kracht. Voor Etherchannel vraag ik me af in hoeverre in de marges gaat komen van het gebruik van een techniek op een manier die daar eigenlijk niet voor bedoelt is.

[Qwek]

beetje off-topic:

Als je met meerdere bedrijven gebruik gaat maken van de Cisco Call Manager loop je het risico dat je bepaalde functionaliteiten niet krijgt. Het is dan om beveiligingsredenen niet mogelijk om via een browser je persoonlijke telefoonlijst te beheren, bedrijfseigen ringtones, menuopties en logo's kun je niet gebruiken omdat de Cisco Call Manager geen mogelijkheid heeft om onderscheid te maken tussen verschillende bedrijvenpools.

Ben je echter alleenheersen op de Cisco Call Manager dan heb je die problemen niet.

[bartgabriels]

Nog een opmerking:

De Cisco 3750 kan niet alle 48 poorten tegelijk van stroom voorzien als je de 7961 aansluit.

code:

WS-C3750-48PS 
Beschikbaar:    370.00  
Benodigd (bij 48 7961G telefoons) 619.20

Bij de 3750-E ligt het eraan welke voeding je gaat gebruiken.

FYI: http://tools.cisco.com/cpc/

[TheBrain]

Wij hebben nu een dergelijke oplossing met alleen 3750's (3750G in de core en 3750PoE voor de Voip toestellen) en gaan voor de netwerkcore overstappen naar een 45xx (06 of 10, zijn we nog niet uit).

Voornaamste zaken betreffen de dedicated supervisor engine en de dubbele Power Unit.

We gaan voor failover in de core dan gebruik maken van 2x3750's (3750G-48TS) waar we de meest kritische servers met een of twee poorten ook in hangen (VMware hosts en mailservers).

De 3750's en de 45xx zetten we in een HRSP groep zodat we en redundantie hebben en geen poorten hebben die niks staan te doen.

Voor powerredundantie (zeker als je een datacenter in het kantoor zelf krijgt) kan je de 3750's ook aan een externe powerunit hangen maar dat heeft wel wat nadelen als er een powerfailover plaatsvindt.

[ijdod]

Begrijp ik goed dat je een aantal gestackte 3750s gaan vervangen door een 4500, met als redundantie nog steeds (een stapel) 3750s?

Waarom zou je dat doen? Welke winst verwacht je van de losse supervisor? Dubbele voeding kan met een RPS ook voor een 3750. Qua poorten/features/prijs doet het elkaar niet zoveel, maar bij de 4500 krijg je wel een backplane bottleneck van 6Gbps per blade. Ik zeg niet dat het een slechte move is, maar ik ben wel erg benieuwd naar de argumenten.

[ Voor 11% gewijzigd door ijdod op 24-02-2007 10:06 ]

[Azhrarn]

ijdod schreef op woensdag 21 februari 2007 @ 15:26:
Ik zie eigenlijk maar een probleem: Qua redundantie ben je afhankelijk van het functioneren van de stacklinks, en het achterliggende mechaniek. Welke waarde je daar aan hecht, in vergelijk met de enkel chassis/redundante sup die je nu hebt is een lastige. Ik zou denk ik voor de 6500 gaan. De 6500 is een beter platform; maar dat komt met een prijs. Ik denk eerder dat een dergelijke 3750 oplossing een forse hap neemt uit situaties waar nu een 4500 zou staan. Dat gezegd, is het een leuke oplossing .

Glas voor de verbindingen naar de SERs is een sterke aanrader in verband met galvanische scheiding. Er kunnen in een pand behoorlijke potentiaal verschillen ontstaan, die er voor zouden kunnen zorgen dat er ergens rook uit gaat komen.

STP vs etherchannel: STP is inderdaad complex, maar juist uiterst voorspelbaar. Daar zit hem juist de kracht. Voor Etherchannel vraag ik me af in hoeverre in de marges gaat komen van het gebruik van een techniek op een manier die daar eigenlijk niet voor bedoelt is.

De stacklinks zijn eigenlijk ook redundant hé. Als er één uitvalt heb je nog steeds 32Gbps van de 64Gbps beschikbaar. Er moeten er al twee uitvallen om problemen te hebben. Dit heb je echter even goed met een 6500. Twee dode supervisors in een 6500 is ook miserie troef hoor. Nog erger zelfs, want dan werkt er niets meer. Eén dode 3750 switch is ook niet echt een groot probleem door de Etherchanneling. Twee dode 3750's en er is nog steeds connectivity want er is een nieuwe master. Of er nog veel gebeurt dat is iets anders, maar ja dat telt evengoed met een 6500. Heb je trouwens de MTBF van de 3750E bekeken? 18 jaar voor de gehele switch en 57 jaar voor een powersupply. Van een 6500 supervisor, voeding, blades of chassis heb ik spijtig genoeg geen cijfers kunnen vinden.
De redundantie van de voedingen zoals in een 6500 wordt verzorgd door de RPS 2300. Die kan dode voedingen zo opvangen.
Groot voordeel is de bekabeling eigenlijk. Momenteel hebben wij dus een 6500, en verdomme dat is miserie hoor om die kabels mooi te laten lopen omdat het zo een grote switch is. Nog erger is het wanneer je die kabels dan moet verpluggen naar onze backupoplossing (1*3550+2*2970+2*2950). Helemaal alleen dit doen s'morgens vroeg is wreed moeilijk hoor zonder de kabels niet te beschadigen en dit voor een 100-tal kabels binnen het aangegeven half-uur.

Glas zou inderdaad een goed idee zijn. Maar voorlopig gaan we hier nog niet voor omdat we momenteel nog geen echte reden hiervoor hebben. De galvanische scheiding is niet zo belangrijk, omdat elk verdiep zijn eigen kleine netwerkschacht (verzamelbuis eigenlijk) heeft naar de computerzaal. Fiber zal er wel komen, maar nu nog niet. Alhoewel je wel een goed punt hebt hoor.

Cross-Stack Etherchanneling is hier helemaal wel voor bedoelt hoor. Het staat aangegeven als één van DE grote features van dit model switch. STP is dan misschien wel voorspelbaar, maar je verliest ook je bandbreedte hé. Er zal namelijk waarschijnlijk geen onderscheid gemaakt worden tussen pc's, printers, thinclients, ... via VLAN's (later misschien via 802.1x). Op die manier zou je de bandbreedte gedeeltelijk kunnen recupereren. Maar dat maakt de setup dan nog ingewikkelder. Etherchannels zijn echter heel simpel en zeer voorspelbaar.
Soit, ik heb altijd al gevonden dat Cisco hun design guides, veel te veel concentreren op het standaard Campus model: Core, Distribution, Access. Bijna elk bedrijf, met uitzondering van de echte grote, hebben voldoende aan een Collapsed Backbone model. Daar vind je echter bij Cisco nooit veel uitleg rond.

[Azhrarn]

bartgabriels schreef op donderdag 22 februari 2007 @ 14:15:
Nog een opmerking:

De Cisco 3750 kan niet alle 48 poorten tegelijk van stroom voorzien als je de 7961 aansluit.

code:

WS-C3750-48PS 
Beschikbaar:    370.00  
Benodigd (bij 48 7961G telefoons) 619.20

Bij de 3750-E ligt het eraan welke voeding je gaat gebruiken.

FYI: http://tools.cisco.com/cpc/

Wij zouden gaan voor Cisco 3560(10/100) Poe model waarschijnlijk in combinatie met 7961G. De 1gigabit telefoon kost ongeveer 100 € meer. Je kan dat niet krijgen in basismodel, 7911G. Om dan nog niet de meerprijs van een 48*1000 switch te melden.
Wist je trouwens dat de 7961G voldoet aan de Class 2 PoE norm en dat de 3560 (PS-model) gecertifieerd is voor 48*Class 2 PoE.

[Bl@ckbird]

ijdod schreef op woensdag 21 februari 2007 @ 15:26:
[...]

Glas voor de verbindingen naar de SERs is een sterke aanrader in verband met galvanische scheiding. Er kunnen in een pand behoorlijke potentiaal verschillen ontstaan, die er voor zouden kunnen zorgen dat er ergens rook uit gaat komen.

En:

Azhrarn schreef op dinsdag 20 februari 2007 @ 12:17:
Tja, waarom zou ik fiber nu leggen. Koper is goedkoper en met Gigabit heb ik meer als genoeg. Mijn afstanden zijn ook in orde, en de kabels worden allemaal geverifieerd dus... Misschien dat we later fiber leggen tussen de verdiepingen voor 10G of 100G of zo?? Maar da's verre toekomstmuziek.
Wat me nog wel steeds dwarsligt is die opmerking van die consultant. Is er een goede reden om deze setup niet te gebruiken of was het alleen maar een snobistische opmerking?

Dit is wel iets om rekening mee te houden.

De 3560-E en de 3750-E zijn voorzien van twee TwinGig converter modules. Deze kun je standaard vullen met 2x2 = totaal 4 SFP's voor gigabit uplinks over koper of glasvezel. Wil je in de toekomst de de backbone upgraden, dan voorzie je de 3560-E van twee X2 10Gb Ethernet modules.
Als je als core switches 2x een 6504-E of een 6506-E hebt staan, kun je hier een 10Gb Ethernet blade bij in plaatsen. Het serverpark kun je op de switching fabric enabled lijnkaarten van de 6500 aansluiten.

Daarnaast heeft de 6500 wat betere high-availability features, zoals NSF en modulair IOS.
Modulair IOS komt van de CRS-1 router en wordt voorlopig alleen voor de CRS-1 / CAT6500 ontwikkeld.

Je kunt je afvragen:
- Hoe schaalbaar moet het zijn? (Welke groei in dataverkeer verwacht ik?)
- Hoeveel uptime wil ik halen?
- Welke investering wil ik daarvoor doen?

Het 3750 Core / 3560 Access ontwerp is verder prima... Niks mis mee.
Zeker als bovenstaande info en service modules je niet boeien.

[ijdod]

[b][message=27562467,noline]Azhrarn schreef op zondag 25 februari 2007 @ De stacklinks zijn eigenlijk ook redundant hé. Als er één uitvalt heb je nog steeds 32Gbps van de 64Gbps beschikbaar. Er moeten er al twee uitvallen om problemen te hebben. Dit heb je echter even goed met een 6500. Twee dode supervisors in een 6500 is ook miserie troef hoor.

Het punt is dat een 6500 toch net iets anders in elkaar steekt als een 3750. De kans dat eea uitvalt is kleiner, de failover mechanismen zijn verdergaand getest, enz enz. Of dit voor het gewenste scenario de (forse) meerprijs waard is, is vers twee.

Duidelijk is wel dat een hogere pet op hebt van de stacklink dan ik. Ik heb die namelijk een aantal keren niet helemaal 'as designed' zien werken, waarbij gezegd moet worden dat dit vrij vroeg in de 3750 serie was. Dit soort ervaringen maken je huiverig op bepaalde techniek op een bepaalde plek in te zetten, maar da's persoonlijk.

De redundantie van de voedingen zoals in een 6500 wordt verzorgd door de RPS 2300. Die kan dode voedingen zo opvangen.

In je OP is de keuze voor RPS nog open. De 2e voeding van een 6500 is ontworpen als volwaardige failover, dus ook tegen het uitvallen van een spanningsgroep. Hiervan kan afgewerken worden, maar dat moet expliciet geconfigureerd worden. De RPSen zijn ontworpen om het uitvallen van een voeding op te vangen. Je kan ze ook gebruiken als 2e voeding op een aparte groep, maar dan moet je er rekening mee houden dat het aantal 'gedekte' devices slechts beperkt is. In dat geval is het functioneel identiek. Uit ervaring kan ik stellen dat 'dode voeding' aanmerkelijk minder vaak voorkomt als 'dode groep'.

Groot voordeel is de bekabeling eigenlijk. Momenteel hebben wij dus een 6500, en verdomme dat is miserie hoor om die kabels mooi te laten lopen omdat het zo een grote switch is. Nog erger is het wanneer je die kabels dan moet verpluggen naar onze backupoplossing (1*3550+2*2970+2*2950). Helemaal alleen dit doen s'morgens vroeg is wreed moeilijk hoor zonder de kabels niet te beschadigen en dit voor een 100-tal kabels binnen het aangegeven half-uur.

Da's persoonlijk. Ik heb nooit echt problemen gehad met de poort density van 6500s, en dat is inclusief 6513s met 12 x 48 poorts rj45 blades, anders dan het gebruikelijke probleem van dikke vingers en weinig ruimte, en dat is niet exclusief voor 6500s.

Cross-Stack Etherchanneling is hier helemaal wel voor bedoelt hoor. Het staat aangegeven als één van DE grote features van dit model switch. STP is dan misschien wel voorspelbaar, maar je verliest ook je bandbreedte hé.

Hangt van je ontwerp af, met 1 vlan inderdaad wel. Cross stack channels *moest* cisco op die switch wel aanbieden, anders gaat een belangrijk deel van het voordeel van het stacken verloren. Het ging mij ook niet op het cross stacken van die channels an sich, dat is ook op een chassis goed gebruik. Waar het me op ging is het gebruik van die techniek, in combinatie met de 3750/stacklink, als core. Dat komt zeker ook door onbekendheid met die techniek, doordat die keuze voor mijn huidige opdrachtgevers nooit een issue zal zijn. Ik geloof zonder meer dat eea gaat werken zolang je binnen de door cisco aangegeven marges blijft.

kunnen recupereren. Maar dat maakt de setup dan nog ingewikkelder. Etherchannels zijn echter heel simpel en zeer voorspelbaar.

Gedeeltelijk mee eens. Eenvoudig, ja. (Aan de andere kant, spanning tree staat al aan, en tenzij je autonegotiate op je channels wilt gaan gebruiken, zul je die expliciet moeten configureren). Voorspelbaar kan je over discussieren. De basis is eenvoudiger dan STP, maar troubleshooten van STP vele malen eenvoudiger, omdat je daar exact weet wat er zou moeten gebeuren. Etherchannel doet een aantal zaken anders afhankelijk van het type switch/IOS, en niet alle switches/IOSen ondersteunen een aantal erg handige commando's.

[TheBrain]

ijdod schreef op zaterdag 24 februari 2007 @ 10:04:
Begrijp ik goed dat je een aantal gestackte 3750s gaan vervangen door een 4500, met als redundantie nog steeds (een stapel) 3750s?

Waarom zou je dat doen? Welke winst verwacht je van de losse supervisor? Dubbele voeding kan met een RPS ook voor een 3750. Qua poorten/features/prijs doet het elkaar niet zoveel, maar bij de 4500 krijg je wel een backplane bottleneck van 6Gbps per blade. Ik zeg niet dat het een slechte move is, maar ik ben wel erg benieuwd naar de argumenten.

Het probleem met die RPS is dat als je een power failover hebt en de power komt terug je 3750's niet automatisch weer overschakelen op rackpower. Je moet ze power cyclen en omdat die switches bij ons in een datacenter staan (40km verderop) moet je er dus naartoe om erbij te zijn voor het geval de switch niet meer op komt.

Natuurlijk is dat ook het geval als een PSU kapot gaat in een 45xx maar bij een 3750 heb je meer situaties waarbij je er naartoe moet (en meer werk). Als b.v. de PSU in die 3750 stuk gaat moet je zowieso de hele unit vervangen en je bekabeling opnieuw doen.

Een ander nadeel dat wij ervaren met de 3750's is dat we de verbindingen naar onze kantoren laten uitkomen in de fiberpoorten van de 3750's. Als er dus een 3750 failt dan ligt meteen de verbinding naar een of twee kantoren uit (we krijgen die verbindingen aangeleverd op een enkele fiber, KPN eVPN).

Die 6Gb connectie naar de backplane wist ik niet we moeten gaan testen of we dat wegswitchen met de huidige 3750's. Zou nog leuk kunnen worden

(sorry voor het lange verhaal, niet bedoeld als topic hyjack).

[Azhrarn]

ijdod schreef op maandag 26 februari 2007 @ 22:29:
[...]


Het punt is dat een 6500 toch net iets anders in elkaar steekt als een 3750. De kans dat eea uitvalt is kleiner, de failover mechanismen zijn verdergaand getest, enz enz. Of dit voor het gewenste scenario de (forse) meerprijs waard is, is vers twee.

Duidelijk is wel dat een hogere pet op hebt van de stacklink dan ik. Ik heb die namelijk een aantal keren niet helemaal 'as designed' zien werken, waarbij gezegd moet worden dat dit vrij vroeg in de 3750 serie was. Dit soort ervaringen maken je huiverig op bepaalde techniek op een bepaalde plek in te zetten, maar da's persoonlijk.

Dus als ik het goed begrijp is de grootste reden om dit nog niet te gebruiken de StackWise kabels zelf. Je bent nog niet overtuigd van de goede werking hiervan.

Ik zou misschien toch naar dubbele 6500 moeten gaan, maar dit is vermoed ik wel een stuk duurder dan 4*3750E.

Het spanning-tree verhaal ten opzichte van etherchannel is misschien meer iets van mij persoonlijk. Ik heb een lichte aversie t.o.v Spanning-Tree, via etherchannels heb ik geen loops nodig en dus ook een simpele STP. Tevens heb ik met die 3750E een grote backbone tussen de switches. Of zou ik nu gewoon voor 1*6500 blijven gaan zoals nu en en een backup-netwerk zoals nu. (3550+2970+2950)

Mijn bedoeling is maximum uptime. Ik dacht dat mijn uptime voor kritische servers en verdiepingen hoger zou liggen omdat er één switch altijd gemist kan worden. Onafhankelijk van de beschading. Dit is inderdaad niet waar, indien die StackWise kabels niet perfect werken.

Soit, wat geeft nu volgens jullie de beste uptime voor mijn etherchannels? De cluster van 3750E of de 6500... Ik begin te vermoeden dat jullie de 6500 een betere oplossing vinden dan de 3750's

[Turtle]

Azhrarn, je bent voor zover ik kan beoordelen heel goed bezig met je ontwerp. Je weet waar je het over hebt en verteld heel concreet waarom je zaken op een bepaalde manier doet. Dat is meer dan van menig verkoper valt te verwachten. Laat je dan ook niet van de wijs brengen. Wanneer die 6500's geen functies toevoegen waar je gebruik van gaat maken, maar wel flink extra kosten dan blijft de keuze makkelijk. Ga voor de 3750E.

De 3750E heeft soms nog een snellere backplane dan de 6500 met sup720, want die 720Gbit zijn:
20Gbit per kanaal * 2 kanalen per module * 9 modules * 2 full-duplex = 720Gbit.
Een 48 poort Gbit is 2 * 24Gbit poorten op een 20Gbit kanaal. Dan moet je er wel een losse Distributed forwarding card (DFC) bijkopen per module voor Distributed Cisco Express Forwarding (DCEF), om die 20Gbit uberhaubt te kunnen halen.
Op de 3750(E) is DFC, of DCEF geen optie, maar standaard.

Ik heb zelf recentelijk een soortgelijke afweging gemaakt en kon ook niet op de 3750E heen i.p.v. de 6509E. Ik had wel een feature die ik miste, namelijk netflow wat handig was geweest voor monitoring. Dit kon echter de extra prijs niet rechtvaardigen voor de 6500.

Enige verschil met jou ontwerp: Ik kies juist bewust voor twee fysiek en logisch gescheiden eenheden voor de coreswitches. Op die manier is de kans ook veel kleiner dat een tik-fout op 1 console alles plat gooit. Ook ben je dan met failover niet afhankelijk van propriatary protocollen, maar openbare en goed voorspelbare. Daarnaast kun je IOS upgraden en zelfs je cores 1 voor 1 vervangen zonder downtime. Wanneer 24 * 7 beschikbaarheid wenselijk is dan zou ik niet voor 1 stack van 4 gaan maar voor 2 van 2 en 2 * 10Gbit (CX4-copper) er tussen. En inderdaad weer rapid spanning-tree gebruiken. Iets minder bandbreedte, maar consistente en voorspelbare failovers.

Succes er mee, als je dit oude topic nog leest realiseer ik me net. In ieder geval goed bezig.
*edit*: Zet voor de gein het stroomgebruik van een 6509 met sup720-B eens naast dat van 2 3750's.