This text was hidden. Now it is visible. Click the link to hide the text.

HP RAMS 9.20 includes the following major, new features:

• RSVP-TE Tunnel Monitoring
  The major new feature for the HP RAMS 9.20 release is support for traffic- engineered tunnels as an integral part of the network topology model. Previous releases could show which entry and exit PE routers would carry the traffic for a particular BGP/MPLS VPN customer's communication, but the path across the service provider's network was assumed to follow IGP routing.HP RAMS 9.20 added dynamic monitoring and analysis of tunnels created with RSVP-TE to follow traffic- engineered paths.
  
  RAMS periodically gathers information from each router about the tunnel configuration using the most efficient data collector mechanism (CLI, NetConf, SNMP) for each type of router. This release includes support for Cisco (IOS, IOS-XR), Alcatel-Lucent (TimOS) and Juniper (Junos) routers. For Alcatel routers, the collected information includes the configuration of Service Distribution Paths (SDPs). This tunnel information collection extends the basic router and interface information collection provided in previous releases.
  
  RAMS continuously monitors IGP routing to detect link state changes, hence it can detect when tunnels would also be affected by a change. Tunnel changes can also be detected from SNMP traps or syslog messages sent by the routers to RAMS. These mechanisms allow RAMS to dynamically monitor the state of the tunnels with a significantly reduced load and increased accuracy than with polling alone. Exploration of the head-end router for a specific tunnel can also be initiated on demand from the GUI if the displayed state is suspected to be not current.
  
  After constructing the network topology model including tunnels, RAMS lets the user visualize specific TE tunnel paths overlaid on the layer-3 topology. Alternatively, for any tunnel selected from a tunnel report, a schematic view of the tunnel is available in a "tunnel map" coupled with a "tunnel inspector" to view all the configuration and status details collected for the tunnel. Multiple tunnels can be selected for display on the tunnel map at the same time for comparison.
  
  Users can also analyze the link and node protection characteristics of the tunnels and use the Analysis mode to look any changes to the tunnels over time as presented in new reports. Just as for IGP routing, a complete recorded history of the tunnel status allows rewinding to an earlier time to diagnose tunnel problems.
  
  RAMS will show how VPN customer paths traverse the service provider network following the traffic engineered tunnels. An arch icon indicates the entry and exit points of a tunnel along the path. With RAMS Traffic, measured traffic flows are also deployed across the network according to the combined IGP and tunnel routing to allocate traffic to each link. It is possible to display a tunnel path that crosses from one AS to another even when there is insufficient topology information to create an eBGP link between the two border routers.
  
  The collection of RSVP-TE reports includes some for failure analysis. For all interfaces protected by an FRR, two reports show the impact of traffic flowing on the FRR as the result of a failed interface as measured by the increase in utilization or reserved bandwidth for the worst impacted link. Three drill-downs are provided: a Tunnels drill-down lists the tunnels traversing the failed interfaces and how they are rerouted; an FRR drill-down lists all the FRRs that had traffic rerouted onto them due to the failed interface; and the Links Impacted drill-down shows each link that was impacted by the failed interface.
  
  The RSVP-TE support includes tunnel planning features that allow simulating changes to the tunnel configuration in a manner analogous to the existing planning features for IGPs and BGP. The dialogs for adding and editing tunnels take the user through steps of adding primary and secondary tunnels, specifying or modifying tunnel paths, attributes and constraints, or simulating tunnels going down or coming up. These dialogs can be invoked from icons on the tunnel reports in addition to the Planning menu and toolbar.
  
  Simulated changes in the IGPs will also be reflected in changes to the affected tunnels. Tunnel routing and creation of fast re-route (FRR) tunnels can either be explicit or automatic according to constraints.
  
  Simulated tunnel changes cause the reports and tunnel maps to be updated correspondingly, and impact analysis reports show the effects of the tunnel changes on link utilization.
  
  
• Support for Huawei Routers in RSVP-TE and Traffic
  The Collector recorder adds support for Huawei routers using both SNMP and CLI access methods to gather information for connected and static routes as well as RSVP-TE tunnels. Appendix B in the Administrator's Guide provides details about the accessed MIBs and CLI commands. RAMS will periodically gather information from each router about the tunnel configuration. When multiple access methods are configured, the most efficient method is used. This additional support extends the set of supported router types to Alcatel-Lucent (TimOS), Cisco (IOS, IOS-XR), Juniper (JunOS, JunOSe), and Huawei. For JunOSe, collection is limited to base information and VRF information to map PE-CE traffic, but not RSVP-TE tunnel information. For IOS-XR and Huawei, VRF information is not collected.
  
  Traffic recording also now accommodates the Huawei routers' variations in NetFlow data formats.
• Integration with HP Network Node Manager (NNMi)
  
  HP RAMS 9.20 in integration with HP NNMi supports:

  • NNMi Root Cause Analysis (RCA) for the following HP RAMS forwarded traps:
    • rexAdjDown
    • rexAdjUp
    • rexRtrIsolated
    • rexRtrConnected
    • rexPathChange
  • Make a note that:
    • RAMS Traps invoke a named poll for the NNMi object available in RAMS traps. This named poll will trigger NNMi RCA.
    • You will have to enable Custom Correlation for RAMS traps manually. See, Configure Basic Settings for a Custom Poller Collection topic in NNMi Online Help for steps to enable Custom Correlation.
    • NNMi RCA for these traps will be done at real time.
• Support for Routes and 4-byte Autonomous System Numbers in BGP
  
  The BGP recorder can now be configured to accept "6PE" routes (AFI 2, SAFI 4) in addition to the IPv4, IPv6 and VPNv4 routes accepted in previous releases. These routes are displayed in the Prefixes table and other BGP reports. They can be used as the destination for paths across the core network. [12245]
  
  The BGP Root Cause Analysis and RIB Visualization features have been extended to work for the VPN, IPv6 and 6PE address families in addition to IPv4. [5786, 16858, 17893]
  
  In addition, for any of the BGP address families, 4-byte Autonomous System (AS) numbers are now supported. This applies to the AS being recorded as well as any neighbor AS. The AS numbers are displayed in ASDOT notation on the map and in reports. Both ASDOT and ASPLAIN formats are accepted as input values, such as in the filters. [11295]
• Compatibility Changes in Alerts and XML RPC API
  All alerts for the IS-IS protocol now include the System ID as part of the router identification for alerts dispatched using syslog, email, or the internal database. Previously, the System ID was printed only if the IPv4/IPv6 address wasn't available. Similarly, the messages for the VPN Reachability of Customer by PE and RT by PE alerts dispatched using syslog, email, or the internal database now include the router name in addition to the router address if the name is available. For both cases, the MIB for SNMP dispatch already included varbinds for all of the available forms of router identification. [16836, 17910]
  
  In the XML RPC API, the api_manage_config call uses an XML schema to describe the configuration object that is read or written. In the HP RAMS 9.20 release, two changes were made to the schema that are not backwards compatible with earlier releases:

  • When parsing a PathGroup as input, a path's source router must be identified by either a or encapsulated inside a object rather than without the encapsulation. [18024]
  • In the PathAlert, the tag was renamed to alertOnHopOrECMPDegChange. [18231]
• User Interface Enhancements
  In addition to the primary new features, HP RAMS 9.20 incorporates
  several appearance improvements and functional enhancements to the
  user interface, including the following:
  

  • The number of available operations in Planning mode has increased substantially with the addition of RSVP-TE planning, so the Planning toolbar is now configurable in Administration -> Options so the user can select and arrange the icons that are most useful. [17823, 18042]
  • Context-sensitive copy/paste has been implemented for nodes on the map. Selecting one or more nodes on the map and typing Ctrl-C followed by typing Ctrl-V in the Add Tunnel or Edit Tunnel dialog fields for headend or tailend routers will fill in the names of the routers.
  • The Planning mode dialogs for adding, changing and dropping prefixes now display an improved layout with consistent behavior of the Apply and Cancel buttons across the set of dialogs. These dialogs and others also now feature a Revert button to undo the edit after is is applied. [17826, 17827, 17829, 18031, 18055]
  • Bandwidth values in all of the reports (especially for traffic) are now right-justified in the column so that the numbers are easier to compare. The values may be scaled with a K, M or G suffix to indicate kilobits, megabits or gigabits per second. Two digits of fraction are displayed for measured or calculated values, while three digits are shown for configured values. [15169]
  • Correspondingly, the Planning mode dialogs for adding and changing peerings now use a spinbox widget for bandwidth values that will accept a suffix of K, M or G. [17637]
  • When adding an IGP peering, the source and destination interface addresses now default to "Unnumbered", and that value is accepted as 255.255.255.255/32 if not changed. The "Unnumbered" text is cleared automatically when the field is clicked to facilitate entry of an address. [17642]
  • In Planning mode, the Add VPN Customer wizard now includes a navigation tree on the left to allow random access through the steps, and fixed several problems with editing values in the table. [16183]
  • The Alert Configuration dialog now replaces the Threshold column
    with a generic Attributes column to display additional alert-
    specific configuration parameters such as the RT value for the
    Reachability by RT Prefix alert. [10054]
  • The labels for both ends of a link on the map are now displayed
    right-side up or as close to that as possible, rather than the one
    on the bottom of the link being upside-down as before. [16916]
  • Text entry fields now include a small X button to clear the text.
  • In the Tunnel Inspector panel that can be displayed from tunnel
    reports, text can now be selected from tree widget items, such as
    paths, for copy/paste elsewhere in the GUI. [16936]
  • In the Planning mode Traffic Reports, the Link reports now include
    a set of columns showing the utilization percentage before and
    after the edits, in addition to the traffic rates. [17901]
  • The dialog for Assign Names -> IPv4/6 Prefixes now includes an Import button to allow bulk setting of names using copy/paste from an external spreadsheet or table. This Import dialog and those for routers, router locations and AS numbers will now highlight the invalid portion of the input when a syntax error is detected. After names are assigned to prefixes, those names will be displayed in a new column of the Prefixes table. [17360]
  • The capability to find paths using the Route Source and Route Destination buttons on the node info panels on the map has been extended to work for networks where only Collector and BGP topologies are present. [17571]
• Web administration UI enhancements
  • Licenses pasted with double-spacing will now be accepted rather than giving an error indicating an invalid license. The double-spacing may result from opening the license in a program that treats line-ending characters differently.
  • When creating a backup file, the inclusion of log files is now controlled by a separate checkbox. Since the log files can be large, this change allows users to routinely prepare System Configuration backups of more manageable size. [17469]

Note: HP RAMS releases have supported both SSH version 1 and version 2 for X/ssh access to the user interface. Please note that SSH version 1 was deprecated in the HP RAMS 8.11 release and is removed from the HP RAMS 9.xx releases because it is considered a security risk.

• When the Collector recorder is configured to accept syslog messages, the syslog daemon may hit an infrequent crash. There is not yet any automatic mechanism to restart the daemon, so the system must rebooted or remote access for Technical Support must be enabled to manually restart the daemon. [17487]
• When using the RSVP-TE Planning feature to create tunnels, it is possible to create a large number of tunnels in a full mesh. If the number of tunnels and constraint options is too large, attempting to save the edits to the database will cause the GUI process to pop up an error message and then become stuck. [18093]
• Traffic reports in the GUI and XML RPC API may show inaccurate results in a scenario where some IGP adjacencies are down for an extended period of time while the Collector recorder has not queried the affected routers again to detect that the Connected route is also down. In this case, flows may be routed over the down link using the Connected route, or over a tunnel that is expanded across the down link using the Connected link, producing incorrect traffic results. [18183]
• After the Collector recorder has finished its topology exploration, its status may report some number of "possibly inaccessible" routers even though all routers were successfully queried. This count is the number of router addresses that were tried unsuccessfully, even though another address tried subsequently for the same router may have allowed a successful connection. [18216]
• RAMS Traffic does not yet model multicast routing. If multicast traffic is recorded, the flows will be listed in the traffic reports and may be incorrectly projected on the map and in link statistics according to unicast routing to the default route. [17439]
• The List/Find Path dialog will work from a 6PE source node to a 6PE destination prefix so long as the source node is identified by name rather than by its IPv4 address. In the next release, the IPv4 address will also work. [18221]
• In the Developer's Guide, the title heading for the api_traffic_src_dst_matrix call is written as api_traffic_dst_nbr_matrix instead, and the "neighbor as" parameter should be describing the "destination as". [18269]
• In a report window with a tree of reports listed on the left, if the user accidentally moves the mouse while intending to click on one of the entries in the tree, the new entry will be selected, but the report won't change because the input is considered a mouse drag operation rather than a click operation, and the drag operation has no action associated. The workaround is to click again on the desired entry. [16430]
• In the HP RAMS 9.20 release, some of the tables and some of the inspector panels in the GUI will automatically update as time advances in Monitoring mode. Other tables and inspectors will retain their data and display a "reload" icon that must be clicked to see changes in the data. The plan for a future release is for all tables and inspectors to auto-update. [15134]
• Consolidation of router nodes on the map may be incorrect until the second Collector full exploration after starting a fresh database with BGP, IGP and Collector topologies all at once with the Start All Recording button. This problem can be avoided by starting recording individually for each of the protocols except Collector and waiting 15 minutes or so for the full BGP and IGP topologies be recorded. Then start Collector recording separately. Consolidation may also be incorrect if the same interface address is configured on more than one router. [15904]
• In the HP RAMS 9.0 and later releases, the limit on the size of copy/paste transfers from a GUI running inside a VNC session to the clipboard on the VNC client machine is 256KB, compared to a limit of 4MB in earlier releases. The smaller limit results from the 64-bit VNC server using a different method for the transfer. The 4MB limit may be restored in a future release. In addition, the new feature for exporting CSV-format files is an alternative. [4934, 13865]
• RAMS OSPF route calculation conforms to RFC2328 and assumes "RFC1583Compatibility" is disabled, so the path chosen from one ABR to another ABR in the same area will be within that area even if there is a lower-metric path through the backbone. Since some routers enable RFC 1583 compatibility by default, the actual path may differ. A future release will support a configuration option to enable RFC 1583 compatibility. [1897]
• In the RIB Comparison for an OSPF or ISIS domain, the number of down links reported in the table may be fewer than the number shown when the links are listed from the context menu. [12295]
• Path Reports for IPv6 networks will show that some paths are incomplete because to reach the destination requires IPv6 connected interface information. That information is not collected yet. [12452]
• In Traffic Reports -> Top Changes, the context menu on the drill-down button may not appear after sorting a column. The workaround is to select a cell from another column. [12506]
• In the XML RPC API, the method api_mp_list_paths requires the source address to be specified in the form of a prefix now; that is, with both an address and a mask. This is consistent with the specification in the Developer's Guide, but releases before HP RAMS 8.1x were more lenient and would accept just an address without the mask.
• Since release HP RAMS 8.0, the Recorder Configuration allows only a single top-level administrative domain to be created. Users who need multiple domains to configure different portions of their network should create one top-level domain and then subdomains under it. For existing configurations that already contain more than one top-level administrative domain, only the lexicographically first of those domains can have alerts configured. If a recorder client that already contains some configuration is added, that configuration will be pulled up to the master, possibly creating a new top-level domain. This might cause a problem if it comes first.
• If the top-level domain is deleted and replaced with a new top-level domain, the system should be rebooted so that the reports/alerts daemon will be restarted and will detect the new one. [12741]
• If a client unit fails and must be replaced, before adding the replacement unit as a client of the master unit, you must stop replication on the master unit. Then after adding the client, start replication again. This will rename the replicated database on the master and start replicating anew from the database on the replacement client.
• Some of the RAMS IM traps show IP address as Hex-String in NNMi incidence browser after upgrading from earlier version of NNMi to NNMi version 9.20.

In addition to the primary new features, HP RAMS 9.20 incorporates several appearance improvements and functional enhancements to the user interface, including the following:

• In the MPLS WAN report for Reachability from Other Sites, when
  drilling down to Prefixes the counts of sites that received each
  prefix and the counts of sites that did not receive each prefix
  have been corrected. [17008]
• In the Events table for ISIS, the local and remote interface IDs
  are displayed if they are set for an Add or Change Neighbor event.
  [17872]
• Trending functionality was unavailable without traffic enabled,
  but now trending is available for any timeline graph. [17407]
• In the Analysis menu of the History Navigator, the BGP Root Cause Analysis and RIB Visualization items are now enabled for IPv6 topologies in addition to IPv4. [18174]
• The Events table and the Flow Record Browser now monitor memory consumption as they are loading events or flows, respectively, into the table. If the process memory size gets near the limit, loading is stopped and a popup message is displayed. [17620]
• In the HP RAMS 9.20 release, drilldowns in the VRF section of the VPN Routing Reports were not useful in Monitoring mode because the drilldown would be removed each time the network updates (every 10 seconds by default). Now the report remains stable. [17156]
• For CSV output of tables in the GUI, field values that contain a comma are now enclosed in double quotes to maintain column integrity. [17370]
• In the History Navigator, when switching to another protocol tab after zooming the graph on the previously selected tab, the zoom level and time range information is now updated correctly. [17706]
• The recorder status window accessed in the GUI by clicking on the status LED is no longer modal and if resized larger will now keep that larger size. [17136]
• The dialogs for configuring the Prefix Diagnostics, Routing Stability and Routing Comparison reports are no longer modal, so now parameters may be collected from other windows to fill in the dialog fields. [17318]
• The preview display of a BGP Root Cause Analysis visualization export was clipped and drawn with lines on top of labels. Now that preview is shown correctly. [16938]
• The preview display of a BGP Root Cause Analysis visualization export was clipped and drawn with lines on top of labels. Now that preview is shown correctly. [16938]

• In the RSVP-TE headend/midpoint and link reports, instead of reporting the number of tunnels that are "primary up" or the number of tunnels that are "secondary up", the reports now show the number of primary LSPs and the number of secondary LSPs originating or transiting through the element to make the impact that failure of the element would have on the network more prominent. [15844]

• Several improvements were made in the content and formatting of
  the Attributes column of the Edits table to show what changes have been made in Planning mode. [16255, 17987, 18060, 18146]
• In the Add Flow Distribution dialog, dynamic validation of input values was added to indicate invalid values as the user is typing. [16501]
• When editing traffic flows, selecting a single row and clicking Change -> Selected now brings up the same dialog as for changing the values when multiple rows are selected. This avoids some anomalous behavior of editing in the cell. [17507]
• When traffic data is included in the Open Topology, the Planning menu now includes a Show Edits item to be consistent with that menu when no traffic data is opened. This new menu item is an alternative to the Edits page of the Traffic Reports in the Planning menu. [17875]
• When entering Planning mode with traffic databases loaded and time near the current time, the user will now be asked if the network model should be moved to the latest traffic time. If the user chooses not to move time, then the Traffic Reports in the Planning menu will be disabled. [16808]
• Since the Path Reports and RIB Browser depend upon the network model not changing while they are open, most planning operations are disabled when either of these reports is open. In the HP RAMS 9.20 release, these reports are also forced to close when switching modes to or from Planning, but that restriction will be removed in the next release. [17743, 17965, 18030, 18088, 18268]
• When adding a VPN prefix, it is now allowed to specify an MPLS label associated with a VRF for which no routes had been received. The MPLS label is validated to be not in use by any other VRF. However, when editing a VRF that does have MPLS labels associated, the set of labels cannot be edited because they are in use already. [16156, 17918]
• The color of group links on the map (that is, those connecting to a cloud) was not being updated correctly when some of the links in the group were simulated as down or up in Planning mode. Now the color changes to one line red if some links are down and both lines red if all links are down. [17257]
• EIGRP and BGP prefixes added in Planning mode were not completely removed when the edits were undone, leading to a possible crash when accessing the Assign Names -> IPv4 Prefixes table. Now they are removed, as they were for OSPF and ISIS before. [16603]
• After adding an IPv6 prefix to an OSPFv3 router and then opening the list of prefixes on that router, the list of prefixes would be correct until the edit was undone, at which point the table would become empty. Now just the prefix added in the edit is removed from the table. [16732]
• Attempting to change a down EIGRP router to be up did not work, but now it will. [17474]
• Taking down an eBGP peering from an Originator node now withdraws all of the routes obtained over that peering in the same manner as taking down an eBGP peering from a peer node. [17810]
• If the BGP recorder peers directly with a router and as a client of a route reflector that peers with the same router, then the recorder will hear some of the same routes twice. Now if the eBGP peering is simulated down in Planning mode, both sources of the route will be marked down. [17975]

• The EIGRP routing calculation now performs the EIGRP split horizon policy correctly, which requires that a route not be sent out through the same interface on which is is received. Since there can be multiple adjacencies over a single LAN interface, this requires tracking which physical interface carries each adjacency. [17264]

• Consolidation between protocols for interfaces on a router will now match up an address that is secondary in one protocol with the same address as primary in another protocol. [17851]

• The MTU of GRE tunnels can now be adjusted in the range [576,65504] on the Network and Interface page. This is an increase from the range [576,9000] implemented earlier, and is in addition to the ability to adjust the MTU of physical interfaces in the range [576,9216] that was added in 9.3.22-R. [9862]
• The View Log page will now include log messages from the mailer daemon, which may be helpful for investigating DNS server problems. [17458]
• The Daily Routing Report now includes information on OSPFv3 databases as for the other protocols. [17982]
• The BGP recorder peering status is now displayed correctly even if the IPv4 address family is not included among those being recorded. [18210]
• On the Recorder Configuration page of the web UI, the display of the logged-in username was sometimes different from the actual logged-in user. Now it is correct. [17036]
• The Database Administration web page on a Modeling Engine unit would show an alarming and misleading message about no databases being present, which was actually the expected condition. Now the user is referred to the Database Administration page on the recorder unit, which is where the databases are present. [17066]
• The checkbox for "Collect Static Routes" in the global section of the Collector configuration has been removed since it has had no effect for several releases. Collection of static routes from all routers can be configured using the checkbox on the default row 0.0.0.0/0 in the router-specific configuration section. [17970]

• Input parameter strings that are XML-safe encoded, such as "&" for the ampersand character, are now correctly decoded. Also, the BGP AS names in the output of api_traffic_neighbor_as_ipv4, api_traffic_source_as_ipv4, api_traffic_destination_as_ipv4, and api_traffic_transit_as_ipv4 are now XML-safe encoded. [17224, 18191]
• In the api_manage_config call, the topology name is no longer a mandatory element while specifying a group. By default it is the specified top-label. [17867]
• In the api_manage_config call, if a "get" operation was performed for some groups (any type), and then the same output was supplied as input for a "set" operation, the result was that the groups would be deleted. Now this is a NOP as it should be. [18153]
• In the api_manage_config call, is was not possible to add multiple Router State alerts that differed only in the selected alert condition (e.g., Isolation vs. Flap). Now all the alerts will be added. [18230]

• For state change alerts regarding the adjacency between an OSPF router and pseudonode when that router is the one elected as the Designated Router that the pseudonode represents, the name of the pseudonode is now displayed with "DR" appended so that the two roles of the router are distinguished. ISIS was fixed in HP RAMS 9.10. [16639]
• A bogus tunnel path change alert could be issued when there was a change in the tunnel hops but the LSP was down and remained down. Now there will only be an alert when the LSP comes up. [18080]

• The EIGRP recorder now supports collection of topology information from routers configured for VRF-Lite. The recorder determines which VRF to use for a given router based on the assignment of the interface through which the exploration reaches that router. [8396]
• The EIGRP recorder stores the prefixes of a route-filter ACL in a radix tree for economical storage and lookup costs. A radix tree can only manage contiguous wildcard masks (zeros on the left and ones on the right, with only one transition in the middle). In previous releases, non-contiguous masks were handled by enumerating all of the possible values as /32 prefixes so long as there were no more than eight 1 bits in the mask, otherwise the mask was treated as an error and ignored. Now any number of 1 bits contiguous on the right will not be counted against the limit of eight, so much larger common cases are handled. [5088]
• In earlier releases, it was possible that the Collector recorder may have recorded in its database two instances of a router, one corresponding to a time when the router was down and one when it was up. Similarly, if the software was updated from HP RAMS 8.xx to HP RAMS 9.0 while a router was recorded as down, that router might be shown as up even if it was taken out of service. These conditions are expected to be a rare. Updating to HP RAMS 9.20 should consolidate the nodes and show the correct state. [16138, 16142]
• When the Collector recorder is started, it will attempt to obtain a list of routers known from the IGPs right away, but if the IGP recorders are just starting as well, there may not be any routers known yet. Rather than waiting one hour for the next router list update, the attempts will be repeated with exponential backoff starting after 2 minutes. The result will be merged with the list of /32 prefixes configured (if any) to create the list of routers to query. [17448]

• Documentation now includes the new features (CSV export and OSPF graceful restart). Moreover, some missing filter expression terms are added, screenshots are updated, and other improvements are made.
• Documentation was added for the api_mp_vpn_connections call.

• The Flow Recorder includes a hidden debugging feature to write all the NetFlow packets into time-segmented files. When the feature is disabled, zero-length files were still created. Accumulation of a large number of those files caused customer concern. The empty files are no longer created. [17206]

• The Perl packages were updated to include security patches for several vulnerabilities: CVE-2010-1168, CVE-2010-1447, CVE-2008-5302, CVE-2008-5303. [15107]
• The configuration of the FTP server on the appliance has been changed so that file timestamps in directory listings are shown in the timezone set on the system rather than in UTC. [17123]
• When database replication is restarted, the database connection parameters are now set so that requests for a long period of time (such as 12 weeks) to be synchronized will not time out. [17299]
• When database replication is restarted, the database connection parameters are now set so that requests for a long period of time (such as 12 weeks) to be synchronized will not time out. [17299]

IMPORTANT: Consider your disk space requirements, fault tolerance needs, and ensure that all available physical drives are installed before powering up the HP ProLiant server for the first time.

Starting with the HP RAMS 9.xx release, the Flow Collector is only supported on DL380 G5, DL360 G6, DL380 G6, DL360 G7, and DL380 G7 hardware platforms. HP RAMS will require two logical drives be configured for a Flow Collector unit - the first logical drive must be set at RAID 1 + 0, the second logical drive set at RAID 0. If you have an existing Flow Collector unit running a pre-8.0 appliance version, you must re-configure the server with two logical volumes and install the 8.0 appliance version from a CD image. Failing to do so can cause unexpected behavior. Cases reported as such will not be supported.

When using a DL360 or DL380 G6 hardware platforms as the Flow Collector unit, it is required that the HP RAMS Flow Collector HiCap SW LTU license be purchased and installed.

For all non-Flow Collector units, HP RAMS will only utilize a single logical drive as configured on the ProLiant DL380/360 hardware; this means any extra physical disks configured in a second logical drive will be not be recognized by HP RAMS.

For detailed steps to configure an HP RAMS 9.20 Flow Collector, it is recommended that you use a HP Proliant SmartStart CD (shipped with the server). The SmartStart CD provides a more comprehensive Array Configuration Utility interface. See to instructions in the HP RAMS Appliance Setup Guide.

The following describes a quick way to configure a single logical drive.

During the initial power-up of a new server, an auto-configuration process uses all of the physical drives on the HP Smart Array controller to set up a single logical drive. The default RAID (fault tolerance) level used for the logical drive depends on the number of physical drives as listed below:

• 1 drive = RAID 0
• 2 drives = RAID 1 +0 (Mirrored set, total disk space* is the size of smallest disk)
• 3 or more drives = RAID 5 (Striped set with 1 drive used for parity, parity drive is not included in total disk space*)

* The available disk space is ~5% less than the disk's reported size. Every physical drive in an array will have the usable capacity of the smallest drive in the array.

NOTE: Multiple drives configured as a RAID 0 striped set will provide maximum disk space but will NOT provide any fault tolerance. If you install more than one drive intended for maximum disk space usage, i.e., not for fault tolerance, you MUST configure to use RAID 0 or the hardware will default to RAID 1 +0.

During the initial hardware boot sequence, you have the opportunity to accept the default logical drive configuration as shown above, or you can create the logical drive based on your drive space and fault tolerance needs. Watch for the following message during the boot process:

Slot 0 HP Smart Array Controller

Press <F8> to run the Option ROM Configuration for Arrays Utility

Press <F7> to Accept the default configuration - 2 drives in RAID 1 +0

For configuration options and details, see the HP Smart Array Controller Reference Guide .

IMPORTANT: Make sure the logical drive is configured as needed before installing HP RAMS. Any changes to the logical drive configuration, e.g., adding drives or changing the RAID level, will require a reload of the HP RAMS software and a restore (from backup) of the HP RAMS configuration and databases.

The following information is important for HP RAMS or the Traffic Analysis Add-on installation and deployment:

• For Route Recorder or Traffic Recorder:
  • BGP/VPN databases that are currently being recorded will be automatically renamed with a prefix "Pre94X" upon upgrading to HP RAMS 9.20 from an earlier release. As recording continues, a new database will be created. This rename was required to change the database schema to facilitate moving time in the GUI. [13806]
  • WARNING: Updating from any appliance version 7.5.xx or earlier to appliance version 8.0.xx on a 3510 unit that has an option card installed in slot 2 (the full-height slot) using Intel Gigabit Ethernet chips and a PCI-X bus (such as an Intel PRO/1000 MT or GT) will cause the network configuration to be reset. The same problem will occur on a 4000 unit with that type of option card installed in slot 3. A similar problem will occur for any platform with an option card installed that was not qualified for the version of software that is running but is qualified now. In particular, any system running software older than appliance software version 8.5.76-R with an Intel PRO/1000 PF card installed, or a system with any release earlier than appliance software version 9.2.xx with an Intel PRO/1000 MF or Intel Gigabit EF card installed, or a system with any release earlier than appliance software version 9.3.22 with an Intel PRO/1000 PT Quad Port LP Ethernet adapter (part EXPl9404PTL) installed. The network configuration and the recorder configuration will require patching before the software update to avoid the need to delete and re-enter the configuration. Users are advised to contact Technical Support for assistance. A test script that will check whether a particular system is vulnerable is available to be downloaded and run in the same manner as a software update. This problem is a consequence of a change in the Linux operating system to split the support for Intel Ethernet chips for PCI-X and PCIe into two separate drivers. This causes the device probing order and the eth interface numbers to change.
  • Event suppression specs now require the duration portion of the rate limit to be at least 30 seconds.
  • Graceful restart will fail if there are two peerings from the same recorder to the same peer router (which is not a useful scenario).
  • Software update directly to HP RAMS 9.20 from any HP RAMS 5.x or later release is supported.
  • After updating to HP RAMS 9.20, requesting to revert to the alternate software and OS or attempting to software update to a version older than HP RAMS 9.20 will result in a warning that the appliance will be reset to factory defaults. If the user still decides to go ahead, all recording configuration, databases, user accounts, etc., will be deleted, but licenses are retained.
  • The password on the Queries page must be set again after updating to this release from a release prior to appliance software version 6.5.xx even if the password is not changed. That is because the password now needs to be stored in unencrypted form whereas it used to be stored only encrypted.
  • A RAMS Traffic system or a distributed RAMS system is comprised of multiple units. One unit will be designated as the master. All licenses MUST be applied on the master, which will then distribute the licenses to the client units.
  • Before adding a client unit to the master unit using the admin web interface, make sure that both units are configured to run NTP and that time on the client unit is no more than a few seconds behind the time on the master. Otherwise a warning will be issued and the client will not be added.
  • Before shutting down or rebooting a unit that is recording routing or traffic data, first stop recording and make sure that it has stopped by verifying the status on the web page or using the status details available by clicking on the status LED in the GUI. This is to allow time for the recorder daemons to flush any data or reports that may have been in progress.
  • When updating to a new software release, update the master unit first and let it finish coming up after the reboot before rebooting the client units.
  • Before adding a unit as a client, recording must not be running on that client because the databases will be renamed. If recording is not stopped, a warning will be issued and the operation will not complete. [8437]
  • When a new system is first being brought up, it may be necessary to exit the GUI and the start the GUI again if the database has not been created before the GUI was started.
  • For RAMS Traffic
    • Since release appliance software version 6.0.xx, Flow Recorder units have required a RAID configuration with two volumes so that raw flows can be recorded on a separate volume to avoid disk contention. As a temporary measure, a unit configured with a single RAID volume was still allowed to run as a Flow Recorder, but would not record raw flows. As of the appliance software version 9.0.xx release, it is imperative that Flow Recorders be configured with two RAID volumes, otherwise the traffic reports will not be generated correctly. To emphasize this, the warning message shown on the Flow Recorder configuration page if the configuration is not correct has been strengthened to state that "NO TRAFFIC DATA WILL BE RECORDED." The Flow Recorder will not start recording. [14334]
    • In the appliance software version 9.2.xx release, the RAID configuration check is now more strict for the non-Flow Recorder units as well. There must be a single RAID volume configured as RAID 1+0. This guards against an accidental misconfiguration of RAID volumes during manufacturing. [17401]
    • The NetFlow sampling ratio should be set appropriately for the traffic level. For a small ISP, a ratio of 4 to 16 could be enough. For larger tier-1 ISP, a sampling ratio of 1024 to 2048 is fine. We recommend that the ratio not be set higher than 8192 to avoid introducing too much inaccuracy.
    • Make sure that the NetFlow sampling ratio specified in the Flow Recorder configuration matches the sampling ratio that is configured on each exporting router. The sampling rate may be set to different values for each exporter if needed. If these settings don't match, RAMS Traffic will over-report or under-report the traffic levels. RAMS Traffic does not currently have any means to detect a mismatch on its own.
    • We recommend that the NetFlow active flow timeout, which is used to detect long-lived flows, be reduced from its default value to no more than to 15 minutes and preferably to one minute. If the aggregation cache is used, its active timeout must also be similarly set. Exceeding these times can cause NetFlow data to be delivered to the Flow Recorder too late for processing, in which case it will be dropped. For the inactive timeout, the default value need not be changed.
    • When opening a collection of topology databases including traffic, the GUI will start in Analysis mode, rather than Monitoring mode, and with the selected time set to the ending time of the traffic data which is typically 20-30 minutes earlier than the current time. For a display that follows the latest traffic data as it becomes available, Traffic Tracking mode can be enabled in Administration -> Options.
  • WARNING: Older hardware G3 series (1200, 2400) cannot run in 64-bit mode and therefore cannot be updated to HP RAMS 8.xx or newer. If an update is attempted, the system will fail to boot up. To recover the system will require reinstalling the earlier version of software from CD with loss of all data. In addition, the 2500 hardware is not supported for 64-bit releases because it is limited to 3GB of memory which is not sufficient. [11783]
  • HP RAMS 9.20 uses a licensing version different from HP RAMS 5.x. For this reason, supported migrations of previous versions of HP RAMS (5.x) license keys must be migrated ( http://webware.hp.com/ ) for use in HP RAMS 9.20.
  • After you update from HP RAMS 5.x to HP RAMS 9.20, if you ask to revert to the alternate software and OS, you will receive a warning that the appliance is reset to factory defaults. If you choose to go ahead, all recording configuration, databases, user accounts, etc., are deleted.
  • When updating to a new software release, update the master unit first, and let it finish coming up after the reboot before rebooting the client units.
  • When updating from pre-HP RAMS 8.01 versions, any custom configurations done for the alerts in the previous versions will also have to be manually migrated. This is required since the PD-ROUTE_EXPLORER MIB mib-tree structure has been changed in order to provide a streamlined, smaller set of well-understood, concise alerts in the HP RAMS 8.01 version. Consequently HP RAMS SNMP trap OIDs from the HP RAMS 8.01 release are not compatible with previous versions of HP RAMS.
  • When updating from a HP RAMS 5.x version, the databases are automatically renamed with a "Pre60X" prefix because the database table structure has changed. The older databases can still be viewed, but recording to them is not allowed.
  • When updating the software from a pre-HP RAMS 8.01, the existing accounts configured on each unit will be transferred into the new local authentication server running on that unit. To switch to a single authentication server on the master unit, a common shared secret must be configured on the master and each client unit.