cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
967
Views
23
Helpful
36
Replies

Unable to Access Controller via HTTPS or SSH – Only Standby IP Ac

athan1234
Level 3
Level 3

Hi 

I am trying to access Controller 5500, but I’m having trouble because I don’t have access via HTTPS or SSH to the management or primary IP addresses. I only have SSH access to the standby (secondary) IP.

This controller has reached its maximum license capacity, and there are many access points trying to connect, so it might be overloaded or unresponsive.

I need to access it via HTTPS, but when I try to connect via SSH to the management or primary IP, I can reach the login prompt. However, after entering the username, it seems to freeze when I type the password, as if the controller is stuck.Do you have any suggestions for accessing it via HTTPS? Is there any way to manage it or run commands from the secondary IP, since I can access it via SSH?

36 Replies 36

I don't know how it will affect the registered APs if we upgrade the version
- Check the Compatibility Matrix (link below) for your AP models
- Read the release notes: https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn85mr8.html
- Take careful note of all the Field Notices below.

I think @marce1000 is correct.

Check his reply 

MHM

If you can share output 

show apf-ha logs

MHM

Are you sure that's a valid command @MHM Cisco World ?

(8.0.152.8-WLC) >show a?
aaa acl advanced ap arp assisted-roaming auth-list avc
(8.0.152.8-WLC) >show apf-ha logs
Incorrect usage. Use the '?' or <TAB> key to list commands.

athan1234
Level 3
Level 3

@Rich R @MHM Cisco World  

Show ap summary all of the are registred   AIR-LAP1242AG-E-K9 

I am seeing in this document  https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn85mr8.html  are not compatible with the last version 

athan1234_0-1750680602783.png

 

Share below please 

show redundancy summary
show redundancy state 

The issue is not AP register' issue primary try to sync db (db of client connect to AP) to standby and it failed 

I see the timestamp in log you share the primary try sync many times.

I think this make CPU busy to process https.

MHM

(Cisco Controller-Standby) >show re?
redundancy remote-lan reset
(Cisco Controller-Standby) >show redundancy summary
Redundancy Mode = SSO ENABLED
Local State = STANDBY HOT
Peer State = ACTIVE
Unit = Primary
Unit ID = F8:C2:88:8
Redundancy State = SSO
Mobility MAC = F8:C2:88:
Average Redundancy Peer Reachability Latency = 490 Micro Seconds
Average Management Gateway Reachability Latency = 260 Micro Seconds


(Cisco Controller-Standby) >show re?
redundancy remote-lan reset
(Cisco Controller-Standby) >show redundancy s?
summary statistics
(Cisco Controller-Standby) >show redundancy statistics


RF Client brief
--------------------------------------------------------------
clientID = 0 clientSeq = 0 RF_INTERNAL_MSG
clientID = 4105 clientSeq = 1 SIM_INTERFACE_COMPONENT
clientID = 25 clientSeq = 69 CHKPT RF
clientID = 35 clientSeq = 177 History RF Client
clientID = 4100 clientSeq = 272 RF_CAPWAP client
clientID = 4101 clientSeq = 273 RF_RRM Client
clientID = 4108 clientSeq = 274 RF_APFSEC client
clientID = 4109 clientSeq = 275 RF_DOT1X client
clientID = 4107 clientSeq = 278 RF_ConfigSync client
clientID = 4110 clientSeq = 279 RF_MOBILITY HA client
clientID = 4113 clientSeq = 280 rf_ha_sso client
clientID = 4111 clientSeq = 331 PMIPv6 HA client
clientID = 4112 clientSeq = 332 mDNS HA client
clientID = 14 clientSeq = 333 CHKPT_HA_DHCP_CLIENT_ID
clientID = 15 clientSeq = 335 CHKPT_HA_SLEEP_CLIENT_SYNC_CLI
clientID = 16 clientSeq = 336 CHKPT_HA_DOT11V_DMS_DB_SYNC_CL
clientID = 17 clientSeq = 337 CHKPT_HA_APF_PROFILER_ID
clientID = 65000 clientSeq = 338 RF_LAST_CLIENT
--------------------------------------------------------------

--More-- or (q)uit


Sanity Counters..................
--------------------------------------------------------------
Sanity Messages succefully sent..........: 10365500
Sanity Messages failed to send...........: 0
Sanity Messages received from peer.......: 20730992
--------------------------------------------------------------

Transport Counters..................
--------------------------------------------------------------
Number of messages in the hold Queue..........: 0
Application mesage Max Size...................: 8876
IPC message Max Size..........................: 8976
Time to hold IPC messages.....................: 100
IPC sequence number in the TX side............: 9614
IPC sequence number mismatches(Low)...........: 0
IPC sequence number mismatched(High)..........: 0
--------------------------------------------------------------

Keepalive Counters........:
--------------------------------------------------------------
Keepalive requests sent.................................: 99668349

--More-- or (q)uit
Keepalive responses received............................: 99668305
Keepalive requests received from peer...................: 49834190
Keepalive responses sent to peer........................: 49834190
Keepalive requests failed to send.......................: 0
Keepalive responses failed to send......................: 0
Number of times two Keepalives are lost consecutively...: 0
--------------------------------------------------------------


Network Latencies (RTT) for the Peer Reachability on the Redundancy Management Interface in micro seconds for the past 10 intervals
Peer Reachability Latency[ 1 ] : 496 Micro Seconds
Peer Reachability Latency[ 2 ] : 496 Micro Seconds
Peer Reachability Latency[ 3 ] : 491 Micro Seconds
Peer Reachability Latency[ 4 ] : 538 Micro Seconds
Peer Reachability Latency[ 5 ] : 481 Micro Seconds
Peer Reachability Latency[ 6 ] : 483 Micro Seconds
Peer Reachability Latency[ 7 ] : 486 Micro Seconds
Peer Reachability Latency[ 8 ] : 488 Micro Seconds
Peer Reachability Latency[ 9 ] : 486 Micro Seconds
Peer Reachability Latency[ 10 ] : 486 Micro Seconds

 


--More-- or (q)uit
Gw Reachability Counters........
--------------------------------------------------------------
Gw pings succesfully sent...............................: 9966810
Gw responses received...................................: 9965615
Gw pings failed to send.................................: 0
Current consecutive Gw responses lost...................: 0
High water mark of Gw responses lost....................: 29
--------------------------------------------------------------


Network Latencies (RTT) for the Management Gateway Reachability in micro seconds for the past 10 intervals
Gateway Reachability Latency[ 1 ] : 326 Micro Seconds
Gateway Reachability Latency[ 2 ] : 337 Micro Seconds
Gateway Reachability Latency[ 3 ] : 318 Micro Seconds
Gateway Reachability Latency[ 4 ] : 315 Micro Seconds
Gateway Reachability Latency[ 5 ] : 320 Micro Seconds
Gateway Reachability Latency[ 6 ] : 324 Micro Seconds
Gateway Reachability Latency[ 7 ] : 328 Micro Seconds
Gateway Reachability Latency[ 8 ] : 325 Micro Seconds
Gateway Reachability Latency[ 9 ] : 329 Micro Seconds
Gateway Reachability Latency[ 10 ] : 319 Micro Seconds

Ping Requests sent to Peer..............................: 54

--More-- or (q)uit
Ping Response received from Peer........................: 51


Config Sync Counters........
--------------------------------------------------------------
Usmdb syncs received........................................: 69
Failed sync for usmdb sync..................................: 0


Port Information....:
Local Physical Ports : LAG
Peer Physical Ports : LAG

?

show redundancy ?

summary Display Redundancy Facilitator States.

detail Display Redundancy Detailed Info

interfaces Display Redundancy Interface Ip.

peer-route Display configured route which are specific to standby controller

bulk-sync Display the details of BulkSync

latency Display Redundancy Manager Latency.

statistics Display Redundancy Manager Statistics.

timers Display Redundancy Manager Timers.

retries Display Redundancy Manager Retries.

mobilitymac Display the HA mobility mac address.


infra Display Redundancy Infra stats

--More-- or (q)uit

transport Display Redundancy transport stats

gw-reachability Display Redundancy GW stats

keepalive Display Redundancy KA stats

config-sync Display Redundancy config sync stats

ap Display Redundancy ap information

client Display Redundancy client information

 

show redundancy summary <<- this also please 

MHM

(Cisco Controller-Standby) >show redundancy summary
Redundancy Mode = SSO ENABLED
Local State = STANDBY HOT
Peer State = ACTIVE
Unit = Primary
Unit ID = F8:C2:88:8
Redundancy State = SSO
Mobility MAC = F8:C2:88:
Average Redundancy Peer Reachability Latency = 490 Micro Seconds
Average Management Gateway Reachability Latency = 260 Micro Seconds

Any idea to solve this issue?

Taking ownership doesn't mean that what is currently implemented is correct.  Being the new service owner, its up to you to figure out what you need to do and it seems like you have a few things you really need to fix in order to move on and to really be able to provide good wireless service.  We can start with the easy one since this thread is already very long.  AP's... disable dhcp on the controller and also make sure there is no dhcp on that subnet.  You don't control it, but you can ask and verify.  If you can't access either one of the controllers, even if you perform a failover, you need to probably reset it or verify that it's still actually functional. It is a 5508 so you probably don't have anymore support and sooner or later they may fail. What is your experience with the 5508's or even SSO?

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

As 2 others have already explained you will have to power off the primary so that the secondary becomes active.  Then power the primary on again and it should come up in standby role.
At that point you could switch back to the primary (if you want to) but the system should at least be accessible for you to make the changes you want to make.

Risks: worst case scenario there is a possibility the standby does not take over as it should - that is a risk you'll have to take.  You might have to reset that too, and again there is a risk it might not come back.  This is an unfortunate fact of life running very old, unsupported, hardware and software.  If you're lucky it will all go smoothly but this should serve as a timely warning of the need to upgrade to supported kit.

I have console access to the primary unit. Do you want me to check anything to help identify the problem? It's a critical system, so I prefer not to modify anything for now, haha. At the moment, I'm configuring the static IP

Review Cisco Networking for a $25 gift card