Archived from groups: comp.dcom.lans.ethernet (
More info?)
Walter Roberson wrote:
> In article <cjek1i$2smc$1@nyheter.ipsec.se>, <phn@icke-reklam.ipsec.nu>
> wrote:
> :Liz Eriksen <NoSpam@yahoo.com> wrote:
> :> I am pricing switches for a client. In the past, I have simply used
> :> Cisco and been pleased. This client is balking at the price and points
> :> to other vendors such as HP or even Dell.
>
> :In short : dependability, support, future upgrade and compatibility.
>
> Dell's products that are not computers, are usually devices bought
> from OEMs. Sometimes Dell says outright who made a device, and
> sometimes they do not. If you are looking for a particular device,
> then sometimes you will find that Dell has a quite competitive price
> for it, due to their bulk-buying.
>
> As, though, the devices are not made by Dell, then you cannot expect
> Dell support to be able to know the devices well. If you get the
> support for a device through Dell, then if you have a tricky problem,
> Dell support is going to end up playing the middleman, relaying your
> questions to the original company, rather than dealing with the matter
> themselves. Or alternately, Dell will just act as a payment location
> and will give you direct access to the vendor's support facilities,
> however good they are. In the case of Cisco, those vendor facilities
> support facilities are quite good... but if it turns out that the device
> was made by a company that turns largely out of a "third world" country,
> then support could be nearly unavailable, incomprehensible, slow,
> fast but so inaccurate as to make your problem worse -- or it might turn
> out to be quite helpful, if the company is trying hard to compete on
> service rather than on price alone.
>
> Do not, in other words, expect Dell's reputation for good support
> for their computers in North America to carry over to support for the
> other devices available through Dell: ask Dell hard questions about
> the support for any non-computer equipment you are investigating
> purchasing through them.
>
> When your client's network fails, who will be responsible for fixing
> it? If it is you, then you are going to want to take a "dry run"
> on the support infrastructure to find out what it is like. You do
> NOT want to be stuck in the situation where your client decides to
> go with a product based mostly upon price, and *you* get stuck being
> unable to do quality support because the vendor's support infrastructure
> for the product is poor.
>
> If the client plans to handle the support directly then your "due
> diligence" extends to finding out what the support for the item would
> be like (e.g., by examining past usenet postings in which people have
> talked about their support experiences with the OEM) and to
> conveying what you found to the client. If the client still decides
> to go with low price instead of the best price + performance + support
> combination, then the client will probably -still- blame you when
> they can't get good support, but at least they won't be able to
> successfully sue you if you have on record the report in which you
> warned about support issues.
>
>
> Around here, some people are unhappy about the ~$CDN5000 that we pay in
> support annually for our Cisco firewall. They complain about the
> size of my budget, and insinuate that I'm spending my budget frivilously.
>
> Well, yes, it is true that I could go for a lower support level,
> such as 8x5 Next Business day, rather than 24x7 with 4 hours response
> time with parts delivered (if needed) in the middle of the night from
> a district support warehouse. But I do a simple calculation that
> has proven to be compelling to anyone who actually asks about the
> price instead of assuming that I'm gold-bricking.
>
> I obtain the total annual salary costs for our organization from the
> admin staff, and divide by the number of official working hours per day
> (10 hours in our case, taking into account that not everyone starts
> work at the same time), and reduce the result by a fudge factor of
> about 0.8 to account for the fact that on any particular day, not
> everyone is going to need the network in order to be able to perform
> their job. The resulting figure is the "opportunity cost" per hour --
> the cost to the organization in lost wages from people unable to do
> their jobs because they can't access the facilities they need. I then
> multiply that by the average number of hours to fix the device
> if we only have "next business day" replacement and if I have no
> access to the vendor's support if I find a problem during the "off-hours"
> that could potentially be solved before other people need the network.
>
> For our organization, the resulting calculation shows that
> an 8x5xNBD support contract could cost the organization about $CDN 10000
> in lost productivity for a single incident. The $CDN 2000 price
> difference between the bottom-level support we could get and the layer
> we actually purchase then becomes a quite acceptable expense. Management
> is often more than a little fuzzy about why you would buy more expensive
> equipment or a more expensive support contract than the minimum that
> would do that job, but they do sit up and take notice when you can
> deduce hard figures such as $CDN 10000 lost wages per incident as the
> potential consequence for going with cheaper, less supported devices.
> (The potential costs would be much higher if we were a "business" instead
> of a research site.)
>
>
> Speaking in generalities, *our* experience with vendors has led us to
> the following stereotypes:
>
> Cisco: There's always someone else less expensive, but Cisco's devices
> are often more price competitive than reputation would led you
> to expect. Online support facilities are excellent, and we really
> do get a callback within 15 minutes of opening a case in the middle
> of the night (even when the matter could easily wait.) But the
> sheer volume of online documentation leads to situations in which
> the online support (such as the Feature Navigator or sales brochures)
> might not catch up with new releases for several months -- but even
> then, if you notice something in particular and nudge the writers,
> then the correction will usually appear in the next internal Cisco
> documentation release cycle, possibly in less than a week.
>
> The sheer number of features available can be daunting: to learn
> -everything- about any particular device might take months or years.
> And you likely will only use a fraction of the features at any one
> time. But if your organization undergoes a sudden topology change,
> or if someone suddenly plops a project on you (e.g., they went
> ahead and bought a major new device without consulting you
> about potential network impacts), then chances are high that there
> is a feature already present that you can use. And 5 years down the
> road when devices are faster and cheaper and you are taking the
> Cisco device out of mainline service, you will likely be able to
> use other features you had not looked at before and redeploy the
> Cisco device for other useful work. The usual phrasing is that
> Cisco devices have "the kitchen sink" of features. But the flip side
> of this is that you are paying for features that *you* don't need
> (or didn't think you needed when you bought the device.)
>
> Look at the market in used Cisco equipment. People are still asking
> serious questions about the 1600 series routers; we deployed a
> 1600 series router pretty close to a decade ago.
>
> Nortel: Usually less expensive and significantly faster than the
> corresponding Cisco device. But the device is probably not nearly
> as flexible as the Cisco device, and some of the Nortel device's
> feature combinations will probably -never- work over the lifetime
> of the device. The Nortel WWW site is getting a better over time,
> but the search engine on it is still relatively poor: google does a
> -much- better job of finding useful information on the nortel site
> than nortel's [presumably context sensitive] search engine does.
> We had a number of instances in which the Nortel search engine said
> that there was no information available on a particular topic, only
> to later discover that if you happened to read the release notes
> in detail and get an exact document reference, that the information
> was there after-all.
>
> Nortel service is, I am told, quite good... at least if you are a
> big account and are in the same city as a major nortel office. If not,
> then the service might not be nearly as accomedating. And even on
> the big accounts they are known to say "You must be doing something
> wrong, because that feature works", and to refuse to admit to a
> problem until you apply some clout and get the regional sales manager
> and some nortel technical experts to come to your site and you
> demonstrate that the problem is real. [That was one of the problems
> that never got fixed before that product was EOL'd; in the meantime
> the customer had given up and moved on to other equipment.]
>
> The lesser flexibility might not be an issue in some situations, but
> in other situations, it can lead to a lot of frustration. I suspect
> that Cisco routers are pretty close to "Turing complete" if you chain
> together enough loopback interfaces, nat translations, and policy
> routing ;-) With Nortel, you are more likely [in our experience] to
> be out of luck if what you want to do does not fit the architecture
> of the ASICs. (Cisco, in those cases, drops to cpu-processed paths,
> which might be noticably slower, but at least allow the job to be
> done.)
>
> On the plus side, the Nortel Baystack layer 2 switches are fairly
> easy to configure and are quite reliable, well suited to being just
> plain managed workgroup switches with VLANs. But we're going to have
> to replace ours in not too long, as they just don't have the
> flexibility to be more than that.
>
> Netgear: fast, cheap, but keep a spare supply of blood on-hand. And
> before you buy, ask hard questions about return policies in the case
> that you can't get the device to do what you need.
Minor nit--Netgear really in a different market from the others you're
discussing, just as Linksys is. Netgear is to Nortel Bay Networks as
Linksys is to Cisco.
Assume that Netgear and Linksys products will do simple things reasonably
well. If you need something flexible then plan on spending the money for
pro equipment.
> SMC: we haven't used any of their equipment for several years. Our
> measured network reliability went way up when we replaced the SMC
> switches with the Nortel Baystack ones. I have no information about
> what their equipment is like these days. Essentially at the time
> we looked, their devices were "consumer quality", not business
> quality. The current generations of SMC wireless devices aren't
> getting slammed (nor noticably praised) in the wireless newsgroups,
> which are usually pretty fast to whine about problems.
>
> HP: There was an interesting (but not particularily long) discussion
> perhaps a year ago, that pointed out an issue with the Procurves.
> At the time at least, the Procurves only had [if I recall properly]
> a single spanning tree, rather than a per-vlan spanning tree -- and
> they used the same MAC for all of their VLAN routing. The result was
> not pretty in cases where you had physical topological loops
> and multiple connections between devices that were distinguished by
> their VLAN. Because of the single spanning tree, the Procurves could
> end up flapping that one common MAC between ports, resulting in
> noticable packet loss. If the device had per-vlan spanning tree
> or used different MACs for each VLAN, then there would not have been
> a problem. It could be that this issue has been addressed in more
> recent software versions. (The Procurves did use distinct MACs
> per physical ports set to layer 2 mode, but that didn't apply to
> ports configured for layer 3 routing.)
--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
Facebook
Twitter
Instagram