The engine that drives the Configuration Assessment is a powerful tool, one that places a lot of responsibility on you. Not only do you create the configuration rules file that makes sense for your environment and your goals, but you also need to understand the following:
how to set up a rules file that will look for certain components and return accurate results.
how to understand and apply the results you receive.
how to revise your rules file if the results do not match your expectations.
The topic titled Section 4.1.1, Creating a Rules File provides a basic introduction to the rules file format and explains the available parameters. The topics in the current section extend the discussion to special cases and possible pitfalls in running a Configuration assessment.
Following are examples of usage scenarios in which you have to do a little extra thinking when you set up your rules file to get the results you need:
When you create a comparison rule to check the operating system version (“OS Revision”) of your devices, you can set the Type to be either string or integer. If you select string for the Type, a straight comparison is performed on the string values in the rules file and in the database; no conversion is performed. For values that are within the same range of 10’s (for example, comparing 12.1 and 11.0), this approach works fine.
However, for values that are not within the same range of 10’s, such as a comparison of 12.1 and 8.0, this approach gives incorrect results because the comparison is based on the value of each character. When you wrote the rule, you knew that an OS version of 12.1 was greater than a version of 8.0, but when this comparison is performed, Vivinet Assessor finds that 1 is less than 8.
On the other hand, if you had set the Type to be integer, the comparison is performed on the converted value of the string (Vivinet Assessor converts each string to a double). This type of conversion throws out the text values and only returns their numeric equivalents. In this case, the comparison will work for the comparison of 12.1 and 11.0, as well as 12.1 and 8.0, and even values like 12.1(a) and 12.2(b). However, if the alphabetical portion of the revision is really important, in some cases it is better to set the Type to string.
A final option is to use the Find feature to search for an exact string of letters, characters, or numbers within a property. For example, you may need to know whether the OS version contains the string “12.3.” For more information, see Section 4.3.2, Example 2: Installed Modules.
In the case of OS Revision, you should write the configuration rules file with some prior knowledge not only of the vendor-recommended operating-system levels for VoIP, but also of the OS versions already installed on the network. If you think some devices might have OS Revision values with letters in them, set the Type to string. Or try running the same Configuration assessment with OS Revision Type set to string, and then run it again with the Type set to integer.
For a few device characteristics, such as Installed Modules, the relevant information in the device MIB (and thus, in the Network Inventory for that device) is a complex string of characters and numbers. Sorting through the relevant characters can be tricky, and making a rule that compares it with a LessThan or GreaterThan string may be impossible.
The Installed Modules data presents an example where you need to use a Find operator in your rules file. (In the rules file, the Installed Modules property appears as <Property>InstallModules</Property>.) You may, for example, want to ensure your routers have at least two voice ports.
Here is how the Find feature works:
For Router X, the information stored in the database after the Network Inventory was performed includes the following for the installed modules property:
VendorX mainboard, VendorX FSO ethernet 12345, VendorX voice port ABC, mainboard upgrade 654321
To check for these values, you add the property to the rule as follows:
<BasicRule ComparisonOperator="Find"> <BasicPropertyItem FilterOn="false"> <Property>InstallModules</Property> <Type>String</Type> <Unit>None</Unit> <Value>voice port</Value> <DeviceType>all</DeviceType> </BasicPropertyItem> </BasicRule>
In this case, the rule searches the InstallModules property for the string “voice port.” If the string is located, the result is true (shown as success in the Configuration assessment results); otherwise the result is false (the device fails the rule). For the rule shown above, the result for Router X is true.
In some cases, you might want to treat one of the properties of a configuration rule more as a rule detail than as a hard-and-fast configuration requirement. For example, if your environment contains devices from multiple vendors, you will want to include the name of Vendor A in some of your rules. After all, your rules for those devices should be based on the system resources recommended by Vendor A. However, you will not want to see a failure in the results for every device on the network that was manufactured by Vendor B.
The Configuration assessment offers a filtering feature for just such a case. To enable it, add a FilterOn attribute to a BasicPropertyItemType. A filtering attribute allows you to exclude certain values from consideration by a single rule without returning a failure result for the rule or excluding that particular value from consideration by any other rule in the rules file.
Unless you add a FilterOn attribute to a property item, no filtering takes place. The FilterOn attribute type is string, with possible values of “true” or “false.” Any property can have this attribute, and for a given rule, multiple properties can have it set to “true.” In the results table and VoIP Readiness Assessment Report, any filtering is indicated next to the rule where filtering was applied.
Here is an example of how you might use the FilterOn attribute. You discovered six routers by Cisco and six by Nortel during the Network Inventory, and you want to use a single configuration rules file to analyze all 12 of them. For any rule that treats Cisco IOS levels, add the filter to avoid seeing failures for all six Nortel devices.