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

HP RAMS 9.10 includes the following major, new features:

• RSVP-TE Tunnel Monitoring
  A new feature for the 9.10 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. Release 9.10 added dynamic monitoring and analysis of tunnels created with RSVP-TE to follow traffic- engineered paths.
  RAMS will periodically gather 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.
  Because RAMS continuously monitors IGP routing to detect link state changes, it can infer 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. Future changes in the configuration of the tunnels due to periodic reoptimization can be anticipated based on the timer values gathered earlier. 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.
  A future release of RAMS will add TE tunnel planning capability to allow simulating changes to the tunnel configuration in a manner analogous to the existing planning features for IGPs and BGP. In Release 9.10, if RSVP-TE databases are opened, Planning mode is disabled. To use Planning mode, deselect the RSVP-TE databases in the Open Topology dialog.
• Support for OSPFv2 Graceful Restart Helper Mode and Demand Circuits
  In earlier releases, routers that peered with the Router Recorder could not use OSPFv2 Graceful Restart because all peers of a router must support Graceful Restart Helper Mode before you can use this operation. A Route Recorder supports this mode if enabled in the OSPF recorder configuration. After you enable this feature, the recorder will send its own Router LSA when appropriate, and during a graceful restart of the peer it will reflect the peer's Router LSA and Network LSA. No other LSAs are sent. In this mode, the link from the recorder to its peer will no longer be red on the map. The Router LSA is sent with metric LSInfinity to reinforce the recorder's role as a stub, and it includes the DC option bit set so that demand circuits can be used within the OSPF network.
• CSV export
  This feature is used to export the contents of GUI tables as comma-separated-values (CSV) files.The dialog shows the number of rows selected so the user can judge whether the result might be too large, and the exported reports now include metadata to show the report name, network time, report generation time and table filter information. Also, the format was corrected to separate fields with just a comma and no space.
• Notable Changes in the GUI and API
  HP RAMS represents multi-access network segments in OSPF and ISIS networks with a pseudonode (a small circle icon) to reflect the way those protocols construct an adjacency from each router to the subnet and from the subnet to each router, rather than a full mesh of direct connections among all the routers.
  
  In past releases, when calculating a path across the network, the hop across the multi-access network segment was counted as two hops, one from the upstream router to the pseudonode, and a second from the pseudonode to the downstream router. This matches the treatment of the routing protocol, but does not match what users might expect when comparing the path to the result from traceroute, for example.
  
  In this release, the path list as shown in the List/Find Paths dialog in the GUI and as returned in the XML RPC API will include a single hop from the upstream router to the downstream router, omitting the pseudonode. In the GUI, clicking on that hop in the path list will highlight the arrows on both halves of the hop. The calculated path cost is not changed because the metric for the hop from the pseudonode to the downstream router was always zero, but the count of hops is reduced. In addition, the List/Find Paths dialog now shows a graphical path map to complement the listing of path hops.
  
  There is a separate change in the way paths are indicated on the map. In previous releases, if a bi-directional path calculation was requested, the forward path was indicated by green arrows and the reverse path was indicated by orange arrows. In this release, the color is green for both directions, but the reverse path is indicated by dashed arrows. This change was made to keep the color choice consistent with the tunnel map where different colors indicate paths through primary, secondary and FRR tunnels.
  
  The "information panels" that are accessed by a right-click on a node or link on the main topology map are now called "inspectors" instead. Each inspector shows tabs for the protocols that present. The tab that was previously labeled "Collector/base" is now labeled "Details"; it displays the general information about the node or link that was obtained by the Collector recorder. A new tab labeled "RSPV-TE" displays information about the tunnels present on the node or link. In addition, the layout of the information on each tab is now more compact and functional by replacing some of the action buttons with web-style links on the associated statistics. For example, instead of including a Prefixes button, the count of prefixes is now a link.
  
  In earlier release, three XML RPC API calls were added to allow external processes to configure IGP router, adjacency and prefix alerts. In the 9.10 release, a new API has been added that covers the configuration of these alerts plus BGP alerts. The new API is the first increment of the complete export/import of the unit configuration in XML format.

• Integration with HP Network Node Manager (NNMi)
  HP RAMS 9.10 in integration with HP NNMi supports:

  • NNMi Root Cause Analysis (RCA) for the following HP RAMS forwarded traps:
    • rexAdjDown
    • rexAdjUp
    • rexRtrIsolated
    • rexRtrConnected
  NNMi RCA for these traps will be done at real time.
  • Multi Tenant Architecture for MPLS WAN cloud in HP NNMi.
• VPN Details in Traffic Reports
  The BGP traffic reports for Egress Routers, Neighbor AS, Transit AS, Source AS, and Destination AS have been moved from the IPv4 section of the traffic reports navigation tree to the Aggregate section because those reports include VPN traffic (beginning in the 8.5 release). As part of this change, the source AS for the VPN flows is now correctly determined so those flows can be considered for the Source AS report. To facilitate distinguishing the contributions of the different types of traffic, a new drill-down by Address Family has been added in this release.
• Combined Source/Destination AS Traffic Report
  In the 9.10 release, the Traffic Reports navigation tree provides a new selection to show a report that combines the Source AS and Destination AS reports into a single report showing both the amount of traffic sourced from each AS together with the amount of traffic destined to the same AS. As with other traffic reports, pairs of these columns can be added to the report for different periods and statistics.
• New Traffic Tracking Mode
  In the 9.10 release, users who would like to display the network map with links colored according to the most recently available traffic utilization data can enable a new map mode called Traffic Tracking mode. That mode will then be added to the selection list along with Monitoring, Analysis, and Planning modes. Because the traffic data is produced through a process of sampling and aggregation, the display may be delayed up to 30 minutes. The display will update every five minutes as new averages are prepared. The network topology and routing will be shown as they were at the time corresponding to the traffic data update.

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 9.xx releases because it is considered a security risk.

• Important: HP RAMS integration with NNM
  • Since the HP RAMS 8.01 release, the integration of HP RAMS is with the NNMi series alone. The integration of HP RAMS 8.01 and upwards with the NNM 7.x series is not supported.
  • No separate NNM Integration Module is available for HP RAMS 8.01 and upwards apart from the integration, that is part of the NNMi series.
• Reverting to HP RAMS version 5.5 from HP RAMS 8.01 or higher hangs at grub
  

  This requires the deletion and recreation of the logical drive. The steps to perform that are detailed below:

  • During the boot sequence, the following message would appear:
    

    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

    At this point,

    • Press F8 to enter the array configuration utility.
    • Delete the existing logical drives first.
    • Create a new single logical drive containing the 2 disks.
    • Reboot the system and proceed with the HP RAMS 5.5 installation.
• In releases before 9.10, it is 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. These conditions are expected to be a rare. Updating from 9.0 to 9.10 while a router is in the down state will not be a problem, but if these problems were introduced by an earlier update, updating to 9.10 won't fix the problem. A consequence can be two nodes on the map for the same router, one of which might be shown as down. Other protocols on the router might be combined with the dead instance rather than the live one. If this problem is observed, the best workaround is to rename or delete the Collector database so that a fresh recording can be started. If loss of that history is not acceptable, then the two router nodes can be merged using the Combine Routers dialog. In some cases, existence of two instances of the same static node can cause the GUI and some daemons to crash immediately upon loading the Collector database. If that occurs, the Collector database must be renamed or deleted.
• 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.
• In the 9.10 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.
• 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.
• In the 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.
• HP RAMS's 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.
• f the Route Recorder is configured as a BGP peer with a Cisco router, and the router is configured to send MPLS L3 VPN routes, but you disable MP-BGP support of unicast IPv4 routes (AFI 1, SAFI 1), the BGP peering will constantly reset.
• 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.
• 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.
• 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.
• 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 8.0 were more lenient and would accept just an address without the mask.
• Since release 6.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.
• 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.
• After upgrading from HP RAMS 8.10 to 9.10 or during restore operations using the System Configuration and associated reboot , it is a must to configure IP addresses and network settings again. This is applicable to:
  • Administration Interface
  • Interface Names
  • Static Routes
  Note: Route Recording configuration and TE Tunnels configuration remain as is, and need not be re-configured.

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

• A new GUI option has been added to control whether route recorder node icons are displayed on the topology map. The default is that these icons are hidden. This option does not apply to EIGRP, for which the route recorder icons have never been shown.
• A "Cluster ID" tab has been added in the RIB Comparison and Event Analysis tools to show distributions according to the BGP cluster address values.
• The Routing Reports -> VPN -> Prefixes table will identify routers by router name rather than IP address when the name is known. The names are shown for the Prefixes drill downs as well.
• When routers are grouped into containers on the topology map, mousing over the grouped links between containers will now show a popup of information about the constituent links.
• Many of the table filters that were based on matching text, such as for a Message or Description column, were doing case-sensitive matching. This is now changed to be case-insensitive so it is similar to the behavior of other software systems.
• If an OSPF link has both a base adjacency (Router LSA) and a TE adjacency (Opaque TE LSA), the link will now be displayed as a single line, not a double line indicating multiple adjacencies. The TE adjacency is considered to subsume the base adjacency.
• In a BGP RIB Visualization with a very large number of routes, the text in the nodes might be shown in too small a font to read. That problem is now fixed.
• In the Network Summary on the map, the count of isolated routers could become negative when moving time to a period when a router was isolated and then to a time when it is reconnected, or when moving time back to the beginning of beginning of the Collector database. Those scenarios are now counted correctly.
• On the topology map, routers that are covered by the selection rectangle that was extended to add some other router, but are not themselves selected, can now be added to the selection with Ctrl-left-click in the same manner as routers outside the selection rectangle.
• With the topology map in Group Edit mode, dragging a router node into a used defined group worked, but dragging one out did not. Now the removal operation also works.
• When the Routing Stability reports are first opened, if no topology selection was made earlier, the entire topology hierarchy will be selected.
• The topology map node representing an eBGP nexthop for a router configured with next-hop-self could be incorrectly consolidated with an ASBR in another AS that is advertising and external route with the nexthop address. Now such nodes will not be consolidated with any other router node.
• Turning off the GUI preference option to "Show Standalone BGP Next Hops" would sometimes not be effective when the Combine Routers feature had been used while showing of the nexthops was enabled. This is now fixed.
• On the topology map, a right-click on a router will still display the inspector panel for that router, but it will no longer cause the router to be the selection. This avoids some anomalous behavior such as accidentally zooming to just that one router.
• Interface information from the Collector recorder will now be shown on the map inspector panel for links representing point-to-point IGP links or eBGP peerings so long as the interfaces are of serial type. The Collector links will only be suppressed if the interfaces are of LAN type, requiring a pseudonode, since then the link could not be consolidated with the IGP/eBGP link.
• In the RIB Visualization, the threshold for hiding edges can now be specified with increased precision of 0.01 rather than an integer value. This allows seeing more detail. Also, the pixel width of a link would scale to be too fat when zooming in. Now the width remains constant so that zooming can be used to decrease map density.
• The Flow Record Browser has been enhanced to allow selecting multiple rows and then drilling down to Detailed Flow Records to see an aggregate list of all the individual flow records comprising the collection of selected rows.
• From any traffic report, you can now drill down to the Flow Record Browser to see the prefix-level flows comprising the selected items. Previously this drill-down was available only from a few selected reports. In the reports for Source AS and Destination AS, when drilling down to see the flows comprising a particular entry, the sum of the data rate of the flows did not exactly match the amount shown in the entry because some flows were missed. Now all the appropriate flows are included.
• In the VPN section of Traffic Reports, the Ingress PE report would mark some traffic as belonging to an "Unknown" PE if the address of the egress PE as received from LDP (which is the IGP router ID) was not the same as the address used for the BGP peering with that router. Now the router can be found using any of the addresses known in the network model.
• The number of flows shown in the node or link inspector (info panel) on the map was higher than it should have been in some cases because duplicate flows were sometimes included. They are now properly excluded so the count is accurate.
• In the VPN Status Reports, drilling down to the Interfaces table for a particular customer might show an empty table if there were multiple customers for the same RT value. Now the interfaces are listed correctly even in that case. Also, filtering the VRFs table by PE address was producing an empty result, but now correctly shows the matching entries.
• For better support of OSI networks without IP, the Router Names table that maps router addresses to names can now accept NSAP addresses in addition to IPv4 or IPv6 addresses.
• User-assigned router names were displayed only when the node label mode was Automatic, not when the node label mode was Router Names. Now the user-assigned names are displayed with either selection of mode.
• In the Router Groups browser, automatically created child groups for network areas are supposed to be displayed with the common prefix of the parent group's name elided. An uninitialized variable caused this suppression to occur only randomly, but that is now fixed.
• Some instances of the string "Static Recorder" in List Topology Errors, the GUI recorder status window, and the status table on the web Recorder Configuration page for the Collector have been replaced by "Collector" to be consistent.
• An incorrect optimization caused all flows over the same path to be considered as having the same EXP bits even if they did not. Additionally, non-VPN flows carried in MPLS tunnels were classified by their IPv4 TOS bits rather than the EXP bits. Now the EXP bits of each flow are used for classification.
• When a point-to-point IGP adjacency is configured with /30 or /31 subnet lengths on a multi-access medium such as Ethernet, the Collector topology will now treat the multi-access interfaces as serial interfaces and create a direct link that is consolidated with the IGP link rather than suppressing the Collector link. This allows the collected interface information to be associated with the IGP link.
• In the GUI, when the color of a topology area is changed in the Options dialog, that change is now immediately reflected in the map and in the Network Summary list.
• The drill-down arrow button on the Traffic Reports - Top Changes pages is now disabled until a table entry is selected since until then nothing can be shown.
• The RIB Browser for ISIS now ignores ROUTE-RECORDER nodes and links to such nodes when counting and displaying the list of links that are down to give an accurate state of the network.
• The GUI displays a warning banner at the top of the map if the license is about to expire. That banner can now be removed by clicking a new Dismiss button.
• In the Path Reports configuration dialog, if the Destination Routers selection was Specify by Groups, no routers would be selected. This now works.
• When taking either a snapshot of a report or a CSV export of a report such as Traffic Reports-> Aggregate-> BGP-> Source/Destination AS, the tier 1 heading (that is rate and delta column as shown in attached snapshot) was missing in the output. This is now fixed.
• Status messages, such as the cost of a path, could remain in the status bar of the map window after Close Topology. They are now cleared.
• For the MPLS WAN feature, it is now possible to configure a site to be recorded with only a Collector recorder and no IGP or BGP.
• In the Event Analysis table, the user can now select multiple rows and then use the context menu to see the events corresponding to those rows.
• The Set Interface Capacities table was improved in several ways: when the Save button was clicked, the status bar message reports the number of links that were changed rather than the total number that have a configured bandwidth set; the table can now be opened and used in Monitoring mode, and in Planning mode the table can be open but changes are not allowed; rows that are created for Collector interfaces that don't have associated links now show the configured capacity as "--" to make clear that the value cannot be edited; and when changes are made, the scroll position of the table properly stays where it is.
• VPN reports have been enhanced so that row selections are not lost when the table is reloaded, and the drill-down menu options are shown on the first click.
• When the topology map is zoomed, a small navigation map is displayed in the lower right corner. Updating of that navigation map image was causing the UI to be sluggish, but that updating has now been optimized to remove the problem.
• The GUI could become unusably slow when the network map contains many nodes and there are hierarchical groups overlapping some of the nodes. The expensive operation has been removed to eliminate this problem.
• The GUI could hang if the user requested the Resolve DNS operation from Admin -> Assign Names -> Routers and then attempted to cancel the operation. Now the work is done on a separate thread and the cancel operation is effective.
• The GUI could crash if a table that was organized by grouping the items in one column was subsequently reorganized by grouping the items in a different column. This is now stable.
• A crash from improper handling of static nexthop nodes connected via point-to-point interfaces has been fixed.
• The GUI could crash when the user tries to add a peering between two OSPF routers that already have an invisible virtual link between them. Now the situation is detected and a message is displayed to explain that adding a link in this situation is not yet supported.
• The GUI could crash when selecting a row in the Flow Records Browser report on Protocols and then right clicking to bring up the context menu. This is fixed.
• The GUI could crash when showing the area groups in the Router Groups dialog if one of the groups had somehow become a child of itself. It is not clear how that could happen, but now this situation will be detected, logged and repaired.
• A new router search box has been added to the status bar of the main map window. This is an easier-access alternative to the Find Routers dialog, which may be removed in a future release. A search icon at the left end of the text entry box brings up a menu with previous search results that are saved across GUI restarts. As text is entered, if there are any matching entries in the previous search results, those are displayed in a menu for easy selection. An "X" cancel icon is displayed at the right end of the text entry box when text has been entered. The animation playback controls that appear in the status bar when the date/time selector is activated have also been redesigned in a more compact form using icons, and the management of multiple status messages in the status bar has been improved.
• The recorder status "LED" icon in the status bar of the main GUI map window now conveys additional states for the Collector recorder. The LED will still be blue (a darker blue now than before) during exploration, and at the end of collection the LED will still be yellow if zero routers have been collected. However, now the LED will be cyan (a color between green and blue) if some routers were collected but some are inaccessible. The LED will only turn green if all of the routers were collected successfully.
• The Routing Reports and Routing Analysis Reports have been reorganized into Routing Status, Routing Stability, and Routing Comparison reports to group together those that are most often referenced together for a particular task. The Routing Status reports are split into four different groups: IP, VPN, and WAN (the appropriate subset would be included based on license).
• The navigation tree shown on the left side of many of the reports can now be hidden to leave more room for the table columns and inspector panels that display the report data. When hidden, the items in the navigation tree can still be accessed from a drop-down button.
• In the Administration -> Options dialog for user preference options, the Miscellaneous tab has been renamed to General and moved first in the list. On the Map tab, a new option was added to control whether or not Route Recorder icons should be shown on the map, and the option to hide links now allows multiple link groups to be specified.
• The HP RAMS 9.0 release introduced a Combine Routers feature to manually correct problems with consolidation of router nodes on the map in case the automatic procedures fail. In this release, the Combine Routers table now indicates what manual changes have been made, and it allows restoring the default configuration for any selected rows in the table.
• The options dialog for the Event Operations filter on tables of events now groups the Add/Drop/Change options into a grid to be more compact and easier to select. Separators have been inserted between sections of different kinds of options.
• The HP RAMS 9.0 release included a new feature to export the contents of GUI tables as comma-separated-values (CSV) files. In this release, the dialog shows the number of rows selected so the user can judge whether the result might be too large, and the exported reports now include metadata to show the report name, network time, report generation time and table filter information. Also, the format was corrected to separate fields with just a comma and no space.
• The behavior of selections in the Open Topology dialog has been improved to facilitate making partial selections of the topologies in a network. If all the children of a collapsed item are selected and the item is expanded, it gets deselected because otherwise selection of the parent item implies that all of its children should still be included.

• When adding a new router on the map, the node will be correctly placed where the user clicks rather than in some other random position. Also, the name added for the new router is properly removed from the Router Names table when the edit is undone.
• The Show Edits table would list an OSPF or ISIS edit even if the edit was not successful, such as trying to bring up a link on a down router. Unsuccessful edits result in an error message but are no longer entered into the Show Edits table.
• The operation of adding an IPv4 prefix to a disconnected Originator router could fail with an unrelated error message. The underlying problem has been fixed so that the operation will now succeed.
• The Down IPv4 Prefix and Down IPv6 Prefix operations are now consistent for all protocols in not listing as candidates those prefixes that are already down.
• If BGP routes are added to a router, and then the router is brought down and brought back up, the added routes would be missing. Now those routes will be restored.
• When editing VRFs and performing a sequence of edit steps, all entries listed in the Edits table showed the import policy as revised by the last edit even though the import policy had not been changed when the earlier edits were done. Now each edit shows the state as when it was done.
• After undoing a flow edit that affects flow de-duplication (such as moving a flow to interrupt the flow from another exporter), traffic values might change when doing some other unrelated edit such as adding a VPN customer. Now the de-duplication is recalculated correctly.
• The GUI could crash when the List/Find Paths dialog was open in Planning mode, then a router was downed, and then a drill down from a path in the list was selected.
• If a prefix was added to an EIGRP router, then that prefix was marked down, and then Undo All Edits, the GUI could crash.
• The GUI could crash if an edit to mark a PE router down creates a flow on another router not known to be an exporter, then Analyze Edits is performed, and then the edit is undone. Those steps are now processed correctly.
• The GUI could crash if the Down button on a Collector or EIGRP/static tab of a router info panel was clicked because edit operations are not supported for the static topology. Now those buttons are removed.

• At the end of route selection within a particular protocol topology, if the best route found is a (redistributed) self-originated external route, fail the route lookup for that topology and do not consider any other route in that topology. This follows router behavior.
• Route resolution was incorrect for some flows collected on the CE-PE interface in a hub-and-spoke network topology because it did not correctly model the Cisco IOS behavior. Now the routing considers locally-originated routes with an RD matching that of the relevant VRF in addition to remote VPN routes that pass the import policy.
• In an MPLS WAN network with hug-and-spoke routing, finding a path could fail for a case where a VRF has no export policy, only an import policy. Now the import policy will be used to determine the customer in that case.

• The System Information download on the web support page now includes expanded information about any core files that may be found.
• A message indicating success or failure is now displayed after one of the three Instant-On license buttons is clicked. In particular, if the allowed period for use of an Instant-On license is exceeded, then the attempt will fail. During that period, the user can click the "Remove all licenses on this unit" button and then select another Instant-On license button for a different unit role. That button was previously not working.
• In previous releases, if the disk became full or read-only, an attempt to log in on the web admin UI would just result in the login page being redisplayed. Now the login will succeed and a warning message will be displayed indicating the condition.
• If any VLAN interfaces are configured on the recorder, those interfaces will now be available in the physical interface drop-down list on the Traffic recorder configuration page.
• When the configuration of a unit is restored from a backup file, the IPv6 Prefix groups will not be properly restored.
• On the Report Scheduler web page, a button has been added to allow updating just the mail configuration since that configuration may be needed when emailing reports exported from the GUI even when Health, Routing or Top N reports are not used.
• After making changes to the recorder configuration for an IGP, such as changing an interface from active to inactive and back, and error like "Duplicate entry ... for key 2" might be logged and the interface field in the status table on the recorder page might be blank. This is fixed.
• Login messages configured for the admin web UI are now filtered to remove HTML tags for scripting and other operations that could cause problems.
• The icon returned by the appliance web server for the browser to display in the location bar is now the icon designed for this application rather than a nondescript target icon
• To improve the robustness of daily Routing Reports, acquisition of the data from the QueryServer is scheduled for three minutes after the hour to avoid contention with the Collector, and the queries will be retried if the server is busy. If unsuccessful even after 10 tries, an informative message is displayed in the report to facilitate investigation of the problem.
• On the Software Update page, the Update All function would show a misleading error message suggesting that a software update license was needed when, in fact, the problem was that one of the clients had previously been left in the state where the Software Update page was showing the Finished button, or some similar condition. Now a more appropriate message is shown.
• In the configuration of the Collector recorder, a checkbox has been added to disable the minimum interval between queries to routers outside of full exploration, rather than interpreting an interval of 0 to have this meaning.
• The Technical Support Callback function has been enhanced to display an expanded set of status messages to indicate different modes of failure for the callback function. It can now detect when a middlebox appears to complete the ssh callback connection but does not pass data. It will also retry more quickly in the event of a port number collision at the callback server, and it delivers addition unit information (software version, Unit ID, serial number, and database top-level names) to the server to help identify each customer.
• The MTU of physical interfaces can now be adjusted in the range on the Network and Interface page. This is in addition to the ability to set the MTU for tunnels added in HP RAMS 9.0.

• In previous releases, the Interfaces web page did not prevent an alias or VLAN interface from being deleted if a GRE tunnel was still configured to use it. In one instance, the resulting invalid tunnel caused a crash in a recorder process that had been configured to use the tunnel. Now the web page checks for tunnels using any interface before deleting the interface, and the recorder process will ignore any interface or tunnel that does not have a valid address.
• BGP recorder can be configured to accept and record any combination of IPv4, IPv6 and VPN prefixes, each of which goes in a separate topology database. This release removes a problem that BGP peers that were not participating in one of the address families could still be recorded in the associated topology.
• The ISIS recorder now sets its own values of 10 and 30 for the hello interval and hold time rather than reflecting the values sent in the hello packet of its peer router. This avoids times that are too short for the recorder to maintain the adjacency.
• Transmission of IS-IS Hello packets is now more robust; it will ignore Hello packets from another IS that do not include the recorder's own system ID in the list of IS neighbors so that such Hello packets will not be reflected by the recorder.
• Support has been added for recording and displaying Shared Risk Link Groups (SRLGs) on OSPF unnumbered interfaces.
• The list of mismatched distances reported by the EIGRP recorder no longer includes the invalid entries for external routes originated by the peer router. The peer will advertise that those routes to the recorder but won't use the external route itself (it would use the route from which the external was redistributed). Therefore it was incorrect to compare the advertised metric with the distance in the topology model from the peer to that prefix.
• If the configuration for the Collector recorder includes two /32 prefixes that are addresses on the same router, this will be detected and only one router node will be created.
• The Collector recorder could stop making progress in its full exploration if timers were set such that the interval between queries, after randomization of the delay, was zero. This is now fixed.
• The Collector recorder now supports PE interfaces in separate routing domains so that static links are not created between two routers that have interfaces configured with the same prefix but in different VRFs.
• In the Collector topology, the packet-over-sonet (POS) interface type has been added to the list of types that are considered as serial interfaces for creation of static links and static nexthop nodes. Interfaces of types 92 (Multiproto Interconnect over FR) is a candidate interface for creating a serial link, and type 161 (IEEE 802.3ad Link Aggregate) should result in a network link.
• The Collector recorder was creating extraneous pseudonodes on the map when it incorrectly interpreted internal interfaces (bcm, bme, fxp, em) on Juniper routers as real interfaces. A similar problem existed for EOBD interfaces on Cisco routers. These are now ignored.
• The Collector recorder failed to collect interface information from routers using the proprietary Cisco VLAN protocol called ISL. Now the subinterfaces of that type are captured with the limited details that are available.
• Fixed a problem that prevented the Collector from recording the data for routers explicitly identified with /32 prefixes if access to the QueryServer failed to get the router list.
• Collection of router details using telnet/CLI could fail if the login banner message contained some characters (such as '#') that could be misinterpreted by the parser as a command line prompt. This problem has been avoided by not looking for a command line prompt before the login sequence has completed. A second problem resulted from caching the result of a match to the command line prompt in a way that could sometimes result matching to the prompt of another router.
• The Collector recorder incorrectly parsed the interface capacity value reported by JUNOS routers as Mbps even when the value was reported in bps, kbps, or Gbps. Now the units are parsed and interpreted as provided. Also, those capacities reported as "T1", "T2" or "T3" are now interpreted as 1544 kbps, 6312 kbps or 44736 kbps, respectively, rather than "N/A".
• Under certain conditions when querying a JUNOS router using SSH, the Collector process could get stuck in an infinite loop. The defective library software has been replaced so this problem is fixed.
• The Collector recorder will now use the same address as was
• When a VRF is removed from a router, unnecessary error messages about not finding the VRF might be logged when VRF's static routes are also removed. Those error messages are now eliminated.
• The parsing of SNMP query responses will now tolerate tables where some of the data that should be present is missing (incomplete rows with ROW STATUS).
• The regular expression that is used to extract the router vendor name from the SNMPv2-MIB::sysDescr value has been relaxed so that it can work for experimental versions of Cisco IOS as found at some customers.
• The message warning that the Collector will not begin exploration until the next scheduled start has been generalized to not refer to SNMP since that is just one of the methods that can be configured.
• When the Collector recorder gathered interface information with SNMP, if a router queried at an address configured as a /32 prefix returned a list of interfaces not including that address, the collection would loop indefinitely. This is now avoided.
• The Collector recorder could go into an infinite loop if the "show class-map" output contained a certain error. This is now fixed.
• When the Collector recorder has a mix of CLI and SNMP queries queued, and if an SNMP query is delayed for some reason, then the CLI session could time out resulting in a crash when the session was used again after the SNMP query finished. Now a new CLI session is created as needed.
• A crash could occur in the Collector recorder when junoscript parsing errors were encountered due to a fault in the way that the parsing error message was prepared. This is fixed.
• When querying a JUNOSe router to learn its VRFs, a parsing error could cause the query to fail due to the inclusion of whitespace at the beginning of the VRF's RD string. The whitespace is now ignored.
• In any of the programs that load a network topology model, a crash could occur in networks where the Collector is recording PE interfaces in separate routing domains when a new interface is seen if some of the interfaces have previously gone down and timed out. A crash could also occur when two router nodes on the map for different protocols were discovered by the Collector to be the same physical router such that the two nodes were subsequently consolidated. Removal of an unnecessary operation avoids this crash.

• In the Collector recorder, several enhancements have been implemented in order to improve the discrimination between newly discovered routers and previously known routers with some configuration changes. First, the chassis serial number is collected if available. If not, when interface MAC addresses are available, they are used in preference to interface IP addresses for matching a new router against existing ones since IP addresses may change or not be unique. Also, to accommodate the case where many new interfaces are added (and therefore the percentage matching is small), if 100% of the previous interface list is included in the new router, it is considered the same router.
• When the Collector is configured to query specific interfaces, once it has queried the routers at those interfaces, it will match any of the other interfaces on those routers with interfaces known in routers recorded by the IGPs, including EIGRP, so that the routers can be consolidated.
• If two OSPF processes are running on a router, they must have different router IDs, and this would cause two nodes to be shown on the topology map. Now if the Collector recorder is enabled to query the router, the two nodes will be properly consolidated into a single node on the map.

• 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.

• Path alerts configured for the pair of a source router and a destination prefix were reporting bogus destination router information. This is now corrected.
• A significant memory leak in the QueryServer while loading and unloading routing topologies that included VRFs caused the query responses to time out, while system swapping. This is now fixed.
• Connections opened with api_conn_keep_open sometimes timed out and were closed by the server prematurely; particularly if the server had multiple clients. The timeout is now maintained at exactly 10 minutes.
• The result from api_mp_links for a link that contains multiple physical links reports the state of only those links that are Down. Previously the result used to display all the links as Up if the overall link was Up.
• The QueryServer could crash if it received a request to list paths originating at a router unknown in the network topology. Now that request will be indicated as invalid.
• A crash in the QueryServer daemon that could occur in a network topology with Static NextHop nodes is fixed.
• In the result returned by the api_mp_list_paths query, the struct for a hop across a VPN cloud now includes a new field for the VPN name that the user has configured for that cloud.
• A new field named "mpID", for multi-protocol ID, has been added to the MP router struct in the result of all queries in the XML RPC API using that struct, including api_mp_routers, api_mp_links, api_mp_list_paths. This ID allows correlation of routers in the different query results in order to accurately consolidate routers and join them with the links, and in particular to consolidate OSPF and Collector pseudonode instances. The addition of a new fields into the existing struct is not expected to cause backwards compatibility problems.
• When the Query Server loads a network topology using the MPLS WAN feature, the network model will be set to include BGP and Static nexthop nodes so that paths passing through those nodes to traverse the VPN cloud can be correctly calculated and returned by the api_mp_list_paths query.
• The output of the api_traffic_links call has been expanded to include the source and destination interface address, name, and index information when it is available and determinable (such as when there are no parallel links).
• In the api_mp_vpn_connections call, if an entry in the VPN Connections table is not part of a "site", then it is output with the site name "None". This avoids a QueryServer crash. In addition, do not create a potential VPN connection for a BGP peering if the originator is not in a site or the other node is not an BGP nexthop.

• Alert suppression was not working correctly when multiple alerts occurred in different network areas (topologies) during the same 30 second interval. Multiple alerts could be generated when the rate limit should allow only one. Now the rate limit is obeyed so long as the duration value is at least 30 seconds.
• The daemon that produces and dispatches alerts could lag if the event and alert processing in any 30 second interval took more than 30 seconds. The processing now catches up to real-time, in order to avoid accumulation of the lag.
• Alerts for OSPFv3 Router Isolation events could show an invalid address 255.255.255.255 for pseudonodes. The correct identification is now displayed.
• Fixed a problem that could cause a repeated Route Analyzer crash when attempting to send an alert for an OSPFv3 pseudonode if the DR interface could not be determined.
• Router Isolation alerts were incorrectly generated both at the time the router became isolated and again later when the routing protocol signaled that the router was down. Now the alert is issued only when theisolation occurs.
• The Adjacency Flap alert could stop being emitted because of an incorrect calculation of the sliding window for the interval in which the flaps were counted. This is fixed.
• In a large MPLS WAN network, the RouteAnalyzer process that writes reports could cause the MySQL server to consume 100% of the CPU. The database access is optimized, so the processing is no longer a problem.
• The RouteAnalyzer daemon that generates alerts could crash if an alert was configured using a path group containing a path defined with a destination node rather than a destination prefix. This is now fixed.
• When the Collector uses SNMP to find an interface that has type 53 (proprietary virtual/internal), the interface will now be considered a VLAN interface if it does not have a MAC address matching a physical interface for a more definite determination. This creates a static link.
• The Collector's parsing of interface index information retrieved from Cisco routers using telnet/ssh CLI queries is augmented to handle T1 interfaces and VLAN subinterfaces.
• When the Collector is obtaining interface information from JUNOS routers, the internal interfaces (fxp, em) are now ignored.
• A crash in the Collector recorder when using SNMP is now fixed.
• To avoid exceeding the system capacity for writing BGP/VPN history time series reports, the reports are no longer written for communities that are opaque RTs since this data is deemed not to be of interest.
• A change was made in the way the EIGRP route recorder issues CLI queries and parses the output to allow collecting interface index values on Cisco 12K routers.
• The EIGRP recorder now supports secondary addresses on interfaces of an NX-OS switch.
• The correct OID is now used by the Collector to get static routes from the inetCidrRouteTable, thereby avoiding error messages in the Topology Errors table.
• When collecting interface information using SNMP, the Collector will now use the IFXTable::name value if the IFTable::descr value is not available, thereby avoiding a failure to collect interface information.
• The Collector recorder could crash or stop making progress while exploring in some cases when an attempt to query a router using SNMP failed to connect.
• The EIGRP route recorder will now adjust the syntax of "show ip eigrp" commands to include the AS number only in a position where it is accepted by the version of IOS that is running on the router. This include new Cisco 3750 routers, and will accept new syntax variations in the output of such routers.
• In previous releases, a Prefix State Change alert configured for an IPv6 prefix group would not generate any alerts. That problem is now fixed.
• False alerts for BGP route state changes and for VPN PE participation changes were emitted when an element was in the Up state long enough to enter Baseline/Up state, or was in the Down state long enough to leave Baseline/Down state. Now alerts are triggered only for events that cause an actual state transition (up to down or down to up).
• In the alerts for Peering State, Prefix State, Adjacency State and Router State for IS-IS, the router IPv4 address fields were left as 0.0.0.0 even when an IP address was known for the router. The MIB description has been updated to indicate that an address would be present if available.
• For state change alerts regarding the adjacency between a router a 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.

• Some short traffic flows were erroneously being discarded as having an end time in the future because the flow duration was being artificially extended when that was not necessary. This extension is no longer done.
• Some Traffic Reports showed VPN traffic belonging to an "Unknown" customer even when the customer - RT mapping had been defined for that customer. This occurred when the mapping between RTs and customers was not 1:1. Now the customer assignment is correctly marked.
• If the Flow Collector report process failed at some time to access the list of topology databases on the Master ME when checking for changes in the hierarchy, it would fail to write reports after that until restarted.

• If an attempt to restart database replication failed repeatedly, the disk could fill up by the database binary log files. These are now cleaned up if the restart fails.
• Incorrect calculation of available disk space on the Modeling Engine caused the trimming of replicated databases to be too aggressive, thereby limiting the available history of topology changes and alerts.
• The Xvnc server for VNC displays 2 - 10 could be induced into an infinite loop consuming 100% of the CPU by an nmap portscan. This is now fixed.
• A log message about processes being restarted by the watchdog included the misleading phrase "with core dumping". This is changed to append nothing when the disk has sufficient space, and to say "without allowing core file dumping" when the disk is too full to allow additional core files.
• On the serial console and for ssh to CLI Access accounts, the traceroute diagnostic function now allows selection of the network interface to use instead of always using the admin interface.
• When using the tcpdump diagnostic on the serial console, extraneous messages about entering promiscuous mode were printed in the midst of parameter collection. These are now removed.
• After a software update from 8.0 or earlier to 8.5.43-R, which renames a Static/snmp database to Collector/base, errors could occur if replication was restarted on that database before a Sunday passed. An update from 8.0 to 8.5.65-R does not have this problem.
• The QueryServer daemon could crash when database access failed. This is now fixed.
• The Route Analyzer or Query Server daemons or the GUI could crash when the information from a router recorded by the Collector included an ACL with 1000 or more lines. This limit has been removed.
• Support is added for the REX 3600 platform using the LSI MegaRAID SAS controller.
• Robustness of the system assembly process for the REX 3600 platform is improved by supporting the internal DVD drive when plugged in to any of the motherboard SATA ports rather than requiring it to be the first port.
• The CD installation procedure is corrected so that it will work on the REX 3600 platform when configured with two RAID volumes for a Flow collector.
• The QueryServer and RouteAnalyzer daemons could crash when multiple router nodes on the map representing different protocols were consolidated to represent a single physical router if one of the nodes was from the Collector.
• Since the 64-bit architecture effectively does not impose a limit on the maximum memory size of a process the way that the 32-bit architecture did, we now enforce an artificial limit based on the physical memory size to avoid the possibility of a memory leak leading to swap exhaustion.
• Support is added for the Intel PRO/1000 PF dual-port fiber card. - The maximum number of CPUs supported was increased from 16 to 32.
• Added support for DL360 G7 and DL380 G7.
• On a system where more than 10 alias interfaces were configured, it was possible for GRE tunnels configured to use those aliases to be bound to the wrong alias. This is corrected.
• The "lastSplit" script, which is intended for support personnel to extract a desired time-slice from a database, has been augmented to properly handle traffic tables that have different trimming schedules.
• Added support for the Intel PRO/1000 MF (Gigabit Fiber LX) card and the Intel Gigabit EF (Fiber SX) card.
• There is a common Cisco IOS bug where BGP packets sent with TCP MD5 authentication will exceed the advertised TCP MSS (typically 1460) because the size of the TCP option is not considered. To avoid this bug, the recorder will always advertise an MSS of 1416 instead, which leaves enough room for the option.
• The set of cipher suites allowed in the HTTPS server has been revised to eliminate those with weak digital signatures (particularly ciphers using MD5 authentication). This change is made to help meet customers' security policies, but may prevent connections from very old browsers.
• A new file named /PATCHES is now installed with each software installation. Any time a patch is applied manually to a unit, that file should be updated with a note to track the patch. A patch installed with software update "pill" can automatically add a note. Those notes will be displayed on the Software Update page to warn the user to make sure that the new software being installed addresses those patches, and also shown in the system information downloaded from the Support page. The "Update All" function will not be allowed on a system with a patched unit.
• The RADIUS client implementation for user authentication has been enhanced for improved compatibility with a wider variety of RADIUS servers. Instead of mapping users into different hunt groups, this change employs a RADIUS feature known as Vendor Specific Attributes which is believed to be widely supported. This change also avoids multiple authentications for FTP access, which was incompatible with one-time-password systems. Backward compatibility with the prior RADIUS authentication scheme is retained, but may be deprecated later.

• The daemon that produces traffic reports could hang in a deadlock among the threads in the process, resulting no reports being available in the GUI. The operations are reorganized to avoid the deadlock.
• The daemon that produces traffic reports was leaking memory when NetFlow records contained an invalid System uptime. If repeated, this could cause slow system performance due to excessive swapping when all physical memory was consumed, and random killing of processes when all swap space was consumed.
• The Flow collector and the GUI could stop working while loading traffic groups that had a source port range whose end value was 65535. That limitation is removed.
• When attempting to use the Raw Flow Browser to view traffic data over a period of multiple days, on a 7.5.x system the raw flow server could crash if the 32-bit virtual memory limit would exceed. In appliance version 8.0 or later, the process would not crash but system performance could degrade. The algorithm that tracks flows crossing 5-minute boundaries has been changed to avoid the excess memory consumption.
• Static routes with a gateway or network nexthop now correctly recurse to the corresponding destination prefix, thus completing some paths that previously ended prematurely.
• The links to NextHop nodes will not be considered as connected routes, and connected routes to pseudonodes will not be considered when the pseudonode is down. Also, when a down pseudonode times out, any static NextHops connected to it will be removed. This avoids paths getting stuck at the down pseudonode.
• Drilling down to Flow Details would fail for flows for which a path could not be found. Now the flow details are shown correctly.
• A significant memory leak is fixed in the daemon that generates traffic reports on the Flow collector unit.
• A error message reporting failure of a database insertion when preparing a traffic report was sometimes logged at a very high rate, potentially clogging a remote syslog server. That message is now rate-limited.
• For EIGRP ACL route filtering, a route filter that permits selected prefixes and denies all others would prevent a metric offset filter from being applied to the permitted prefixes. Now the offset is applied correctly.
• Collection of traffic statistics for configured traffic groups is corrected to consider the source and destination addresses from each flow, rather than the more coarse prefixes into which the flows are aggregated. This accommodates traffic groups configured for prefixes longer than those carried in routing.
• The status LED on the map could be stuck yellow after updating from appliance version 7.5.x to appliance version 8.5.x because the status of the Raw Flow Report Generator is now handled separately from the Raw Flow Report Analyzer and status messages from before the upgrade were not cleared. Now the error status is cleared at startup.
• When deploying traffic on the topology, we can project the traffic one hop upstream from the incoming interface of the exporter router. Now if the previous hop is a pseudonode with only two links, the projection will be extended all the way to the router on the other side of the pseudonode.
• A crash in the daemon that calculates traffic reports is fixed.
• When calculating a path, we will now ignore an external route at the point of redistribution in case it is redistributed from an internal route that should take precedence but has higher administrative distance (for example OSPF redistributed into EIGRP). This means some that some paths that were previously marked complete at the edge of the recorded network will now be marked incomplete at the same router. The cost to reach that point will still be shown even though the route is incomplete.
• Route resolution was failing to find a path to a prefix, even though at least one Up route for that prefix was being advertised, because a Down route was chosen. The records of Down and Up routes are now kept to fix this problem.
• Traffic statistics for the last hop of a path sometimes did not match between pre-generated reports and the traffic calculated in the GUI if the destination was a router interface address. Now both calculations extend the traffic over the last hop to the destination interface.

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 software version, you must re-configure the server with two logical volumes and install the 8.0 software 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.10 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:
  • Warning:
    • Updating from any HP RAMS version 8.12 or earlier to HP RAMS 9.0 or later with some particular combinations of Ethernet option cards installed will cause the network configuration to be reset. This requires assigning the primary address again on the serial console and then configuring the addresses of the other interfaces using the web admin UI. The particular system configurations for which this problem exists are listed below. To avoid this problem, the network configuration and the recorder configuration will require patching before the software update to avoid the need to delete and re-enter the recorder 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.
    • Supported PCI-X cards using Intel Gigabit Ethernet chips are: HP NC340T, Compaq NC7170, Intel PRO/1000 MF, MT or GT
    • Vulnerable configurations:
      • DL360 G4 with a PCI-X card installed in slot 1 and a PCIe card installed in slot 2.
      • DL360 G5 if both a PCI-X and a PCIe card are installed.
      • DL360 G6 or G7 with a PCI-X card installed in slot 2 and a PCIe card installed in slot 1.
      • DL380 G5 with any PCI-X or PCIe cards installed. For this model, previous software versions were not recognizing the Ethernet cards at the correct PCI bus addresses and therefore the cards were not displayed correctly on the View Configuration page and the ports were not given the correct names reflecting the slot positions. This is now corrected.
      • DL380 G6 or G7 with a PCI-X card in slot 4 and a PCIe card in slot 1, 2, or 3.
    • Any model running software older than HP RAMS 8.12 with an NC364T card installed because that card was not supported earlier.
    • Any model running software older than HP RAMS 9.00 for G7 with an Intel PRO/1000 PF card installed because that card was not supported earlier.
    • Any model with an Intel PRO/1000 MF or Intel Gigabit EF card installed because those cards are first supported in this release.
    
    Other unit types and units that does not have an Intel-based Gigabit Ethernet option cards in the mentioned slots are not affected.
• Supported PCIe cards using Intel Gigabit Ethernet chips are: HP NC360T, HP NC364T, Intel PRO/1000 PF, PT
• 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.10 from any 5.x or later release should work, but updating from 4.x or earlier requires updating to 5.5 first. QA has verified updates from the previous two releases (HP RAMS 8.0 and 9.0).
• After updating to 9.10, requesting to revert to the alternate software and OS or attempting to an older software update 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.
• A Traffic analyser system or a distributed Route Recorder 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 UI. 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.
• When a new system is first being brought up, it may be necessary to exit and restart the UI if the database has not been created before the UI was started.
• For Traffic Recorder
  • Since release 6.0, Flow collector 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 collector, but would not record raw flows. With the 8.5 release, it is imperative that Flow collectors 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 collector configuration page if the configuration is not correct has been strengthened to state that "NO TRAFFIC DATA WILL BE RECORDED." The Flow collector will not start recording.
  • 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 do not 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 collector too late for processing, in which case it will be dropped. For the inactive timeout, the default value need not be changed.
  • While opening a collection of topology databases including traffic, the UI 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.
• WARNING: Older hardware G3 series (1200, 2400) cannot run in 64-bit mode and therefore cannot be updated to HP RAMS 9.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.
• HP RAMS 9.10 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.10.
• A software update from 5.x version of a Flow Collector to the 7.5.x appliance version in HP RAMS 9.10 without reconfiguring the hardware minimally with two logical drives is not supported. See text in the above "Hardware Requirements" section for more information.
• After you update from 5.x to 9.10, 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-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 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.
• Software update to software version 8.11 is only supported from 5.5 release; updating from pre-5.5 requires updating to 5.5 first.
• When updating from a 5.x software 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-8.01 software version release, 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.