IOS XE 17.9.3 has been released

[marce1000]

    Ref : https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/release-notes/rn-17-9-9800.html#whats-new-1793
       x700 series  support is  back (feature parity with 17.3). Upgrade directly from >= 17.3.4c possible. Fix for x700 cert issue (CSCwd80290) also included.

 M.

[Scott Fella]

Glad you posted this @marce1000.  I'm pretty sure this will help many out there with older x700's and getting them off the AireOS controllers.

[Wes Schochet]

So I'm not the only one stuck with Wave 1 APs in the ceilings and long lead times on replacements??!!

[Leo Laohoo]

---

@Wes Schochet wrote:
So I'm not the only one stuck with Wave 1 APs in the ceilings and long lead times on replacements??!!

---

1. This is not the first time a decision like this was made and had nothing to do with "long lead times" -- Read between the lines.  (Cisco initially announced that the final software support for the 1140 was 8.0.X.X train but had to make the same decision as now.)
2. Next, look and compare the IOS filename of the IW3700 against the 2700/3700.  Does anyone see any difference?  
3. If 1700/2700/3700 are not supported from 17.4.1 until 17.9.2, then how come the 1700/2700/3700 has CAPWAP files from 17.4.1 until 17.9.2 (filename prefix from JPK until JPN1)?  I mean, I can see download link for 17.10.1!
4. Finally, look at the picture below.  

`nuff said.

[marce1000]

           >...`nuff said.
  How and or what do you mean ?

 M.

[Leo Laohoo]

Look at the screenshot I've posted.  

Look at it very closely.

[Clem58]

Hi Leo,

Looks like you were able to upgrade a 3602 AP with 17.9.3 ?

Are you seeing this AP in the wireless controller ?

[Leo Laohoo]

I can manually upgrade a 2600/3600 to 17.11.1 (CAPWAP & autonomous) but it will never join a WLC because the controller has a list of SKUs to allow "in" but the 2600/3600 is not in it.

The exercise is to prove that the 2600/3600 can support the software but stopping it from joining a 9800 is purely for financial reasons alone.

[Clem58]

Yep I agree, this is part of the "planned obsolescence", to buy new (expensive) access points of course

[Scott Fella]

This is just the cycle that happens when there are new controllers introduced.  It's been like this since autonomous and then AireOS 2005 controllers.  You can't keep supporting old stuff, just makes it hard to develop.  Let's see what happens in 5 years or 10 years, it will be another cycle.  You don't have to buy the new stuff, you can just keep what you have and support that.  There are people out there and companies that sill have the old 1242's, which are still functioning.  

[JPavonM]

Great news and thanks for the heds up @marce1000,.
I was monitoring the release of this new minor release that include a fix for something as critical like the IPTHEFT issue with stale entries that I'm working with BU for the last 3 months, but in this case it's only for the central forwarding case and not the local. Maybe more clients are suffering this and they have not even noticed it.

Testing this in the lab now.

[eglinsky2012]

@JPavonM  - Can you tell us more about that issue? Is it a bug?

[JPavonM]

@eglinsky2012 yes this is a new defect in the code. Devices trying to connect are rejected due to stale entries in C9800 databases where another MAC is associated to the IP address granted to this new device. Check device-tracking db we can see the dupplicated MAC entries assigned to different IPs, and the problem is there is no way to remove them from there. The only workaround is to reboot WLC or move APs to another WLC. I've seen that when it happen it only happen to APs using the same site tag.

Developers have managed to reproduce it and fix it in the central fowarding case, and the fix is included in 17.9.3.

The problem is that for the local forwarding issue it has not been possible to reproduce it, nor I have been able to do it in a lab virtual WLC with all debugs enabled, but it's happening in the physical C9800 in production. Thsi is been covered under CSCwd79502.

To address the local issue, Cisco is introducing some checks and cleans in new 17.12 code to be released in June-July but still working with this to find the trigger, analyse it and fix it.