cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6111
Views
12
Helpful
12
Replies

IOS XE 17.9.3 has been released

marce1000
VIP
VIP

 

    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.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !
12 Replies 12

Scott Fella
Hall of Fame
Hall of Fame

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.

-Scott
*** Please rate helpful posts ***

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


@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.`nuff said.

 

 

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

 M.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !

Look at the screenshot I've posted.  

Look at it very closely.

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 ?

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.

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

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.  

-Scott
*** Please rate helpful posts ***

JPavonM
VIP
VIP

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.

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

JPavonM
VIP
VIP

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: