WLC 9800 - ignoring client - [rogue-core]

[forman_102]

Hello,

I've got question related to this particular debug entries (from radioactive trace):

2024/04/18 13:06:43.944436 {rogued_R0-0}{1}: [rogue-capwap] [25943]: (debug): Client info (2/2), MAC:<xxxxxx>, reported by yyyyyyy, GW: 111111111, chan:40, rssi:-85, snr: 4, ipv4: 0.0.0.0 , ipv6:0000:0000:0000:0000:0000:0000:0000:0000 , BSSID:zzzzzzzz
2024/04/18 13:06:43.944439 {rogued_R0-0}{1}: [rogue-core] [25943]: (info): ignoring client <xxxxxx>, of INTERNAL AP <zzzzzzz>

I have Cisco 9800 L-C running 17.6.4 with C9105AXI-E in Flexconnect mode.

I had to deploy additional SSID with PSK and found the group of users, who are unable to connect. It turned out they were using local 5G Wifi router, which my Cisco 9800 classified as rogue along with clients connected to it.

I classified the 5G Wifi router as friendly and asked the users to re-test, but to no avail. Even when they turned off the 5G Wifi router, all I see is the above-mentioned logs and the users are unable to connect.

Any idea what maybe causing this? Bug?

Thank you,

lucas

[marce1000]

 - That's  a tough one , note that you can have full Radio Active traces processed with : Wireless Debug Analyzer 
    for high level analysis
    In general I would say have a try with 17.9.5  (current advisory) because 17.6.x is getting older

   Also have a checkup of the 9800 WLC configuration with the CLI command show tech wireless and feed the output to : Wireless Config Analyzer
                            Probably no direct related results but always informative , 

 M.

    

[Rich R]

What client devices are those users using?
If Windows what WiFi adapter and driver version?
As Marce said best to update software as per TAC recommended link below, but also essential to make sure client OS and network drivers are fully up to date.
For Intel on Windows: https://www.intel.com/content/www/us/en/download/19351/intel-wireless-wi-fi-drivers-for-windows-10-and-windows-11.html

[sroic]

Hi @forman_102 ,

did you managed to find any solution to it? I'm getting similar "Reported rogue client" messages in my radioactive trace but don't understand why would they be classified as rogues? 

[Rich R]

Hi @sroic have you updated your software as per TAC recommended link below? (there are a number of rogue classification bugs which have been fixed)
Use radioactive trace for an affected MAC address to get detailed analysis of why the WLC is classifying the client as rogue.

[forman_102]

Hi @sroic 

WLC is using IP to MAC address binding as a security measure. In my case this is exactly what happened:

In FlexConnect local switching scenarios, where clients from the different sites may share the same address range, there is a possibility of multiple clients being allocated or registered with the same IP address. The controller receives IP address information from the AP, and if more than one client attempts to use the same IP address, the controller discards the last device trying to register an already-used address as an IP theft event, potentially resulting in client exclusion.

Funny part is, that I have disabled IP learning, but it wouldn't help. Still the clients were classified as rogues. There are separate conversations about this feature being buggy... so finally I had to reconfigure one of the overlapping subnets , which resolved the issue. 

You may want to verify this:

1. on your WLC run: show wireless device-tracking database mac

This will display MAC to IP DB and also associated VLAN

2. Verify if there is another client with the same IP address. This can happen if you are using the same IP subnet in multiple locations or due to DHCP misconfiguration or if someone "accidently" statically configure IP address on the client.

3. Assuming the above is true, you can try to disable IP-MAC binding (https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/config-guide/b_wl_17_3_cg/m_disable-ip-learn-in-flexconnect-mode.html) or reconfigure your subnets to remove the overlap.

Of course, other recommendations are also valid... I mean upgrading the soft to recommended version etc.

On a side note... from personal experience, it seems that Cisco software development is going down the toilet. It is really buggy, "features" are not working as expected etc. Documentation and support is pretty bad as compared to what it used to be 10 or 15 years ago. In fact you are lucky if you can get decent TAC support these days.

Hope this helps...

[Rich R]

@forman_102 no need to disable IP/MAC binding for that scenario.
It was major oversight in original 9800 code and was addressed by the "Overlapping Client IP Address in Flex Deployment" feature.  You simply need to configure "ip overlap" in the flex profile.  Never seen any problems with it and we use it extensively. https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_vewlc_flex_connect.html But it does require you to configure your site tags correctly because the mapping is hashed with site tag - this is addressed in Best Practices guide (link below):
"Don't use the same site tag name across multiple FlexConnect sites (this includes the default-site-tag). The C9800 doesn’t know about your physical locations and there is no point in distributing client keys across APs in different physical locations as roaming will never happen. Also, different site tag names are a requirement to support client overlapping IP addresses across Flex connect sites for local switching SSIDs."

[sroic]

Hi @Rich R , we are already running recommended software version and I would like to see the bug report for my issue before upgrading again to something in early deployment on promises it will solve it.

My radioactive trace looks like this, not sure if I can enable more detailed logs then this. Anything suspicious in this output?

2024/05/21 08:54:28.924781482 {rogued_R0-0}{1}: [rogue-capwap] [15354]: (debug): Client info (1/1), MAC:<e460.17aa.7f17>, reported by e438.7edc.0640/0, GW: 92af.5f51.d41a, chan:6, rssi:-50, snr: 206, ipv4: 0.0.0.0 , ipv6:0000:0000:0000:0000:0000:0000:0000:0000 , BSSID:92af.5f51.d41a
2024/05/21 08:54:28.924783962 {rogued_R0-0}{1}: [rogue-core] [15354]: (info): Reported rogue client <e460.17aa.7f17> by AP <e438.7edc.0640/17>
2024/05/21 08:54:28.924784772 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): Client ADD e460.17aa.7f17
2024/05/21 08:54:28.924788536 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): Check for max Client scale: count (905) < max (5000) ? 
2024/05/21 08:54:28.935475778 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): Client LRAD report e438.7edc.0640, slot_id: 17, last_heard: 1716281668.935475
2024/05/21 08:54:28.935483588 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): New Client LRAD: e438.7edc.0640, slot_id: 17
2024/05/21 08:54:28.935496102 {rogued_R0-0}{1}: [rogue-contain] [15354]: (debug): LRAD <e438.7edc.0640> - detecting slot ID 0, containment slot id 0, containment-radio-type: 1
2024/05/21 08:54:28.935543608 {rogued_R0-0}{1}: [rogue-core] [15354]: (debug): Validation for client <e460.17aa.7f17>, [cfg/req] cmx:0/0, aaa:0/0
2024/05/21 08:54:28.935555410 {rogued_R0-0}{1}: [rogue-rule] [15354]: (debug): Apply all classification rules to rogue <92af.5f51.d41a>
2024/05/21 08:54:28.935556850 {rogued_R0-0}{1}: [rogue-rule] [15354]: (debug): Can't apply rules to rogue <92af.5f51.d41a>
2024/05/21 08:54:28.935557018 {rogued_R0-0}{1}: [rogue-rule] [15354]: (debug): Updating generation-id for rogue AP <92af.5f51.d41a>. 52 -> 52.
2024/05/21 08:54:28.941217616 {rogued_R0-0}{1}: [rogue-rldp-all] [15354]: (debug): Skipping LRAD, hidden SSID
2024/05/21 08:54:28.941221344 {rogued_R0-0}{1}: [rogue-rldp-all] [15354]: (debug): Skipping LRAD, it is encrypted
2024/05/21 08:54:28.941221657 {rogued_R0-0}{1}: [rogue-rldp-all] [15354]: (debug): Cannot find AP for RLDP, LRAD entries 2
2024/05/21 08:54:28.941223284 {rogued_R0-0}{1}: [rogue-rldp-all] [15354]: (ERR): RLDP find closest AP failure, error=No such file or directory
2024/05/21 08:54:37.933746178 {rogued_R0-0}{1}: [rogue-capwap] [15354]: (debug): Client info (1/1), MAC:<e460.17aa.7f17>, reported by e438.7edc.5580/0, GW: 92af.5f51.d41a, chan:6, rssi:-46, snr: 210, ipv4: 0.0.0.0 , ipv6:0000:0000:0000:0000:0000:0000:0000:0000 , BSSID:92af.5f51.d41a
2024/05/21 08:54:37.933758341 {rogued_R0-0}{1}: [rogue-core] [15354]: (info): Reported rogue client <e460.17aa.7f17> by AP <e438.7edc.5580/17>
2024/05/21 08:54:37.933759066 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): Client ADD e460.17aa.7f17
2024/05/21 08:54:37.933774018 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): Client LRAD report e438.7edc.5580, slot_id: 17, last_heard: 1716281677.933773
2024/05/21 08:54:37.933780752 {rogued_R0-0}{1}: [rogue-db] [15354]: (debug): New Client LRAD: e438.7edc.5580, slot_id: 17
2024/05/21 08:54:37.933792557 {rogued_R0-0}{1}: [rogue-contain] [15354]: (debug): LRAD <e438.7edc.5580> - detecting slot ID 0, containment slot id 0, containment-radio-type: 1
2024/05/21 08:54:37.933811806 {rogued_R0-0}{1}: [rogue-core] [15354]: (debug): Validation for client <e460.17aa.7f17>, [cfg/req] cmx:0/0, aaa:0/0
2024/05/21 08:54:45.517456592 {rogued_R0-0}{1}: [rogue-capwap] [15354]: (debug): Client info (1/1), MAC:<e460.17aa.7f17>, reported by e438.7e05.78a0/0, GW: 92af.5f51.d41a, chan:6, rssi:-60, snr: 196, ipv4: 0.0.0.0 , ipv6:0000:0000:0000:0000:0000:0000:0000:0000 , BSSID:92af.5f51.d41a
2024/05/21 08:54:45.517459567 {rogued_R0-0}{1}: [rogue-core] [15354]: (info): Reported rogue client <e460.17aa.7f17> by AP <e438.7e05.78a0/17>

[Rich R]

Nobody is suggesting "upgrading again to something in early deployment" - only to TAC recommended stable release.

You don't say what version you're running so cannot point to specific bugs without that.
Some examples: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvx80829
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi96690

Don't see anything noteworthy in that trace. 

[sroic]

Well unfortunately Cisco TAC does exactly this, we had a similar "mysterious" radio crash issue back then on 16.X version and we were said to upgrade to next fw version which will fix the issue. After it didn't we repeated the process and got the same answer, couple of more times like that and they recommend the 17.9.X version which was EA. Deployed test instance with it, even the GUI was all broken, closed the ticket and the issue till this day still appears randomly. 

Same thing on this forum, whenever you ask for anything regarding wireless first two comments are to upgrade fw and to use WCAE (which provides a lot of info, but not much useful to solve bugs). I mean it's a legit comment (not much added value tbh) but if I responded to existing thread were those things were already said I don't know what to say more.

Regarding my issue, thanks @forman_102 for the effort but we don't have overlapped IPs at this site. Had this issue before with guest network and did something similar to what you wrote. Will update here if/when I find the solution for my issue. And couldn't agree more with you on the state of the Cisco products last few years.

[Rich R]

TAC only updates the recommended version to include Extended Support releases and only after at least 4 weeks post release of closely monitoring any reported issues for that release.  If anybody reports a major issue they either won't promote that release or they will include a caveat about the issue in the notes so you can make your own decision. There is no bug-free release so it's about making a judgement on which release is best to deploy.  The recommended release is the one which is judged to be the best compromise of supportability and stability with as up to date bug fixes as possible.  The logic in us recommending that is that it's pointless wasting time troubleshooting an older release which has hundreds of known bugs which have been fixed in the later release (remembering that the release notes only highlight a subset of the fixes in each release).

WCA is a belt and braces thing - it picks up common config mistakes which people may not even mention in their posts which can sometimes affect what they're doing so it's always best to run and eliminate any issues it highlights.  Doesn't mean it will fix the specific issue but just helps to make sure there's a good known baseline.

Of course we can only offer specific advice on specific information. If you prefer to keep the software version you run secret that consequently limits how specific the advice can be.