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

[Ted Mittelstaedt]

> -----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