[c-nsp] Network Analyser with n-way support

[Thomas Kernen]

Thread going to private since I don't think there is much more in this 
for the cisco-nsp ml.

T

----- Original Message ----- 
From: "Ted Mittelstaedt" <tedm at toybox.placo.com>
To: "Thomas Kernen" <thomas at ip-man.net>; <cisco-nsp at puck.nether.net>
Sent: Saturday, January 15, 2005 9:35 AM
Subject: RE: [c-nsp] Network Analyser with n-way support


>
>
>> -----Original Message-----
>> From: Thomas Kernen [mailto:thomas at ip-man.net]
>> Sent: Friday, January 14, 2005 5:12 AM
>> To: Ted Mittelstaedt; cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] Network Analyser with n-way support
>>
>>
>> >> Currently debugging an issue with autonegociation (n-way) between 
>> >> 2
>> >> network devices for which it appears that neither vendor can solve
>> >> the
>> >> issue directly. We are now trying to locate an analyser that
>> >> will allow
>> >> us to sniff the n-way negociation from both devices but without 
>> >> the
>> >> ports on the analyser doing their own negociation with the end
>> >> devices,
>> >> so basically I'm looking for a "pass through" analyser.
>> >>
>> >
>> > I don't think anything like that exists in the commercial realm
>> > because
>> > such problems are usually solved by inserting a switch in between
>> > the devices - thus no commercial viability.  Why don't you
>> do that and
>> > see what happens?
>>
>> Yep, hard time finding vendors, starts off with a yes until the sales
>> engineers turn around and say no. As for the switch, yes we have used
>> that to verify the problem and the switch does solve this problem.
>> Unfortunally I can't deploy 600 switches for the installed ports, 
>> each
>> port is terminating at a different location.
>>
>
> Ah, how did you deploy the equipment at the 600 locations that
> your having problems with, then?  Are all 600 locations unmanned?
> Do you personally have to fly out to each location if there
> is a problem?  Is your failure rate so low that none of these
> lcations ever have breakdowns that require someone at the site
> with technical knowledge to get them running again? Come on
> be honest, this is a lame excuse.  $100K and 6 months time
> with an intern would probably take care of it.
>
> I wish you luck - it sounds to me like you are searching for a way to
> force one of the vendors to write some sort of software patch that
> will magically fix the problem.  I don't think that will be
> possible, because I don't think with this kind of problem that
> a software patch can be written to fix it.
>
> Neither of these vendors actually built the ethernet controller
> chips that they are using.  They just buy them from the lowest
> bidder (usually) and they could care less about them as long as
> they work.  And since working is usually defined by plugging it
> into a hub, it is very unlikely a problem like this would
> show up in testing.
>
> These problems are chip-level problems and aren't generally
> solved by code changes.  And unless your a mammoth large
> customer of one of the vendors devices even if a firmware change
> would fix it, it's going to probably break it for everyone else, and
> the vendor is going to drag their feet on doing anything about
> it.
>
> Not to mention that by now both vendors of the offending hardware
> have probably been told by their own engineers that a $50 hub
> will fix the problem, so they know that this problem of yours
> will go away by itself if they just stall you long enough.
>
> With all due respect I think that you have got carried away by
> the fact that you have 600 devices in the field and you
> are starting to think that this is so many devices that the
> vendors are actually going to pay attention to you.  How many
> devices do you think Cisco sells a year?  It must be in the
> hundred thousands.
>
> You might have some leverage if your PLANNING on deploying
> 600 nodes.  But it sounds like you already spent the money
> on both devices and have found out about the problem after
> the fact.  In that case it would be well to remember the Ferengi
> Rule of Acquisition #1.
>
>> We have QoS, jitter/wander control across the whole network
>> path, everything else works but this is a realtime application that
>> needs to be terminated on this specific end device that
>> doesn't seem to
>> behave the way it should. Agreed that if I had the option I would 
>> move
>> on to something else but this is not the case.
>
> You always have the option to move to something else.  What people
> often lack is the money to move to something else.  I presume
> what your really saying is that you don't have the money to
> move to something else.  And pardon me but is this YOUR money?
> I suspect not - so the actual reality is that what your
> really saying is that the people that own
> your company don't have the money to move to something
> else.
>
> Beating a vendor into submission on something like this is going
> to take a long time.  Can you afford 2-3 months of back and
> forth baloney with the vendor?  Remember even if you prove
> with the help of God Himself that one of the devices is not in
> compliance, if the vendor decides it's not worth fixing to
> them, all you can do is sue them, and by the time you will
> get any kind of settlement, it's going to be 2 years from now
> and your competitors will have long since left you in the dust.
>
> So one has to
>> drill down
>> and look into the details.
>>
>
>> I've had my fair share of thicknet, thinnet, arcnet, tokenring issues
>> back in the 80's and 90's, so troubleshooting networks at the
>> PHY level
>> is not really something new to me, it's only been some time since 
>> I've
>> come across a problem with had lack of support but the vendors
>> and lack
>> of visibility as to which of the 2 devices that are interconnected is
>> actually causing the issue (I reckon it's a bit of both which doesn't
>> really help).
>>
>
> Heh.  Well, welcome to my world. :-)
>
> If your getting lack of support from the vendors there's a reason
> for it.  Unless they are total a-holes, and most vendors aren't,
> a vendor will make easy changes to accomodate customers.  The
> ticklish part is when you are trying to make the vendor make
> hard changes.  These changes cost the vendors serious coin, and
> my experience is that most vendors are simply not going to
> spend the money on fixing them, and will instead work up new
> and creative ways to excuse themselves.
>
> Maybe if you could tell us the exact devices involved someone here
> might have run across this already?  Is there some reason that
> these devices so far have remained black boxes?
>
> Ted
>