[Cisco Vpn Client 4.9 01 Mac Download
Facunda Ganesh
The roaming should not cause service interruption IF clients dont need to re-authenticate. If the PMK (Pair Wise Master Key) is present on the Access Point candidate, clients can smootly roaming between AP pretty fast and maybe client loose one ping on this process. Considering 802.1X.
The problem is that client will prefer higher RSSI dont matter what. This is odd because higher RSSI does not means that the AP has better condition. So, it is important to have an balanced environment in terms of AP distribuition. The WLC will work better when the environment allows it with enough AP and no obstacle between then.
First I would start by increasing the DCA timer to somewhere north of 4 hours. Without proper understanding or logs, we will not be able to tell you what caused the disconnection. So if you want to know the reason what caused the disconnections please post a radio active trace from an offending client.
As you correctly said looking at configured timeout values, session timeout must be set to the maximum possible value in your WLC (in 9800 do not set this to 0, recommendation is 86400, In older AireOS you can set unlimited or 65535). Session Timeout will make sure that the Wireless client is deauthenticated after the set timer even it is actively transmitting and receiving data.
Idle Timeout is there to make sure that the wireless client is deauthenitcated after client is idle for certain time, where the time is defined in the WLC. Set this to somewhere around 30 mins to 1 hour.
Just wondering if anyone has any ideas on why a client would not select the "better" AP? This particular client see's 4 AP's and one of them is obviously the better one at -64. Yet it inists that it wants to connect to one of the worst ones at -84. There is no logic in it, and I don't see a way to force to to connect to the closer AP.
Another factor you should consider is power level of the AP. If the 2 APs are at the max power of 100mW, the client will still hear both and since the mandatory data rate is set at 6Mbps, the client can join any AP at that low rate. For a indoor office with cubicle walls the client can hear an AP set at 30mW with 2.2dBi antenna at approximately 310ft.
These AP's are located in a building with cinder block walls and concrete floors. The location in question has the closest AP located behind a cinderblock wall, and the AP that the client wants to connect to through a concrete floor with steel plates and rebar. The power is the same on both AP's.
Most times the controller will instruct an AP to reduce power if it detects co-channel interference i.e another AP transmitting on the same channel. I am not really a great advocate of auto power settings because most times APs are at full blast until there is co-channel interference. Max power encourages hidden node problem.
Regarding what rates, it's hard to say because clients may support different data rates at the same RSSI level. For 802.11g, mandatory rates are 6,12, and 24. Hence you could disable 6 and 9 or change to supported and set your mandatory to 12 or disable 6,9, 12 and set mandatory to 24.
I would check and verify that the drivers on the client are the most up to date. The client makes the decision on when to move not the wlc. You can do the following from the cli of the wlc the client is connecting to. Debug client (Mac address) in one cli and the other debug client (Mac address) Then have the client connect to the ap and have them start to move. The sho client detail will give you the information like SNR/RSSI ap connected to nearby neighbors. Then as they move away from the ap, you should start to see the rssi go more neg and the SNR to drop down from for example 42 towards 20 and your rssi go from -50 up to -60 -65-70 and so on. You in most cases want your snr to be 22 or better. disable the lower data rates may also help with client sticking
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Actually, VTP server or client both distribute the VLAN database. Switching from client to server or the converse doesn't impact the distribution or the VLAN database. The only real difference between them is whether you're allowed to configure VLAN changes on the device.
If you wondering why have server and client, consider what might happen if you and I make VLAN changes on two different VTP server mode devices at about the same time. So it's good practice to only have one device in server mode. If you lose that device, you just select any other client mode device and set it to server mode.
I would council against such practice, because having more than one VTP server mode may allow a "race condition" update (and every VTP client has a copy of the VLAN database). It's unlikely, but when or if it happens, adds "fuel to the fire" that VTP is "bad" and shouldn't be used.
I had worked in an environment where someone added a VTP client mode, yes client mode, switch to the production network, and it nicely reset the whole prod L2 VTP. So, of course, management insisted that VTP be deactivated so that couldn't happen again.
At my current employer, we haven't yet had that happen, but "just to be safe", we're deactivating the VTP "virus". Also, of course, VTP deactivation makes new joy for VLAN management across multiple switches.
I agree if you have people who don't understand how vtp works it's not a good idea but we ran a big install with 2 vtp servers with 80 vlans for 15 years without an issue. If you don't understand how vtp works and even vtp clients can update the whole vtp domain if it happens to have a higher revision number you should not use it or if you have no control on who is adding things to your network you also should not use it . The reason we had 2 servers is if you lose one of the servers you have a backup which has same revision number as the vtp domain. You can then replace the broken vtp server , check the replacement is lower and it should just learn the revision number when it is inserted into the network, and it does work as we handled a hardware upgrade this way and it worked perfectly .
You can then replace the broken vtp server , check the replacement is lower and it should just learn the revision number when it is inserted into the network, and it does work as we handled a hardware upgrade this way and it worked perfectly .
I would expect it to work exactly as you described; perfectly. However, again my understanding of VTP (until you get to version 3), you could have accomplished the same without even an active VTP server. In fact, if the failed device was the VTP server, the new device could be defined and added as a VTP server while all other devices were VTP clients. Also while waiting to replace the failed device, you can "promote" any VTP client to server mode to allow VLAN configuration changes.
Again, once you have more than one VTP server, you expose yourself to a VTP "race condition" update. This is very unlikely, especially if you do take care making VLAN changes. (An example being your exposure of having two VTP servers for 15 years, but without an incident.) But if you're going to go to the trouble of having VTP server vs. client mode devices (I've worked with VTP where all devices were server mode too, without incident), why not take full advantage of avoiding this possible error? I.e. only allow one device that allows VLAN configuration changes.
Once again I am reaching out to you for help. I am hoping someone can help me. I have been noticing in my trap logs that there are an excessive amount of Client Association/Authentication Failures. I cannot figure out why. I have a Cisco 5508 WLC with 81 AP's (1131ag, 1142abgn, 1262N) models. The wireless devices are on a Windows Domain and use 802.1x EAP authentication, authenticating the user and computer info with a RADIUS Server. I look at the logs and all it can tell me is Reason:Unspecified ReasonCode:1. I read that the Reason Code is due to "Client associated but no longer authorized" but to be honest I am not sure what that means. It could mean many things, unfortunately it is too ambiguous to make heads or tails of. Can someone point me in the right direction? Things I can check? I posted below some of the Trap Logs, they go on and on like that. Thank you for any help you can provide.
795a8134c1