I had a good question from Jan yesterday after my TechEd session. She posted a comment to my article on SCCM and NAP first thoughts and wanted to know about how you use the Wake On LAN capability when the workstation is powered off (obviously) though is not on the correct VLAN. So I talked to my friend Ashley from Cisco. He told me the following:
"...We support wake-on-lan as an additional feature in 802.1x environments.The IEEE 802.1x authentication with wake-on-LAN (WoL) feature allows dormant PCs to be powered when the switch receives a specific Ethernet frame, known as the magic packet. You can use this feature in environments where administrators need to connect to systems that have been powered down.When a host that uses WoL is attached through an IEEE 802.1x port and the host powers off, the IEEE 802.1x port becomes unauthorized. The port can only receive and send EAPOL packets, and WoL magic packets cannot reach the host. When the PC is powered off, it is not authorized, and the switch port is not opened.When the switch uses IEEE 802.1x authentication with WoL, the switch forwards traffic to unauthorized IEEE 802.1x ports, including magic packets. While the port is unauthorized, the switch continues to block ingress traffic other than EAPOL packets. The host can receive packets but cannot send packets to other devices in the network.Note: If PortFast is not enabled on the port, the port is forced to the bidirectional state.When you configure a port as unidirectional by using the dot1x control-direction in interface configuration command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host.When you configure a port as bidirectional by using the dot1x control-direction both interface configuration command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_guide_chapter09186a008081df0b.html..."
Hope this helps you Jan!! :)
Hey Michael, what software where you using to manage your VM's?
It looked pretty handy.
I was actually using Windows Server Virtualisation (hypervisor) which has its own MMC console. If youre using Virtual Server R2 theres now a decent management tool called VMRCPlus that enhances the management experience of Virtual Server. You can search for that on the download center of Microsoft.com/downloads
Thanks. I am using VMRCPlus at the moment..it's impressive in it's own right.
I'll be patient and wait for WSV to come out in some form. :)
Hi Michael, I work with Jan so I thought I might add a bit of detail to the question. The advice from Cisco really just covers whats in the standard in Appendix B1 at http://standards.ieee.org/getieee802/download/802.1X-2004.pdf
The real problem occurs when you configure the cisco switches to use auth fail vlans, and guest vlans. These are designed to place computers which fail authentication into an administrator designated vlan. The interface command s would be something like this.
switchport access vlan 900
switchport mode access
dot1x pae authenticator
dot1x port-control auto
dot1x control-direction in
dot1x guest-vlan 999
dot1x auth-fail vlan 999
Now when a port has this type of config and the computer is turned off there is a very brief link state transition which causes the port to become unauthenticated. The switch will attempt to start authentication a number of times before timing out and placing the port into the guest vlan.
Now the crux of the problem is this. The SMS records for the computer have an IP address from the authenticated access vlan (900 in the example). The wake on lan packet will never be received by the computer because it is in the unauthenticated vlan.
The obvious solution is to modify the SMS records to reflect an IP address and subnet in the guest vlan as well. I've used a modified version of the example at http://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/ops_64m9.mspx?mfr=true to generate the DDR and this seems to work ok. There is also an option to replace data using the ADDPROP_FULLREPLACE flag.
Does SCCM send wakeup packets to each subnet in the SMS discovery record or just the first? Can SCCM exec a script to update the discovery records prior to executing the wakeup?
Hope that makes our issues a little bit clearer.