Capacity cost resource counting does not have a hard per-ISA limit, because the cost values are decoupled from actual ISA resources. However, the value of the total summed cost per-ISA can be reported, and a threshold value can be set which raises an event when exceeded.
ISA capacity overload detection and events are supported within the system resource monitoring / logging capabilities if the traffic and resource load crosses the following high and low load thresholds on a per-ISA basis:
ISA capacity cost
flow table consumption (number of allocated flows)
flow setup rate
traffic volume
host IOM egress weighted average shared buffer pool use (within the egress QoS configuration for each group). These thresholds are also used for overload cut-through processing.
While an app-profile is assigned to AA subscribers, the capacity-cost for that app-profile can be modified. The system makes updates in terms of the load balancing summary, but this does not trigger a re-balance.
In the absence of user configuration, the app-profile default capacity cost is 1. The range for capacity cost is 1 to 65535 (for example, for bandwidth based balancing the value 100 could represent 100 kb/s). 0 is an invalid value.
If the re-balancing of AA subscribers is required (for instance after the addition of new ISAs), there is a tools command to re-balance AA subscribers between ISAs within a group. Re-balance affects which AA subscribers divert to which ISAs based on capacity cost. Transit subs cannot be rebalanced independent of the parent (they move with the parent divert), and DSM subs cannot be load balanced as all subs on an ISA-AA are from the associated ISA-BB pair. The system attempts to move AA subscribers from the fullest ISA to the least full ISA based on the load balancing mode. If the load becomes balanced or an AA subscriber move fails because of ISA resources or divert IOM service queuing resources, the load balancing terminates.
Alternatively, load balancing can be manually accomplished by the AA subscriber being removed and re-added. This triggers a load balancing decision based on capacity-cost. For ESM, SAP, and spoke-sdp subscriber types, this can be accomplished by removing and re-applying the AA subscriber's app-profile. In the case of ESM AA subscribers, shutting down and re-enabling either sub-sla-mgmt or the hosts has the same effect. Dynamic ESM AA subscribers re-balance naturally over time as subscribers come and go from the network.
For transit AA subscriber deployments, the parent divert SAPs are load-balanced based on AA capacity cost from the app-profile configured against the SAP/SDP. The parent capacity cost should be configured to represent the maximum expected cost when all transit subs are present.
All traffic not matching a configured transit subscribers is dealt with as a member of the parent SAP and according to its app-profile.