-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
fc76dfa
to
73a9b3d
Compare
15c69a1
to
c3ff044
Compare
c3ff044
to
663f854
Compare
doc/wol/Wake-on-LAN-HLD.md
Outdated
|
||
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
doc/wol/Wake-on-LAN-HLD.md
Outdated
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comments!
- Added a
Component
section with some pictures to illustrate that. - Added
CLI unit test plan
to cover these validation.
### Example | ||
|
||
``` | ||
admin@sonic:~$ wol Ethernet10 00:11:22:33:44:55 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
doc/wol/Wake-on-LAN-HLD.md
Outdated
|
||
Below diagram describes a common usage of WoL on SONiC switch, this HLD will focus on the green part: | ||
|
||
![WoL Background](./wol-background.png) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
35c2b86
to
be28f6e
Compare
Community review recording https://zoom.us/rec/share/Cfvbr6CAmItpfgei_yhS1yJIYs5e2qL--G8Vf7rBUfzJg6sV09lt26Sv4ScxWio.B4ytA8vMPsMCxj7M |
wol <interface> <target_mac> [-b] [-p password] [-c count] [-i interval] | ||
``` | ||
|
||
- `interface`: SONiC interface name. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) | | ||
+-----------------------------------------+ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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` | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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,
- Users should have some monitor mechanism to check if the target device is wake up as expected.
- 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.
8b1b68a
to
0ddf495
Compare
0ddf495
to
d48a9de
Compare
@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 |
High-level design for Wake-on-LAN feature in SONiC.
wol
script in sonic-utilitiesSonicWolService
gNOI service