ā06-04-2022 02:28 AM
I am troubleshooting a WOL issue for into SDA Fabric with the option "WOL outside the fabricā. The WOL inside the fabric works well if the client placed into the SDA fabric and the L2-flooding is active.
This doesn't work.
All adjustments are performed by DNAC.
The documentation is not available on CCO or a Guideline for Wake on LAN and TS.
WoL outside the fabric requires the following:
The following SW and HW is in use in my Lab:
WOL inside the fabric is migrated to outside. Unfortunately, this does not work as desired. The magic packets are not forwarded via multicast to the fabric edge.
The WOL packets are visible on the border node but do not enter the fabric. So, the sleeping hosts cannot be wake up.
brn-gen14-bn-001#show mon cap cap buf dis "ip.addr==10.82.2.102"
Starting the packet display ........ Press Ctrl + Shift + 6 to exit
1248 4.873523 10.82.2.102 b^F^R 10.82.143.13 WOL 148 MagicPacket for b8:ae:ed:78:6f:ca (b8:ae:ed:78:6f:ca)
ICMP check to IP 10.82.143.1
brn-gen14-bn-001# show mon cap cap buf dis "ip.addr==10.82.2.102"
Starting the packet display ........ Press Ctrl + Shift + 6 to exit
2975 11.785563 10.82.2.102 b^F^R 10.82.143.11 ICMP 102 Echo (ping) request id=0x0008, seq=5/1280, ttl=61
5468 21.334234 10.82.143.1 b^F^R 10.82.2.102 ICMP 98 Echo (ping) reply id=0x000a, seq=1/256, ttl=255
5736 22.345624 10.82.143.1 b^F^R 10.82.2.102 ICMP 98 Echo (ping) reply id=0x000a, seq=2/512, ttl=255
DNAC Host Onboarding settings:
1. Wake on Lan is enabled "Yes"
2. Closed Mode is active with 802.1x
More details are also available in the appendix.
From a network perspective it all looks to be fine, anyone have any suggestions?
I like to ask some questions to the community before opening a TAC.
My questions are as follows:
Thank you for your answer.
Markus
ā06-05-2022 05:29 PM
Hi Markus, should be working. A few ideas:
1. Is ASM underlay setup properly? RP should be programmed in FE GRT, PIM neighbors should be in FE GRT. Does other broadcast (not WOL) flood over VXLAN and out FE access ports?
2. Are you sure the magic packet is not flooded from BN to FE? You can PCAP ingress on FE routed uplinks. When inspecting the PCAP flooded packets will of course be encapsulated on VXLAN.
3. The WOL packet will be flooded in the destination VLAN. Is the access port your "sleeping device" connected to the correct access VLAN? It's not unusual for access port authorization to time out and when it does the port will revert back to VLAN 1. This means magic packet will never egress the FE access port. There is some workarounds for this scenario I can share later if it's applicable to your setup.
WOL is explained here if you have partner level access: https://salesconnect.cisco.com/open.html?c=81dad75a-233b-49e3-91e4-16c0d9009267
Regards, Jerome
ā08-12-2022 12:53 AM
Update 2022-08-12:
Answer to the questions 1-3:
[1] Multicast is active in the underlay and overlay. PIM sparse mode is active in the underlay and PIM is implemented on all nodes (GRT global and FE). ASM is active into VN CORP, see also the document "SDA-WOL-TS.pdf.
Log data underlay:
brn-gen14-en-050#sh ip pim neighbor | i 10
10.82.140.12 TenGigabitEthernet1/1/1 21w0d/00:01:27 v2 1 / S P G
See also the log: LOGDATA-FE-WOL-001.txt.
[2] Yes, the magic packets reach the CP/B node but the encapsulated in VXLAN didn't work. Debugging for analysis was unsuccessfully. The encapsulated in VXLAN could not be recognized on CP/B Node. The CP/B node receives the packets, but nothing happens on the FE.
How WoL outside the fabric works is not clear.
How are the magic packets forwarded into the fabric and what is the best way to debug this on the CP/B and FE node.
See also the log: LOGDATA-CP-B-WOL-001.txt
[3] In generally the silent host cannot be wake up with Magic packets (WoL). The Wol packets do not reach the FE (Vlan 1 or CORP Vlan)
The NAC mode "closed mode" is running on SDA Edge w/o critical or any Access vlan on template.
NAC "close mode" template w/o vlan 1036 for outside the fabric. In past was the Vlan 1036 configured for the WoL WA (inside the fabric).
Only Vlan 1 is running
template DefaultWiredDot1xClosedAuth
dot1x pae authenticator
dot1x timeout supp-timeout 2
dot1x max-req 3
switchport mode access
switchport voice vlan 2046
mab
access-session control-direction in
access-session closed
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
See also the log: LOGDATA-FE-WOL-002.txt.
The workaround for the WoL inside the fabric has been removed from template. Only the native vlan 1 is running.
NAC "close mode" template with vlan 1036 for inside the fabric. This works well but is not the final solution.
Example with inside the fabric ā Access vlan 1036
brn-gen14-en-050#show run all | se template DefaultWiredDot1xClosedAuth
template DefaultWiredDot1xClosedAuth
dot1x pae authenticator
dot1x timeout supp-timeout 7
dot1x max-req 3
switchport access vlan 1036
switchport mode access
switchport voice vlan 2046
mab radius
access-session host-mode multi-auth
access-session control-direction both
access-session closed
access-session port-control auto
no access-session interface-template sticky
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
hold-queue 0 in
hold-queue 0 out
load-interval 300
carrier-delay 0
source template DefaultWiredDot1xClosedAuth
Note: The template isn't longer active with the vlan 1036
The following questions are available:
- On which segment should direct broadcast be activated (CORP Vlan, Dedicated vlan for Wol like 1036)
- Must the template "DefaultWiredDot1xClosedAuth" be modify with a WoL Vlan like 1036 (per default vlan 1 active)
- Is a Cisco guideline for WoL outside the fabric available with any input like requirements, limitations, restrictions, debugging hints and a configuration guide.
ā04-04-2023 04:41 AM
Hi Markus,
i have the same problem with WoL. Did you received or have a solution for this?
regards,
Pascal
ā04-05-2023 11:31 PM
Hi Pascel
In my case this was a bug SCvo49242 available. On the path towards the Border Node, the following must be activated for the WoL outside the fabric.
WoL Outside the Fabric Issue "ip network-broadcast".
Workaround: Configure "ip network-broadcast" on the ingress interface where the directed broadcast is to be received
PMO network (WoL Source) -> Fusion -> CP-B (CORP VN - Segment WoL) - SDA-Fabric
Between Fusion and CP/B must configure "ip network-broadcast".
Note: Keep your broadcast segments small ā it broadcasts (Only SDA-Vlan xx with a C-Class or higher)
interface xxx
!-- Interface form CP/B to FSR into VRF CORP
ip network-broadcast
!
interface Vlanxxxx
ip directed-broadcast 199
!
ip access-list extended 199
10 remark *** WOL - Outside ***
10 permit udp host <WOL-SRV> any eq discard
Modify the "DefaultWiredDot1xClosedAuth" with the WoL SDA Vlan for any FE node
!
template DefaultWiredDot1xClosedAuth
switchport access vlan xxxx
And set "access-session control-direction in" for any Access-Ports.
interface Gix/0/x
access-session control-direction in
Generally the MCAST must be enabled into underlay network for WoL.
Markus
ā08-03-2023 06:46 AM
Hello Markus and Pascal,
we have almost the same infrastructure as Markus with exactly the same problem. But Markus' solution didn't work for us. We see the packets coming to the CP/B. This can be verified via capture, but afterwards they arrive neither at the distribution router nor at the correct edge node where the client (in our case an Igel thin client) is connected.
For the test, we also initially deactivated the entire authentication on the port and also did not restrict the directed broadcast via an ACL, so that this can be ruled out as a source of failure. Does anyone have any advice on what to consider between CP/B and WoL Client (IP-Directed Broadcast and Multicast are activated).
ā08-03-2023 07:01 PM
There's a range of reasons why it might not work so I'd suggest a TAC case please, that will be much quick than a back-and-forth here. Often (not always) the root cause can be no end-to-end ASM signalling and forwarding in the SD-Access underlay. IPDB requires Layer 2 Flooding which in turn requires ASM in the SD-Access underlay. Regards, Jerome
ā08-04-2023 12:39 AM
Hi Heiko
The following must be present:
Step 1: enable ip directed-broadcast on your Server Gateway
Step 2: enable L2-Flooding for the segment
Step 3: enable IP directed broadcast ā VN LAN & CP/B Nod
interface HundredGigE1/0/xx.x
!-- Interface form CP/B to FSR into VRF CORP
ip network-broadcast
no autostate
!
interface Vlan1048
ip directed-broadcast 199
!
ip access-list extended 199
10 remark *** WOL - Outside ***
10 permit udp host <WOL-SRV> any eq discard
template DefaultWiredDot1xClosedAuth
dot1x pae authenticator
dot1x timeout supp-timeout 7
dot1x max-req 3
switchport access vlan 1048
switchport mode access
switchport voice vlan 2046
mab
access-session control-direction in
access-session closed
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
sh platform authentication sbinfo interface GigabitEthernet 1/0/1 | i Port|Control|Access
If that's how it's done, then it should work.
If not, then please to be clarified with the TAC.
Markus
ā08-25-2023 05:11 AM
Hi all,
we have solved the WOL issue by adding the WOL vlan to all the access interface instead of using vlan1. Just as Markus described above.
We had also a call with Cisco for this issue and Cisco is going to discuss internally how this WOL issue can be fixed without adding a specific vlan to an access interface.
regards,
Pascal
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide