Filter
Top Products
Using the 700wl Series System
or has some other configuration information you would prefer not to lose. The act of making it a
secondary Access Control Server in an active redundant peer relationship will cause its configuration to
be overwritten by the Primary Access Control Server configuration. This situation can be avoided by
backing up the configuration of the peer Access Control Server, and double-checking your peer
configuration before enabling redundancy.
The second situation where data loss may occur is if a failover event occurs before the initial data
synchronization between the redundant Access Control Servers has completed. In this case, the
secondary Access Control Server will not have complete information to be able to take over as a fully
functional primary Access Control Server. Because synchronization happens quickly the likelihood of
data loss for this reason is small.
The third situation involves a loss of connectivity between the primary and secondary Access Control
Servers. In this situation there is no power failure of the Preferred Primary, instead the Secondary does
not detect a heartbeat message from the Preferred Primary due to the loss of connectivity and promotes
itself to primary. Now there are two primary Access Control Servers managing the 700wl Series system.
If an administrator attempts to access the Preferred Primary and cannot due the loss of connectivity
affecting that connection, then the administrator will assume there was a failover and access the
secondary Access Control Server now assumed to be the primary. If configuration changes are made to
the previously secondary Access Control Server during the loss of connectivity they will be lost when
connectivity is restored and the Preferred Primary again assumes its role and overwrites the
configuration data in the secondary Access Control Server with its own.
Configuration changes should only be made to the Preferred Primary. If a failover occurs, diagnosing
and repairing the reason for the failover should be performed before any configuration changes are
made.
Bandwidth Management
700wl Series system version 4.0 provides bandwidth rate limiting on a per-client basis. Each client may
use bandwidth as necessary up to the upstream or downstream limit set by the Access Policy currently in
force for that client. This implementation does not attempt to shape bandwidth usage, just enforce a per-
client cap.
Because bandwidth limits are set in the Access Policy, you can set different limits for different sets of
clients even if they are connecting through the same physical port. The bandwidth limit is imposed per
client—even if there is additional bandwidth available on the specific port, a given client will be limited
to the specified limit, and cannot take advantage of the additional unused bandwidth.
For example, suppose you select a bandwidth limit of 1Mbps (upstream and downstream) for an Access
Policy named Sales. Once this is done, each user that gets rights via the Sales Access Policy will receive a
bandwidth limit of 1Mbps. The 700wl Series system algorithm does not apply an overall cap to a group of
users. This means you cannot, for instance, define a 10Mbps limit for the Sales Access Policy and allow all
users affected by that Access Policy to freely use bandwidth within that limit. Since a WLAN is a
relatively low bandwidth shared medium and the purpose of a bandwidth cap is to prevent a single user
from choking all access to other users on the same AP, it generally does not make sense to set per user
limits above 1.5Mbps since most APs only support total actual bandwidth between 5 and 25Mbps.
For non-TCP traffic, bandwidth limits work in a straightforward manner. For TCP traffic there are some
performance considerations that may limit the throughput to less than the configured limit, especially if
client traffic is being encrypted via IPSec or PPTP.
2-20 HP ProCurve Secure Access 700wl Series Management and Configuration Guide