Odd solution to MVP problems

[src666]

I bought an MVP a while back that came misconfigured (it was wired, but thought it was wireless), and when I got the replacement it would not see the network no matter what. I tried different ports on my switch, different cables, etc. I just couldn't get it to grab an address. I gave up on it until yesterday. I was just about to throw it out, but when I tried it one last time it worked.

The only difference is that I instead of being wired directly to my main switch (Cisco 2800), it was hooked to a small 7 port local switch. For some reason, it doesn't play well with the Cisco, but likes the little D-Link just fine.

Just a lesson for us all - sometimes the oddest solution will be the correct one.

[AndyS]

Originally Posted by src666

I bought an MVP a while back that came misconfigured (it was wired, but thought it was wireless), and when I got the replacement it would not see the network no matter what. I tried different ports on my switch, different cables, etc. I just couldn't get it to grab an address. I gave up on it until yesterday. I was just about to throw it out, but when I tried it one last time it worked.

The only difference is that I instead of being wired directly to my main switch (Cisco 2800), it was hooked to a small 7 port local switch. For some reason, it doesn't play well with the Cisco, but likes the little D-Link just fine.

Just a lesson for us all - sometimes the oddest solution will be the correct one.

Do you have portfast on? Try issuing "spanning-tree portfast default" (but disable it on any trunk ports you might have). That may well take care of the problem.

Andy.

[mdnttoker]

Originally Posted by AndyS

Do you have portfast on? Try issuing "spanning-tree portfast default" (but disable it on any trunk ports you might have). That may well take care of the problem.

Andy.

Just out of curiousity what's the reasoning behind this little fix?

[AndyS]

Originally Posted by mdnttoker

Just out of curiousity what's the reasoning behind this little fix?

Spanning-Tree is a protocol that prevents loops while allowing redundancy. When a switch port is activated, by default Spanning-Tree (STP) checks the link to see what's at the other end (ie if the link is a trunk or if there's another switch at the other side of the link). This process takes a few seconds. The default behaviour (for link-safety reasons) is for spanning-tree to do this. Here's a description of spanning-tree.

PortFast tells the switch that the port is connected to an end-device rather than another network device, and not to do this discovery. It makes the connection available to the end-device much faster.

You'll see this misconfigured in many shops (where people install managed switches without changing any of the defaults). The effect is that it takes longer for the PC to be available on the network, as the DHCP process cannot begin until the link is available (which doesn't happen until STP has finished discovery).

This is of course a simplification of the process. The real process involves a number of port states. Hopefully it gives you an idea though.

In this case, I'm wondering if the DHCP process is timing out during STP discovery. The command enables portfast on all ports which can do no harm in a residential installation.

Andy.