Wired Intelligent Edge

Hi all,

Re. Procurve, 802.1x and Wake on Lan

I am presented with a problem which I believe may be due to the limitations of the software on current ProCurve switches.

I am in the process of implimenting 802.1x EAP-TLS machine certificate port security across our site, however the issue of Wake on Lan (WoL) support has arisen.

With a Cisco switching solution I know that the two technologies can interoperate hapily, but from research and testing, I do not believe that the ProCurve solution currently supports this configuration.

The issue is that when a client device goes to sleep or is powered off, the 802.1x switch port changes to the 'unauthenticated' state, meaning that traffic other than EAPOL messages in both directions are blocked; thus the WoL packet cannot reach the host to wake it up.

Cisco compensate for this with the following, to allow both technologies to work together:

"Using IEEE 802.1x with Wake-on-LAN
-----------------------------------

The IEEE 802.1x wake-on-LAN (WoL) feature allows dormant PCs to be powered on based on the receipt of a specific Ethernet frame, known as the magic packet. The wake-on-LAN feature is used in environments where administrators need to connect to systems that have been powered down.

The use of WoL with hosts attached through IEEE 802.1x ports presents a unique problem: when the host powers down, the IEEE 802.1x port becomes unauthorized. In this state, the port allows only the receipt and transmission of EAPOL packets Therefore, WoL magic packets cannot reach the host. Without powering up, the PC is not authenticated and the port is not opened.

The IEEE 802.1x with WoL feature solves this problem by allowing packets to be sent to unauthorized IEEE 802.1x ports. This feature is also known as the Unidirectional Controlled Port in the IEEE 802.1x specification.

If PortFast is not enabled on the port, the port is forced to a bidirectional state.

Unidirectional State
--------------------

When you configure a port as a unidirectional port by using the dot1x control-direction in interface configuration command, the port changes to the spanning-tree forwarding state.

When WoL is enabled, the connected host is in the sleeping mode or power-down state, and the host does not exchange traffic with other devices in the network. If the host connected to the unidirectional port that cannot send traffic to the network, the host can only receive traffic from other devices in the network. If the unidirectional port receives incoming traffic, the port returns to the bidirectional (default) state, and the spanning-tree state is moved to blocking state. When the port changes to the initialize state, no traffic other than EAPOL packet is allowed. When the port returns to the bidirectional state, the switch starts a 5-minute timer. If the port is not authenticated before the timer expires, the port becomes a unidirectional port.

Bidirectional State
-------------------

When you configure a port as a bidirectional port by using the dot1x control-direction both interface configuration command, the port is access-controlled in both directions. In this state, the switch port does not receive or send packets."


Does anyone have any experience with this setup or know if it is possible to achieve it with ProCurve kit?

Many thanks in advance,

Tom Ranson
IT Network Engineer

Yes, this is possible.

The "aaa port-access controlled-direction in" command allows Wake-on-LAN traffic to be transmitted.

Hi Matt,

From reasearch I conducted that command only appears to be available in the latest 5400 (and 3500) series software. We use 2500, 2600, 2800, 4100, 5300 and 5400 series devices.

I can confirm first hand that the latest software for the above devices (excluding the 5400) do not have that command option available - this is not the first occasion that a relatively 'minor' software sub-feature (i.e. a sub-feature of 802.1x (all other devices mentioed above support 802.1x port-access in general) has been implimented on one series of device, but neglected from all other series.

Whats your take on this?

Kind regards,

Tom Ranson

Try: aaa port-access ethernet 1-48 controlled-direction in

That is valid according to one of my 2848s (I10.32)

I stand corrected:

2500 F.05.61 - NO SUPPORT.
2600 H.10.38 - YES.
2800 I.10.32 - YES.
2810 N.11.02 - YES.
4100 G.07.104 - NO SUPPORT.
5300 E.10.67 - YES.
5400 K.12.14 - YES.

The problem is, the 2500 and 4100 series make up a significent proportion of our edge-ports. This lack of support for certain minor features seems to be prolific across the ProCurve range in a number of other areas...

Controlled-direction is a relatively new feature, and although the 4100 and 2500 are still out there they're starting to get on a bit. (Both came out around 2000/2001).

Maybe there's a hardware resource limitation that prevents it being implemented on them.

Keep in mind that they are the only switches remaining which support port-based 802.1x only. The rest have moved to client-based (per mac-address). Possibly controlled-directions is linked into this new client-based code and due to resource issues it may not be possible.

Also there does come a time when switches just stop getting enhancements. If you look at all the free enhancements these switches have had since they've been released it's very impressive.

Anyway I'm completely speculating here as to the reasons.

What you could do with these switches instead of using controlled-directions, would be to use the Open-VLAN feature. Have an unauthenticated VLAN which the clients are put into, and then on your core switch create an ACL that denies all incoming traffic on that VLAN. Outgoing WoL packets will still be able to go out to this unauthenticated VLAN to wake up machines.

If you want to try and see if controlled-directions can be added to these switches, you should find a ProCurve sales rep and ask if they can try to raise a special request for it.

Hi Matt,

I'm now furthing discussions with an HP ProCurve engineer I have contact with.

I have tested the 'controlled directions' feature with a 5300 running E.10.67 and have found that the feature doesn't work- even though the switch accepts the change from 'both' to 'in' within the running config, the output of:

sh port-access authenticator C24 config

Port Access Authenticator Configuration

Port-access authenticator activated [No] : Yes

| Re-auth Access Max Quiet TX Supplicant Server Cntrl
Port | Period Control Reqs Period Timeout Timeout Timeout Dir
---- + ------- -------- ----- ------- -------- ---------- -------- -----
C24 | No Auto 2 5 30 30 30 both

Still reports Control Direction as 'both' rather than 'in'. Having tested this with a client, I can confirm that the feature does not permit WoL packets to reach clients in an unauthenticated state. I assume that this is a bug, which I have reported.

I take on board what you're saying about 2500 and 4100 switches being older models (consequently older, lower-spec hardware) and understand that the 4100 will no longer be 'supported' from October 2007. As you can understand, a significent purchase was made initially for these devices (inc. the 2500's) and we want to extend their operational lifetime as much as possible.

Hi Tom,

Maybe this is relevant?:

Prerequisite. As documented in the IEEE 802.1X standard, the disabling of incoming traffic and
transmission of outgoing traffic on an 802.1X-aware egress port in an unauthenticated state (using
the aaa port-access controlled-directions in command) is supported only if:
â   The port is configured as an edge port in the network using the spanning-tree edge-port
command.
â   The 802.1s Multiple Spanning Tree Protocol (MSTP) or 802.1w Rapid Spanning Tree Protocol
(RSTP) is enabled on the switch. MSTP and RSTP improve resource utilization while
maintaining a loop-free network.

Matt

I did pick up on those prerequsites and have ensured they are implimented.

On the upside, a reboot appears to have kicked the switch into reporting the 'controlled direction' = 'in' for a port (when doing a "sh port-access authent 'port' config") - I'm off to test it now to see if it actually works.

Really not happy about it requiring a reboot to report it correctly though; very odd and not acceptable for kit of this level.

I tried it not that long ago on E.10.61 and it didn't require a reboot. I'm wondering if it's the order the commands are executed in.

Maybe disable 802.1x with the 'no port-access authenticator active', then add the controlled directions, then re-activate it.

Hi Matt,

That was the first thing I tried before getting to deep into this. Unfortunately, it was a no go.

I'm waiting on an HP Engineer for a definitive answer and will post as soon as I've heard.

Tom

Okay I think I know what's happening here. I was able to reproduce this problem, but it only appears to happen if you do not have a link on that port. As soon as get a link, it will then show it as 'in'.

Seems like a minor cosmetic bug.

Hi Matt,

I would like to be able to agree, however prior to the switch reboot, WoL packets were not reaching the client while the 802.1x port was in an unauthenticated state. Post reboot, all works as expected and SLI output is reported correctly.

Kind regards,

Tom

Hi Matt,

I would like to be able to agree, however prior to the switch reboot, WoL packets were not reaching the client while the 802.1x port was in an unauthenticated state. Post reboot, all works as expected and CLI output is reported correctly.

Kind regards,

Tom

HI Tom,

i am using  printer machine  with Hp procurve switches, i am getting problem ,

Description

I configure machine with 802.1x authentication, with 100 mbps LAN speed, after my work done i put my machine in deep sleep mode,when i wake up my machine it not authenticate 802.1x, after few mins i remove the lan cabel and switch it again it start working.
my question is while it came from wake to normal mode, why it not authenticate ?

note : in deep sleep mode speed is 10 Mbps.

waiting your reply, plz help me on that.

regards,

biswa