Original Publication Date: 08/30/2013
Note: This documentation was adapted from the F5 Management Pack Wiki hosted on DevCentral (http://devcentral.f5.com/wiki/MgmtPack.HomePage.ashx). Certain links or context described in this document may refer to content originally created on the Wiki.
Note - You must run discovery from either the Root Management Server if it is a standalone server, or one of the Management Servers other than the RMS. This also means you must have installed the F5 Monitoring Pack onto all Management Servers, including the RMS (which must be installed onto first). You can use Remote Desktop or Terminal Services, but discovery will not work from the Web Console.
Once you have successfully installed and configured the F5 Monitoring Pack software, you can discover managed F5 Networks devices on your system. Discovering F5 devices is the first step in monitoring these devices with the F5 Monitoring Pack. You can discover F5 Networks devices by manually entering device names or addresses, by using a CSV file, or by scanning a subnet.
By default the required ports to communicate with an F5 device from the F5 monitoring service are, on the F5 device: - 443 (HTTPS): iControl connection - 4353: iQuery connection
If the F5 device is behind a firewall, TCP ports 443 and 4353 need to be enabled on the firewall, for bi-directional communication between the F5 device and the F5 Monitoring Service. On the F5 monitoring host the ports for the device connection sockets are allocated dynamically (within the range available on the local TCP/IP stack). When the F5 device is configured to use different ports (from the defaults specified above) for iControl and iQuery connection, the F5 Monitoring service needs to be configured to use the appropriate ports. The related configuration settings are set in f5mpsvc.exe.config file's section:
<add key="iQueryRemotePort" value="4353" />
<add key="iControlRemotePort" value="443" />
When you start the Discover Devices wizard, you can select to discover devices my manually entering device address and password information for each device that you want to discover. On the Devices to be Discovered List, you can type an IP address or FQDN for any device in the network, then add authorization credentials that the system uses to authenticate itself to network devices. Alternately, you can scan a subnet on the network to discover all available, compatible F5 devices. When you scan a subnet, the system uses ping to determine the list of devices available. From this list, you can choose to monitor these devices with F5 Monitoring Pack.
You can also add devices to the list of managed devices by importing a file containing values that specify the IP address, user name, and password of each device. The F5 Monitoring Pack uses the information from this file to populate the Device List box in the Discover Devices wizard.
When you create a CSV file to use for device discovery, use the following format with each unique device represented on its own line: , , The variable refers to the IP address of the device to discover, is the user name that you want F5 Monitoring Pack to use to log on to the device, and is the password for the user name. For example, if you have a list of five devices to discover, your import file may have the following entries: 10.10.10.1,admin,pass001 10.10.10.2,admin,pass002 10.10.10.3,admin,pass003 10.10.10.4,admin,pass004 10.10.10.5,admin,pass005
F5 Monitoring Pack provides a Discover Devices Wizard to assist you in adding devices to the managed device list. The wizard provides prompts to guide you through each of the three different methods of discovering devices:
When you remove a device, the device no longer appears in the Datagram View or State View and the system no longer collects statistical metrics for the device. However, if you re-add the device at a later date, F5 Monitoring Pack retains historical data for the managed device.
When you use F5 Monitoring Pack to discover devices in your network, it installs an updated version of the big3d agent on devices that you discover. The system uses big3d to collect statistical data from managed devices, and requires that certain systems have updated versions in order to be compatible with F5 Monitoring Pack. Also, when discovering a device, the system uses a managed device's IP address in conjunction with its MAC address. This ensures that duplicate IP addresses that may exist in multiple networks do not cause errors.
F5 Monitoring Pack version 1.0 includes a new version of the big3d agent. The big3d agent collects performance information and runs on all BIG-IP systems. F5 Monitoring Pack uses big3d to collect performance data from managed devices. The Monitoring Pack Big-IP discovery process checks managed devices to ensure that big3d is a version equal to or greater than the Monitoring Pack version of big3d. If the version of big3d on any managed device is older than the version included with F5 Monitoring Pack 1.0, discovery can installs new version on the managed device.
When the big3d agent is restarted by the Monitoring Pack discovery process, or by a manual hotfix of big3d by an adminstrator, there is a small window of time where GTM balancing may be impacted ~ usually less than one minute.
To ensure that administrators are informed when the update is required, the Monitoring Pack does NOT update GTM unless the administrator specifically authorizes the update.
If you have not authorized a Big3d update, and the MP Discovery mechanism detects an older or unsupported version of Big3d, Discovery will be aborted and a related error message will be provided to the administrator. In this way, you can schedule when to update Big3d (via discovery) and manage and coordinate your GTM impact.
To authorize an update of Big3d you can do one of the following for a device:
See the following article on updating the big3d agent on a managed device: https://support.f5.com/kb/en-us/solutions/public/9000/700/sol9741.html. This article references the Enterprise Manager, but the same information applies to the F5 Monitoring Pack.
To ensure that a device is only discovered once, the F5 Monitoring Pack uses the MAC address in place of the IP address for the main identifier of each device. If the Monitoring Pack used only an IP address to identify and manage devices, this could cause issues with BIG-IP systems that have more than one IP address mapped to a single MAC address. This prevents the system from discovering multiple times for each unique IP address, and ensures that you do not need to configure network addresses specifically to work with F5 Monitoring Pack.
This section explains some of the security details behind the F5 device user role required for device discovery and the underlying iControl and iQuery connectivity
One of the most common questions when deciding what account should be used in the F5 Monitoring Pack for discovering an F5 device, is about what user role should this account have on the BIG-IP (F5 Device). For an accurate answer we need to take a deeper look into what exactly happens during the device discovery process and also through the lifetime of the device management activity provided by the F5 Monitoring Pack.
From the very beginning we should probably mention the dual aspect of the F5 Monitoring Pack's main functionality: monitoring and management. Monitoring in terms of collecting device statistics and providing System Center Operations Manager (SCOM) integration. Management or 'Device Management' in terms of featuring a certain set of F5 device related configuration tasks, which could be performed by SCOM administrators, given that they have the appropriate security role mapped on the F5 device. This sort of 'mapping' is handled by the 'Authorization Role' security layer within the F5 Monitoring Pack. In this article we'll be discussing the user role required on the F5 device for a successful discovery and device management, without going into the details of the authorization role mapping between this particular account and the SCOM management account.
The focus will be on the two stages / facets of the device-discovery-management and device-monitoring activities, provided by the F5 Monitoring Pack:
Initial discovery of the F5 device requires Administrator role for the user account performing the device discovery (and we're referring to the F5 device user role here). The reason behind this is that during discovery, the iControl interface (port 443 on the F5 device) is used for device certificate management / upload as well as updating the big3d agent on the F5 device, when necessary. Generally speaking, iControl calls into the TMOS (the F5 device's Traffic Management Operating System) and for the particular tasks carried out during device discovery (certificate upload and big3d update), full admin rights are required. So one thing to consider here is that since the iControl makes calls into the TMOS, and these calls are impersonated by the account logged in through the iControl interface, the access policy is controlled by the TMOS's underlying AuthZ security layer. Evidently some of the calls may be allowed, others may not, depending on whose behalf the iControl calls are being executed and what exactly those calls are supposed to do inside the TMOS.
The actual discovery of the device configuration is performed through the iQuery interface (port 4353 on the F5 device). And we'll get back to the security context of the iQuery communication with the device. After the discovery process, iControl is used for performing occasional checks to the iControl interface on the F5 device. The call checking for iControl connectivity is only retrieving the timestamp on the device. This type of call doesn't necessarily require administrator privileges on the F5 device. As a matter of fact such an iControl call is allowed even for a guest account. So, a legitimate question could immediately follow: can we demote the role of the F5 device account used during discovery (which remember, had to be an Administrator) to something less than Administrator? Or, can we switch to a less privileged user account for maintaining device connectivity and manageability, after discovering the device? The answer is YES and NO. Depending on what is intended on the SCOM administration end, in terms of managing the F5 device.
As previously mentioned, the F5 Monitoring Pack provides certain device management capabilities, such as:
These tasks could otherwise be done through the native F5 device management interface (web user interface), console/shell or through TMSH scripting, by the F5 device administrators, given that they have the appropriate security role for performing such operations. The F5 Monitoring Pack attempts to close the gap between the SCOM management and F5 device administration, providing a subset of such device configuration tasks through the SCOM management console.
There are network environments where the F5 device management tasks are exclusively assigned to a group of people who are not SCOM administrators. In this case having a lesser user role for the account used for device discovery would be a legitimate request. The F5 device user role of the account could go as low as 'Guest'. But then the F5 Monitoring Pack would only be able to monitor the device for configuration updates and statistics.
Note: When using a less privileged (e.g. non-administrator) user role for the F5 device account, attempting to set an F5 device object in Maintenance Mode (in SCOM parlance), through the SCOM management console, would fail, as the SCOM 'Maintenance Mode' task is mapped by the F5 Monitoring Pack to the appropriate iControl call, to disable / enable the underlying F5 device object, according to the SCOM Maintenance Mode status (started / stopped).
So, careful consideration should be taken about the user role assigned for the F5 device account used for discovery.
Note: If you wish to continue monitoring and configuring the device without allowing the user access to the admin account, you may lower the account to Manager. This will allow the user to still enable/disable members as well as receive vital health data from the Big-IP.
As mentioned in the previous section, about device discovery, the actual discovery of the device configuration is performed through the iQuery interface (port 4353 on the F5 device). The F5 Monitoring Service (the actual monitoring agent of the F5 Monitoring Pack) subscribes to event notifications about device configuration changes via the iQuery (XML-like protocol). The iQuery interface is exposed through the big3d agent on the F5 device, and inbound/outbound iQuery traffic is directed though and from the MCPD (Master Control Program Daemon) in the TMOS. If say, there is a new LTM Pool Member added (for example using the device web management console), the F5 device configuration / hierarchy is almost immediately updated in SCOM. And this happens through the iQuery interface, where device configuration updates are sent from the F5 device to the F5 Monitoring Service. So there's no need for forcing a rediscovery of the device to process such a change in the SCOM's F5 device hierarchy (configuration) and health state.
Also, device statistics are provided through the iQuery interface. The F5 Monitoring Pack subscribes to device statistics through iQuery, as well. So iQuery is the main 'transport vehicle' for device configuration updates and device statistics. No device management per-se is or can be done through iQuery.
A few words now about the security context of the iQuery communication, between the F5 Monitoring Service and the F5 device. As I mentioned above, the iQuery communication channel with the F5 device is exposed by the big3d agent (on the F5 device). When the F5 device has been initially discovered, and remember this initial discovery task should have been done with an F5 device user account having Administrator role, the F5 Monitoring Service pushed a certificate out to the F5 device, through the SSL communication ensured by iControl. This certificate is used by the big3d agent to authenticate clients requesting iQuery connections. So coming back to our use case of switching or demoting to a lesser user role for the F5 device account used for discovery, the question is: would further iQuery communication still be possible with the F5 device, after discovery, if a less powerful (say 'Guest') account is used for F5 device communication? And the answer is YES. And I explain why. When the big3d receives a client connection request, it checks the available server certificates in the F5 device certificate store and matches them against the client requesting the connection. If the client has previously uploaded a valid certificate (which BTW happened through the initial device discovery process), then big3d grants full access to the client, and the iQuery 'season' is open for communication. And this would be OK, even if the F5 device credentials on the client side have long been changed to a Guest for example, on the F5 Monitoring Pack's side. How long this could go on? The server side certificate pushed on the F5 device, by the F5 Monitoring Service during initial discovery, would expire in 10 years.
The F5 device user account used by the F5 Monitoring Pack to handle the device connectivity has an important role in managing the iControl and iQuery communication with the device. When pondering about the user role to be assigned for such an account on the F5 device, SCOM administrators and F5 device administrators should consider the dual aspect of the F5 Monitoring Pack's main functionality: device-management and device-monitoring. Discovering an F5 device with the F5 Monitoring Pack initially requires an Administrator role for the F5 device user account. Eventually this user account could be demoted to a lesser role, or replaced by a different account, with less privileges. But in this case most of the device management features exposed through the F5 Monitoring Pack in SCOM would be lost. Still, such a requirement may be perfectly valid in network environments where the F5 device management tasks are exclusively assigned to a different group of people, who are not necessarily SCOM administrators. And this would employ the F5 Monitoring Pack only for monitoring statistics from F5 devices.
For additional information, please visit http://www.f5.com.