This document provides an
overview of the HP Network Node Manager
iSPI for MPLS Software (NNM iSPI for MPLS) for the 10.00 release. It
contains important information not included in the manuals or in online
help.
For a list of supported
hardware platforms, operating systems, and
database, see the Support Matrix. You can find both the Support
Matrix and the Release
Notes at the root directory of
the
installation media.
The NNM iSPI for MPLS includes the following features:
LSP
over RSVP support
NNM iSPI for MPLS supports TE Tunnels in the LSP view. You can now launch an LSP Map
and view
details of LSPs passing through the TE Tunnels.
LDP
Support
NNM iSPI now
supports the following features for Label Distribution
Protocol (LDP):
LDP
Neighbors View map.
You can launch a map to display LDP neighbors for any node in the MPLS
network.
LDP Attributes.
You can view the LDP attributes of a node from the LDP Attributes
tab of the Node form.
Telnet
support
NNM iSPI for MPLS supports Telnet for CLI data collection through a non-SNMP interface.
A new column is added to the LSR Inventory labeled as Access Protocol. With
this column you can view if a node uses SSH2 or Telnet to collect CLI data.
TE
Tunnel Monitoring RCA Support
NNM iSPI for MPLS has introduced re-route incident for TE Tunnel. When the TE Tunnel re-route or down incident is generated the RCA provides the details where the TE Tunnel went down or got re-routed.
For more information, see NNM iSPI
for MPLS 10.00 Online Help.
Software Development Kit
Some deprecated function calls and objects for PseudoWire have been removed. For more information, see NNM iSPI for MPLS 10.00Developer's Toolkit guide.
Reports
The NNM iSPI for MPLS introduces the
extension
packs such as TE_Tunnel, MPLS_Lsp, MPLS_PseudoWire and MPLS_VFI.
Quick View for MPLS reports. For more information see, Quick View Reports section in the NNM iSPI for MPLS10.00 Online Help for Reports.
Node Group Filter
You can view the LSR nodes belonging to the node group of your choice from the LSR inventory using the Node group filter. For more information, see NNM iSPI for MPLS Node group filter section in the NNM iSPI for MPLS 10.00 Online Help.
System Health Report
You can launch the health report of the NNM iSPI for MPLS. For more information, see NNM iSPI for MPLS System Health Report section in the NNM iSPI for MPLS 10.00 Online Help.
You can view the previous path between the selected source and destination node for a Monitored LSP and TE Tunnel.
Capability to discover and monitor the Service Distribution Points (SDPs) configured on the network.
Support for Huawei devices. For more information, see HP Network Node Manager iSPI for MPLS Software 10.00 System and Device Support Matrix.
NNM iSPI for MPLS 9.21
The NNM iSPI for MPLS includes
the following features:
RT Include Filter
You can choose to include the Route Targets that you want than specifying the list of Route Targets to be excluded.
This feature can be helpful to exclude all Route Targets except few that you want.
Public Key Infrastructure
You can configure the NNM iSPI for MPLS to map with the Public Key Infrastructure (PKI) authentication.
You can log on to the NNM iSPI for MPLS Configuration Console without having to type in the username and password.
You can also run the command-line utilities without typing -u and -p parameters.
To use the PKI authentication feature in the NNM iSPI for MPLS, you must configure NNMi to use the PKI authentication.
The [-silent] option has been added to run
the nmsmplsmanagementmode.ovpl script silently. For more information, see the NNM iSPI for MPLS Reference Pages.
NNM iSPI for MPLS 9.20
The NNM iSPI for MPLS includes
the following features:
Service-centric Layer 2
VPN maps for VPLS (Virtual Private
LAN Service)
Details & status
of PWs (Pseudo Wires) forming VPWS group
and VPLS in the Analysis pane of Layer 2 VPN maps
Service-oriented launch
of LSP (Label Switch Path) for L3 VPN
& L2 VPN
Note: 'Service-centric' or
'Service-oriented' refers to the
mapping that is done between the
services residing on the node and NOT the node itself.
Non-SNMP interface,
where the NNM iSPI for MPLS can connect
to devices using SSH2 protocol
Service oriented LSP
maps with intermediate hops and links
for chosen service
Incidents
and Alerts
LSP Reroute Alerts for
any change in the path of LSP
LSP Down Alerts
correlated with service impact incidents
either L3 or L2 VPN
Reports
- Quick Launch for MPLS report views.
The
following environments are no longer supported by NNM iSPI
for MPLS
Microsoft Windows 2003
Internet Explorer 7
NNM iSPI for MPLS 9.10
The NNM iSPI for MPLS includes
the following features:
Support for Alcatel and
Redback devices
Support for inter-provider
VPN by implementation of back-to-back
VRF
Support for automatic
migration of configuration data from
version 9.00
Support for Multi-Tenancy
Capability to discover IPv6
enabled PEs.
Note: Cisco devices support IPv6 only in a dual-stack scenario, when it is configured for IPv4 as well.
Capability to discover VRF-lite enabled nodes
Capability
to monitor the PE-CE, PE-PE, and CE-CE link
connectivity on the network
Capability
to monitor PE–PE, PE–CE,
and CE–CE reachability in the L3VPN by integrating the NNM
iSPI
for MPLS with iSPI Performance for Quality Assurance (QA)
NNM iSPI for MPLS 9.00
The NNM iSPI for MPLS includes
the following features:
Support for Cisco and
Juniper devices.
Capability to discover and
monitor the MPLS LSR nodes configured
on the network.
Capability to discover and
monitor the L3 VPNs, L2 VPNs, and
Multicast-VPN (MVPN).
Capability to discover and
monitor the TE tunnels configured on
the network.
Capability to discover and
monitor the PseudoWire VCs configured
on the network.
Capability to monitor the
status of the L3VPNs, L2VPNs, MVPNs,
VRFs, TE tunnels, and PseudoWire VCs.
Capability to monitor the
health of the MPLS objects on the
network.
Capability to monitor the
PE-CE link connectivity on the network.
Capability to distribute the
NNM iSPI for MPLS network management
using NNMi's GNM environment.
Capability to monitor and
troubleshoot the L3VPNs and TE Tunnels
by using the map views.
Capability to investigate
the problems of the network by viewing
the MPLS incidents and new service impact incidents.
Capability to monitor and
troubleshoot L3VPNs by integrating the
NNM iSPI for MPLS with Route Analytics Management System (RAMS).
Capability to monitor and
troubleshoot MVPNs by integrating the
NNM iSPI for MPLS with the iSPI for IP Multicast.
Capability to monitor PE
– PE reachability in the L3VPN by
integrating the NNM iSPI for MPLS with iSPI Performance for Quality
Assurance (QA).
Troubleshooting the network
by viewing the MPLS reports. This is
only possible after you install the HP NNMi iSPI Performance for
Metrics and NPS. The NNM iSPI for MPLS introduces the
extension
packs such as
MPLS_LSR_Node, MPLS_LSR_Interface, and L3_VPN_VRF.
NNM iSPI for MPLS 8.xx
The NNM iSPI for MPLS includes
the following features:
Support for Cisco and
Juniper devices
Capability to discover and
monitor MPLS LSR devices configured in
the network
Capability to discover and
monitor L3 VPNs configured in the
provider edge devices of the network
Capability to discover and
monitor TE tunnels configured in the
network
Capability to discover and
monitor PseudoWire VCs configured in
network
Capability to monitor the
status of discovered VPNs, VRFs, TE
tunnels, and PseudoWire VCs in the network
Capability to generate the
incidents for the fault or the changes
in the topology
Display the VPNs, VRFs, TE
tunnels, and PseudoWire VCs details in
the MPLS views
NOTE:
To view files in PDF format (*.pdf), Adobe
Acrobat Reader must be installed on your system. To download Adobe
Acrobat Reader, visit http://www.adobe.com/products/acrobat.html
Installation requirements, as
well as instructions for installing
the NNM iSPI for MPLS, are documented in the installation guide
provided in Adobe Acrobat (.pdf) format. The document file is included
on the product's installation media as: MPLS_install_guide_en.pdf.
Note:
For information about upgrading to the
NNM iSPI for MPLS 10.00 from earlier versions, see NNM iSPI for MPLS 10.00 Upgrade Reference.
For a list of supported
hardware platforms, operating systems, and
databases, see the NNMi 10.00
Support Matrix.
The ovstart process
stops
responding and fails to start the mplsjboss
process after you install the NNM iSPI for MPLS. You might get the
following error messages when you use the ovstart
-c and the ovstatus -c
commands:
ovstart -c
mplsjboss - FAILED Unable to start
process using start command. ovspmd:
Attempt to start HP OpenView
services is complete.
ovstatus -c
ovspmd: Could not successfully run the
status command for process mplsjboss
mplsjboss - FAILED The LRF-specified status command failed.
Workaround
This problem might occur if there is a conflict in the port numbers.
You can perform the following steps to resolve this problem:
Make sure that you have
installed all the necessary patches
for NNMi. See the NNMi
Installation Guide for more
information.
Verify the mpls.log
file present
in the
mpls log folder for any
entry
specified as ROOT
CAUSE in the deployment
of Java MBeans. If there are any port conflicts, you can edit the
values in the following files:
server.properties
file present in the following directory:
For Linux: /var/opt/OV/nmsas/mpls/
For Windows: %NNMDataDir%\nmsas\mpls
nnm.extended.properties
file
present in the:
For Linux: /var/opt/OV/shared/mpls/conf
For Windows: %NNMDataDir%\shared\mpls\conf
Check the mplsjboss
startup process
by running the nmsmplsstart.ovpl
script
present under the following directory: %NNMInstallDir%\bin.
Verify the spiOvspmd.log
file in
the mpls log folder. This file includes the results of the twiddle
commands that invoke the mplsjboss
process. This file lists the connection exceptions (ConnectionExceptions)
at the beginning of the process and displays the messages at the end of
the file indicating that the process is started.
Note: If the listed steps do not
resolve the problem, you might have
to uninstall and re-install the NNM iSPI for MPLS.
After starting the mplsjboss
process, the process displays its status as RUNNING
even after the process has failed to start. This problem might occur if
the mplsjboss fails to start due to installation issues, port
conflicts, or authentication issues.
Workaround
You can perform the
following steps to resolve this problem:
Check if the mplsjboss
process
is running as follows:
Using the ps
command on
Linux operating system
Using the Task
Manager on Microsoft Windows operating
system
Use the nmsmplsstart.ovpl, nmsmplsstatus.ovpl, and nmsmplsstop.ovpl
scripts present in the NNM_BIN
directory
to verify the problem
Verify the mpls.log
file
present at the following location %NNMDataDir%\log\mpls
for any entry specified as ROOT CAUSE
in
the deployment of Java MBeans. Also, make sure that there are no
port-related exceptions in the log file.
Verify the spiOvspmd.log
file
present in the mpls
log folder for any
authentication problem logged while running the twiddle commands to
start the mplsjboss
process. If you see
any error messages in the log file from the following scripts: nmsmplsstart.ovpl, nmsmplsstop.ovpl,
or nmsmplsstatus.ovpl
for issues related
to authentication or port numbers, you must update the correct user
name and password using the encryptmplspassword.ovpl
script and update the port numbers in the following files:
server.properties
file in the following directory:
For Linux: /var/opt/OV/nmsas/mpls/
For Windows: %NNMDataDir%\nmsas\mpls\
nnm.extended.properties
file
in the
For Linux: /var/opt/OV/shared/conf/mpls
For Windows: %NNMDataDir%\shared\conf\mpls
The mplsjboss
process stops
responding to the OVsPMD commands (ovstart, ovstop, and ovstatus) when
the system resource usage is high.
The process stops responding to further OVsPMD commands and the process
state changes to FAILED.
Workaround:
This problem might occur due to a failure by the twiddle commands to
invoke the mplsjboss
process due to the
high system resource usage. You can resolve this problem as follows:
Stop the mplsjboss
process
using the nmsmplststop.ovpl
command and
check for the shutdown complete message for the process in the boot.log
file to see if the process is
stopped.
If you are unable to
stop the
mplsjboss
process with the steps listed, you can end the process as follows and
then perform the step to start the process:
End the process from
the Task Manager for Microsoft
Windows operating systems.
Kill the process
using the kill
<process_id>
where <process_id>
is the process ID of the Java instance for the mplsjboss
process.
Run the nmsmplsstart.ovpl
script to start the mplsjboss
process.
Run the ovstatus -c
command
to confirm that the OVsPMD commands now use the current status of the mplsjboss
period
Multiple instances of the mplsjboss
process result in the mplsjboss process not working as expected.
Workaround:
This problem might occur when you restart all the processes including
the NNMi processes after you encounter a FAILED
state for the mplsjboss process. The ovstop
command does not stop the underlying Java processes when you execute
this command after encountering a FAILED
state for the mplsjboss
process. The ovstart
command executed, creates another
instance of the mplsjboss
process, thus
resulting in multiple mplsjboss
processes.
This causes port conflicts and the mplsjboss process does not work as
expected. You can resolve this problem as follows:
Stop the mplsjboss
process by
using the nmsmplsstop.ovpl
command and
check for the shutdown complete message for the process in the boot.log
file to see if the process is
stopped.
If you are unable to
stop themplsjboss
process with the steps listed, you can
end the process as follows and then perform the step to start the
process:
End the process from
the Task Manager for Microsoft
Windows operating systems
Kill the process
using the kill
<process_id>
where <process_id>
is the process ID of the Java instance for the mplsjboss
process.
Run the nmsmplsstart.ovpl
script to start the mplsjboss
process.
Run the ovstatus -c
command
to confirm that the OVsPMD commands now use the current status of the mplsjboss
process.
The Data MDT appears as the Default
MDT if you
open the MVPN form for the first time
Workaround:
Refresh the MVPN form to
view the correct information.
The NNM iSPI for MPLS may
display an error message, “A
problem occurred while loading the data from the NNMi management server
for this component”.
This error occurs if MPLS web service
client is not created before installing the NNM iSPI for MPLS.
Workaround
Take a backup of %NNMDataDir%/shared/mpls/conf/nnm.extended.properties
file.
Create a new web service
client user as follows:
Go to Configuration
-> Security -> User Account
Click New
icon to open the User Account
view
Type the user name and
password
Select External
Account if applicable
Use the 'click here'
option from the view for more
information on 'Directory Service
Account'.
Click the Save
and close icon
Assign a user group
Go to Configuration
-> Security -> User Account
Mappings
Click the New icon to open
the User Account Mapping view
Select a User
account from the User Account
list
Select NNMi
Web Service Clients from the User
Group list
Click Save
and close icon
Stop the NNMi processes
using ovstop
-c.
In the nnm.extended.properties
file, edit com.hp.ov.nms.spi.mpls.Nnm.username.
Replace the username
with the web service
client username created in step b.
Run /opt/OV/bin/encryptmplspasswd.ovpl
-e mpls <password given in step b>. This command will
update the nnm.extended.properties
file with the encrypted password for the web service client.
Start all the processes
using ovstart
-c.
Execute nmsmplsdisco.ovpl –all.
This step will start a fresh MPLS discovery. The iSPI discovery happens
automatically if the web service client is created before the MPLS SPI
installation.
NNM iSPI for MPLS may
display an error if the extension packs are
not installed properly by the performance SPI. There are two scenarios
in which this error occurs:
If NPS is installed over
NNM/MPLS and no tabs related to MPLS
extension packs is displayed on the reports page.
Workaround
Delete the MPLS_LSR_Interface.tar.gz.processed,
MPLS_LSR_Node.tar.gz.processed, L3_VPN_VRF.tar.gz.processed,MPLS_Lsp.tar.gz.processed, MPLS_PseudoWire.tar.gz.processed,MPLS_VFI.tar.gz.processed and TE_Tunnel.tar.gz.processed
from $NNM_DATA/shared/perfSpi/datafiles/extension/final
This will trigger the perf process to reinstall the extension packs.
NPS is installed over
NNM/MPLS, and MPLS SPI extension pack
tabs are displayed on the reports page, but when you launch of any
particular report from any of these tabs for the first time, a message,
"Unable to verify if data
exists for this package. If this is newly
configured custom collection then try again in a few minutes."
is
displayed.
Workaround
Delete the
MPLS_LSR_Interface.tar.gz.processed,LS_LSR_Node.tar.gz.processed, L3_VPN_VRF.tar.gz.processed,MPLS_Lsp.tar.gz.processed, MPLS_PseudoWire.tar.gz.processed,MPLS_VFI.tar.gz.processed and TE_Tunnel.tar.gz.processed from $NNM_DATA/shared/perfSpi/datafiles/extension/final.
This
will trigger the perf process to reinstall the extension packs.
During the NNM iSPI for MPLS
Global Network Management (GNM)
configuration in a Linux environment, after the 'Successfully
created new connection. Please activate regional manager'
message,
an alert message 'Failed to add
connection <connection_name>
for regional manager <regional_manager>.'
may be displayed. This alert message is displayed if you add NNM iSPI
for MPLS Regional manager on Linux and use the Microsoft Internet Explorer for
configuration.
Workaround
Ignore the alert message and
close the last two child browser
windows namely, 'Add Regional
Manager connection' and ' Creating
New Regional Manager'. Refresh
the main window, 'Configuration
for NNM iSPI for MPLS'
containing the Configured
Regional
Managers tab to see the
newly configured Regional Manager.
This message will not be displayed if you are using Firefox version.
The NNM iSPI for MPLS
automatically refreshes node status on a
map view. If you open more than one MPLS L3VPN Topology map view on the
console, the node status gets refreshed only for the most-recent map
view. All the other MPLS L3VPN Topology map views that were opened
earlier appear in the disabled state (grey color).
After you change
configuration of attachment circuits discovery
for VPLS PW, rediscovery of the associated nodes still continue to show
old attachment circuits.
Workaround
This problem occurs when you
make changes in the router
configuration and do not save it. After the configuration is saved, next
discovery cycle discovers the changes.
In some cases, the TE Tunnel hops are not discovered for Huawei device.
Workaround
Add mpls te record-route label and mpls te commit parameter to the configuration from the command line interface. For example, you can add the parameters to the configuration as follows:
interface Tunnel0/1/1
description connecting to PE2
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 10.0.1.1
mpls te tunnel-id 11
mpls te record-route label
mpls te priority 1
mpls te bandwidth ct0 500
mpls te commit
#
The TE Tunnel hops will now be discovered for Huawei device.
When the NNM iSPI for MPLS generates an incident for TE Tunnel down before the NNMi incident for interface down is generated, the RCA for TE Tunnel down is not displayed.
Workaround
If the polling interval for TE Tunnel is increased and is more than the polling interval for the Interface, this problem can be handled.
Limitations
If there are any TE tunnels that starts from a Cisco IOS-XR device and are part of an LSP, then the LSP cannot be traced from that node to its destination.
The interface details of the last hop is not displayed on the LSP Map due to MIB issue. However, if the interface details for Out node is displayed, the interface details for In node can be found by clicking the Connection tab of that interface in the Analysis pane.
The LSP monitoring may perform only after the completion of two state polling cycle. Hence, the LSP status calculation and monitoring works on the best effort.
If an LSP is not monitored
at Regional Manager but monitored at
the Global Manager, the status of the LSP will always be shown as
normal.
The LSP map may not be
displayed in case of same IP addresses for
two different nodes.
Monitoring of LSPs and LSP path view launch across
Regional Managers is not supported.
The launch of L2 VPN map for the default VPWS group is not valid.
The VRF incidents shows VPN information as UNKNOWN. This is because the VPNs were not formed while generating this incident.
The VFI critical incidents shows the VPLS information as NOT_FOUND when the status of the VFI is down. This is because the VPLS VPN computation was not complete while generating this incident.
When the status of the BGP based PseudoWires in Juniper device is down during node discovery, these PseudoWires will be removed from the NNMi. This is because PseudoWire entries from the PseudoWire MIB table gets deleted.
The NNM iSPI for MPLS does not discover targeted LDP neighbour in some Cisco devices that are not able to report values for targeted LDP neighbor to the LDP MIB.
For all the MPLS forms, the StatusTab
does not appear with the ordered time stamps.
Filter and sort option for some columns in the NNM iSPI for MPLS views and forms are not available. The options will be disabled or grayed out for such columns.
The source object of the
PseudoWire VC traps does not get
resolved in the incident view of the Global Network Manager. The source
object appears as none.
The CE routers without SNMP
access only appears in the NNM iSPI
for MPLS Regional Manager.
Trap and Incident
correlation rules do not work in the NNM iSPI
for MPLS Global Network Manager (GNM)..
The NNM iSPI for
MPLS supports only Cisco devices for MPLS_LSR_Node and
MPLS_LSR_Interface reports.
In the MPLS
LSR Node Top N report, an
error
appears when you select a metric (TE
Tunnel Head (distinct
count)).
All the NNM iSPI for MPLS
commands do not work for the following:
Non-root users with the
administrative rights and permissions.
Any user with
administrator role different from Administrator
user.
Occasionally, when you
unmanage or manage multiple MPLS-enabled
nodes, the management mode of the corresponding MPLS objects does not
change.
VPN computation algorithm
may take time to complete in case of
complex topologies with large number of VPNs and VRFs. While
computation, some of the VRFs will not be associated to any VPN. After completion, the
inventory will display correct number of VPNs with appropriate
topology.
During a discovery poll,
for a managed node, all the associated
VRFs will be discovered irrespective of their Management mode. This
happens because managed or unmanaged state of a VRF does not impact its
discovery. However, any VRF which was Unmanaged shall remain unmanaged
after the discovery process is complete.
A TE Tunnel in 'Down' state
is not supported in the NNM iSPI for
MPLS Topology View.
A TE Tunnel with status as
Critical
throws an exception if opened in the Topology view.
If NNM iSPI for MPLS is not
integrated with NNM iSPI for IP
Multicast, an 'HTTP status 404' error occurs while opening Multicast Path
view.
Management Mode setting does
not recognize user privileges.
Irrespective of the operator level, an operator 2 can Manage and
Unmanage the underlying objects which do not belong to operator 2. For
example, if the operator unmanages a VPN, participant VRFs that are not
accessible to the user will also get unmanaged.
An additional IP subnet icon
is shown in the Inter-Provider VPN
topology view when multiple CEs are connected to a single PE through
multiple third-party VPN clouds (AS numbers).
NNM iSPI for MPLS does not
support default routes. NNM iSPI for
MPLS does not discover Remote CEs configured with default routes.
Cross launch for QA probes
on double-click from the VRF form is
not supported by NNM iSPI for MPLS.
If there are multiple paths
existing between a Provider Edge (PE)
and a Provider router, there is a possibility that the service traffic
may take more than one path to balance the traffic load. However, these
multiple paths are not shown.
"Could
not complete construction of directed graph for
presentation: null" message is
displayed when a VPWS map is
launched if more than 100 pseudowires are loaded on the default VPWS
group.
Some PE-PE or PE-CE entries
in the QA Probe Category may be shown
as PE-UNKNOWN when the same destination IP address has entries for
multiple nodes belonging to different VRFs. This happens because iSPI
Performance for QA does not support same IP addresses for multiple
nodes.
When you take backup MPLS
database and restore it in a freshly
installed machine, the configured device credentials does not work
without the .keyfile. This file is available at:
For Windows:
%NNMDataDir%\shared\mpls\conf\.keyfile
For Linux:
/var/opt/OV/shared/mpls/conf/.keyfile
You must manually copy this .keyfile to the same location on the
freshly installed machine.
If you update a license
after the expiry, the MPLS workspace
takes substantial time to come up. Restart NNMi in this case.
Status of Pseudowires, are
computed based on cpwVcMIB and
CISCO-IETF-PW-MIB and not based on status of Virtual Circuits.
The NNM iSPI for MPLS does not monitor any change on the Penultimate Hop
router (PHP router).
HP Software online support
provides an efficient way to access
interactive technical support tools. As a valued customer, you benefit
by being able to do the following:
Search for knowledge
documents of interest
Submit and track progress on
support cases
Submit enhancement requests
online
Download software patches
Manage a support contract
Look up HP support contacts
Review information about
available services
Enter discussions with other
software customers
Research and register for
software training
NOTE:
Most of the support areas require that you
register as an HP Passport user and sign in. Many also require an
active support contract. To find more information about support access
levels and HP Passport, go to the following URL: support.openview.hp.com/new_access_levels.jsp
The only warranties for HP
products and services are set forth in
the express warranty statements accompanying such products and
services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial
errors or omissions contained herein. The information contained herein
is subject to change without notice.
Restricted Rights
Legend
Confidential computer software.
Valid license from HP required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government
under vendor's standard commercial license.
For information about
third-party license agreements, see the
license-agreements directory on the product installation media.
Acrobat® is a trademark
of Adobe Systems Incorporated.
Oracle and Java are registered trademarks of Oracle and/or its
affiliates.
Microsoft® and Windows® are U.S. registered trademarks
of
Microsoft Corporation.
UNIX® is a registered trademark of The Open Group.
Oracle Technology
— Notice of
Restricted Rights
Programs delivered subject to
the DOD FAR Supplement are
‘commercial computer software’ and use,
duplication, and
disclosure of the programs, including documentation, shall be subject
to the licensing restrictions set forth in the applicable Oracle
license agreement. Otherwise, programs delivered subject to the Federal
Acquisition Regulations are ‘restricted computer
software’
and use, duplication, and disclosure of the programs, including
documentation, shall be subject to the restrictions in FAR 52.227-19,
Commercial Computer Software-Restricted Rights (June 1987). Oracle
America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
For the full Oracle license
text, see the license-agreements
directory on the NNMi product DVD.