Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High-level design for Wake-on-LAN feature in SONiC #1508

Merged
merged 4 commits into from
Nov 9, 2023

Conversation

lizhijianrd
Copy link
Contributor

@lizhijianrd lizhijianrd commented Oct 31, 2023

High-level design for Wake-on-LAN feature in SONiC.

Description Repo PR title State
Add wol script in sonic-utilities sonic-utilities sonic-net/sonic-utilities#3048 Merged
Implement SonicWolService gNOI service sonic-gnmi Todo

@lizhijianrd lizhijianrd force-pushed the wake-on-lan-hld branch 2 times, most recently from 15c69a1 to c3ff044 Compare November 6, 2023 03:25

The `wol` command is used to send magic packet to target device.

This command requires root privilege because it'll modify the power-mode of target device.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SONiC device just need to send the magic packet to target device(s), right? not sure why we need root privilege at the SONiC device for command execution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, SONiC device just send the magic packet. As the doc mentioned, the magic packet will modify the power-mode of the target device, so it's considered as an OPERATION command and requires root.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for point this out, I think we can remove this root privilege requirement since SONiC only need to send a packet. I've update the doc.

admin@sonic:~$ wol Ethernet10 00:11:22:33:44:55
admin@sonic:~$ wol Ethernet10 00:11:22:33:44:55 -b
admin@sonic:~$ wol Vlan1000 00:11:22:33:44:55 -p 00:22:44:66:88:aa
admin@sonic:~$ wol Vlan1000 00:11:22:33:44:55 -p 192.168.1.1 -c 3 -i 2000
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which module is building the Magic packet for SONiC CLI and gNOI interfaces?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, capture the validations e.g interface not present, down, socket errors..etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your comments!

  1. Added a Component section with some pictures to illustrate that.
  2. Added CLI unit test plan to cover these validation.

### Example

```
admin@sonic:~$ wol Ethernet10 00:11:22:33:44:55
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These commands need to be executed in root mode.
Please update the example accordingly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your comment! After consideration, we removed the root privilege requirement.


Below diagram describes a common usage of WoL on SONiC switch, this HLD will focus on the green part:

![WoL Background](./wol-background.png)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please expand SONIC Switch in the diagram and explain the components involved in generating the Magic Packet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I added a Component section with some pictures to illustrate that.

@zhangyanzhao
Copy link
Collaborator

wol <interface> <target_mac> [-b] [-p password] [-c count] [-i interval]
```

- `interface`: SONiC interface name.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are PortChannel intfs supported apart from Ethernet and Vlan?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, PortChannel will be supported.

20 | Target MAC (repeat 16 times, 96 bytes) | PAYLOAD
+-----------------------------------------+
116 | Password (optional, 4 or 6 bytes) |
+-----------------------------------------+
Copy link
Collaborator

@venkatmahalingam venkatmahalingam Nov 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wake on LAN - IP packet (UDP dest port -9) is not a requirement?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wol utility will construct and send an Ethernet frame. It doesn't require the packet is an IP packet.

| :- | :- |
| Input a valid SONiC interface name. | Parameter validation pass, send magic packet |
| Input an invalid SONiC interface name. | Parameter validation Fail |
| Input a valid SONiC interface name, but the interface status is not `up`. | Return `Error: interface not up` |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in the community-meeting, this error can be thrown only when the input interface is ethernet-interface by validating the interface-status as UP.

If the input interface is VLAN, then actual host can be connected on any of the VLAN-member-ports and that actual target-device connected interface status can be down at that point. But since the VLAN-interface-status can be up, user will not see any error and user might think actual target device is woken up successfully, but in reality due to transient actual interface-status down/up flap, magic-pkt might not have reached target-host.

In this case, user initiating this cmd might not be aware they have to retry this cmd again to wake up the target-host again. May be, we can consider throwing warning, if any of the VLAN-member interface-status is down at the time of issuing this cmd and then it's upto the user to fix interface-status and reissue the cmd again.

It's better to explain, how this situation can be handled in HLD.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rathnasabapathyv, thanks for your question. After consideration, I think if users input VLAN as the interface, then the wol utility will only ensure the packet is delivered to target VLAN, but not guarantee to reach each physical interface. So,

  1. Users should have some monitor mechanism to check if the target device is wake up as expected.
  2. If users want to ensure the magic-packet be sent out from a physical interface, they should specify the physical interface name instead of vlan name as the wol CLI parameter.

@zhangyanzhao zhangyanzhao merged commit e2d910b into sonic-net:master Nov 9, 2023
1 check passed
@lizhijianrd lizhijianrd deleted the wake-on-lan-hld branch November 10, 2023 17:10
@skg-net
Copy link
Member

skg-net commented Jan 31, 2024

@lizhijianrd Can you please update the Quality Metric (Alpha/Beta/GA) for the feature either in this PR comments or in HLD itself based on https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants