Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Related Documentation


    Network Monitoring Topology Overview

    On the Topology page in the Network Monitoring workspace, you can view Junos Space nodes, Fault Monitoring and Performance Monitoring (FMPM) nodes, and devices that were discovered by Junos Space Network Management Platform, as well as node links and the alarm state of the services links.

    Note: On the Topology page, the term node refers to Junos Space nodes, FMPM nodes, or devices discovered by Junos Space Network Management Platform. The term node link refers to the link between the nodes.

    The EnhancedLinkd network topology discovery daemon is used to discover the network topology. Five physical link discovery methods—Bridge Discovery Protocol, Cisco Discovery Protocol (CDP), IS-IS, Link Layer Discovery Protocol (LLDP), and OSPF—are supported and enabled by default. After the SNMP interface is discovered, the availability of links in the topology depends on the following:

    Note: Junos Space Platform currently supports only OSPF version 2 for topology discovery.

    • The time that the EnhancedLinkd daemon waits after a node has been provisioned; the default is 60 seconds
    • The time taken for the EnhancedLinkd deamon to scan the node
    • The time after which the node links are refreshed automatically; the default is 60 seconds

    After the topology is discovered by Junos Space Platform, any changes to the topology are automatically detected. This includes changes in logical entities, such as Ethernet services and VPNs, that are discovered by Junos Space Platform. The EnhancedLinkd daemon updates only the topology changes in the database and does not rescan the entire network. This incremental link discovery ensures that data related to topology changes is updated dynamically. In addition, the dynamic update ensures that only the node or the node link that was updated is redrawn and not the entire topology.


    • From Junos Space Network Management Platform Release 14.1R1 onward, the SNMP polling time for discovering links between devices is set using the rescan_interval parameter in the enlinkd-configuration.xml file. In prior releases, this SNMP polling time for discovering links between devices was set using the snmp_polling parameter in the linkd.xml file. The default value for the rescan_interval parameter is 86,400,000 milliseconds
    • A sample of the /opt/opennms/etc/enlinkd-configuration.xml is as follows:
      <?xml version="1.0" encoding="ISO-8859-1"?>
      <linkd-configuration threads="5"

      For more information about the parameters in the enlinkd-configuration.xml file, see .

    The node link status is color-coded—a green link indicates that the link is up and a red link indicates that a link is down. In addition, if an SNMP trap is received indicating that the node link status has changed, then the EnhancedLinkd daemon updates the node link in the topology to indicate the current status of the node link.

    The alarm state of services links is also color-coded—a green line indicates that no service-impacted alarms are present and that the service status is up; a red line indicates that at least one service-impacted alarm is present and that the service status is down.


    • The color-coding of the link status is displayed only if the option to display the link status is selected; this option is not selected by default.
    • Similarly, the color-coding of the alarm state for services links is displayed only if the option to display the alarm state for services links and link status are selected; these options are not selected by default.
    • The node link data and alarm states for services links are automatically refreshed in the network monitoring topology only if the options to automatically refresh the topology is selected; this option is not selected by default.

    The links on a node can also be rediscovered on demand manually by requesting for a rescan of a node.


    Related Documentation


    Modified: 2015-08-10