Heads Up :
The post you are writing will appear in a public forum. Please ensure all content is appropriate for public consumption. Review the employee guidelines for the community here.
Hello,I observe a weird random behaviour for wireless clients that remain connected for a long time. It does not happen frequently (at least I'm not aware of). The client considers that it is not connected anymore (no idea what triggers this) and iss...
Hi,I'm trying to survey the presence of a given entry in the c9800 wireless controller mdns cache. SNMP does not seem to forward this kind of information, neither does netconf. The last idea was to ssh the command, but bash scripts work when executed...
Hi,I'm trying to survey the presence of a given entry in the c9800 wireless controller mdns cache. SNMP does not seem to forward this kind of information, neither does netconf. The last idea was to ssh the command, but bash scripts work when executed...
Hi,It seems that C9800 (17.12.3) wireless controllers don't return all their associated mobile stations through SNMP in AIRESPACE-WIRELESS-MIB::bsnMobileStationEntry subtree (.1.3.6.1.4.1.14179.2.1.4.1). Did anybody see this elsewhere?
Hello,In previous wireless controllers (ex. Wism2 v. 8.5.151.0) , mdns gateway was grouping service providers by mdns service name and was allowing more than 100 entries from the same mac address. It seems that in recent IOSXE version on C9800, where...
OK, this could probably change somehow the situation, but it is not clear from the logs: first why controller should send an eap request without any roaming or session timeout request; and second, why C9800 does not take any action after the expirati...
Perhaps I didn't explain it well... My issue is that the controller does not reset client connection internally, and not that it fires it out on its side.Looking closely at the Catalyst Center I can see:UPDATE: - 13m:20s before the following Timeout ...
This supposes that I know the client that will fail in advance and I don't.I just saw in the radius log that the last authentication request (triggered by policy session timout parameter) before connectivity loss was delayed by more than 30 seconds. ...
Well, even the term command did not do the trick, changing the way of sending the command (almost) allowed me to get the text I wanted. Indeed, ssh -l myuser mywlc 'show mdns-sd cache' does not work, but ssh -l myuser mywlc <<EOT | grep -v "mywlc"...