Users Guide

Features/Devices Supported in 6.1
27
ctrl and shift will allow multi select in resource manager minimized portlets
allowing delete of more than 1 device at a time.
The "Alarms by location" page is a context driven view that depends on the pre-
configuration and administration of containers from the container manager in
the Admin tab. If there are no container configured the Container tree will be
empty and the other context driven portlets will also be empty. Refer to the user
manuals or search "Help" for "Container manager" for more information. (25373)
With this release, traffic flow data is automatically converted to a new format
that can be inserted into the DB and queried more efficiently. Our testing showed
that the original implementation of IP conversations could be improved. This
implementation involved a table that had a row for every unique IP conversation
(sender/receiver combination, where IP A sends to IP Z is the same conversation
as when B sends to A) where the only purpose of this table was to assign a unique
ID to each conversation. At some customer sites where they measured all internet
traffic going through their network, this table quickly grew to hundreds of
millions of rows, and this was a significant performance drag when it tried to
insert new data because it constantly had to query this table to see if the
conversation is already on record and so it could get the ID. So we came up with
a new approach that simply assigned a unique key to each conversation and
stores this in the rollup tables. This key is derived from all essential factors that
are relevant to the conversation (IP A and Z, protocol, port) and it converts this
into a base 64 string so that it can be readable in string format. After upgrade to
this new code, all conversation queries will assume the data is in this new format,
but if the user had data before then the new data will be lost unless it is
converted. When the server is started the first time after upgrade, there will be a
thread running in the background to convert the user's legacy data. After this
process is complete, the conversation data should be query-able.
In earlier versions, there were restrictions for what types of managed equipment
could be registered as exporters. This was handled by the system property:
ta.exporter.types which was set to:
Router,Switch/Router,Switch,Converged Ethernet Switch,Firewall
Now this property has no value and instead we have a new property which
disables ta.exporter.types and allows all devices to be registered as exporters,
regardless of type: ta.exporter.restrictType
Which is set to false. It is still possible to override these properties so that these
restrictions would be back in place. This can be done by setting
ta.exporter.restrictType to true and then to setting ta.exporter.types to a list of
equipment types.