Solve this and you're a genious: Port problems with SRW2016

rkoch · ‎03-30-2010

Equipment:

One SRW2016 fresh out of the box and set to factory default settings

One Dell Laptop running Windows XP

One custom network appliance running a full TCP/IP stack but limited to 10M half duplex.

Setup:

The laptop has a static IP address. The network appliance has a static IP address. The switch has the factory default static IP address. All three devices are on the same subnet.

The laptop is plugged into port 1 on the switch, and the network appliance is plugged into various ports as described below. The laptop is set to continuously ping the network appliance using the ping –t command.

Problem:

When the network appliance is plugged into switch port 2 I am unable to ping the device from the laptop. When I plug it into port 3 I get the same result. In fact I am unable to ping the network appliance on any of the switch ports EXCEPT for ports 7, 8, 15, and 16. As soon as I plug the network appliance into any one of those four ports, the pings are replied to.

My question is - why am I unable to communicate with the network appliance on any ports other then ports 7, 8, 15, and 16? What makes these four ports different then the others?

Other Notes:

I have a second Linksys SRW2016 and notice the exact same behavior.

I’ve also tried a Linksys SLM2008 8-Port switch and experience NO communication problems on any ports.

I’ve tried a hub and it works 100%

I notice that after trying to ping the network appliance on a non-working port, I can see the device properly listed in the ARP table on both the switch AND laptop. So I am unable to ping the device yet it somehow makes it into the ARP table.

Any help with this issue would be greatly appreciated.

Best regards,

Rob

Alejandro Gallego · ‎03-31-2010

I should know better than to answer a post with a tittle like this, but I am a sucker..

What makes ports 7,8 and 15,16 different from the rest is those ports are our uplink ports. They are able to handle the most traffic and typically are most likely to respond correctly to "Auto Negotiation" which sounds to me is the main problem on the other ports. Force port speed to match your network appliance and try again.

Hope this helps or I will feel very dumb!

sjmudd · ‎12-06-2010

Hi,

Thanks for explanation that not all ports are the same.

I've just had a similar issue with a Siemens C470IP ip phone. It worked fine with my Dlink 8-port DES3010F switch which I've just replaced with the SRW2016, and also when plugged into my Draytek 2820n ADSL router's LAN ports. I'm a bit disappointed that I happened to plug the device into port 3 and suddenly my monitoring showed that things were not working properly. I checked cables and then remembered that auto-negotiation sometimes can cause problems.

On the SRW2016 if I leave the port with auto-negotiate on I see:

Flow
Port Enable Link Spd/Dpx Ctrl
-----------------------------------

g3 ENABLE UP 10H Off

Yet inspite this pinging the device does not work properly. That is I get from ping:

64 bytes from 192.168.0.36: icmp_seq=431 ttl=128 time=7.357 ms
Request timeout for icmp_seq 432
64 bytes from 192.168.0.36: icmp_seq=433 ttl=128 time=8.956 ms
Request timeout for icmp_seq 434
64 bytes from 192.168.0.36: icmp_seq=435 ttl=128 time=5.920 ms
Request timeout for icmp_seq 436
Request timeout for icmp_seq 437
Request timeout for icmp_seq 438
Request timeout for icmp_seq 439
Request timeout for icmp_seq 440
64 bytes from 192.168.0.36: icmp_seq=441 ttl=128 time=9.242 ms
Request timeout for icmp_seq 442
Request timeout for icmp_seq 443
Request timeout for icmp_seq 444
Request timeout for icmp_seq 445

Doing the explicit configuration of 10Mb Half duplex as suggested does not help either. In fact it's worse as I get no responses from a ping and it does not make any difference if I enable flow control or not.

So must be the Siemens device? Well plugging into port 16 as suggested makes all the difference:

Auto negotiation works and the link comes up and works fine:

That is:

Auto Flow
Port Enable Neg. Spd/Dpx Ctrl
------------------------------------

...

g13      ENABLE   On   Auto    Off
g14      ENABLE   On   Auto    Off
g15      ENABLE   On   Auto    Off
g16      ENABLE   On   Auto    Off

and

Flow
Port Enable Link Spd/Dpx Ctrl
-----------------------------------

...

g14     ENABLE   DOWN -----   ---
g15     ENABLE   DOWN -----   ---
g16     ENABLE   UP    10H     Off

and ping shows what I expect:

64 bytes from 192.168.0.36: icmp_seq=353 ttl=128 time=5.918 ms
64 bytes from 192.168.0.36: icmp_seq=354 ttl=128 time=6.675 ms
64 bytes from 192.168.0.36: icmp_seq=355 ttl=128 time=8.052 ms
64 bytes from 192.168.0.36: icmp_seq=356 ttl=128 time=5.430 ms
64 bytes from 192.168.0.36: icmp_seq=357 ttl=128 time=6.763 ms
64 bytes from 192.168.0.36: icmp_seq=358 ttl=128 time=7.861 ms
64 bytes from 192.168.0.36: icmp_seq=359 ttl=128 time=9.996 ms
64 bytes from 192.168.0.36: icmp_seq=360 ttl=128 time=5.526 ms
64 bytes from 192.168.0.36: icmp_seq=361 ttl=128 time=6.374 ms
64 bytes from 192.168.0.36: icmp_seq=362 ttl=128 time=4.750 ms
64 bytes from 192.168.0.36: icmp_seq=363 ttl=128 time=2.305 ms
64 bytes from 192.168.0.36: icmp_seq=364 ttl=128 time=4.748 ms
64 bytes from 192.168.0.36: icmp_seq=365 ttl=128 time=7.279 ms
64 bytes from 192.168.0.36: icmp_seq=366 ttl=128 time=6.359 ms
64 bytes from 192.168.0.36: icmp_seq=367 ttl=128 time=6.536 ms
64 bytes from 192.168.0.36: icmp_seq=368 ttl=128 time=8.089 ms
64 bytes from 192.168.0.36: icmp_seq=369 ttl=128 time=8.797 ms

So why is this broken? Is it a firmware issue or a hardware issue? The firmware I'm using is I believe the latest though it looks rather old:

Boot Version: 1.0.1 (Date: 11-Jun-2006, Time: 18:43:59)

Software Version: 1.2.2b (Date: 28-Feb-2008, Time: 16:47:37)

Hardware Version: 00.03.00

If this affects me it's likely to affect others and I really wanted to buy the switch to add to the number of "managed ports" I have. This current behaviour is rather disappointing and I would have hoped that perhaps a firmware upgrade would solve this, or the documentation would be clearer that some devices do not work properly (auto-negotiation seems to be rather a troublesome subject). Is such a fix available?

FSTAMM-2011 · ‎11-03-2011

Hi There

I have as well problems with Panasonic IP Phones and the speed negotiation of 3 x SRW2024P Switches, the speed goes down to 3Mbps!!

Any Ideas???

Or is the only way to replace this SRW2024P Switches by the new SG300-24P Series - Any Trade-In possible?

The reseller just changed from Zyxel Switches and now he doesn't think any bether about this Cisco Switches :-(