cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5039
Views
8
Helpful
6
Replies

17.9.x clients failing to join due to VLAN failure - fix

p.lan
Level 1
Level 1

Wanted to post this in case anyone else has a similar issue.. took us a week of troubleshooting.

After upgrading from 17.3.5b to 17.9.3, clients are failing to join wireless if they leave one policy profile and join later on another one. 

shown in logs/DNAC: "f8ff.c25f.0ac2 exclude_reason: VLAN failure". 

Circumstances: You have SVIs on client VLANs (perhaps for mDNS like we had)

This was NOT due to AAA override issues or the VLAN missing from the WLC, but was actually caused by the client ARP'ing out with its old IP address onto the new VLAN that (naturally) had a different IP network configured on the SVI for that VLAN, on the WLC.

Example: Client is successfully joined to VLAN A via Policy Profile A. Client closes their laptop and takes it to another building, perhaps 20min away. Client is no longer in the device-tracking database, and has idle-timed out successfully as you'd expect. Client laptop opens and tries to connect at Building B, to VLAN B via Policy Profile B. The client ARPs out with its old IP on VLAN A, because the DHCP lease is still valid from its old VLAN A IP. 

The WLC sees that this IP does not match the IP network on the SVI for VLAN B, and excludes the client.

Solution: Delete the client VLAN SVI.

For us, this was easy because 17.9 no longer requires SVI IPs for mDNS purposes. 

 

Debugs that pointed me towards this: 

(note): MAC: f8ff.c25f.0ac2 Client IP learn successful. Method: ARP IP: 10.10.79.250 <-- This is the old IP, from VLAN A.

Retrieve VLAN for client IP address 10.10.79.250 

(debug): Client IP is not in subnet of Vlan: 2712, ret 2 <-- This is the new VLAN, VLAN B. 

[client-iplearn] [23278]: (note): MAC: f8ff.c25f.0ac2 IPLearn static ip : client vlan not resolved and static ip mobility disabled. Exclude the client

 

By removing the SVI off the client VLAN, you remove the logic in the WLC that it must check for the client's IP against the IP network configured on the SVI for that resultant VLAN. When the SVI is gone, the WLC just drops the client onto the new VLAN as you'd expect and all is well.

6 Replies 6

Thank you for outlining issue and solution as well.

Luke Jenkins
Level 4
Level 4

If anyone else hits this, just shutting the SVIs isn't enough. I had to actually remove them from the config of the WLC and then mobility anchoring worked.

Michael Voity
Level 5
Level 5

Thank you for posting this.   Solved a bunch of problems.

Ethan Grinnell
Level 1
Level 1

Another solution is to enable DHCP required. I'm unsure of why it makes a difference, but that's the one I went with. Seems to do the trick. I'm surprised that there aren't more complaints of this issue.

JPavonM
VIP
VIP

The problem with enabling DHCP required is that devices roaming between APs are not granted to forward traffic until a full DHCP conversation happen (DORA) between client and server on the new AP.

True, but with some configurations you need the the SVI. Not many though, it's a corner case, but it does fix the issue.

Review Cisco Networking for a $25 gift card