10 messages in net.nether.puck.cisco-nsp[c-nsp] Network Analyser with n-way s...
FromSent OnAttachments
Thomas KernenJan 13, 2005 8:12 am 
Marty AdkinsJan 13, 2005 9:22 am 
Ignas BagdonasJan 13, 2005 4:28 pm 
Ted MittelstaedtJan 14, 2005 12:52 am 
Gert DoeringJan 14, 2005 3:15 am 
Thomas KernenJan 14, 2005 8:12 am 
Thomas KernenJan 14, 2005 8:12 am 
Thomas KernenJan 14, 2005 8:12 am 
Ted MittelstaedtJan 15, 2005 3:35 am 
Thomas KernenJan 16, 2005 5:10 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] Network Analyser with n-way supportActions...
From:Ted Mittelstaedt (te@toybox.placo.com)
Date:Jan 15, 2005 3:35:32 am
List:net.nether.puck.cisco-nsp

-----Original Message----- From: Thomas Kernen [mailto:tho@ip-man.net] Sent: Friday, January 14, 2005 5:12 AM To: Ted Mittelstaedt; cisc@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