cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2996
Views
0
Helpful
8
Replies

DNA Center and outside WOL

m.maier
Level 1
Level 1

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.

 

  • WOL inside works well [ok]
    DNAC Version 1.3.3.9 and 2.1.2.8
    IOS-XE 16.12.3

 

  • WOL Outside the fabric not [nok]
    DNAC Version 2.1.2.8
    IOS-XE 17.3.4

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:

 

  • DNAC 1.2.5/6 for L2-Broadcast
  • DNAC 2.1.2.4 for directed-Broadcast
  • Edge and Border require ≥ 17.3.1
  • Routers, Nexus 7700 are not supported

 

The following SW and HW is in use in my Lab:

  • DNAC Controller: DNAC 2.1.2.8
  • SD-Access FE: CAT9300, IOS-XE 17.3.4
  • Border Node: CAT9500, IOS-XE 17.3.4
  • Fusion (FSR), not a part of SDA: CAT9500 IOS-XE 17.3.4
  • 802.1x: enabled
  • MCAST Underlay and Overla: active with PIM-SM (underlay) ans ASM into overlay

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:

 

  • Does anyone have experience with WoL outside the Fabric?
  • In which IOS/DNAC version does this work properly?
  • Are any workarounds available?
  • How this works technically with WOL and SDA?

Thank you for your answer.

 

Markus

8 Replies 8

jedolphi
Cisco Employee
Cisco Employee

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

 

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.

Pascal Lacroix
Level 1
Level 1

Hi Markus,

i have the same problem with WoL. Did you received or have a solution for this?

 

regards,

Pascal

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

Heiko Kelling
Level 1
Level 1

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).

 

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

Hi Heiko

The following must be present:

  1. Underlay with MCAST must be enable.
    • In my case is PIM Spare mode is overall enabled also into L3VPN (underlay) WAN to FE
    • RP is configured on CP/B Node as LP
    • An end-to-end MCAST works well
  2. Device Support:
    • DNAC 1.2.5/6 for L2-Broadcast => DNAC 2.2.2.9 or current Version
    • DNAC 2.1.2.4 for directed-broadcast => DNAC 2.2.2.9 or current Version
    • Edge and Border require ‚≥ 17.3.1 => IOS 17.3.4 running on CP/B, IMC, IMB & FE
  3. Define a new Segment only for WoL
    • Best practice:Keep your broadcast segments small – it broadcasts
    • In my case Vlan1048 into VN CORP
  4. WoL implementation
    • WoL outside will be activated on Vlan 1048 with DNA

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

  1. CP/B adaptation (manually)

 

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

 

  1. FE listen ports
  • WoL fabric vlan 1048 (CORP)
  • Operation vlan on every access-port is vlan 1048
  • The Port listen on Vlan 1048
  • Modify the template "DefaultWiredDot1xClosedAuth" with the DNAC template manager and the start a provisioning

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

 

  • Example to verify the port operation status

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

Pascal Lacroix
Level 1
Level 1

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

Review Cisco Networking for a $25 gift card