Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

    Learning the Network Topology

    PSM learns the topology of the network in different ways:

    • For optical links on ROADM nodes, PSM learns the optical topology automatically from the DOL or ROADM neighbor information tables retrieved from the nodes. See Deriving optical topology using DOL or ROADM data.
    • For layer 1 (physical) Ethernet links on BTI7800 NEs with LLDP snooping enabled, PSM learns the layer 1 topology automatically from the snooped LLDP information retrieved from the NEs. See Deriving Ethernet topology using LLDP data.
    • For layer 2 Ethernet links on NEs with LLDP enabled, PSM learns the Ethernet topology automatically from the LLDP neighbor tables retrieved from the NEs. See Deriving Ethernet topology using LLDP data.
    • Additionally, PSM supports a manual specification method that allows you to specify the topology directly for BTI7000 Series and BTI800 Series network elements. See Deriving topology using Remote IDs. This is the method you use for specifying the transport topology in a BTI7000 Series network.

    Deriving Optical Topology Using DOL or ROADM Data

    Juniper Networks BTI Series ROADM nodes advertise and identify themselves to their optical neighbors by exchanging information over the optical service channel (OSC). Each node builds a table of its neighbors. PSM uses this information to build and display an accurate, up-to-date optical topology of the network.

    Deriving Layer 1 Topology Using Snooped LLDP Data

    LLDP snooping allows transport equipment to snoop LLDP frames on Ethernet links.

    Some Ethernet devices discover their Ethernet neighbors using the Link Layer Discovery Protocol (LLDP). LLDP runs over Ethernet and allows devices to advertise and identify themselves to their peers.

    When these devices are connected across a transport network, the transport equipment can snoop passing LLDP frames to determine the identity of the attached devices. If the transport equipment is managed by PSM, PSM can then use this information to show connectivity between the transport equipment and the attached Ethernet device.

    This capability to snoop LLDP frames is supported for network elements running the following releases:

    • BTI7800 release 4.1 or later

    Note: LLDP snooping must be enabled on the Ethernet interface on the device. See Editing an Interface for information on how to enable LLDP snooping on a BTI7800 UFM interface.

    Deriving Ethernet Topology Using LLDP Data

    Some BTI Series network elements can be configured to discover their Ethernet neighbors using the Link Layer Discovery Protocol (LLDP). LLDP runs over Ethernet, and allows network elements to advertise and identify themselves to their peers. Each NE builds a table of its Ethernet neighbors that PSM can retrieve. PSM uses this information to build and display an accurate, up-to-date Ethernet topology of the network.

    This capability is supported in PSM for network elements running the following releases:

    • BTI7000 Series release 10.3 or later
    • BTI700 Series release 1.5 or later (BTI718E all releases)
    • BTI800 Series release 1.1 or later

    PSM can only display this topology if the NEs have been configured to use LLDP. You can configure LLDP on the NEs directly using the proNX 900 or the CLI. Alternatively, you can use PSM to enable LLDP on the NEs during initial NE discovery. For information on how to do this, see Discovering Network Elements.

    Be aware that this method produces an Ethernet topology of the network, which might not necessarily reflect the physical topology. Where the two topologies do not align, you can use manual specification (that is, Remote IDs) to change the discovered Ethernet topology to align with the physical topology if desired.

    Deriving Topology Using Remote IDs

    PSM allows you to specify the topology manually hop by hop through the use of the Remote ID, a parameter that you configure on a supported port to indicate the identity of the port attached to the other end of the fiber. There are a number of reasons for specifying the topology in this manner:

    1. To include topology that is not automatically discovered, such as connections between transport equipment (for example, transponder to transponder for BTI7000 Series equipment) and connections between transport equipment and optical equipment (for example, transponder to multiplexer/demultiplexer)
    2. To change an automatically-discovered topology to align with the actual physical topology, such as changing the discovered Ethernet topology to show connectivity to transport or optical equipment
    3. To include topology to external equipment

    The ability to configure Remote IDs is supported in PSM for network elements running the following releases:

    • BTI7000 Series release 9.2.0 or later
    • BTI800 Series release 1.1 or later

    The Remote ID is a string that references the remote end of the connection (fiber). The string is not used by the NE itself, but is read and correlated by PSM to determine the connection endpoints. For this reason, the accuracy with which PSM derives the topology is dependent on proper configuration of this field. If improperly configured, the topology shown by PSM might not reflect the actual topology.

    The NE treats the configuration of the Remote ID as an opaque string and does not otherwise perform any syntactical or semantic checking on the configured value. All syntactical and semantic checking is performed by PSM.

    Remote ID configuration can be bookended or singled-ended:

    • Bookended: the Remote ID is configured at both ends of the connection (to point to each other). This is mandatory when both endpoints support Remote ID configuration. PSM validates the Remote ID configuration and raises an alarm if the validation fails. See Detecting Remote ID Errors for more information.
    • Single-ended: the remote ID is configured at only one end of the connection (to point to the other end). This is the only possible method when only one endpoint supports Remote ID configuration. In this situation, PSM uses the Remote ID configured at one end to derive the topology. PSM does not require information from the other endpoint except to perform limited validation in specific situations. See Detecting Remote ID Errors for more information.

    Because the Remote ID is used to specify the physical fiber connectivity, you should typically configure the Remote IDs when the actual fibers are installed. Not only will this allow PSM to display the topology correctly, but it will also allow you to activate supported services with endpoints referenced by the Remote IDs.

    The following table shows where the Remote ID can be configured and what endpoint it can reference.

    Remote ID can be configured on:

    Remote ID can reference:

    BTI7000 Series muxponder, transponder, DOL, and packetVX ports, and BTI800 Series ports

    For DOL ports, the Remote ID can be configured as follows:

    • You can configure the Remote ID on a BTI7000 Series DOL multiplexer/demultiplexer channel port or on a BTI7000 Series DOL ROADM module Alien/C2 port to point to attached equipment (for example, PVX or MX Series or PTX Series router port). This configures the connectivity from the attached equipment to the DOL network.
    • Addtionally, you can configure the Remote ID on the BTI7000 Series DOL ROADM module Alien/C2 port to show a split ROADM node. In this situation, you cannot use the ROADM module C2 port as an optical service endpoint. See Configuring a Split ROADM Node.

    BTI7000 Series muxponder, transponder, DOL, and packetVX ports, and BTI700 Series, BTI800 Series, BTI7800 Series, MX Series, PTX Series, and external device ports

    For information on connecting to an external device port, see Viewing External Devices.

    Remote ID Format

    PSM provides great flexibility on how you build your topology with Remote IDs. As long as the Remote ID configuration conforms to the required syntax, and as long as the Remote IDs at each end refer to each other (for bookended configurations), PSM will display the connection. Therefore, you must provision the Remote ID with great care or the topology might not turn out as you intend.

    The general format of the Remote ID is as follows:

                   <IP Address>-<Circuit Pack Type>-<Shelf>-<Slot>-<Port>
                

    where the <IP Address> is the remote IP address of the connection in dotted decimal notation, the <Circuit Pack Type> is the type of card at the remote location, and <Shelf> , <Slot> , and <Port> represent the shelf, slot, and port identifiers of the remote end.

    The following table shows how the Remote ID is constructed for the different types of endpoints. All characters in the syntax are case-insensitive.

    Note: This table lists the values that PSM considers to be valid (for the purpose of determining whether or not to raise an "Invalid Remote ID" alarm). PSM does not check the specified Remote ID against the actual NE being referenced for this alarm. Not all values that PSM considers to be valid are applicable for certain circuit pack types. See Detecting Remote ID Errors for more information on how PSM determines what is considered valid.

    Remote Endpoint

    Remote IP

    Circuit Pack Type

    Shelf-Slot-Port

    Example

    BTI7000 Series muxponder

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    MXP

    <shelf>-<slot>-L<n>

    <shelf>-<slot>-C<n>

    10.1.121.24-MXP-11-3-L2

    10.1.121.24-MXP-11-3-C2

    BTI7000 Series transponder

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    TPR, WM, WR, WT

    <shelf>-<slot>-<port>

    10.1.121.24-TPR-1-3-3

    BTI7000 Series packetVX

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    PVX

    <shelf>-<slot>-X<n>

    <shelf>-<slot>-G<n>

    10.1.121.24-PVX-21-3-X2

    10.1.121.24-PVX-21-3-G7

    BTI7000 Series multiplexer/demultiplexer

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    D32MD1 to D32MD4

    D40MD

    D96MD

    <shelf>-<slot>-CH<n>

    10.1.121.24-D40MD-0-1-CH280

    BTI7000 Series ROADM

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    ROB

    <shelf>-<slot>-C2

    10.1.121.24-ROB-1-3-C2

    For information on where to use this, see Configuring a Split ROADM Node.

    BTI7800 Series UFM

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    OTU4

    OCH

    <shelf>-<slot>-<BIC>-<port>

    <shelf>-<slot>-<Port Group>-<Xcvr Port>-<Fiber Port>.<OCH>

    10.228.220.71-OTU4-1-5-1-1

    10.228.220.71-OCH-1-14-2-1-2.1

    BTI800 Series

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    BTI800

    <shelf>-<slot>-G<n>

    10.1.111.4-BTI800-1-2-G3

    MX Series or PTX Series

    IP address in dotted decimal notation

    Note: The remote NE must be a discovered network element.

    JUNOS

    <FPC>-<PIC/MIC>-<port>

    10.1.111.5-JUNOS-1-0-0

    BTI700 Series

    IP address in dotted decimal notation

    BTI700

    not validated

    10.1.121.24-BTI700-1-1-6-X

    A BTI700 Series NE is treated like an external device and requires a trailing -X or -x in the Remote ID. See Viewing External Devices for more details on external devices.

    External

    IP address in dotted decimal notation

    EXT

    not validated

    10.1.121.24-EXT-2-3-6-X

    An external device requires a trailing -X or -x in the Remote ID. See Viewing External Devices for more details on external devices.

    Remote ID Configuration

    PSM provides a GUI-driven method to configure the Remote ID. The benefit of this approach is that you do not need to know the remote ID syntax in order to construct the remote ID. Figure 1 shows the Remote ID configuration dialog:

    Figure 1: Provision Remote Port ID

    Provision Remote Port ID

    Note: The Remote ID configuration attributes might change depending on the CP Type that you select.

    The meanings of the attributes are as follows:

    • Local Port ID This displays the local port identifier. This attribute cannot be changed.
    • Remote Id This is the Remote ID that is currently set. This field cannot be changed directly. It is changed by editing the individual components of the Remote ID through the various drop-down menus.
    • Hostname/IP Address Set the hostname or IP address of the remote endpoint. For convenience, completion suggestions are provided based on the discovered network elements.
    • CP Type Set the circuit pack type (or BTI7800 UFM interface name) from the drop-down menu.

      Note: Only the circuit pack types described in Remote ID format are supported.

    • Shelf, Slot, Port Set the shelf, slot, and port indexes respectively.
    • BIC Set the BIC (subslot) if referencing an OTU4 interface on a BTI7800UFM.
    • Fiber Port, OCH Set the Fiber Port (subport) and OCH (channel) if referencing an OCH interface on a BTI7800UFM.
    • Alien This specifies whether the remote ID refers to an external device. This is usually used when configuring a Remote ID to point to a BTI700 Series or third-party device. Selecting this attribute causes an -X to be appended to the end of the Remote ID.
    • Bidirectional This option allows you to specify whether you want PSM to automatically set the remote ID on the remote port to point back to this local port. This attribute should only be selected if the circuit pack type is one of MXP, TPR, WR, WM, WT, PVX, ROB, BTI800. You cannot select both Alien and Bidirectional at the same time.

    This dialog can be reached through the Network tree (Setting the Remote ID, Setting the Remote ID on a multiplexer/demultiplexer, Setting the Remote ID on a ROADM C2 port) or through the NE Shelf view (Setting the Remote ID from the Shelf View).

    If you are familiar with the Remote ID syntax, you can set the Remote ID in a freeform manner within certain nodal provisioning windows for BTI7000 Series ports. This is shown in various places in Nodal Management for BTI7000 Series Network Elements.

    Setting the Remote ID

    Use this procedure to set the Remote ID on the following ports from the Network tree:

    • a BTI7000 Series transponder, muxponder, or packetVX port
    • a BTI800 Series port
    1. Expand the network element in the Network tree to show the shelves in that NE.
    2. Expand a shelf to show the slots in that shelf.
    3. Expand a module to show the ports in that module.
    4. Right-click a provisioned port and select Remote ID >Provision.

      The Provision Remote Port ID dialog appears.

    5. Configure the Remote ID as described in Remote ID configuration.
    6. Click OK.

      Note: If you select Bidirectional and you specify a Remote ID that cannot be reconciled, PSM will be unable to configure the remote endpoint, and the task will fail.

      Note: The task might fail if you try to use this procedure on a card that has not been provisioned.

    Setting the Remote ID on a Multiplexer/demultiplexer

    Use this procedure to set the Remote ID on a BTI7000 Series multiplexer/demultiplexer port from the Network tree.

    1. Expand the network element in the Network tree to show the equipment in that NE.

    2. Expand the Optical Groups branch to see the configured optical groups.

    3. Expand an optical group to show the degrees in that optical group.

    4. Expand a degree to show the multiplexer/demultiplexer for that degree.

    5. Expand the multiplexer/demultiplexer to show the ports/channels on that multiplexer/demultiplexer.

      Each port on the multiplexer/demultiplexer is named by its frequency. For example, channel 235 on the multiplexer/demultiplexer represents the port with frequency 192.35 THz (1558.58 nm).

    6. Right-click a port/channel and select Remote ID >Provision.

      The Provision Remote Port ID dialog appears.

    7. Configure the Remote ID as described in Remote ID configuration.
    8. Click OK.

      Note: If you select Bidirectional and you specify a Remote ID that cannot be reconciled, PSM will be unable to configure the remote endpoint, and the task will fail.

      Note: The task might fail if you try to use this procedure on a card that has not been provisioned.

    Setting the Remote ID on a ROADM C2 Port

    Use this procedure to set the Remote ID on a BTI7000 Series ROADM C2 port from the Network tree. This procedure can be used to create a split ROADM node. For more information, see Configuring a split ROADM node.

    1. Expand the network element in the Network tree.
    2. Expand the Optical Groups branch to see the configured optical groups.
    3. Expand an optical group to see the degrees in that group.
    4. Expand a degree to see the ROADM module in that degree.
    5. Expand the ROADM module to see the ports in that module.
    6. Right-click the Client: 2 port and select Remote ID >Provision.

      Figure 2: Selecting the C2 Port

      Selecting the C2 Port

      The Provision Remote Port ID dialog appears.

    7. Configure the Remote ID as described in Remote ID configuration.
    8. Click OK.

      Note: If you select Bidirectional and you specify a Remote ID that cannot be reconciled, PSM will be unable to configure the remote endpoint, and the task will fail.

      Note: The task might fail if you try to use this procedure on a card that has not been provisioned.

    Deleting the Remote ID

    Use this procedure to delete the Remote ID from an existing port on a BTI7000 Series or BTI800 Series network element.

    There are different ways by which you can delete the Remote ID. You can delete the Remote ID from the Network tree or from the NE shelf view or from nodal provisioning windows. This procedure describes how to delete the Remote ID from the Network tree. For information on deleting the Remote ID from the shelf view, see Deleting the Remote ID from the Shelf View. The Remote ID can also be deleted in a freeform manner within certain nodal provisioning windows. This is shown in various places in Nodal Management for BTI7000 Series Network Elements.

    1. Expand the network element in the Network tree view to show the shelves in that NE.
    2. Expand a shelf to show the slots in that shelf.
    3. Expand a module to show the ports in that module.
    4. Right click a provisioned port and select Remote ID >Delete.

      The Delete Remote Port ID dialog appears.

    5. To delete the remote ID at both endpoints, select bidirectional deletion.
    6. Click OK.

    Interactions with LLDP

    PSM can display Ethernet connections using either LLDP or Remote ID. This section only applies to those BTI Series network elements that support LLDP and Remote IDs. See Deriving Ethernet topology using LLDP data for the list of supported network elements.

    In general, LLDP provides a more accurate representation of the Ethernet topology because LLDP-derived topology is learned rather than manually provisioned. However, since LLDP provides the Ethernet topology rather than the physical topology, you can use remote IDs to change the topology view to reflect the physical topology if desired.

    When LLDP is enabled and the Remote ID is configured, the following rules apply:

    Note: An incorrect Remote ID in the table refers to either a syntactically-invalid Remote ID or a Remote ID that leads to a Remote ID mismatch condition.

    Table 1: When LLDP is Enabled and Remote ID is Configured

    Configuration Scenario

    Topology Shown

    Explanation

    The Remote IDs at both ends correctly point to a BTI7000 Series packetVX, BTI700 Series device, or a BTI800 Series device.

    LLDP

    This situation occurs when you want to represent a direct connection (fiber) between two Ethernet devices. In such a case, LLDP should have provided the correct information, and therefore PSM assumes the LLDP topology is correct. If the Remote ID topology differs from the LLDP topology, PSM raises an "NE Link Mismatch" alarm.

    The Remote IDs at both ends correctly point to a muxponder, a transponder, a multiplexer/demultiplexer, or an external device (that is, MXP, TPR, WM, WR, WT, D32MD1, D32MD2, D32MD3, D32MD4, D40MD, D96MD, EXT).

    Remote ID

    This situation occurs when you want to change the LLDP view to align with the physical topology. This is the primary use case for configuring remote IDs when LLDP is enabled.1

    Note: 1Be aware that you might run into situations where PSM displays a broken path due to incorrect Remote ID configuration on the second or subsequent hops, up to and including the penultimate hop.

    The Remote ID at one end correctly points to a muxponder, a transponder, a multiplexer/demultiplexer, or an external device (that is, MXP, TPR, WM, WR, WT, D32MD1, D32MD2, D32MD3, D32MD4, D40MD, D96MD, EXT) but the Remote ID at the other end does not, either because it is incorrect, or because it points correctly to a packetVX, BTI700 Series device, or a BTI800 Series device.

    LLDP and Remote ID

    PSM cannot determine which is the actual physical topology, so it displays both as best as it can.

    The Remote ID at one end correctly points to a packetVX, BTI700 Series device, or a BTI800 Series device, but the Remote ID at the other end is incorrect.

    LLDP

    PSM assumes the LLDP topology is the physical topology, and raises an "NE Link Mismatch" alarm.

    The Remote IDs at both ends are incorrect.

    LLDP

    PSM cannot resolve the Remote IDs, and assumes the LLDP topology is the physical topology.

    Viewing External Devices

    PSM provides the capability to display external devices in the topology Map view if the external device is connected to a network element that supports remote IDs. An external device is any device that is unmanaged by PSM.

    PSM displays an external device whenever an EXT-formatted Remote ID has been provisioned on a discovered network element. A Remote ID in the form <IP Address>-EXT-<Shelf>-<Slot>-<Port>-<X|x> denotes an external device at the remote end of the connection. The trailing X is case-insensitive.

    When PSM encounters an EXT-formatted Remote ID (for example, 10.1.121.24-EXT-1-3-2-x), it creates an icon for the specified IP address if one does not already exist, and draws a link from the network element in which this Remote ID has been provisioned to the external device.

    Note: PSM has no way of verifying if the Remote ID is properly referencing the external device.

    The external device is displayed as an undiscovered network element. You manipulate the external device in the same way you manipulate an undiscovered network element, such as editing notes or adding or removing the device from groups.

    You can delete an external device as you delete an undiscovered network element, but the external device will reappear when PSM performs a topology refresh and reprocesses all the configured Remote IDs. To delete an external device permanently, you must first delete it from the Remote ID on all network elements that reference this external device. You can then proceed to delete the external device by right-clicking the device and selecting delete.

    Detecting Remote ID Errors

    PSM performs validation of the Remote ID during topology discovery.

    The following errors are detected:

    • PSM raises an "Invalid Remote ID" alarm upon detection of malformed fields. The alarm is raised against the port where the invalid Remote ID was found. Specifically, PSM performs the following (case-insensitive) syntax checks:
      • ensures the IP address is of the form <0-255>.<0-255>.<0-255>.<0-255>
      • ensures the circuit pack type is <MXP | TPR | WR | WM | WT | D32MD1 | D32MD2 | D32MD3 | D32MD4 | D40MD | D96MD | PVX | BTI800 | JUNOS | BTI700 | EXT>
      • ensures that both BTI700 and EXT circuit pack types contain a trailing case-insensitive -x
      • ensures the shelf index is <0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 11 | 21 | 31> for all devices other than for BTI700 and EXT devices
      • ensures the slot index is <0-20> for all devices other than for BTI700 and EXT devices

      This alarm does not identify contextual errors, such as a Remote ID referring to an impossible port identifier for that circuit pack type (for example, port 24 on a device with only two ports).

    • PSM raises a "Remote ID Mismatch" alarm as follows:
      • Bookended: PSM correlates both ends of the connection and raises this alarm if the Remote IDs at the two ends are not referring to each other. This alarm implicitly identifies contextual errors such as when a Remote ID refers to an impossible port.
      • Single-ended: In the specific situation where the Remote ID is configured on a BTI7000 Series DOL multiplexer/demultiplexer channel port and points to a supported UFM interface on a discovered BTI7800 or points to a supported interface on a discovered MX Series or PTX Series router, PSM checks the wavelength at the remote endpoint as follows:

        If the supported interface is on a tunable transceiver, PSM validates the wavelength configured on the interface with the wavelength associated with the multiplexer/demultiplexer port. If the wavelengths do not match, PSM raises an alarm and does not display the link in the topology view.

        In all other cases, including configurations where the supported interface is on a fixed-wavelength transceiver or where the Remote ID is configured on a port that is not a BTI7000 Series DOL multiplexer/demultiplexer channel port, PSM does not validate the wavelength at the remote endpoint.

    Note: For bookended configurations, PSM cannot detect configuration errors where the Remote IDs are properly formed and referencing each other, but where no connection is actually provisioned between the stated endpoints.

    Note: For single-ended configurations, PSM cannot detect configuration errors where the same Remote ID is configured on more than one port (in other words, where multiple ports point to the same remote port).

    Modified: 2016-12-14