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

[Thomas Kernen]

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

>
> I also have the same problem with a router/PC running an Intel
> Etherexpress Pro 100 plugged into a horribly expensive switch
> at a colo site.  The colo vendor normally hard-codes the 
> autonegotiation
> on this switch to 100/Full, because they say that autonegotiation
> is unreliable.  My gear loses about 2% of the packets when they
> do this no matter how I have my side set.  When they set to
> autonegotiation on their side (after lecturing me on how doing
> this is a Bad Thing) and I set to autonegotiation, the packet loss
> goes away.  However the downside is about 1 in 10 reboots, their
> port goes to a funny state and stops talking.  I can kick it by
> a quick set of the port on my side to 10base/half, then back to
> auto.

Our problem is we are running realtime video applications across these 
links so 0% loss is what is expected. Since we can't change the end 
devices, we need to understand which of the two devices is not working 
properly. There is a lack of visibility at the fast link pulses level 
and this is how deep we are having to investigate.
>>
>
> You are way overengineering this.  Accept the fact that Ethernet
> isn't a particularly good kind of interconnect to use in between
> network devices and the reason it's used is because it's cheap,
> buy a switch, and move on.

I appreciate the input and comment but this is purely a vendor 
interoperability issue, one end is a L2 switch and the other is an end 
device. 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. So one has to drill down 
and look into the details.

>
> I would also venture a guess that your a young guy.  Old timers
> that dealt with Ethernet years ago had these problems all of the
> time and have many stories to tell.  You haven't lived until you've
> debugged a thinnet network.

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

Thanks for the input
Thomas