HP vs Cisco switches

[TrailBlazer]

Op dit moment zit ik puur in de Cisco netwerkhoek, dagelijks werk ik met Cisco switches van 2960 to 6500.
HP heeft echter ook een heel breed switching portfolio en voor een lagere prijs dan Cisco. Nu ben ik aan het inventariseren wat nu wel en niet mogelijk is met HP switches ten opzichte van Cisco.
Als ik de Cisco 6500 vergelijk met de HP 8200ZL dan heeft de HP een lagere maximum port density. Echter wel tot 30 % goedkoper (list price). Supervisor redundancy biedt HP wel maar bij een switchover heb je wel duidelijk meer outtage dan bij de Cisco. Aan de andere kant hoe vaak sterft je supervisor af?

In bestaande Cisco switched netwerken wordt vaak PVST gebruikt wat uiteraard niet ondersteunt wordt door de HP switches. Dit hoeft geen probleem te zijn maar loadbalancing met STP is dan enkel mogelijk door MSTP te gaan gebruiken. MSTP ben ik nog nooit tegengekomen in het wild. Dit is waarschijnlijk omdat wijzigingen in een MSTP omgeving nogal lastig zijn.

Beide devices hebben wel een CLI structuur, uiteraard verschillen ze van elkaar maar dat lijkt me geen onoverkomelijk probleem.
Op dit moment lijkt het me vooral aantrekkelijk om een core/distributie te maken aan de hand van Cisco en alle access devices op basis van HP.

Wat zijn jullie ervaringen met:

• HP switches in het algemeen?
• HP switches in combinatie met Cisco switches?
• Features die missen op een HP die je wel op een Cisco hebt (of andersom!)

[Bl@ckbird]

Kan alleen voor Cisco spreken...

Komende vrijdag is er een sessie bij Cisco over dit topic.
( Catalyst versus de rest. ) 's Ochtends is het een sales-achtige sessie,
's middags wordt het wat technischer.

Daarnaast heeft Cisco wat behulpzame info hier over.
Vooral deze PDF is handig. ( Inloggen met je CCO / Cisco.com login en je moet Cisco Partner zijn. )

Wat ook interessant is, is de prijs per switchport.
In het verleden heb ik hier zelf een opzetje voor gemaakt in Excel.
Het omslagpunt fixed switches / modulaire switches is dan handig te bepalen.

Neem ook zaken mee als technical support (Cisco TAC vs. HP Support) en of je hierover tevreden bent.

[TrailBlazer]

Eerste link mag ik niet openenen (misschien omdat we geen reseller zijn). 2e is wel interessant. Komt een beetje overeen met wat ik zelf even snel had opgezocht. Ik zal nog even wat beter kijken naar de kosten van het geheel.

[Stampertje]

TrailBlazer schreef op maandag 09 november 2009 @ 14:45:
Aan de andere kant hoe vaak sterft je supervisor af?

In mijn vorige werkkring (bij een van de grootste NL Cisco Resellers) werden in de meeste gevallen toch voor een redundante oplossing gekozen. OK een supervisor zal niet zo snel de geest geven, maar je moet er niet aan denken dat het wel gebeurt, en je gehele netwerk "plat" gaat. Dan kan je beter die "paar" K euro extra investeren.

@ TS:

Waarom richt je je alleen op een vergelijking met HP, en laat je bv. 3Com buiten beschouwing?

[TrailBlazer]

Ik wil ook wel investeren in die redundantie alleen bij een Cisco 6500 gaat het vrijwel naadloos over NSF en SSO bijvoorbeeld dit heeft de HP duidelijk niet. Daar ben je wel een paar minuten weg als ik het zo lees.

De keuze voor HP is van hogeraf ingegeven.

[Kabouterplop01]

Het lijkt inderdaad precies wat je zegt brand1 vs brand2.
Zeker als je naar de interoperabillity kijkt, deze is yuk... Ik doel dan op het samenwerken tussen cisco en hp apparatuur.
zelfs op gigabit nivo waar autosensing en autonegotiate rouleren zeg maar, krijg je het redelijk regelmatig niet voor elkaar om zelfs maar de link up te krijgen. Meer heb ik er eigenlijk niet mee gewerkt als zijnde 2 domeinen aan elkaar knopen. (Waar ik aan de cisco kant zit) werk net als Trailblazer, met flinke cisco's. (tot 7600 (L3 switched))

dit zijn voor mij de features die men van beide kanten mist: (zowel cisco als HP) 1 operating system, algemene netwerk stack die naadloos aansluit op elkaar.

[TrailBlazer]

Wel vreemd we hebben hier een hoop HP VC-Enet modules en die werken direct samen met verschillende Cisco switches.

[Attilla]

Iedere hardware heeft zijn dingen. Cisco, Foundry, HP, F10, Juniper .. ik denk dat je altijd wel iemand kan vinden die ergens een probleem mee heeft gehad. Zeker met betrekking tot interoperabiliteit al vind ik dat dit steeds meer aan het verdwijnen is. Zelfs Cisco ziet in dat het zich langzaam toch maar aan standaarden moet gaan houden.

Maar wat ik gedaan heb met HP vind ik gewoon goed werken. Maar dat was alleen puur switching en het meeste was nog relabled Foundry spul. Helaas kan ik je weinig vertellen over stp of een Cisco variant daarvan, want, zeker in mijn gebied is dat sowieso een hopeloze techniek.

Ik denk dat je bij jou vooral zou kunnen winnen op access layer. Dat zijn veelal toch "domme" switches die toch al helemaal uit gedeveloped zijn. Maar zover ik weet zit hier juist een groot prijsverschil op als je kijkt naar hoeveelheid. Want op gebied van failover zie je dat HP dus het spul niet heeft, maar dat heeft dan waarschijnlijk te maken met de markt waar zij zich op richten. Dus dan zou ik daar niet verder naar kijken (op core gebied dus).

Maar als je toch naar andere vendors kijkt, wat is er mis met Foundry (MLX), Force10, Extreme? Lijken me toch ook leuke alternatieve vendors.

[Vicarious]

Mijn ervaring met HP switches beperkt zich vooral tot de procurve desktop varianten (2610 e.d.), en dat doen ze prima. De functionaliteiten die Cisco biedt en die ik ook gebruik, worden ook geboden door de HP varianten. Bovendien heeft HP een aantal erg handige management tools waarmee je het beheer zeer eenvoudig kan maken voor bijvoorbeeld een servicedesk. Zo kun je bijvoorbeeld met die tool grafisch weergeven hoe verkeersstromen lopen en door welke switches een pakketje heen gaat bij een ping.

Voor wat betreft de flinkere modellen heb ik er eigenlijk nog geen ervaring mee. Wat me wel erg aanspreekt is dat je er modules van andere fabrikanten in kan schuiven. Zo kun je bijvoorbeeld een Sonicwall "blade" erin schuiven voor firewallfunctionaliteiten etc. Dat is wel een feature die Cisco voor zover ik weet niet heeft.

edit: ik zag dat Extreme ook genoemd was. Waren die niet (bijna) failliet?

[ Voor 4% gewijzigd door Vicarious op 10-11-2009 12:38 ]

[Bl@ckbird]

De 6500 kan je voorzien van Services Modules, zoals firewall blades met virtuele firewalls, IPS blades en ACE loadbalancing blades. ( Maar dit is Cisco only.)

In de ISR routers (de oude en nieuwe) kan je wel 3rd party modules plaatsen via het AXP programma. ( Eventueel met je eigen software. ) Maar dit zijn routers en geen switches.

[Kabouterplop01]

Wel vreemd we hebben hier een hoop HP VC-Enet modules en die werken direct samen met verschillende Cisco switches.

Ik heb nog nooit iets aan zo'n module geknoopt, dus ik heb er totaal geen ervaring mee.

Meestal kleinere to ong 4u max hoogte apparatuur.
Waarschijnlijk was dat nog wat oudere meuk. Tegenwoordig meer met 6500/7600's en routers aan de slag

[ Voor 15% gewijzigd door Kabouterplop01 op 10-11-2009 13:49 ]

[JackBol]

Ik heb een tijdje geleden ook wat switches vergleken,

Voornamelijk:
Cisco 6500 vs. Juniper EX8200 vs. HP 8200 vs. Nortel 8600
Cisco 2960/2560 vs. Juniper EX3200/EX4200 vs. HP 2810 vs. Nortel 4500


Tot mijn verrassing was HP vrij volwassen. Als je een kantoor LAN wilt bouwen voor een enkelvoudige enterprise kan je met HP perfect uit de voeten. Alle core en access functionaliteit is aanwezig;

o.a. Management, redundancy, port-density, garantie (levenslang op hw!) L2 security, VoIP support (LLDP/LLDP-MED/LAN QoS) en prijs waren zeer prettig!

Maar de beoogde oplossing was voor een multi-tenant omgeving waar vrij hoge eisen aan beschikbaarheid werden gesteld, en we hebben uiteindelijk toch niet voor HP gekozen. De redenen waren dat HP nog zeker onder doet voor scalability en availability tov. Cisco Juniper en Nortel. Zo ondersteunen ze geen VRF-lite, geen switch-clustering (tbv. spanningtree-loze topologieen) en stateful failover.

[CyBeR]

_DH schreef op dinsdag 10 november 2009 @ 19:36:
Ik heb een tijdje geleden ook wat switches vergleken,

Voornamelijk:
Cisco 6500 vs. Juniper EX8200 vs. HP 8200 vs. Nortel 8600
Cisco 2960/2560 vs. Juniper EX3200/EX4200 vs. HP 2810 vs. Nortel 4500

Heb je ook wat kunnen spelen met die Junipers? Ik vind wat ze er zelf over zeggen heel interessant klinken, maar ik kan nog niemand vinden die er zelfs maar een aan heeft geraakt.

[FatalError]

Ik heb pas een Juniper-in-one-day cursusje gehad, daarbij hebben we met EX4200's mogen spelen. In 1 woord: Fantastisch! En dan met name qua features. Zo kan je bijvoorbeeld een Layer3 ACL's op een layer 2 poort toepassen. Ik ken geen ander apparaat waar dat bij kan.
En natuurlijk heb je de geniale CLI die de grotere Juniper routers ook hebben

Momenteel doe ik beheer over ongeveer 5000 Cisco switches (voornamelijk ME3400 en Cat6500) en ongeveer 30 Juniper routers. Ik kan je over de Cisco's zeggen dat het echt mega stabiel spul is. De meeste switches hebben uptimes van 3+ jaar. Er zijn echt zelden problemen mee. Laatst een Cisco router met een uptime van 10+ jaar. Screenshot naar Cisco leverde een mooie taart op
Alle andere merken die we nog gebruiken worden op termijn allemaal uitgefaseerd en vervangen door Cisco en Juniper.
Over de kosten-baten kan ik geen zinnige mening geven, want daar ga ik niet over;)

[ Voor 45% gewijzigd door FatalError op 10-11-2009 20:10 ]

[axis]

Ik heb zelf (bijna) alleen ervaring met de Procurve series.. Heb een stuk of 20 procurves, varieren van 2626's tot 2848's.. Wat ik een erg groot voordeel vind, is dat je de hp firmware upgrades voor altijd en eeuwig gratis kunt downloaden, bij Cisco moet je geloof ik een cco-contract hebben.

Ik heb wel laatst 2 Cisco Catalyst 3750G switches gekocht als iSCSI 'core' switch, omdat je die kunt stacken met een native stacking cable, en dus ook een lacp trunk/team kunt maken over 2 switches, in tegenstelling tot bij de niet-stackbare procurves. Maar goed, daarom zijn de hp's ook een stuk goedkoper.

[JackBol]

CyBeR schreef op dinsdag 10 november 2009 @ 19:46:
[...]


Heb je ook wat kunnen spelen met die Junipers? Ik vind wat ze er zelf over zeggen heel interessant klinken, maar ik kan nog niemand vinden die er zelfs maar een aan heeft geraakt.

Ja, we hebben uiteindelijk voor de junipers gekozen.

Het concept is briljant.
Ze hebben die EX switching chipset ontwikkeld. Deze gebruiken ze ook voor de MX L2 linecards.
Aan deze chipset zit een losse routing engine die standaard JunOS draait.

Ze zijn erg feature rich en ze hebben een goede backplane architectuur. Een switch stack tot 10 members heeft 128Gb en de EX8216 zelfs tot 3.2Tb geloof ik. Alles non-blocking en zeer betaalbaar!!

Ik heb gespeeld met JunOS 9.1 t/m 9.4 op deze apparaten. Daar zaten nog veel bugs in en miste nog heel wat features (graceful (=SSO) failover werkte niet goed) services (syslog, dhcp etc) in een VRF (zelfs dhcp-forwarding in een VRF was moeilijk). Maar schijnbaar is het vanaf 9.6 nogal een stuk beter!

Verder staat JunOS 10.0 op de stapel en die heeft een hoop nieuwe features en bugfixes.

[CyBeR]

FatalError schreef op dinsdag 10 november 2009 @ 20:01:
Ik heb pas een Juniper-in-one-day cursusje gehad, daarbij hebben we met EX4200's mogen spelen. In 1 woord: Fantastisch! En dan met name qua features. Zo kan je bijvoorbeeld een Layer3 ACL's op een layer 2 poort toepassen. Ik ken geen ander apparaat waar dat bij kan.

Toevallig kan ik dat op mijn Alteon 180 (oud beestje, maar doet 't perfect) ook. Maar ik moet wel bekennen dat me dat enigszins verbaasde toen ik daar 'tegenaanliep'.

[FatalError]

Ik heb laatst wat met de nieuwe Juniper SRX210 mogen spelen. Heel erg leuk apparaat, maar deze was meegeleverd met JunOS 9.5. Daar waren inderdaad nog wat problemen mee. Later 9.6 erop, dat werkte n heel stuk beter.

[killah]

Ik zelf werk dagelijks met HP Procurve ben ook gezegend met wat papiertjes. Zelf ben ik dus totaal niet thuis met Cisco en hun speciaaltjes.

Procurve is begonnen als wij gaan switches doen maar dan IP only. Ze zijn rustige begonnen met wat switches (2600) en wat chassis (5300). Onder tussen zijn ze gegroeid naar meer enterprise spullen ik hou het meer op campus werk. Dus geen BGP hardware (ooit 9300 switches gehad maar dat waren overgeplakte foundry's).
Hp ging lekker door met ontwikkelen en hebben nu 8200 switches met redundante onderdelen.

Procurve ONE. Oftwel mini servers als blade die je zo de switch in kunt drukken. (zie rest van die spullen op de HP site.

Laatst is er ook distributed LACP bijgekomen. Voordeel LACP trunks over meerdere switches. Nadeel geen routing engine actief.

Als je het zo allemaal bekijk is procurve groeiende. Nemen af en toe leuke spullen over. Colubris wireless. Werkt best wel goed en de klanten zijn tevreden.

De enigste misstap die ze begaan hebben is om een WAN product te maken de 7200 met een "industry standard cli" oftwel Cisco command. Wie dat ooit bedacht heeft.

Maar goed ooit werd procurve gezien als een "3com" en nu zijn ze de competitie voor Cisco.

Ze zijn al ver en het wordt steeds beter.

Het grootste probleem op het moment is de (r)STP tussen Cisco en Procurve. Lijkt wel af en toe of ze in twee werelden hun RFC lezen. De ene firmware combo gaat goed. Week later even patch fixen en het is weer over. Het rare is dat procurve bijna geen problemen heeft met de andere merken.

Persoonlijk is mijn idee dat je zelf het beste voor 1 merk kan gaan. Of alles Cisco (pak je portemonee maar) of HP Procurve (let op je wan).

Allees heeft zijn voor en nadelen. Kijk eerst wat je nodig hebt en natuurlijk budget. En ga dan rondkijken.

[ Voor 27% gewijzigd door killah op 10-11-2009 20:43 ]

[BCC]

Beide zijn prima, maar ik zou ze niet mixen als je de keus hebt.

Interoperabiliteit is soms een probleem, maar zeker zaken als vervanging, reparatie en garantie zijn een stuk eenvoudiger als je maar 1 merk hebt.

[PolarBear]

FatalError schreef op dinsdag 10 november 2009 @ 20:01:
Ik kan je over de Cisco's zeggen dat het echt mega stabiel spul is. De meeste switches hebben uptimes van 3+ jaar. Er zijn echt zelden problemen mee. Laatst een Cisco router met een uptime van 10+ jaar. Screenshot naar Cisco leverde een mooie taart op

Eens, maar wat ik wel gemerkt heb is dat als het dan een keer misgaat bij Cisco het ook meestal fors misgaat.

[TrailBlazer]

Hoop reacties Tot nu toe klopt alles wel een beetje met mijn eigen onderzoek. Mixen is kans op rare problemen maar op zichzelf werkt het allemaal prima.
Een Cisco kan trouwens ook prima een L3 access-list op een L2 poort hebben hoor. Leuk weetje een L2 access-list zal al het ip verkeer ongemoeid doorlaten.

Van die taart even onthouden we hebben ook nog wel wat oude sup2 supervisors staan denk ik zo.

[ Voor 5% gewijzigd door TrailBlazer op 10-11-2009 21:39 ]

[CyBeR]

TrailBlazer schreef op dinsdag 10 november 2009 @ 21:38:
Hoop reacties Tot nu toe klopt alles wel een beetje met mijn eigen onderzoek. Mixen is kans op rare problemen maar op zichzelf werkt het allemaal prima.
Een Cisco kan trouwens ook prima een L3 access-list op een L2 poort hebben hoor. Leuk weetje een L2 access-list zal al het ip verkeer ongemoeid doorlaten.

Volgens mij doet Cisco niet aan L4 access lists op L2-switched poorten, wel? Ik kan dergelijke ACL's instellen en ongeacht of verkeer routed of switched door een poort heen gaat, het houdt zich eraan.

[TrailBlazer]

uit de 3560 config guide

Use the ip access-group interface configuration command to control access to a Layer 2 or Layer 3 interface. Use the no form of this command to remove all access groups or the specified access group from the interface.

bron

dus het zou gewoon moeten werken.

[FatalError]

Hm.. dan heb ik weer wat geleerd
Het zat keihard in mn hoofd gebeiteld dat het niet kon.
Morgen eens mn 4506 aanslingeren om het te proberen ;-)

[ Voor 23% gewijzigd door FatalError op 10-11-2009 22:39 ]

[CyBeR]

TrailBlazer schreef op dinsdag 10 november 2009 @ 22:19:
uit de 3560 config guide

[...]

bron

dus het zou gewoon moeten werken.

Afgezien van het volgende dan, bij L2 interfaces:

•You can only apply ACLs in the inbound direction; the out keyword is not supported for Layer 2 interfaces.

•You can only apply one IP ACL and one MAC ACL per interface.

wat het nut toch zeer limiteert.

[TrailBlazer]

Ik heb altijd geleerd dat je ACL's altijd zo dicht mogelijk bij je source moet zetten. Sterker nog ACL's op een switch/router moet je eigenlijk nooit gebruiken om verkeer te filteren op een interface vind ik. Dan koop je maar een firewall.

[JackBol]

TrailBlazer schreef op woensdag 11 november 2009 @ 06:26:
Ik heb altijd geleerd dat je ACL's altijd zo dicht mogelijk bij je source moet zetten. Sterker nog ACL's op een switch/router moet je eigenlijk nooit gebruiken om verkeer te filteren op een interface vind ik. Dan koop je maar een firewall.

Hey! Niet plots in de discussie je filosofie veranderen!

Maar ik ben het wel met je eens. Als je L3/L4 acls op een L2 interface zet schendt je het OSI model. Dat moet je nooit willen. Dat het kan is een mooie feature en kan je op $moment wel eens uit de shit helpen, maar als je dit in de dagelijkse operatie nodig hebt, getuigt je netwerk wel van Bad Design^TM.

[TrailBlazer]

Dat is altijd mijn filosofie geweest hoor. ACL op router/switch interfaces maakt je netwerk nogal ondoorzichting is mijn ervaring.

[Kabouterplop01]

Ik denk dat dat ligt aan je gelaagdheid en de grootte van je netwerk;
een rode zone, een oranje zone en een groene.
stel je voor tig webservers, een zwik ldap (unix) een hele zooi mailservers (cluster van 100+ machines), domain controllers, dns bakken (tot aan split dns met caching en auth ns uiteraard in andere subnets).
Om dat op zoveel mogelijk lagen te controleren lijkt het me juist erg handig om die in een subnetje (vlan) per service te hangen.
dan filteren op de vlan (l3) interface wat er in mag en wat er uit mag.
De rode zone a/h internet.
de oranje zone is de 2e nic (meeste machines hebben 3 nics tegenwoordig) "intern" verkeer.
groen zone backend met totaal geen routeringen naar internet.
Anyway you get the picture. Sommige bakken mogen per definite nooit direct met internet in aanraking komen, andere in principe wel, maar zijn er totaal niet voor gemaakt/ingericht. Of de machines die juist aan internet hangen, moeten alleen maar geschikt zijn voor de service die ze draaien.

Dus erg interessant hoe jullie dit zien; welke orde van grootte is het netwerk waar we over spreken? Hoe is het opgebouwd? En welke functionaliteit biedt het? (core, access, distributie, etc) (Campus, ISP,LAN)

@ DH Volgens mij zijn alle Junipers waarbij een routing engine komt kijken zo opgebouwd.(Daarom zijn ze zo bloedje snel)

anyway helemaal eens op L2 moet je geen L3/L4 acl zetten, (Overigens is port -sec, etc ... op je distr switch veel efficienter) daar zijn die machines niet voor gemaakt imho. Eigenlijk zoals hierboven al impliciet geschreven

[ Voor 7% gewijzigd door Kabouterplop01 op 11-11-2009 19:19 ]

[JackBol]

Kabouterplop01 schreef op woensdag 11 november 2009 @ 18:29:
@ DH Volgens mij zijn alle Junipers waarbij een routing engine komt kijken zo opgebouwd.(Daarom zijn ze zo bloedje snel)

Klopt, op de J series na hebben alle junipers gescheiden control en dataplanes. Wat ik eigenlijk wilde aangeven is dat er een practisch volwaardige router in zit, met een hoopfunctionaliteit die je van Juniper gewend bent. Natuurlijk zijn er ASICs wel toegespitst op switching dus minder diepe buffers etc.

[TrailBlazer]

Ik heb ook niks tegen het filteren van verkeer tussen subnets. Ik heb enkel wat tegen het filteren van verkeer dmv ACL's Koop gewoon een device wat er voor gemaakt is en dat is een firewall.
Op dit moment werk ik met een netwerk waar we al gauw over 10000 ethernet poorten praten dus best een behoorlijk aantal.

[FatalError]

Haha, ik roep een keer iets waarvan ik dacht dat Juniper de enige was die het ondersteunde.. komt er gelijk een discussie over het nut van deze functionaliteit. Beetje offtopic;-)

[Stampertje]

Stampertje schreef op maandag 09 november 2009 @ 20:33:
[...]

@ TS:

Waarom richt je je alleen op een vergelijking met HP, en laat je bv. 3Com buiten beschouwing?

Wellicht hadden je opdrachtgevers wel ingelichte bronnen? HP neemt 3Com over voor 2.7Miljard. Bron

[BCC]

HP gaat 3Com overnemen. Dat belooft een beste clash of the titans te worden tussne HP en Cisco
http://www.boston.com/bus...to_be_sold_to_hp_for_27b/

[CyBeR]

BCC schreef op donderdag 12 november 2009 @ 07:49:
HP gaat 3Com overnemen. Dat belooft een beste clash of the titans te worden tussne HP en Cisco
http://www.boston.com/bus...to_be_sold_to_hp_for_27b/

With 3Com, HP gets a ready-made line of core network products to sell.

... die niemand wil kopen omdat er '3com' onder het 'hp' labeltje staat.

[Uberprutser]

Ik ben ooit van 3Com naar HP gevlucht vanwege de vreselijke prestaties van de 3Com switches in een Gbit netwerk dus ik ben erg benieuwd of het een "3Com, made by HP" verhaal wordt of dat ze gewoon alleen nog onder HP spullen gaan verkopen.

Verder werk ik met zowel HP als Cisco als Juniper en heb ik bij HP nog steeds het gevoel dat ik dat niet wil inzetten in een "groot" netwerk en liever voor de laatste 2 kies. Soms mis je nog wel is een optie maar zie je die in een latere firmware opeens wel terugkomen. Denk dat ik ook nog gewoon niet zo thuis ben in het HP (netwerk) assortiment. Desondanks vind ik het mooi spul en zeker als je een strak budget hebt het een prima optie is.

[winux]

Hier ook overgegaan van 3Com/Cisco naar HP. Draait nu dikke 2 jaar, en werkt perfect.

4 x 3500 coreswitches
12 x 2626 pwr, voor de ip-telefonie
5 x 2626, voor randapparatuur.

Werkt buiten gewoon en werkt geweldig. De cli van Cisco of HP verschilt overigens niet zo heel veel.

Dus met Cisco kennis, kom je wel een eind hoor.

[dreester]

Afgelopen zomer zijn wij hier over gegaan van HP naar Cisco. Voorheen hadden wij veel al 26xx en 28xx hier staan. Werkte allemaal prima, ook nog een 3500yl gehad hier met wat Cisco 3500 spul ertussen. Ik vond de menu's in de HP's wel prettig als het ging om accesspoortjes aan VLAN's toewijzen. Tot nu toe ook nog erg tevreden met het Cisco spul. Helaas geen ervaring met STP configs in de HP omgeving.

[CyBeR]

Digitizers schreef op donderdag 12 november 2009 @ 13:33:
Afgelopen zomer zijn wij hier over gegaan van HP naar Cisco. Voorheen hadden wij veel al 26xx en 28xx hier staan. Werkte allemaal prima, ook nog een 3500yl gehad hier met wat Cisco 3500 spul ertussen. Ik vond de menu's in de HP's wel prettig als het ging om accesspoortjes aan VLAN's toewijzen. Tot nu toe ook nog erg tevreden met het Cisco spul. Helaas geen ervaring met STP configs in de HP omgeving.

Waarom die overstap?

[Barreljan]

TrailBlazer schreef op woensdag 11 november 2009 @ 07:41:
Dat is altijd mijn filosofie geweest hoor. ACL op router/switch interfaces maakt je netwerk nogal ondoorzichting is mijn ervaring.

Vergeet de performance niet op de routers van cisco, de grotere chassis gaan er wel goed mee om, maar de wat kleinere gooien de cpu-load vrij snel omhoog

[DavidK]

FatalError schreef op dinsdag 10 november 2009 @ 20:01:
... Zo kan je bijvoorbeeld een Layer3 ACL's op een layer 2 poort toepassen. Ik ken geen ander apparaat waar dat bij kan....

Misschien een beetje off-topic, maar de N-series van Enterasys bieden deze functionaliteit al ruim vijf jaar. Middels policies, welke dynamisch toegewezen kunnen worden (via 802.1X of mac authenticatie), kun je layer 2/3/4 based rulesets op een layer 2 poort activeren. Werkt geweldig.

Ik weet dat de discussie over HP vs Cisco gaat, ik heb zelf niet veel ervaring met beide werken (ik lees dat ik hier een van de weinige ben ), maar ik weet wel dat over het algemeen de hier boven vermelde merken (Cisco, HP, Juniper, Foundry etc etc) goed van aard zijn. Natuurlijk kan ieder merk zijn nukken hebben, maar zo blijft er natuurlijk geen enkel merk over om uit te kiezen.

Het blijft altijd zoeken naar de gulden middenweg; wat wil je qua functionaliteit, wat wil je betalen en ook een belangrijke: wat wil je in de toekomst gaan doen (extra functies activeren op het netwerk).

Veel succes in ieder geval

[ Voor 0% gewijzigd door DavidK op 13-11-2009 14:21 . Reden: Typo (zal wel meer instaan...) ]

[Predator]

Kleine annekdote over Enterasys...

1 van onze onderafdelingen ging zijn telefooncentrale (analoog) vervangen door een nieuwe (siemens hipath - VoIP). Ik had zelfs voorgesteld dat ik naast de WAN configs (centraal beheerd) ook best voor de nieuwe switches met PoE wou zorgen en de config daarvan.

Dat vonden ze niet nodig, siemens had een (goed)koop alternatief en ging zelf voor switches en config zorgen.
Nou ja, geen probleem.
Dat bleken Enterasys switches te zijn.

Uiteindelijk is daar een technieker 2 dagen fulltime aan bezig geweest ! (aan 2 48p PoE switches)
Ik heb er zelf eens op aangelogd en meer dan 2 vlans (data/voice) stond er niets eens op.
Zelfs geen QoS.

Bellen ze mij daarna op met de vraag of dat normaal is dat die configuratie zou lang duurt.
Nou ja niet echt, ik doe dat op 10 minuten remote from scratch

Uiteindelijk bleek het dus een stuk duurder te zijn met de install uren bij

Altijd het totaalplaatje bekijken

[ Voor 3% gewijzigd door Predator op 14-11-2009 10:53 ]

[dreester]

CyBeR schreef op vrijdag 13 november 2009 @ 01:52:
[...]


Waarom die overstap?

Samenwerking met een grote ROC.

[DavidK]

Predator schreef op zaterdag 14 november 2009 @ 10:52:
Kleine annekdote over Enterasys...

....

Altijd het totaalplaatje bekijken

Op één of andere manier wil ik hier toch op reageren

Vraag me om het één en ander op te zetten op basis van HP / Cisco, dan zal het langer voor me duren dan wanneer ik hetzelfde moet opzetten op basis van bijvoorbeeld Enterasys. CLI is misschien (iets) anders, maar het principe is hetzelfde; de technieken en mogelijkheden zijn op basis van standaarden...

Ik heb dus andere ervaring met Enterasys dat Predator (no offense), zoals ik net als zei, ik heb meer 'moeite' met andere merken. Bij mij komt het 'totaalplaatje' er iets anders uit te zien ...

Maar misschien is dit wel een goede discussie (het totaalplaatje). Ik ben in het verleden te vaak aangelopen tegen het feit dat men producten aanschaften op basis van naam, prijs, aanbieding what so ever.. terwijl er nooit gevraagd wordt aan de mensen die het moeten beheren/op moet zetten...
Dus krijgen ze hardware matig een hele vette deal, maar dat men vervolgen tig dagen bezig is om het op te bouwen, wordt even totaal buiten beschouwing gelaten (zoals Predator ook al aangaf...).

Terugkomend op de orginele discussie: ...verschil tussen HP en Cisco...je hebt meer kennis van Cisco?
Kostentechnisch kan dat gewoon zeer belangrijk zijn op momenten van (grote) storingen, projecten etc. etc. ...
Maar als je de kans krijgt vanuit je werk om je meer te verdiepen in een ander merk (technisch gezien), dan zou ik dat zeker aangrijpen...

[ Voor 35% gewijzigd door DavidK op 15-11-2009 13:22 . Reden: Even terugkomen op de orginele discussie :) ]

[TrailBlazer]

Afgelopen week een sessie bij Cisco gehad over de concurenten van Cisco. Hoewel er een duidelijk Cisco sausje overheen zat ook wel een hoop aardige dingen gezien. Kostentechnisch valt HP heel erg tegen eigenlijk.

[CyBeR]

TrailBlazer schreef op zondag 15 november 2009 @ 19:54:
Afgelopen week een sessie bij Cisco gehad over de concurenten van Cisco. Hoewel er een duidelijk Cisco sausje overheen zat ook wel een hoop aardige dingen gezien. Kostentechnisch valt HP heel erg tegen eigenlijk.

Vertel, welke spin hebben ze aan hun belachelijke prijsstrategie ('omdat ze het toch wel betalen') gegeven?

Als ik Cisco was zou ik ook niet vertellen dat HP goedkoper en beter is tenslotte..

[ Voor 9% gewijzigd door CyBeR op 15-11-2009 19:58 ]

[Vicarious]

CyBeR schreef op zondag 15 november 2009 @ 19:57:
[...]


Vertel, welke spin hebben ze aan hun belachelijke prijsstrategie ('omdat ze het toch wel betalen') gegeven?

Als ik Cisco was zou ik ook niet vertellen dat HP goedkoper en beter is tenslotte..

HP is ook niet beter, wel goedkoper. En ja, dat kan zomaar 50% schelen.

Cisco 2960 -> 1029 euro bij Misco: http://www.misco.nl/produ...sco%20Catalyst%202960.htm

HP 2610 -> 459 euro bij Misco: http://www.misco.nl/produ...ve%20Switch%202610-24.htm

Goed, de specs verschillen wel iets, maar volgens mij zijn dit redelijk vergelijkbare modellen.

[TrailBlazer]

CyBeR schreef op zondag 15 november 2009 @ 19:57:
[...]


Vertel, welke spin hebben ze aan hun belachelijke prijsstrategie ('omdat ze het toch wel betalen') gegeven?

Als ik Cisco was zou ik ook niet vertellen dat HP goedkoper en beter is tenslotte..

Dat HP bijvoorbeeld exact dezelfde chips gebruikt die er ook op een Linksys switch zitten en dat daar wat bekende problemen mee zijn wat betreft buffer allocatie.

[CyBeR]

TrailBlazer schreef op maandag 16 november 2009 @ 08:09:
[...]

Dat HP bijvoorbeeld exact dezelfde chips gebruikt die er ook op een Linksys switch zitten en dat daar wat bekende problemen mee zijn wat betreft buffer allocatie.

Aha. Dus Cisco geeft hier toe dat Linksys prut is? Alles om de concurrentie de grond in te boren blijkbaar.

Maargoed, dat heeft nogal niets te maken met dat HP uiteindelijk duurder zou zijn dan Cisco (alleen dat 't niet beter is), dus we zijn er nog niet... Welke overduidelijk-in-het-voordeel-van-Cisco-rekensom hebben ze gegeven?

[TrailBlazer]

Nee Cisco geeft aan dat HP beter vergeleken kan worden met Linksys dan met Cisco switches. Ik heb de data even niet liggen hier ze kwamen ook financieel lang niet altijd in het voordeel uit van Cisco alleen wel een duidelijk beeld geschept van de Pros en Cons.

[badnews.nl]

Tja.. mijn ervaringen zijn inderdaad memory leaks enzo in HP switches.
2 jaar mee gedraaid (2x 24ports giga's) en moesten telkens gaan herstarten zodra we packetloss zagen.
Daarnaast truncte de HP's niet...

voor Cisco gegaan en sindsdien werkt alles weer zonder herstart en loss gezeik.

[Pinooo]

Misschien ook nog een puntje van aandacht,

HP geeft lifetime warranty op zijn hardware vanaf fabriek... Op dit gebied zal Cisco het natuurlijk nooit gaan winnen:)

Succes met de zoektocht en ben best benieuwd wat je resultaat wordt!

[Predator]

(wat ik schreef klopte niet echt)

[ Voor 94% gewijzigd door Predator op 16-11-2009 11:18 ]

[TrailBlazer]

Pinooo schreef op maandag 16 november 2009 @ 09:58:
Misschien ook nog een puntje van aandacht,

HP geeft lifetime warranty op zijn hardware vanaf fabriek... Op dit gebied zal Cisco het natuurlijk nooit gaan winnen:)

Succes met de zoektocht en ben best benieuwd wat je resultaat wordt!

Ja zolang dat ding inderdaad niet end of life is en de ervaring leert dat dat die hele levenscyclus van HP max 7 jaar is. Zeker voor modulaire switches is dat kort.

[Vicarious]

badnews.nl schreef op maandag 16 november 2009 @ 09:52:
Daarnaast truncte de HP's niet...

Onzin, dan heb je een configuratiefout gemaakt.

[DrFlash]

Graag wil ik nog even inhaken op het 3com/hp verhaal hier, 3com heeft sinds een jaar of 4 geleden enorme stappen gemaakt in het high-end segment het enige probleem wat 3com nu heeft is de naam. maar tegenwoordig hoef je qua kwaliteit de 3com producten niet meer rechts te laten liggen. ik zou er eens goed naar kijken want de combinatie HP/3com kan best een positieve verrassing opleveren

[Bl@ckbird]

CyBeR schreef op maandag 16 november 2009 @ 09:06:
[...]
Aha. Dus Cisco geeft hier toe dat Linksys prut is? Alles om de concurrentie de grond in te boren blijkbaar.

Maargoed, dat heeft nogal niets te maken met dat HP uiteindelijk duurder zou zijn dan Cisco (alleen dat 't niet beter is), dus we zijn er nog niet... Welke overduidelijk-in-het-voordeel-van-Cisco-rekensom hebben ze gegeven?

ASICs op de switches van HP en Cisco SMB (ex-Linksys) zijn gelijk en hebben daarmee dezelfde buffer problemen. Cisco positioneert de SMB lijn voor het SMB / MKB. (Dus voor kleine netwerken.) Buffer problemen spelen hier minder, omdat het netwerkverkeer vaak minder intensief is. Deze switches hebben ook minder features, maar de prijs is daarom wel lager. HP positioneert hun switches als Enterprise-graded, maar dat zijn ze dus niet.

Cisco SMB switches zijn goedkoper dan HP. Verder bestaan er voor de 4500 en 6500 instap bundels (chassis + supervisor en één of twee lijnkaarten) die erg gunstig geprijst zijn.

Pinooo schreef op maandag 16 november 2009 @ 09:58:
Misschien ook nog een puntje van aandacht,

HP geeft lifetime warranty op zijn hardware vanaf fabriek... Op dit gebied zal Cisco het natuurlijk nooit gaan winnen:)

Succes met de zoektocht en ben best benieuwd wat je resultaat wordt!

Cisco geeft ook Limited lifetime hardware warranty op hun switches. ( Catalyst 2960 t/m de 4500. )
Op Cisco SMB switches zit 5 jaar garantie. Sla de datasheets er maar op na.

Limited lifetime betekent bij zowel Cisco als bij HP, dat dit exclusief de fans en power supplies is. En laat deze twee componenten meestal defect raken. 90-95% Van de cases die bij Cisco TAC gemeld worden hebben te maken met configuratie problemen, software bugs of een vage netwerk topologie. Hardware is meestal niet het probleem meer. Daarbij is het TAC van Cisco veel uitgebreider dan de support afdeling van ProCurve. Als (een deel van) het netwerk down is zit je op een oplossing te wachten. Hardware replacement kan een oplossing zijn, maar bij een groot deel van de gevallen is dat het niet.

TrailBlazer schreef op maandag 16 november 2009 @ 11:34:
[...]

Ja zolang dat ding inderdaad niet end of life is en de ervaring leert dat dat die hele levenscyclus van HP max 7 jaar is. Zeker voor modulaire switches is dat kort.

Supervisors en lijnkaarten van modulaire switches kan je bij Cisco meenemen naar een nieuwer chassis. Bij HP moet je dan een complete nieuwe switch kopen.

DrFlash schreef op maandag 16 november 2009 @ 15:48:
Graag wil ik nog even inhaken op het 3com/hp verhaal hier, 3com heeft sinds een jaar of 4 geleden enorme stappen gemaakt in het high-end segment het enige probleem wat 3com nu heeft is de naam. maar tegenwoordig hoef je qua kwaliteit de 3com producten niet meer rechts te laten liggen. ik zou er eens goed naar kijken want de combinatie HP/3com kan best een positieve verrassing opleveren

De overname van 3Com door HP betekent dat er redelijke overlap zit in het product portfolio.
De vraag is welke producten het zullen overleven. Ik betwijfel of HP z'n eigen producten zal opofferen..

[Stampertje]

DrFlash schreef op maandag 16 november 2009 @ 15:48:
Graag wil ik nog even inhaken op het 3com/hp verhaal hier, 3com heeft sinds een jaar of 4 geleden enorme stappen gemaakt in het high-end segment het enige probleem wat 3com nu heeft is de naam. maar tegenwoordig hoef je qua kwaliteit de 3com producten niet meer rechts te laten liggen. ik zou er eens goed naar kijken want de combinatie HP/3com kan best een positieve verrassing opleveren

Die slechte naam komt deels doordat ze een jaar of 10 geleden "ineens" stopte met de enterprise lijnen. De CoreBuilder 9000 was voor veel NL bedrijven een topproduct, waar van de ene op de andere dag de ontwikkkeling stop gezet werd. Een bedrijf zal zich dat geen tweede keer laten overkomen en zullen dus eerder voor een ander merk kiezen (wij hebben toen heel wat CB3500 en CB9000 vervangen door Cisco apparatuur).

[Bas]

Wat ik voornamelijk als een van de grote problemen bij HP switches vind (kleinere modellen dan wel te verstaan als 2800 / 2900 series en lager): Maximaal 8 vlans te definieren op 1 switchs.

Nu hebben wij geen multinational netwerk, maar 8 vlans is wel heel snel bereikt...

(ps: ben niet geheel onbevooroordeeld, wij zijn Cisco partner)

[CyBeR]

Bas schreef op maandag 16 november 2009 @ 20:54:
Wat ik voornamelijk als een van de grote problemen bij HP switches vind (kleinere modellen dan wel te verstaan als 2800 / 2900 series en lager): Maximaal 8 vlans te definieren op 1 switchs.

Nu hebben wij geen multinational netwerk, maar 8 vlans is wel heel snel bereikt...

(ps: ben niet geheel onbevooroordeeld, wij zijn Cisco partner)

Ahem:

ProCurve Switch 4204vl(config)# max-vlans
<1-256> Enter an integer number for the 'max-vlans'
command/parameter.

Max is 256 voor deze switch*. De default is inderdaad 8, nog altijd geen idee waarom. Ik vermoed iets met geheugen ofzo.

*) Geldt ook voor 6100, 2800, 2600, etc.

[ Voor 3% gewijzigd door CyBeR op 16-11-2009 20:59 ]

[Uberprutser]

CyBeR schreef op maandag 16 november 2009 @ 20:58:
Max is 256 voor deze switch*. De default is inderdaad 8, nog altijd geen idee waarom. Ik vermoed iets met geheugen ofzo.

Dat antwoord kreeg ik van een grote leverancier dus ik denk dat het dan wel klopt

[Extera]

In de nieuwe software release van HP ( K.15 beta uit mijn hoofd). Ondersteund de 8200 ook L2 hitless failover.
Het is natuurlijk nog beta software, maar het komt er aan. Ze zijn ook L3 hitless failover aan het testen.

Het chassis is overigens niet 100% redundant. De clocking module is dat niet. De MTBF is wel erg hoog van deze module. En hij is als spare mee te bestellen voor een paar 100 euro.

Ik ben niet erg thuis in cisco, daar ga ik volgend jaar mee beginnen. Maar volgens mij is het helemaal niet zo duur, om in grotere LAN omgevingen 5400 chassis in de access laag in te zetten. Als je een x aantal 24port modules besteld, krijg je het chassis er gratis bij.

Alle modules zijn uit mijn hoofd ook standaard 10/100/1000 met POE.

Op die manier kan je ook veel intelligentie aan de edge brengen, en de cores ontlasten.

[ Voor 5% gewijzigd door Extera op 18-11-2009 10:47 ]

[Bl@ckbird]

Extera schreef op woensdag 18 november 2009 @ 10:36:
[...]

Ik ben niet erg thuis in cisco, daar ga ik volgend jaar mee beginnen. Maar volgens mij is het helemaal niet zo duur, om in grotere LAN omgevingen 5400 chassis in de access laag in te zetten.

Beetje afhankelijk van het type switch ( 3750v2 / 3750G / 3750E en de 4500 / 6500 ):
Maar bij meer dan 96 tot 288 switch poorten is het goedkoper om naar een 4500 of 6500 te kijken.
( In plaats van naar een stack van 3750v2 / 3750G / 3750E switches. )

En dan heb ik de voordelen van een redundant voeding (en evt. een extra RPS2300 voor de 3750 switches)
niet meegewogen.

[Vicarious]

Bl@ckbird schreef op donderdag 19 november 2009 @ 11:12:
[...]


Beetje afhankelijk van het type switch ( 3750v2 / 3750G / 3750E en de 4500 / 6500 ):
Maar bij meer dan 96 tot 288 switch poorten is het goedkoper om naar een 4500 of 6500 te kijken.
( In plaats van naar een stack van 3750v2 / 3750G / 3750E switches. )

En dan heb ik de voordelen van een redundant voeding (en evt. een extra RPS2300 voor de 3750 switches)
niet meegewogen.

Je kan natuurlijk ook 1 of 2 (gestackte) 3750's nemen voor de layer 3 functionaliteiten en daarbij wat 2960's bestellen indien het om een simpel netwerkje puur voor desktops gaat. Zou dat niet goedkoper zijn dan een 6500? Die kaarten daarin zijn namelijk erg duur (7000 euro voor 48 10/100/1000 poorten meen ik?)

[JackBol]

Vicarious schreef op donderdag 19 november 2009 @ 11:37:
[...]

Je kan natuurlijk ook 1 of 2 (gestackte) 3750's nemen voor de layer 3 functionaliteiten en daarbij wat 2960's bestellen indien het om een simpel netwerkje puur voor desktops gaat. Zou dat niet goedkoper zijn dan een 6500? Die kaarten daarin zijn namelijk erg duur (7000 euro voor 48 10/100/1000 poorten meen ik?)

Er zijn altijd een hele hoop mogelijkheden.
Als je werkplekken wat verspreid staan (zeg, maar dan 150 meter uit elkaar), zijn meerdere 2960s misschien handiger. Wanneer je managed beheer op afstand hebt is een enkelvoudige 6500 mischien handiger.

De kosten voor een oplossing gaan veel verder dan alleen de aanschaf. Daar komt die marketing term TCO iedere keer weer om de hoek kijken, maar je beheers- en bedrijfsprocesses kosten veel meer geld dan een 6500.

Voorbeeldje:
Een gemiddelde IT beheerder kost 100.000 euro per jaar voor een werkgever.
Als die met oplossing A 2 dag in de week bezig is met netwerkbeheer en met oplossing B 1 dag in de week, scheelt dat 20.000 euro per jaar.

[Vicarious]

Mjah maar ik zie nou niet direct een verschil in beheerkosten tussen beide oplossingen. Hoogstens een verschil in bekabelingskosten omdat je met de optie van losse switches waarschijnlijk minder (lange) kabels hoeft te trekken als je de switches in verschillende SER's kan verspreiden, maar verder...

[Bl@ckbird]

Vicarious schreef op donderdag 19 november 2009 @ 11:37:
[...]
Je kan natuurlijk ook 1 of 2 (gestackte) 3750's nemen voor de layer 3 functionaliteiten en daarbij wat 2960's bestellen indien het om een simpel netwerkje puur voor desktops gaat. Zou dat niet goedkoper zijn dan een 6500? Die kaarten daarin zijn namelijk erg duur (7000 euro voor 48 10/100/1000 poorten meen ik?)

Voor een klein netwerkje is dat zeker aan te bevelen.
( Met mijn opmerking doelde ik eigenlijk op gestackte switches. )

Wil je alles een beetje redundant aansluiten, dan heb je per 2960 twee uplinks nodig.
Als dit verder dan 100m is, dan moet je glasvezel (laten) trekken.
Natuurlijk kan je ook per SER twee distributie switches plaatsen, zodat je minder uplinks nodig hebt.



Zo is bij 96 poorten een 4500 al goedkoper dan een stack van 3750G switches.
Bovenstaande prijzen gaan uit van wereldwijde advies / list prijzen in Dollars, dus hier gaan nog het één en ander aan kortingen van af. Maar het geeft een aardige vergelijking. Bovenstaande grafieken zijn natuurlijk ook voor HP te maken.

[ Voor 3% gewijzigd door Bl@ckbird op 19-11-2009 23:04 ]

[Verwijderd]

Mooie topic met interessante meningen!
Ik werk zelf tegenwoordig niet erg veel meer met Cisco maar ben altijd wel bevooroordeeld.
Tegenwoordig zie ik veel 3Com 5500 langskomen maar als ik het goed begrijp zijn HP toch niet te stacken?
Dat lijkt me toch wel een groot nadeel zeker omdat je met alle ESX servers tegenwoordig makkelijk wil trunken over meerdere switches?

Ziet niemand dat als nadeel bij HP?

[Vicarious]

Verwijderd schreef op vrijdag 20 november 2009 @ 00:27:
Mooie topic met interessante meningen!
Ik werk zelf tegenwoordig niet erg veel meer met Cisco maar ben altijd wel bevooroordeeld.
Tegenwoordig zie ik veel 3Com 5500 langskomen maar als ik het goed begrijp zijn HP toch niet te stacken?
Dat lijkt me toch wel een groot nadeel zeker omdat je met alle ESX servers tegenwoordig makkelijk wil trunken over meerdere switches?

Ziet niemand dat als nadeel bij HP?

ESX servers e.d. heb je meestal op je datacenter staan, en daar kun je over het algemeen het beste een chassismodel voor nemen, aangezien die een stuk hogere performance halen. En dan kun je dus prima 'trunken' (in dit geval betekent trunken dus port aggregation neem ik aan? In Ciscoland ether of portchannel?)

[WhizzCat]

Verwijderd schreef op vrijdag 20 november 2009 @ 00:27:
Mooie topic met interessante meningen!
Ik werk zelf tegenwoordig niet erg veel meer met Cisco maar ben altijd wel bevooroordeeld.
Tegenwoordig zie ik veel 3Com 5500 langskomen maar als ik het goed begrijp zijn HP toch niet te stacken?
Dat lijkt me toch wel een groot nadeel zeker omdat je met alle ESX servers tegenwoordig makkelijk wil trunken over meerdere switches?

Ziet niemand dat als nadeel bij HP?

HP is ook stackable. Tegenwoordig levert HP ook met CX4. Dit is min of meer een HP eigen (prop-dinges, te moeilijk om te spellen om 7:10 ) stack-achtige oplossingen. Die van Cisco zijn ook nooit helemaal compatible met de rest.

Wij hebben in ons datacenter de 48 poorts access switches van HP hangen, deze lopen getrunked met CX4 (10 Gbit overigens) naar 5406 Distri switches (alles redundant uiteraard) die alleen dienen als switch koppelvlak. Deze 5406'en zijn gekoppeld op 4 (geografisch gespreide) 5412 die ook onze datalijnen afhandelen (routing functionaliteit dus). Alle servers gekoppeld middels HP Teaming en dat werkt echt super! Ook al onze ESX bakken zijn per stuk met 6 nics aangesloten (vmotion, heartbeat, data, verspreid over alle poorten/switches). Performance is echt geweldig tot nu toe.

Ik moet zeggen dat dit alles mij tot nu toe prima bevalt. We zijn nog niet echt gekke dingen tegen gekomen (draait nu een jaartje ofzo). Alleen op een van onze lokale vestigingen gaf 1 access switch problemen met trunking via ethernet, maar we vermoeden dat dat domweg een hardware failure is omdat er maar 1tje is die het doet.

Wij zitten met zo'n 60 nevenvestigingen varierend van 10 mensen tot 400 op lokatie. Op de grotere vestigingen werken wij met een access <-> disitributie <-> core achtige oplossing (26xx, 29xx, 5406). Dit is natuurlijk wat afhankelijk ook van wat er precies in een ser/mer hangt en hoeveel werkplekken er op zitten. Als er 1 access switch in een ser hangt komen er natuurlijk geen 2 distri's, maar gaan er gewoon 2 uplinks richting een mer.

[Bl@ckbird]

WhizzCat schreef op woensdag 25 november 2009 @ 07:16:
[...]

HP is ook stackable. Tegenwoordig levert HP ook met CX4. Dit is min of meer een HP eigen (prop-dinges, te moeilijk om te spellen om 7:10 ) stack-achtige oplossingen. Die van Cisco zijn ook nooit helemaal compatible met de rest.

CX4 zijn 10Gbps links over koper bekabeling.
De 3750 en 3750-E switches kan je stacken op de backplane van de switches.
( Met speciale stackwise kabels. )

Dat betekent dat tussen de switches een verbinding loopt van 32 of 64 Gbps. Daarmee zijn deze switches een aardig alternatief voor chassis-based switches. ( Mits het aantal dus niet te hoog is, want dan is een 4500 chassis goedkoper. ) De 3750-E heeft overigens ook 10 Gbps poorten, maar deze worden als uplinks gebruikt.

De 3750 / 3750-E switches worden door Cisco als campus switches gepositioneerd. ( Wat niet betekent, dat je ze niet in een data center kan gebruiken. )

Data center switches zijn bij Cisco de 4900 en Nexus modellen.
De latency van deze modellen is erg laag, wat handig is als je grote brokken data wil verzenden.
Ook zijn ze standaard voorzien van redunant voeding.

Met een stack van 3750 switches of met twee modulaire chassis based switches werk je End-of-Row.
( Waarbij alle bekabeling van een aantal patchkasten in één patchkast met switches uit komt. )

Met de Nexus 5000 / 2000 kan je ook Top-of-Rack werken.
De Nexus 2k is een fabric extender en doet zich als "lijnkaart" voor aan een Nexus 5k. ( Zoals dat in een modulaire switch gebeurt. ) Via 10 Gbps is de Nexus 2k gekoppelt aan de Nexus 5k. De Nexus 2k heeft alleen 1 Gbps poorten. De Nexus 5k doet van alles: 10 Gbps Ethernet, 4Gbps Fibre Channel en 10Gbps FCoE.

Daarnaast ondersteund de Nexus serie VNLink.
Dit protocol is door VMWare en Cisco ontwikkelt en is aan de IEEE aangeboden om hier een standaard van te maken. Wanneer je nu een dot1q trunk naar een ESX host hebt lopen, dan is het lastig te checken welke VM's aan welke VLAN gekoppeld zijn.

VNLink voegt deze info toe aan de trunk. Je hebt hiervoor netwerk interfaces nodig die "network interface virtualization" ( NIV ) ondersteunen. Hiermee kan je tot 128 virtual interfaces toekennen aan specifieke VM's.

Voor de UCS-C servers staat network interface virtualization op de roadmap en voor de UCS-B servers is dit al beschikbaar. Wanneer de IEEE er naar gekeken heeft, denk ik dat Qlogic en Emulex VNLink snel zullen introduceren in hun Converged Network Adapters voor 3rd party server fabrikanten. ( Aangezien Cisco nauw met deze partijen samenwerkt. )

Een andere mogelijkheid is de Nexus 1000v. Dit is een distributed switch die in VMWare vShere draait.
In beide gevallen kan een netwerkbeheerder een port profile aanmaken ( met bijvoorbeeld ACL's ) en deze bijvoorbeeld "webserver" noemen. De systeembeheerder kan dit profiel toewijzen aan één of meer van zijn VM's.
- Bij de Nexus 1000v switch je echter in software op de ESX hosts.
- Bij VNLink / Nexus 5k/2k / NIC met "network interface virtualization" switch je in hardware op de Nexus 5k/2k.

Doe je een VMotion van ESX host 1 naar ESX host 2, dan blijven counters e.d. gewoon doorlopen.

Dit zijn features die op de standaard campus switches (2960 / 3560 / 3750) niet zullen verschijnen.