The down side is the possibility of overwhelming the controller card with SNMP SETs and GETs when managing a large number of cards in the rack. When retrieving a status from the rack, this is really no big deal, as a retry of the command will usually be successful. When a configuration update is being performed, however, the ability of the controller card to retry failed SETs and come back to non-res ponding cards depends upon the intelligence b uilt into the GUI management application and the controller card. The GUI management software promises to segregate operational and systems tasks by making the management display easier, through an intuitive GUI representation of the rack modules. Even power and fan modules are selectable with a mouse.
Actions are available from tool bars and drop down menus.
In order to segregate duties between systems and operational folk, security and consistent English context must be applied to the managed functions. At best, modem and SNMP variables are named with cryptic, often varying monikers that require an intimate understanding in order to accurately apply. Most of the management applications for rack systems include some level of automation to react to exception conditions like those received from a threshold being exceeded. The only rub here is that much of this function runs through the controller card. But, if the controller card is unreliable under load, this becomes a useless feature.