I have just got VMPS working on our network, and I now find that Wake-on-LAN no longer works. I guess, if I think about it, that should have been obvious. When the PC gets switched off, it bumps the port, and so loses its VLAN membership. It's a pity, 'cos our PC support team rely quite heavily on WoL. Does anyone know any way round it? Is there any way of telling the switch "if you have not seen a MAC address yet, you should stick to the default VLAN rather than being VLAN-less."?
I'm not sure, I'll have to try it. The problem is essentially that when the machine shuts down, it bumps the LAN connection, so the port loses its VLAN membership. If hibernating does not bump the port in this way, then it could work. I'll try it when I get time, but a bit busy on other things at the moment.
We have a similar situation here. We run VMPS across our entire campus with 3 6513 core switches, and 3550 and 1900EN edge switches. We have a bunch of lecture hall machines that the person in charge of would like to use WOL to turn them all on in the middle of the night and reblast ghost images to them. He has had marginal success in making this work, I think he said about 50% of the time it will work. I've been testing WOL out in our test lab with 3550 switches and haven't been able to get it to work at all. Has anyone had any sort of success in getting this to work? I've seen the posts on using ACL's to limit the redirected broadcast, but all of our machines are in the same VLAN/subnet which shouldn't be a problem. Even putting the switch ports to a static membership doesn't help at all. Anyone experience similar issues?
Greg, I think your situation is probably a bit different. In my case, the issue really is VPMS. If I don't run VPMS, then the WoL works fine. For that reason, I have held back the deployment of VPMS. We did find that WoL is quite sensitive, but once we had experience with it, it worked OK.
The most obvious requirement is that the BIOS of the target machine must be set up to "suspend" in the right way,a dn to listen for the WoL frames. Are you sure your target machines support WoL?
The next obvious requirement is that the target machine must be in the same VLAN as the management machine generating the WoL frames. WoL won't work through a router! But you say you have a flat VLAN, so this cannot be the problem.
Thirdly, and this may seem an odd think to say, don't expect to wake up a machine unless is went to sleep connected to the LAN. If your ports are autonegotiating, then the autonegotiation needs to take place to set up the port. If you connect an already suspended machine to the LAN, then the port will not have been negotiated correctly, and you may not be able to wake it up. Same, or course, if you simply connect the PC and apply power without switching it on.
Check the port status on the switches shows "connected", I use CatOS, so the behahiour in my situation may be different from yours, which are all IOS, aren't they? Maybe that difference has some bearing on the problem.
That's is for the moment. Good luck, and post to let us know how you get on ... feedback, negative or positive, is always useful.
I am assuming your problem is with machines that have mac addresses not added to the vmps database yet. You must identify a fallback vlan (a vlan to assign a port to if it is not identified in the vmps-mac-addrs table). To do this, add the following line to your vmps database:
Follow the following link for details.
No, that's not the problem. The problem is that when the PCs go to sleep, they bump the switch port (offline-online for about a second). The port then loses its VLAN membership, and of course does not regain it until the PC next generates a MAC frame. But the PC is asleep so it cannot generate a frame.
Seems that we've the same problem. I wonder if it can be solved because no Cisco engineer has responded to this problem. Maybe if other Cisco-users whith the same problem respond it comes more attractive to Cisco to come with a workaround.
I'm listening on several newsgroups now for a solution and asked our supplier to look for it.
If I get a promising answer I'll let you know.
I gave up in the end. WoL was too valuable on this site, and the requirement for host mobility was to weak for now.
Instead, I have trained my team to reconfigure the port VLAN by hand each time a user wants to use the teleconferencing VLAN.
Good luck, and if you get any reply, post it here so we can all see it.