I'm looking for a little insight regarding an infrastructure purchase my company is considering. We are a carrier, and we're in the process of building a DR site. Our existing production site is all Cisco equipment with a little Juniper thrown into the mix. I'd like to either get the same Cisco equipment for the DR, or the equivalent Juniper equipment. We have skill sets for both Cisco and Juniper, so neither would be a problem to manage. A business issue has come up since we have a large number of HP servers for Unix and Wintel. With HP's recent acquisition of 3Com they are pressing hard to quote on the networking hardware as well, going as far as offering prices that are way below the equivalent Cisco and Juniper models. In addition they're saying they'll cut us deals on the HP servers for the DR site to help with the decision to go for HP Networking. Obviously to the people writing the cheques this carries a lot of weight.
From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate.
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?
This situation scares me. It has HP "best interest" written all over it. You have expertise in competing vendors but not with HP/3Com. They could very well be easy to configure but maybe inferior when you get into the details of how they function. Then if you find out they can't support your business needs, it would cost even more to replace them. I don't think that's going to happen, I'm sure the people writing the checks will tell you to make it work, but if it can't meet the demands, it's going to hurt your business... The people writing the checks need to know this. I'm not against new companies competing with Cisco/Juniper but at the same time, you don't want to be the guinea pigs for them....
Date: Thu, 17 Jun 2010 09:52:13 -0400 Subject: Advice regarding Cisco/Juniper/HP From: james@jamesstewartsmith.com To: nanog@nanog.org
I'm looking for a little insight regarding an infrastructure purchase my company is considering. We are a carrier, and we're in the process of building a DR site. Our existing production site is all Cisco equipment with a little Juniper thrown into the mix. I'd like to either get the same Cisco equipment for the DR, or the equivalent Juniper equipment. We have skill sets for both Cisco and Juniper, so neither would be a problem to manage.
A business issue has come up since we have a large number of HP servers for Unix and Wintel. With HP's recent acquisition of 3Com they are pressing hard to quote on the networking hardware as well, going as far as offering prices that are way below the equivalent Cisco and Juniper models. In addition they're saying they'll cut us deals on the HP servers for the DR site to help with the decision to go for HP Networking. Obviously to the people writing the cheques this carries a lot of weight.
From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate.
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?
On 06/17/2010 09:52 AM, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? Not for core networking. How is HP's functionality and performance compared to Cisco or Juniper? HP's Procurve switches have been around forever, they're about the same quality as a 2xxx 3xxx Cisco, but nothing better Does anyone have any HP networking experiences they can share, good or bad?
never had any issues with them.
A couple consulting gigs I did had 3Com stuff since it was cheap and they got educational deals. They were consulting me to put in Cisco gear ;-) This was admittedly 3-4 years ago. I've never met anyone who has told me positive stories about 3Com equipment, but I suppose I'm biased also from the horror stories. My $0.02, -Jack On Thu, Jun 17, 2010 at 10:18 AM, Andrew D Kirch <trelane@trelane.net>wrote:
On 06/17/2010 09:52 AM, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Not for core networking.
How is HP's functionality and performance compared to Cisco or Juniper?
HP's Procurve switches have been around forever, they're about the same quality as a 2xxx 3xxx Cisco, but nothing better
Does anyone have any HP networking experiences they can share, good or
bad?
never had any issues with them.
I can tell many stories about 3com switches, email me off list, the language used will not be suitable for the list. On 18/06/2010 2:27 a.m., Jack Carrozzo wrote:
A couple consulting gigs I did had 3Com stuff since it was cheap and they got educational deals. They were consulting me to put in Cisco gear ;-) This was admittedly 3-4 years ago.
I've never met anyone who has told me positive stories about 3Com equipment, but I suppose I'm biased also from the horror stories.
My $0.02,
-Jack
On Thu, Jun 17, 2010 at 10:18 AM, Andrew D Kirch<trelane@trelane.net>wrote:
On 06/17/2010 09:52 AM, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Not for core networking.
How is HP's functionality and performance compared to Cisco or Juniper?
HP's Procurve switches have been around forever, they're about the same quality as a 2xxx 3xxx Cisco, but nothing better
Does anyone have any HP networking experiences they can share, good or
bad?
never had any issues with them.
From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate.
I work with networking products from all of the mentioned vendors on a daily basis. HP Networking (was ProCurve) make a solid SME switching product, it is comparable to Cisco 2000/3000 series switches, they also have chassis switches such as the 54xx/82xx, however these lack a lot of the more advanced features available from Cisco and Juniper, and have significant hardware limitations e.g. backplane bandwidth. HP also do not have decent stackable switches, which will be a concern if you want to split LACP trunks across multiple switches/chassis. Another major negative with the HP gear for us is that their switches only support SFP/SFP+ modules manufactured by HP, so those SFP+ Twin-AX cables that came with your Dell/IBM Blade chassis will be useless to connect to your HP Switches, to add insult HP often sell their own modules at 3x the price of an equivalent module from say Extreme or Juniper.
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?
My reccomendation would be, use Juniper for Core and Aggregation with ProCurve at the edge. Regards, Andrew
On Fri, Jun 18, 2010 at 02:40:04AM +1200, Andrew Thrift wrote:
Another major negative with the HP gear for us is that their switches only support SFP/SFP+ modules manufactured by HP, so those SFP+ Twin-AX cables that came with your Dell/IBM Blade chassis will be useless to connect to your HP Switches, to add insult HP often sell their own modules at 3x the price of an equivalent module from say Extreme or Juniper.
I've had no issues putting Netgear multimode GBICs into 1800-24g switches. Of course, these are probably useless for most people here. Btw, 3Com is HP now. Apparently, people liked 4800G series a lot. http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1276786511413+28353475&threadId=1400446 -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
On 6/17/2010 10:40 AM, Andrew Thrift wrote:
Another major negative with the HP gear for us is that their switches only support SFP/SFP+ modules manufactured by HP, so those SFP+ Twin-AX cables that came with your Dell/IBM Blade chassis will be useless to connect to your HP Switches, to add insult HP often sell their own modules at 3x the price of an equivalent module from say Extreme or Juniper.
Very true (and you thought Cisco was proud of their branded optics...). Apparently the HP ink cartridge marketing department is in cahoots with their network optics counterparts :-) Jeff
And to add to it here's a Cisco SFP in a Juniper chassis showing a serial number that looks suspiciously like a Finisar serial number. PIC 1 REV 04 711-021270 AR0209216364 4x GE SFP Xcvr 0 NON-JNPR FNS0932K03B SFP-SX -b On Thu, Jun 17, 2010 at 8:01 AM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 6/17/2010 10:40 AM, Andrew Thrift wrote:
Ā Another major negative with the HP gear for us is that their switches only support SFP/SFP+ modules manufactured by HP, so those SFP+ Twin-AX cables that came with your Dell/IBM Blade chassis will be useless to connect to your HP Switches, to add insult HP often sell their own modules at 3x the price of an equivalent module from say Extreme or Juniper.
Very true (and you thought Cisco was proud of their branded optics...).
Apparently the HP ink cartridge marketing department is in cahoots with their network optics counterparts :-)
Jeff
-- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges.....
I have never used 3Com or HP equipment in an infrastucture / mission critical enviornment so I will not attest to their qualities or failures. What I can tell you about is HP's recent acquisition of 3Com in my opinion had little to do with HP wanting to get into a core switch/routing market. Shortly before HP purchased 3Com I had the chance to meet Mark Hurd and listen to him talk about the direction HP was moving. At that time it seemed HP was not interested in the enterprise switch/routing market. I think Mark said something like, "Cisco/Juniper has that market all tied up so we are not going to go there." Instead, HP is very very intenetly focused on services. Especially enterprise services. This fits in very nicely with their new UCS (I don't remember what they call their version) blade enclosures. HP needed better switching / routing modules for their unified archtecture. These products come heavily laden with services. Anyone who has SANs, blade chassis, or routing/switching chassis knows the service contracts are enormously expesive. Sometimes half the cost of the system can be the service contract. 3Com also brought something else HP needed. A VOIP handset line. HP has partnered with Microsoft for their unified communication strategy and they do not have a phone. This may be acceptable in some enviornments, but many businesses go "What, no phone?" and kick them out the door. That is what happened with my company when Mircosoft pitched their UC system to us. We simply have too many "high up" users who would show the IT department the door if they didn't have a desk phone. (yes I understand you can add phones, but the package ends up looking like a hodgepodge of services) 3Com has phones and handsets and HP needed those if they want their UCS to compete with the new Cisco UCS. When we evaulate vendors for products we use these great big spreadsheets where we define metrics for everything we can thing of. Every product we evaluate we also look deeply at the company as well. My biggest concern with using HP in the core is if they are actually serious about being in the core or are they just going to let that product unit die over time. Dylan Ebner -----Original Message----- From: James Smith [mailto:james@jamesstewartsmith.com] Sent: Thursday, June 17, 2010 8:52 AM To: nanog@nanog.org Subject: Advice regarding Cisco/Juniper/HP I'm looking for a little insight regarding an infrastructure purchase my company is considering. We are a carrier, and we're in the process of building a DR site. Our existing production site is all Cisco equipment with a little Juniper thrown into the mix. I'd like to either get the same Cisco equipment for the DR, or the equivalent Juniper equipment. We have skill sets for both Cisco and Juniper, so neither would be a problem to manage. A business issue has come up since we have a large number of HP servers for Unix and Wintel. With HP's recent acquisition of 3Com they are pressing hard to quote on the networking hardware as well, going as far as offering prices that are way below the equivalent Cisco and Juniper models. In addition they're saying they'll cut us deals on the HP servers for the DR site to help with the decision to go for HP Networking. Obviously to the people writing the cheques this carries a lot of weight.
From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate.
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?
On Thu, 17 Jun 2010, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Pretty much never, unless you're talking about a rebadged Brocade product. Every time I've seen HP networking gear in production, its usually before it gets replaced with something else. The last install I dealt with was having so many problems it had a constant %10 packetloss on a simple flat network.
How is HP's functionality and performance compared to Cisco or Juniper?
Typically poor, but this varies widely with the series of HP gear. The software updates available also vary widely in quality, and I have rarely gotten a good answer from HP support on anything.
Does anyone have any HP networking experiences they can share, good or bad?
To end on a positive note, HP does have a good warranty, is typically fairly low cost and provides free software updates. -Tom
We've had a much different experience than what Tom is describing here. We've used HP extensively in our networks, mostly because of the price and warranty. For simple, flat networks, they are a great buy, in my opinion. We've never seen the packet loss issues that were described, and we push quite a bit of data through the 5412, 2900, and 6600 series products. That said, we've never used them for much outside of basic layer 2 services. We have a couple of c6500s for our core network, but at the edge, we have been very happy with HP. So far, warranty service has been flawless, although we have only replaced maybe half a dozen switches out of about 70 total that we have installed, over the course of 5 years. There isn't much as far as advanced features (for example, don't expect to get MPLS or BGP), but since we don't use those features at the edge, we haven't been hurt by that. Tom On 06/17/2010 10:37 AM, Tom wrote:
On Thu, 17 Jun 2010, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Pretty much never, unless you're talking about a rebadged Brocade product. Every time I've seen HP networking gear in production, its usually before it gets replaced with something else. The last install I dealt with was having so many problems it had a constant %10 packetloss on a simple flat network.
How is HP's functionality and performance compared to Cisco or Juniper?
Typically poor, but this varies widely with the series of HP gear. The software updates available also vary widely in quality, and I have rarely gotten a good answer from HP support on anything.
Does anyone have any HP networking experiences they can share, good or bad?
To end on a positive note, HP does have a good warranty, is typically fairly low cost and provides free software updates.
-Tom
-- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273 Center for High Performance Computing University of Utah http://www.chpc.utah.edu
Haven't seen these same issues either, but have seen others.. We use HP 8212's here to connect our storage and hpc devices. each 8212 has about 20 or more 10Gbit connections. Everyone is happy with them from an availability and performance perspective. Two things which I noticed, 1. Under heavy load (60% or more of 10Gbit interfaces at +80%) we have seen _all_ interfaces simultaneously drop packets and generate interface errors. this was on an early release of the firmware and I don't think we have seen this problem in awhile. 2. each module only has about 28 Gbits of bandwidth to the backplane. this means if you want non blocking 10Gbit access to the backplan you can only load up an 8212 50% of its physical port capacity with active links. Very recently they changed licensing, the 8212's use to ship with premium licenses included. this gave you OSPF, PIM VRRP and QinQ. without a product number change or other clear indication, these no longer are included but must be purchased separately. This was a bit of a let down as we use OSPF internally and was one of the items that made the 8212's interesting when deciding what we would standardize on for access switches. We also use 6509e's for our core routers, they use to be the only routers till we deployed OSPF. On the internet edge we use ASRs. The 'H3C' switches they recently acquired look nice(r). -g On Jun 17, 2010, at 12:47 PM, Tom Ammon wrote:
We've had a much different experience than what Tom is describing here. We've used HP extensively in our networks, mostly because of the price and warranty. For simple, flat networks, they are a great buy, in my opinion. We've never seen the packet loss issues that were described, and we push quite a bit of data through the 5412, 2900, and 6600 series products.
That said, we've never used them for much outside of basic layer 2 services. We have a couple of c6500s for our core network, but at the edge, we have been very happy with HP. So far, warranty service has been flawless, although we have only replaced maybe half a dozen switches out of about 70 total that we have installed, over the course of 5 years.
There isn't much as far as advanced features (for example, don't expect to get MPLS or BGP), but since we don't use those features at the edge, we haven't been hurt by that.
Tom
On 06/17/2010 10:37 AM, Tom wrote:
On Thu, 17 Jun 2010, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Pretty much never, unless you're talking about a rebadged Brocade product. Every time I've seen HP networking gear in production, its usually before it gets replaced with something else. The last install I dealt with was having so many problems it had a constant %10 packetloss on a simple flat network.
How is HP's functionality and performance compared to Cisco or Juniper?
Typically poor, but this varies widely with the series of HP gear. The software updates available also vary widely in quality, and I have rarely gotten a good answer from HP support on anything.
Does anyone have any HP networking experiences they can share, good or bad?
To end on a positive note, HP does have a good warranty, is typically fairly low cost and provides free software updates.
-Tom
-- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273
Center for High Performance Computing University of Utah http://www.chpc.utah.edu
On Thu, Jun 17, 2010 at 7:21 PM, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
1. Ā Under heavy load (60% or more of 10Gbit interfaces at +80%) we have seen _all_ interfaces simultaneously Ā drop packets and generate interface errors. Ā this was on an early release of the firmware and I don't think we have seen this problem in awhile.
I have seen this also, but on older 2848g's that were fully populated. Replaced the switch and the problem went away, but the old switch worked fine on test bench so I think this is fixed in firmware. Also using 5406 chassis, and never had the slightest hiccup. I dislike HP switches from a management point of view (and I think the VLAN config is nonsense), but they work fine.
On 23 June 2010 08:54, Colin Alston <karnaugh@karnaugh.za.net> wrote:
I dislike HP switches from a management point of view (and I think the VLAN config is nonsense), but they work fine.
That's strange, I abhor the Cisco way of doing VLANs and love the HP/Procurve method. What do you find so irritating? Kind regards, Matthew Walster
That's strange, I abhor the Cisco way of doing VLANs and love the HP/Procurve method.
What do you find so irritating?
I find it irritating because I am often running thousands of vlans and do not want to explicitly type them all out in the config or to have to do so with a script. `switch trunk allowed vlan 2-3000` is much more awesome, for me. ---Carl
For large campuses that have a lot (hundreds) of switches, Cisco seems to win out over HP from a TCO standpoint. I've consistently seen HP switches have higher failure rates, which isn't a big deal if you're a smaller shop, but when you have a large campus (or several large campuses across a state in our case) the man-power that you need to run around and do equipment swaps adds up pretty quick. I think what we do using about 10 people in a Cisco environment would be closer to 20 in an HP and Juniper environment, so those additional salaries and benefits need to be a factor. Cisco VTP is a killer app for VLAN management IMHO, but only for campus deployments, really. If you're a service provider you probably will be running in transparent mode. As far as Cisco's failure rate... I'm not proud of it, but given that we're a public institution and limited in funding we still have a large amount of 3500 XL series switches that have been running for 10+ years without failure in harsh environments (old buildings, boiler rooms...). It's nice to have that level of dependability in hardware and it certainly makes our lives easier. To be fair, I don't know many large HP deployments anymore as most of them have moved to Cisco, so I'd be interested in hearing from people who run an HP shop for a campus. The pricing and warranty seem hard to resist, but if the failure rates are still high it's hard to make a case. On Thu, Jun 24, 2010 at 5:55 PM, Carl Rosevear <crosevear@skytap.com> wrote:
That's strange, I abhor the Cisco way of doing VLANs and love the HP/Procurve method.
What do you find so irritating?
I find it irritating because I am often running thousands of vlans and do not want to explicitly type them all out in the config or to have to do so with a script. Ā `switch trunk allowed vlan 2-3000` is much more awesome, for me.
---Carl
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
pretty quick. I think what we do using about 10 people in a Cisco environment would be closer to 20 in an HP and Juniper environment, so those additional salaries and benefits need to be a factor.
I hear you on the HP stuff, but are you saying that Juniper equipment also shows a higher failure rate? Or, are you saying they require a higher staffing rate for different reasons? Just wondering, since Juniper is trumpeting running the stock exchange and all. ~JasonG
Poor choice of words, Juniper does fine. On Fri, Jun 25, 2010 at 9:12 AM, Jason Gurtz <jasongurtz@npumail.com> wrote:
pretty quick. Ā I think what we do using about 10 people in a Cisco environment would be closer to 20 in an HP and Juniper environment, so those additional salaries and benefits need to be a factor.
I hear you on the HP stuff, but are you saying that Juniper equipment also shows a higher failure rate? Ā Or, are you saying they require a higher staffing rate for different reasons?
Just wondering, since Juniper is trumpeting running the stock exchange and all.
~JasonG
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Fri, Jun 25, 2010 at 09:12:57AM -0400, Jason Gurtz wrote:
pretty quick. I think what we do using about 10 people in a Cisco environment would be closer to 20 in an HP and Juniper environment, so those additional salaries and benefits need to be a factor.
How many switches/users are we talking about that you need 10-20 people to manage?
I hear you on the HP stuff, but are you saying that Juniper equipment also shows a higher failure rate? Or, are you saying they require a higher staffing rate for different reasons?
Just wondering, since Juniper is trumpeting running the stock exchange and all.
I can vouch for the fact that the batch of Juniper EX-PWR-930-AC modular power supplies shipped around June/July last summer had some quality issues. We've replaced about 10 so far (out of about 140) in the year we've had them. Presumably they've fixed this on new batches. It's a good thing we sprang for the redundant power supply modules in those switches. Compare this to the Nortel (now Avaya) BayStack 55xx line where we've had approximately 0 built-in power supply and maybe 2-3 unit failures for other reasons in the last 3 years.
On Thu, Jun 24, 2010 at 9:52 PM, Matthew Walster <matthew@walster.org> wrote:
On 23 June 2010 08:54, Colin Alston <karnaugh@karnaugh.za.net> wrote:
I dislike HP switches from a management point of view (and I think the VLAN config is nonsense), but they work fine.
That's strange, I abhor the Cisco way of doing VLANs and love the HP/Procurve method.
What do you find so irritating?
It just feels ass backwards alot of the time, especially trunking. That's more likely an "RTFM" problem, but the Cisco VLAN config has always just seemed more logical.
That's strange, I abhor the Cisco way of doing VLANs and love the HP/Procurve method.
What do you find so irritating?
It just feels ass backwards alot of the time, especially trunking. That's more likely an "RTFM" problem, but the Cisco VLAN config has always just seemed more logical.
The Cisco default of allowing all VLANs on a trunk is dangerous in a service provider environment (not to mention VTP, DTP and other evils). The Cisco "interface-centric" method (adding VLANs to an interface instead of adding interfaces to a VLAN) is prone to typos which can have severe results (typing "switchport trunk allowed vlan 5" instead of ""switchport trunk allowed vlan add 5"). I'd definitely say "more logical" is in the eye of the beholder... Steinar Haug, Nethelp consulting, sthaug@nethelp.no
-----Original Message----- From: sthaug Sent: Wednesday, June 30, 2010 12:35 AM Cc: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP
The Cisco default of allowing all VLANs on a trunk is dangerous in a service provider environment (not to mention VTP, DTP and other evils).
I agree. In a perfect world, the default should be to not allow any vlans on a trunk unless explicitly configured. I think Cisco defaults are set so that someone not all that familiar with network gear can plug in a new switch, it will negotiate a trunk, and all vlans will be available on it without a lot of configuration. So like a lot of things, a piece of gear in the hands of someone who doesn't know exactly what they are doing can be dangerous. G
-----Original Message----- From: Colin Alston Sent: Tuesday, June 29, 2010 11:27 PM To: Matthew Walster Cc: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP
On Thu, Jun 24, 2010 at 9:52 PM, Matthew Walster <matthew@walster.org> wrote:
It just feels ass backwards alot of the time, especially trunking. That's more likely an "RTFM" problem, but the Cisco VLAN config has always just seemed more logical.
I can sympathize. Some gear you add vlans to a port. Other gear you add ports to vlans. Personally, I prefer the Cisco configuration syntax because if I want to know which vlans a port is in, you look at the port config and there it is. Other gear you need to look through each vlan configuration and note which vlans the port appears in and hope you don't overlook one. George
On Jun 30, 2010, at 12:07 PM, George Bonser wrote:
if I want to know which vlans a port is in, you look at the port config and there it is. Other gear you need to look through each vlan configuration and note which vlans the port appears in and hope you don't overlook one.
or become familiar with some basic commands, which is after all, our job... on hp: show port vlan e1, which will show you all the vlans port E1 is a member of.. I like cisco, but i think the HP way is more logical and less prone to error. A previous poster gave an excelent example, i burnt myself not adding the "add" to a trunk config on our cisco switches. i went over the magical number (and I've no idea why you need to use another argument when you pass some threshold, it seems redundant and silly) of vlans and took out about 7 departments till I realized what I had done. thankfully you only need to do this once to learn. the trunking is more logical on HP config wise too, there is a line in the config which shows all the members and trunk type, on one line. not being able to issue commands while in config mode (without the 'do') is annoying as hell too.. its like not being able to do anything on a unix box while you are root without being asked "are you sure" every time you hit carriage return. the biggest think I don't like about the HP CLI is the lack of regx or the ablitly to string a few together on one line. some models have it, others don''t. that woudl be the second issue, the lack of consistency between devices. cisco owns that one. -g
On Wed, 30 Jun 2010 12:18:24 -0400, Greg Whynott <Greg.Whynott@oicr.on.ca> wrote:
I like cisco, but i think the HP way is more logical and less prone to error. A previous poster gave an excelent example, i burnt myself not adding the "add" to a trunk config on our cisco switches. i went over the magical number (and I've no idea why you need to use another argument when you pass some threshold, it seems redundant and silly) of vlans and took out about 7 departments till I realized what I had done. thankfully you only need to do this once to learn.
Education is education. If you don't know what you're doing (and paying attention), you eventually will do something stupid and break the whole internet. Every manufacturer has their own specific brand of brain damage. In the Cisco world, there are 3 modes... add vlans, remove vlans, and *specify* vlans. Leaving out a word changes the entire meaning. Typos are just as simple (even more simple) on an HP. There's no add/remove mode for vlan port membership. You specify the entire list every time. Migrating port vlan assignments gets messy fast. (that's when people reach for IE to click a few checkboxes.) Personally, I prefer a bit of both. I like the HP method of keeping VLAN configuration in one section. However, I'll give that up every time for Cisco's much simpler means of managing vlan port membership. (at least on anything supporting interface ranges :-))
the trunking is more logical on HP config wise too, there is a line in the config which shows all the members and trunk type, on one line.
On the other hand, looking at the interface configuration, there's zero indication it's a member of a trunk. Cisco shows that in the interface config, and will immediately yell at you it you "unbalance" the port-group/etherchannel -- you shouldn't mess with the member interfaces directly once added to a port-group.
not being able to issue commands while in config mode (without the 'do') is annoying as hell too..
This is a safety measure to keep your mind on the road. A typo in config mode can make a seriously royal mess.
... that woudl be the second issue, the lack of consistency between devices. cisco owns that one.
No they don't. Which version of IOS are you running? Oh, right, that switch doesn't run IOS, it runs CatOS? Wait a min, that's a 1900... it uses a menu interface. I have three Cisco switches right here that are radically different. In fact, the 2948G-L3 confused a CCIE for several weeks. :-) Until I told him stop thinking "switch" and config it like a 48 port router. (and sadly, it doesn't support interface ranges. :-() --Ricky
On Jun 30, 2010, at 4:50 PM, Ricky Beam wrote:
Personally, I prefer a bit of both.
same here. both have some things which I don't agree with. prime example again is adding more than X vlans to an interface, why the "add"? interface TenGigabitEthernet5/5 switchport trunk allowed vlan 20,30,40,50,60,100,121,124,125,128,334-336 switchport trunk allowed vlan add 500-505,509,510,513,515-518,530,532,540 that should all be able to go onto one line. I don't follow the logic. we could sit here all day nit picking I guess. It was more my managers rage on that fateful day that made me hate that 'method' so much. 8)
not being able to issue commands while in config mode (without the 'do') is annoying as hell too..
This is a safety measure to keep your mind on the road. A typo in config mode can make a seriously royal mess.
I dis-agree with you on this. who might they be to determine my ability to not mess things up, and why are the so concerned? and how does this logic follow onto ASA/PIX/FWSM and WLC devices? when you are enabled and in config mode on those you can issue non elevated commands. there is much more potential for damage on an edge security device than an inter departmental switch/router I'd think. but i could be wrongā¦.
... that woudl be the second issue, the lack of consistency between devices. cisco owns that one.
No they don't. Which version of IOS are you running? Oh, right, that switch doesn't run IOS, it runs CatOS? Wait a min, that's a 1900... it uses a menu interface.
haha. I have to agree with you there. i stand corrected. It been awhile since i used a "set" based IOS.
I have three Cisco switches right here that are radically different. In fact, the 2948G-L3 confused a CCIE for several weeks. :-) Until I told him stop thinking "switch" and config it like a 48 port router. (and sadly, it doesn't support interface ranges. :-()
in closing, i have to say I love HP's "alias" command, I can rev my config and save it to a tftp server by typing "saveit" while enabled. Some IOS's allow you to do a "wr net" and get it there with a predefined tftp server, but as we discovered, this isn't available on all devices.. take care and have a great weekend, greg
On 6/30/2010 5:14 PM, Greg Whynott wrote:
On Jun 30, 2010, at 4:50 PM, Ricky Beam wrote:
No they don't. Which version of IOS are you running? Oh, right, that switch doesn't run IOS, it runs CatOS? Wait a min, that's a 1900... it uses a menu interface.
Actually, before they went completely off the update radar, you could select between a menu, IOS-like CLI, or HTTP management thing on a 1900 (and perhaps 2820s?). They haven't been completely retired from here that long (may still have a couple in surplus...) Jeff
in closing, i have to say I love HP's "alias" command, I can rev my config and save it to a tftp server by typing "saveit" while enabled. Some IOS's allow you to do a "wr net" and get it there with a predefined tftp server, but as we discovered, this isn't available on all devices..
take care and have a great weekend, greg
You can use alias for Cisco as well but default is to ask for TFTP IP etc but you can change this with file prompt quiet. Then you can do copy run tftp://1.2.3.4/router-conf and make an alias for that. Or you could write it in EEM like I did, you can trigger to save when someone changed the config or at a certain time etc. You could also use the archive command to upload configs. /Daniel
On 30 June 2010 21:50, Ricky Beam <jfbeam@gmail.com> wrote:
Typos are just as simple (even more simple) on an HP. Ā There's no add/remove mode for vlan port membership. Ā You specify the entire list every time.
conf t vlan 1000 tag 1 tag 22 untag 44 exit exit write memory exit Result: vlan 1000 is tagged on ports 1 and 22, and the untagged (native) port is changed on port 44 to vlan 1000. HP is cumulative, typos generally don't matter. M
On Wednesday, June 30, 2010 04:50:40 pm Ricky Beam wrote:
No they don't. Which version of IOS are you running? Oh, right, that switch doesn't run IOS, it runs CatOS? Wait a min, that's a 1900... it uses a menu interface.
Yep, much like the 'NetBeyond' EtherSwitch 1420 I have here doing... well... 10Base-5 to 100Base-FX and 24 10Base-T's 'work'. Man, that left a bad taste in my mouth. But if it ain't broke...
I have three Cisco switches right here that are radically different. In fact, the 2948G-L3 confused a CCIE for several weeks. :-) Until I told him stop thinking "switch" and config it like a 48 port router. (and sadly, it doesn't support interface ranges. :-()
Have a couple of 2948G-L3's in production here, doing trunked gigabit etherchannel uplink to a 7609, with the 7609 doing the DHCP. Configure them like the nearly forgotten Catalyst 8500's..... they're one step from broke, but there's no budget to replace at the moment. Too bad they look virtually identical to the very different 2948G's, which is 4500-based instead of 8500-based. But I'm glad to see I'm not the only one still working those AnyFlow-based switches.... In this case, perhaps the statement should be 'Advice concerning Cisco BU1/BU2/BU3/etc/Juniper/HP/Extreme.....'
-----Original Message----- From: Greg Whynott Sent: Wednesday, June 30, 2010 9:18 AM To: George Bonser Cc: Colin Alston; nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP
or become familiar with some basic commands, which is after all, our job... on hp: show port vlan e1, which will show you all the vlans port E1 is a member of..
True if you happen to be logged on to the device. What I had in mind was reading config files which is an exercise I happen to have been doing recently. I can look at the config file for a Cisco unit and determine easily which ports are in which vlans by looking at the port config. Some other vendors I must parse the vlan config for port numbers. So yeah, on a Brocade unit one can do sho vlan <interface> if you are logged on to it and other vendors have their way. It isn't that big of an issue but if I could have a perfect world, I would rather specify vlans per interface than interfaces per vlan. G
On 30/06/2010 17:07, George Bonser wrote:
Some gear you add vlans to a port. Other gear you add ports to vlans. Personally, I prefer the Cisco configuration syntax because if I want to know which vlans a port is in, you look at the port config and there it is. Other gear you need to look through each vlan configuration and note which vlans the port appears in and hope you don't overlook one.
Both syntax types (per port and per vlan) break in terms of readability at a certain stage. Unfortunately, that stage comes very quickly in terms of many configurations. There's just no way to be elegant on most complicated configurations. Nick
On Thu, 17 Jun 2010, Tom Ammon wrote:
We've had a much different experience than what Tom is describing here.
To be fair, each platform seems to vary quite a bit in quality and reliability. I have seen some HP installs work ok, but they were primarily edge switches or bladecenter switches.
Not to stir the pot, but Extreme is making some good products at a low cost and have lifetime warranties. I've been using them lately in the end-user edge as lower cost POE termination. They do LLDP-MED flawlessly so Cisco, or other phones get their voice vlan and pass the data vlan. Now, they are missing some of the prime-time features found in J and C which is why I wouldn't recommend them in the agg or core. -b On Thu, Jun 17, 2010 at 9:37 AM, Tom <bifrost@minions.com> wrote:
On Thu, 17 Jun 2010, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Pretty much never, unless you're talking about a rebadged Brocade product. Every time I've seen HP networking gear in production, its usually before it gets replaced with something else. The last install I dealt with was having so many problems it had a constant %10 packetloss on a simple flat network.
How is HP's functionality and performance compared to Cisco or Juniper?
Typically poor, but this varies widely with the series of HP gear. The software updates available also vary widely in quality, and I have rarely gotten a good answer from HP support on anything.
Does anyone have any HP networking experiences they can share, good or bad?
To end on a positive note, HP does have a good warranty, is typically fairly low cost and provides free software updates.
-Tom
-- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges.....
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy. -----Original Message----- From: Bill Blackford [mailto:bblackford@gmail.com] Sent: Thursday, June 17, 2010 12:49 PM To: Tom Cc: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP Not to stir the pot, but Extreme is making some good products at a low cost and have lifetime warranties. I've been using them lately in the end-user edge as lower cost POE termination. They do LLDP-MED flawlessly so Cisco, or other phones get their voice vlan and pass the data vlan. Now, they are missing some of the prime-time features found in J and C which is why I wouldn't recommend them in the agg or core. -b On Thu, Jun 17, 2010 at 9:37 AM, Tom <bifrost@minions.com> wrote:
On Thu, 17 Jun 2010, James Smith wrote:
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper?
Pretty much never, unless you're talking about a rebadged Brocade product. Every time I've seen HP networking gear in production, its usually before it gets replaced with something else. The last install I dealt with was having so many problems it had a constant %10 packetloss on a simple flat network.
How is HP's functionality and performance compared to Cisco or Juniper?
Typically poor, but this varies widely with the series of HP gear. The software updates available also vary widely in quality, and I have rarely gotten a good answer from HP support on anything.
Does anyone have any HP networking experiences they can share, good or bad?
To end on a positive note, HP does have a good warranty, is typically fairly low cost and provides free software updates.
-Tom
-- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information which is confidential to, and/or privileged in favor of, CDI Corporation or its affiliated companies (CDI) or CDI's customers. Any review, use, reproduction, disclosure or distribution by the recipient is prohibited without prior written approval from an authorized CDI representative. This notice must appear in any such authorized reproduction, disclosure or distribution. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. Thank you.
On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual? ~Seth
they may require a deposit before you load their web site.. -g -----Original Message----- From: Seth Mattinen [mailto:sethm@rollernet.us] Sent: Thursday, June 17, 2010 2:07 PM To: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual? ~Seth
On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote:
On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual?
We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals. There's a 1000+ page manual on the management software itself. William
The main problem with HP switches and their 'free software upgrades' is that there are regularly bugs and regressions in the software and their solution is to have you 'oh just update the software'... this is not always practical in a production environment. And other weirdnesses. I like their gear for office networks, etc but I, personally, would keep it out of the DC and resist it in general as much as possible. A lot better than stringing a bunch of Linksys together but really not on par with "real" Cisco or Juniper. Close enough though that if you engineer around the effect of the constant software upgrades, etc, they can be a good play. Most networks I have worked on would rather get rid of their HPs and try to do so whenever they can take the outage / afford the new gear / etc. When I was a consultant in a more rural area, I pushed HP switches because businesses needed to operate on the cheap, would NOT buy Cisco due to price, etc... but I do find HP better than most of the other brands in that price range in regard to configurability, feature set, and reliability. -Carl
On 17/06/10 20:02, Carl Rosevear wrote:
The main problem with HP switches and their 'free software upgrades' is that there are regularly bugs and regressions in the software and their solution is to have you 'oh just update the software'... this is not always practical in a production environment.
This has been our experience too. It's nice having "free support" and "free software upgrades" but when their support consists of "upgrade to this latest unreleased firmware and hope it fixes your problems", I'd rather be paying a vendor for support... that said I think the 5412's are OK for edge switches.
To emphasise more this subject, the technical support HP Procurve is providing (for free) is more consumer level and in my opinion is one of the key differentiators from teams like Cisco TAC. Here is a short laundry list of my experience: For an example a typical phone call to their help desk (only way to raise tickets with them, at least if you want a response in less they 7 days :) ends by the help desk (level 0 technical personnel) "advising" you to upgrade first, and only IF after that the issue persists they will open a ticket. The fact that you are speaking about DC switches with 200 servers does not seem to matter. Another example is when troubleshooting spontaneous switch reloads, the help desk usually replies by saying that it "sometimes happens", suggesting to "wait a while" to see whether it will reload next time.....which I found hilarious. Also (you already noticed) the 0th and 1st level are not very technically competent, basically they act as a firewall to upper support lines. To have the ticket "escalated" to the 2nd line they will let you fill a huge form about your whole network, with tons of irrelevant data in it - a formal barrier. Once you get there, you might actually get to troubleshooting and talk to people who really understand your issue - kudos to those. The only problem is that it takes about a week to get to them.... Another area which is a big HP Procurve disadvantage is that their CLI does not have too much troubleshooting capabilities. Things like extended ping/traceroute, extended telnet (source interfaces, packet size, sweep size) do not exist or exist only on specific platforms, not speaking about the fact that you cannot telnet to other TCP port then 23.... Also we cannot do "show ip arp <IP address>" and only do "show arp" and then manually search for the IP in the 10 page output.......which tells a lot about the people who are coding the software. Another one....the include|exclude grep statements either do not exist or only apply to certain commands like "show run" In light of above I don't think you would be surprised with the fact that there are almost no debug commands and the logging facility displays unneeded messages (about lacp starting during end-user port flaps), and does not display messages about OSPF neighbor going down.... Bear in mind is that all above applies to my own opinion on HP Procurve not-yet-merged with 3com , so not sure how the situation changed in the meanwhile with the new H3C products. On the other side I would certainly recommend HP Procurve in simple access/edge layer scenarios, certainly not as a DC distribution layer switch, not due to its technical drawbacks, but mostly due to operational difficulties described above. -pavel skovajsa On Fri, Jun 18, 2010 at 7:56 PM, James Braid <jamesb@loreland.org> wrote:
On 17/06/10 20:02, Carl Rosevear wrote:
The main problem with HP switches and their 'free software upgrades' is that there are regularly bugs and regressions in the software and their solution is to have you 'oh just update the software'... this is not always practical in a production environment.
This has been our experience too. It's nice having "free support" and "free software upgrades" but when their support consists of "upgrade to this latest unreleased firmware and hope it fixes your problems", I'd rather be paying a vendor for support... that said I think the 5412's are OK for edge switches.
On Sat, Jun 19, 2010 at 7:52 AM, Pavel Skovajsa <pavel.skovajsa@gmail.com> wrote:
To emphasise more this subject, the technical support HP Procurve is providing (for free) is more consumer level and in my opinion is one of the key differentiators from teams like Cisco TAC. Here is a short laundry list of my experience:
Trimming your post, apologies
-pavel skovajsa
I would have to agree with your points. We have about a dozen HP switches, mostly 3500YL's performing light layer3 duties, and migrating to some 10Gbit modules for the access layer. We have had several issues with packet loss on the HP's, in particular a bug more than 2 years old and still unresolved on the 2600's, 2900's and 3500's: When you SSH into those models of HP switches, the SSH negotiation uses 100% of the host processor, and will block out pings, and upper layer services such as OSPF and VRRP. A single SSH sessions won't likely make an impact, but we have some monitoring applications that hit SSH frequently, and can 100% reliably freeze those models of HP switches with just 2-3 SSH login attempts. Imagine that, a switch that will lock up when SSH'ing to it, fun isn't it? We had to rethink some of our extended monitoring for the HP's, we originally wanted to use SNMP, but their provided MIB files are formatted so badly only HP Openview will read them without a lot of fuss. Next is 10Gb. We bought their new SFP+ 10Gb modules for the 3500YL's, and for more than 6 months, they didn't have any stable firmware to support those modules. They would send us engineering builds of the firmware with massive regressions and new bugs. It was until June 10th or so when they officially released firmware for the 10Gb SFP+ modules for the 3500's. While the HP CLI is different than Cisco's, it is easy to use and will be familiar to anyone with about a day of learning the differences, however the CLI is also limited as you said. Debug and troubleshooting output is almost non-existent, I don't believe their programmers had any idea of what a production level network wants to see. Their fiber interfaces do not expose any SNR, transmit power, heat, or load to the CLI or any management software. SO if you are fiber heavy, to diagnose anything be prepared to take down links to gather even the most basic information with separate troubleshooting hardware. All in all, if you have a small network, maybe half a dozen switches, require no stacking, no fiber, and no 10Gb on a large scale, HP will work. But as far as being affordable, their licensing costs for OSPF and VRRP are insane. You'd be better off paying slightly more at that point and going with Juniper or Cisco. To the OP, I lost the fight with our head of IT on the HP vs. others on networking, and I deeply regret it. If you are already familiar with Juniper and Cisco, pick your favorite and not use HP. -- Brent Jones brent@servuhome.net
From: William Pitcock <nenolod@systeminplace.net> Date: Thu, 17 Jun 2010 13:35:30 -0500
On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote:
On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual?
We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals.
There's a 1000+ page manual on the management software itself.
The Brocade manuals are good, but you need to have a customer account to access them. Very annoying when you are trying to do an evaluation. I have spoken with one of their engineers about that and he said that they (the engineers and sale folks) are trying to get that changed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
I am guessing they might be referring to the h3c equipment. 3com and Huewai had joint venture, that was bought out by 3com before they were purchased by HP see http://www.h3cnetworks.com/en_US/index.page We use the HP as edge switches in the campus networks, and they seem to work well. I would be interested to hear what people think of the h3c equipment. Hibernia seem to use them if you read the hp website Ben On 17 Jun 2010, at 22:12, Kevin Oberman wrote:
From: William Pitcock <nenolod@systeminplace.net> Date: Thu, 17 Jun 2010 13:35:30 -0500
On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote:
On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual?
We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals.
There's a 1000+ page manual on the management software itself.
The Brocade manuals are good, but you need to have a customer account to access them. Very annoying when you are trying to do an evaluation.
I have spoken with one of their engineers about that and he said that they (the engineers and sale folks) are trying to get that changed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Changes to the Brocade and legacy Foundry support sites are in progress. The candid comments from the community expressed here in numerous threads this year have captured your frustration for me to explain to management in far better words than I can write myself. I've had several mail and phone conversations with the team in charge of our support site about our current practice of requiring a login to access documentation, and they understand why this is not at all helpful and a bad way of doing business. It's the way it is for various historical reasons. Product documentation will be freely available on the new MyBrocade support site that is under construction. This is part of a huge effort to integrate the disparate support sites' software, knowledge bases, manuals, etc. into one new happy place. Stand by, and thanks for your patience. Greg (works for Brocade) -- Greg Hankins <ghankins@mindspring.com> -----Original Message----- Date: Thu, 17 Jun 2010 14:12:40 -0700 From: Kevin Oberman <oberman@es.net> To: William Pitcock <nenolod@systeminplace.net> Cc: nanog@nanog.org Subject: Re: Advice regarding Cisco/Juniper/HP
From: William Pitcock <nenolod@systeminplace.net> Date: Thu, 17 Jun 2010 13:35:30 -0500
On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote:
On 6/17/2010 11:01, Sandone, Nick wrote:
I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy.
Do you still have to pay them to read the manual?
We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals.
There's a 1000+ page manual on the management software itself.
The Brocade manuals are good, but you need to have a customer account to access them. Very annoying when you are trying to do an evaluation. I have spoken with one of their engineers about that and he said that they (the engineers and sale folks) are trying to get that changed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Product documentation will be freely available on the new MyBrocade support site that is under construction. This is part of a huge effort to integrate the disparate support sites' software, knowledge bases, manuals, etc. into one new happy place.
Stand by, and thanks for your patience.
Greg (works for Brocade)
--
I brought up the issue to Martin Skagen last year in San Francisco and we probably chatted for over an hour on that subject. There is a certain leverage that the community having access to manuals provides to a manufacturer. If people who might never buy a support contract can pick up a piece of gear and find the manuals for it, particularly someone who might be just learning about your products, you might be able to create a loyal customer for many years to come. As it currently stands, a piece of used (but still quite viable) Brocade/Foundry gear might be quite useless to and avoided by someone in that category.
From personal experience, I often like to peruse manuals of new equipment in order to judge the value of new features. The availability of the manual can generate a sale if I can see that a feature would be of value in the network. One can often obtain a better idea of how the feature works from reading the manual than from some marketing slick.
It would also be important to have access to old manuals, too, for gear that is no longer manufactured. Enabling self-support is also a way to install brand loyalty. Getting back to HP gear, I haven't had a problem with the rebranded Brocade stuff but there was a line of low-end switches that gave me fits for a couple of years. I think others have mentioned the same issue where they would simply decide to start dropping packets on all ports. Kicking the switch every week or so was the only cure. Don't have them in the network anymore so I don't know if they fixed it.
OK, I'll throw in my $.02, It really doesn't matter what any of us say, anecdotes from NANOG will not stop your CEO/CFO or worse your CMO from directing you to use HP. You have only two choices. The first is to engage in "war of the PowerPoints" during which you and the HP account team inform "the people who write the checks." As most account teams are pretty good at this type of warfare, and as the war will eventually escalate into a "war of the Excel Spreadsheets" it's a pretty difficult road. The second choice is a "war of the Lab Reports" in which you bring HP equipment into your lab and test it against the comparable Cisco/Juniper equipment. By choosing this road you get to learn all about HP and if it works in your application, you're that much closer to deploying it safely. If it won't work, you have real data which, in most cases (but not all), trumps any war of the PowerPoints your account team might start. Sometimes you even find that while the "deal" looks really good, in order to accomplish your application you'll need twice as much of Brand X and therefore, the deal isn't quite so appealing. (By the way HP, Cisco and Juniper are pretty much interchangeable in this discussion). What CEO's, CFO's and CMO's really like to see are options. Cost and test all three. jy On 17/06/2010, at 11:52 PM, James Smith wrote:
I'm looking for a little insight regarding an infrastructure purchase my company is considering. We are a carrier, and we're in the process of building a DR site. Our existing production site is all Cisco equipment with a little Juniper thrown into the mix. I'd like to either get the same Cisco equipment for the DR, or the equivalent Juniper equipment. We have skill sets for both Cisco and Juniper, so neither would be a problem to manage.
A business issue has come up since we have a large number of HP servers for Unix and Wintel. With HP's recent acquisition of 3Com they are pressing hard to quote on the networking hardware as well, going as far as offering prices that are way below the equivalent Cisco and Juniper models. In addition they're saying they'll cut us deals on the HP servers for the DR site to help with the decision to go for HP Networking. Obviously to the people writing the cheques this carries a lot of weight.
From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate.
So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?
Jeff Young wrote:
you'll need twice as much of Brand X and therefore, the deal isn't quite so appealing. (By the way HP, Cisco and Juniper are pretty much interchangeable in this discussion).
If they are interchangeable then why bother getting into a war at all? It's very tiresome. :-| -- http://goldmark.org/jeff/stupid-disclaimers/
On Thu, Jun 17, 2010 at 6:52 AM, James Smith <james@jamesstewartsmith.com> wrote:
we're in the process of building a DR site.
Assume for purposes of discussion that all the vendors have equivalent quality equipment with approximately equivalent features. I can think of four occasions you'd need a DR center 1 - Practicing your disaster-recovery drills 2 - Testing out new configurations or equipment that you'll roll out to the main system 3 - When you're having a really bad day and need to switch over quickly 4 - When you're having a really really bad day due to common-mode failures of your main-system's vendor's equipment. Case 1 is fine. Case 2 may let you do proofs of concept, but if the DR isn't a close enough model of your real equipment, it's often not good enough Case 3 is the canonical time that you want your DR center to look as much like the real thing as possible, especially if you're trying to handle partial failures of the main system and not just smoking-hole-in-the-ground disasters. Case 4 is the canonical time you wish you'd ignored my advice for Cases 2 and 3, because your HP box has different bugs than your Cisco box. Depending on quite what you do and what your failure models are, you may be able to build parts of your DR center using other vendors' equipment, without too much risk of mismatched configurations, but in general you're going to need to buy a lot of parts for your DR center that are identical to the primary systems they're backing up. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
participants (36)
-
Andrew D Kirch -
Andrew Thrift -
Ben Roeder -
Bill Blackford -
Bill Stewart -
Brandon Kim -
Brent Jones -
Carl Rosevear -
Chuck Anderson -
Colin Alston -
Daniel Dib -
Dylan Ebner -
Eugen Leitl -
George Bonser -
Greg Hankins -
Greg Whynott -
Jack Carrozzo -
James Braid -
James Smith -
Jason Gurtz -
Jeff Kell -
Jeff Young -
Jeroen van Aart -
Kevin Oberman -
Lamar Owen -
Matthew Walster -
Nick Hilliard -
Pavel Skovajsa -
Ray Soucy -
Ricky Beam -
Sandone, Nick -
Seth Mattinen -
sthaugļ¼ nethelp.no -
Tom -
Tom Ammon -
William Pitcock