 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
10 messages in net.nether.puck.cisco-nsp[c-nsp] Network Analyser with n-way s...| From | Sent On | Attachments |
|---|---|---|
| Thomas Kernen | Jan 13, 2005 8:12 am | |
| Marty Adkins | Jan 13, 2005 9:22 am | |
| Ignas Bagdonas | Jan 13, 2005 4:28 pm | |
| Ted Mittelstaedt | Jan 14, 2005 12:52 am | |
| Gert Doering | Jan 14, 2005 3:15 am | |
| Thomas Kernen | Jan 14, 2005 8:12 am | |
| Thomas Kernen | Jan 14, 2005 8:12 am | |
| Thomas Kernen | Jan 14, 2005 8:12 am | |
| Ted Mittelstaedt | Jan 15, 2005 3:35 am | |
| Thomas Kernen | Jan 16, 2005 5:10 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread 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 support | Actions... |
|---|---|---|
| From: | Thomas Kernen (tho...@ip-man.net) | |
| Date: | Jan 14, 2005 8:12:45 am | |
| List: | net.nether.puck.cisco-nsp | |
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