Node discovery provisioning using OSPF

Some operators use third-party or self-build NMS and need to discover the nodes using OSPF and its Type 10 opaque LSA TLV. When a node is discovered through OSPF, the NMS pushes the new configuration to the node and perform any other required modifications using CLI (SSH or Telnet).

Node discovery procedure

A node is configured with a network element profile. A network element profile has all of the necessary information for node discovery, including the node NEID, NEIP, Vendor Identifier, chassis type, and MAC address. The network element profile can be added to an OSPF area in VPRN and when it is, the network element information is advertised using OSPF type 10 opaque LSA to the rest of the network. These discovery procedures are only available in VPRN.

An aggregation node (node closest to the NMS) gathers all of the network element information received using OSPF and converts this information into a MIB. When configured, the aggregation node also generates traps as necessary to update the NMS. In addition to the traps, the NMS can walk the MIB table to update its new view of the network. Use the following command to configure the trap generation:

configure system network-element-discovery generate-traps

The node is discovered using an IPv4 or IPv6 NEIP, but the advertisement protocol is always OSPFv2 (OSPFv3 is not supported). However, if the NMS wants to discover a node in an IPv6 network, you must enable both OSPFv2 and OSPFv3. OSPFv2 advertises the node information to the aggregation node to generate the traps and build the MIB table, and OSPFv3 provides the routing information required to reach that node using an IPv6 network.

The following minimum configuration is required on the node so that it can be discovered:

  • a management VPRN

  • a network element profile configured under the configure system network-element-discovery context

  • a loopback or physical L3 interface in the VPRN with same IP address as the network element profile NEIP

  • a physical interface in the VPRN (SAP) with an optional unnumbered interface inheriting the IP address from the loopback IP (this is light VPRN where the uplink is a SAP and not a spoke SDP)

  • an optional VLAN DOT1Q support for the L3 interface

  • a temporary username and password. This could be the default.

  • OSPF on the physical L3 interface in the VPRN (SAP). OSPF must be configured as P2P and has an additional flag to include the LSA type 10 opaque value.

  • SSH or Telnet management enabled on the VPRN, these are disabled by default

As all discovery is done using the VPRN SAP, there is no need for GRT configuration.

Configuring network element profiles

You can create a Network Element (NE) profile for the system with all the information needed for node discovery. The NE information is flooded to the network using IGP.

Use the commands in the following context to configure an NE discovery profile.

configure system network-element-discovery profile

You can assign the NE discovery profile to a VPRN OSPFv2 area for advertisement. You can only create one profile for each node.

MD-CLI

[ex:/configure system network-element-discovery]
A:admin@node-2# info
    profile "testProfile" {
        neid 0x91001
        neip {
            ipv4 128.9.10.1
        }
    }

classic CLI

A:node-2>config>system>ned# info
----------------------------------------------
            profile "testProfile" create
                neid 0x091001
                neip
                    ipv4 128.9.10.1
                exit
            exit
----------------------------------------------

Advertising an NE profile using OSPF

When you assign an NE profile to OSPFv2, its information is advertised using LSA type 10 opaque.

Use the following command to assign an NE profile to OSPFv2.

configure service vprn ospf area advertise-ne-profile 

The NE information is not added to the Routing Information Base (RIB) table or Forwarding Information Base (FIB) table, this includes the NEIP. If the NEIP of the profile needs to be visible to the network then a loopback interface or a physical interface must be configured with the same IP address as the NEIP and added to the OSPFv2 area.

For example, if the following profile is created, the NEIP is duplicated in a loopback interface address. This is because the NEIP is only used in type 10 LSA and is not added to the RIB or FIB. Type 10 LSA is only used to relay the information to the NMS. As such, the loopback interface with the same IP address as the NEIP, must be assigned to the same OSPF area to ensure the address is injected into the RIB and FIB of all nodes and is reachable. If this loopback interface is not configured and not added to OSPF then SR OS does not have any route entry in the RIB or FIB for the NEIP.

MD CLI

[ex:/configure system network-element-discovery]
A:admin@node-2# info
    profile "testProfile" {
        neid 0x91001
        neip {
            ipv4 128.9.10.1
        }
    }
[ex:/configure service vprn "1"]
A:admin@node-2# info
    interface "loopback" {
        loopback true
        ipv4 {
            primary {
                address 128.9.10.1
                prefix-length 24
            }
        }
    }
    interface "uplink" {
    }
    ospf 0 {
        area 0.0.0.0 {
            advertise-ne-profile "testProfile"
            interface "loopback" {
            }
            interface "uplink" {
            }
        }
    }

classic CLI

A:node-2>config>system>ned# info
----------------------------------------------
            profile "testProfile" create
                neid 0x091001
                neip
                    ipv4 128.9.10.1
                exit
            exit
----------------------------------------------
A:node-2>config>service>vprn# info
----------------------------------------------
            interface "loopback" create
                address 128.9.10.1/24
                loopback
            exit
            interface "uplink" create
            exit
            ospf
                shutdown
                area 0.0.0.0
                    advertise-ne-profile "testProfile"
                    interface "loopback"
                        no shutdown
                    exit
                    interface "uplink"
                        no shutdown
                    exit
                exit
            exit
----------------------------------------------

OSPFv2 opaque LSA requirements

OSPF Opaque LSA packets are made up of the following, as shown in OSPF opaque LSA packet.

  • LSA ID is 202.255.238.0

  • opaque type value is 202

  • instance value is 255.238.0 (ffee00)

Figure 1. OSPF opaque LSA packet
Note: Type 10 opaque LSA can only be added to OSPFv2 and not OSPFv3.

OSPF Opaque LSA type 10 TLV contains the following information:

  • vendor identifier

    This is the vendor-id (vendor defined string).

    • type is 0x8000

    • length is length of identify string

    • default value is "Nokia"

  • equipment identifier

    This is the product-id (vendor defined string).

    • type is 0x8001

    • length is length of identify string

    • default value is "chassis-name, chassis-type"

  • system-mac

    This refers to node system MAC (node unique).

    • type is 0x8002

    • length is 6

    • default value is chassis MAC address

  • NEID

    This refers to node hostname (customer defined).

    • type is 0x8003

    • length is 4

  • NEIP IPv4

    This refers to loopback IPv4 address (preconfigured).

    • type is 0x8004

    • length is 4

  • NEIP IPv6

    This refers to loopback IPv6 address (preconfigured).

    • type is 0x8005

    • length is 16

IPv4/IPv6

Both IPv4 and IPv6 node discovery is supported. However, LSA type 10 is only advertised on OSPFv2 and not OSPFv3. If the operator wants to use IPv6 or dual-stack, OSPFv2 must be configured under VPRN to advertise the node information using LSA type 10 opaque. In addition, OSPFV3 can also be enabled to advertise IPv6 routes and interfaces for IPv6 reachability. If both IPv4 and IPv6 are configured on the loopback interface within the VPRN (dual-stack) then both values are sent in the OSPFv2 LSA type 10, NMS prefers one over the other. In this case, all discovered routers must be configured with dual-stack OSPFv2 and OSPFv3.

Auto-provisioning using OSPF

SR OS supports the OSPF option for ZTP. The network element identifier (NEID) is configured using the chassis MAC address and the network element IP address (NEIP) is derived from the NEID. The first few slots and ports are auto-provisioned and the ZTP process tries to establish OSPF adjacency on these slots and ports to communicate the node information using type 10 opaque LSAs.

NEID

On a data communication network (DCN), a network element (NE) is uniquely identified by an ID (NEID), not by an IP address. Each NE is assigned a default NEID manually or through the auto-provisioning process.

The assigned NEIDs on a specific DCN must be different from each other because they represent the unique identities of the NEs on that DCN. If the NEIDs of two NEs on a DCN are identical, route flapping occurs.

The NEID range is from 0x10001 to 0xFEFFFE and consists of a subnet ID and basic ID. The first 8 most significant bits represent the subnet ID, which ranges from 0x1 to 0xFE. The 16 least significant bits represent the basic ID, which ranges from 0x0001 to 0xFFFE.

NEIP

NEIP addresses help managed terminals to access the NEs and allow addressing between NEs in IP networking. An NEIP address consists of a network number and a host number. A network number uniquely identifies a physical or logical link. All NEs along the same link have the same network number. A network number is obtained using the AND operation on the 32-bit IP address and corresponding subnet mask.

The NEIP address is derived from the NEID when the NE is initialized. The NEIP address is in the format 140.subnet number.basic ID. The vendor has assigned 140.x.y.z for Nokia routers.

For example, if the NEID is 0x09BFE0, which is 1001.10111111.11100000 in binary format, the NEIP address is derived as follows.

  • The subnet number is represented by the 8 most significant bits 00001001, which is 9 in decimal format. 9 is the default value.

  • The basic ID is represented by the 16 least significant bits 10111111.11100000, which is 191.224 in decimal format.

  • The NEIP address derived from the NEID 0x09BFE0 is 140.9.191.224.

Until the NEIP is configured manually, the NEIP address is derived from the NEID; changes to the NEID cause the associated NEIP address to change. After the NEIP address is configured manually, that NEIP no longer changes when the associated NEID changes.

NEIP and NEID autogenerate CLI configuration

The IPv4 format of NEIP is x.y.a.b. Where:

x is the vendor ID value

y is NEID subnet

a.b is the host portion of the NEID.

Use the following CLI commands to configure NEID and NEIP autogeneration

  • Use the following command to configure the NEID.

    configure system network-element-discovery profile neid

    The NEID can be set manually or the host portion can be set. If the host portion is set, the subnet is automatically set to 09.

  • Use the following commands to configure the NEIP in IPv4 and IPv6 formats, respectively.
    configure system network-element-discovery profile neip ipv4
    configure system network-element-discovery profile neip ipv6 

    When the NEIP is derived from the NEID, the NEID value is used as the subnet number and the host portion of the NEIP. You can configure the vendor ID value. The default vendor ID value is 140.

Auto-provisioning using OSPF

The node is auto-provisioned using OSPF if the auto-boot ospf flag is set in the BOF. When this flag is set, the node automatically creates the necessary configuration for a management VPRN and automatically generates the NEIP as described in Autogenerate configuration. The NEID must be configured and staged as described in NEIP and NEID autogenerate CLI configuration.

Autogenerate configuration

When the auto-boot ospf flag is set in the BOF, the node is configured in the following sequence:

  1. west and east port configuration and the associated MTU

  2. a management VPRN

  3. a network element profile configured under the following context.

    configure system network-element-discovery
  4. router ID in VPRN set to the NEIP address

  5. loopback interface in VPRN with the same IP address configured as the network element profile NEIP

  6. a physical interface in VPRN (SAP) with an unnumbered interface that inherits the IP from the loopback IP (this is light VPRN, where the uplink is a SAP and not a spoke SDP)

  7. VLAN dot1q support for the above L3 interface with the VLAN set to 4094

  8. a temporary username and password configured for the node, which can be the default

  9. OSPF on the physical L3 interface in the VPRN (SAP). OSPF is configured as P2P and has an additional flag to include the type 10 opaque LSA value.

  10. Telnet and FTP servers enabled under the system security context

  11. SSH, Telnet, and FTP management are supported in the VPRN; they are disabled by default.

Node discovery is done through a VPRN and SAP interface. A GRT configuration is not required.

Autogenerate NEID configuration

When the auto-boot ospf flag is used without any options, the NEID is autogenerated from the chassis MAC address. The least significant bytes of the chassis MAC address can be 00 or FF. These values are invalid as least significant bytes of an IP address. SR OS uses the following methods to mitigate these invalid bytes:

  • For IPv4, the least significant chassis MAC bytes (3 to 5) are used to generate the NEID. The bytes are shift to the left by 2 bits and ‟logical OR”-ed with 01 to generate the least significant 3 bytes of the IPv4 address.

  • For IPv6, the least significant chassis MAC bytes (2 to 6) are used to generate the NEID. The bytes are shift to the left by 2 bits and ‟logical OR”-ed with 01 to generate the least significant 5 bytes of the IPv6 address.

The auto-boot ospf flag and options

If the auto-boot ospf flag is set in the BOF, the node enters auto-discovery mode and automatically creates the management VPRN and its required configuration.

The auto-boot ospf flag options can be set manually in the BOF or by editing the bof.cfg file. For information about these options, see the auto-boot ospf command description in the CLI help or the command reference guide:

  • 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide
  • 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide

CLI generation of the loopback address and router ID using auto-boot ospf options

The loopback address and the Router ID in the management VPRN are set to the NEIP address automatically. When auto-boot ospf is executed, the configuration is generated automatically.

After node connectivity has been established, these addresses can be changed by an administrator account. If these addresses are changed using the CLI, OSPF renegotiates its neighboring session and uses the new addresses.

The only way to regenerate these addresses automatically is to change the bof auto-boot ospf option and to reboot the node.

If no options are specified for auto-boot ospf, the management VPRN configuration is set as follows:

  • NEID host must be set by the user.

  • NEIP vendor-id-value is set to 140.

  • The node goes through the ports with links operationally up and tries to establish OSPF adjacencies. If the OSPF adjacency is established on an interface, the interface is kept and the LSA type 10 TLV is advertised. The node can bring up multiple OSPF adjacencies in the discovery mode.

  • Port MTU is set to the default value for the port type.

  • OSPF MTU is set to 1500.

If options are specified for auto-boot ospf, they are used when the management VPRN CLI is created automatically. The mapping of the auto-boot ospf options to CLI commands is displayed in Mapping of auto-boot ospf options to CLI commands

Table 1. Mapping of auto-boot ospf options to CLI commands
Option Commands

neid

configure system network-element-discovery profile neid hex-string

neip-ipv4

configure system network-element-discovery profile neip ipv4 a.b.c.d

neip-ipv6

configure system network-element-discovery profile neip ipv6 x:x:x:x:x:x:x:x

no explicit neip-ipv4 or neip-ipv6

configure system network-element-discovery profile neip ipv4 auto-generate and configure system network-element-discovery profile neip ipv6 auto-generate

vendor-id set and no explicit neip-ipv4 or neip-ipv6 value

configure system network-element-discovery profile neip ipv4 auto-generate [vendor-id-value value] and configure system network-element-discovery profile neip ipv6 auto-generate [vendor-id-value value]

ospf-mtu

configure service vprn ospf area interface mtu

port-mtu

configure port ethernet mtu

Auto-provisioning details

The node is shipped with the default bof.cfg file. The operator must stage the node and execute auto-boot ospf and the NEID accordingly.

At bootup, the application reads the ospf flag and performs the following functions:

  • The node discovers and provisions the chassis and the cards according to the connectivity requirement for the chassis.

    The card and slot discovery and provisioning depend on whether the port option is set under auto-boot ospf. If the port option is set, the corresponding IOM or MDAs are discovered.

  • It does not load any configuration file.

  • If you set only the option neid for auto-boot ospf, the following occurs.

    • A vendor ID value of 140 is assigned automatically.

      Vendor ID is the most significant byte in the NEIP. By default, it is set to 140.

    • Default ports and default MTUs are set up automatically.

    • The configuration is set up based on these default values.

  • If you set additional options for auto-boot ospf, the following occurs:

  • Always disable generate-traps because it applies only to non-aggregation nodes.

    • MD-CLI
      configure system network-element-discovery generate-traps false
    • classic CLI
      configure system network-element-discovery no generate-traps

This configuration process forces the node to generate its auto-discovery profile and to advertise it through OSPF to the rest of the network.

An aggregation node must be configured manually and cannot be auto-discovered. This is because the node is connected to the NMS and must have an SNMP configuration to connect to the NMS.

Use the following commands to configure the node to generate the NEIP automatically.

configure system network-element-discovery profile neip ipv4 auto-generate
configure system network-element-discovery profile neip ipv6 auto-generate

If either of the following are set, the IP address is 140.9.c.d.

auto-boot ospf vendor-id 140
configure system network-element-discovery profile vendor-id Nokia

When the NMS has discovered the nodes, the NMS or the user can SSH to the node and clear the auto-boot ospf flag manually. In addition, the following operational guidelines apply:

  • After node discovery, all management and operations are performed through Telnet, SSH, or SNMP.

  • The NE profile and management VPRN and its configuration that was autogenerated (as described in Autogenerate configuration) are not deleted, unless explicitly deleted by the user. These are valid configurations generated automatically during auto-provisioning. They should perform the following actions to manage these valid, autogenerated configuration.

    1. Execute an admin save to save these configurations in the configuration file. If a previous configuration file exists, the existing configuration file is backed up and a new configuration file with the current configuration is saved on the compact flash (CF).

    2. Run the already existing configuration file. The management VPRN configuration should not overlap with the existing configuration file that is being executed.

Connectivity requirements

Most access topologies are ring-based, for which two interfaces are required with OSPF adjacency in VPRN. Two ports based on the chassis and auto-boot ospf options must be created and used to establish OSPF neighbor adjacencies. These interfaces should be created with VLAN 4094 for the auto-discovery process.

Auto-provisioning success

The node declares auto-provisioning success when the OSPF adjacency is created and the node has advertised the type 10 opaque LSA TLV with the node information using OSPF. When a single OSPF adjacency is created, the auto-boot ospf process declares success and does not reboot the node; the node resumes normal operational mode. However, the process tries indefinitely to bring up OSPF on other ports with link up.

If the NMS has discovered the node, the operator can log in to the node and disable auto-boot ospf.

To terminate auto-boot ospf, the user must Telnet or SSH to the node and use the option in the user prompt or the tools command.

Auto-boot OSPF reboot timers

If auto-boot ospf is not successful (that is, no OSPF adjacency is found) for 30 minutes, the node is rebooted and auto-boot is retried.

Auto-boot OSPF relation with auto-boot

The auto-boot command without the ospf flag executes ZTP with DHCP discovery. The ospf flag forces the node discovery using OSPF.

Auto-provisioning log options

Detailed auto-provisioning logs are gathered in a dedicated log queue that can be displayed with the tools dump auto-boot log command. At the end of ZTP, these logs are also written to the autoboot.log file.

Console access during auto-provisioning

While the node is running auto-provisioning, the console is accessible and node configuration is possible and accepted. If the configuration is saved during the auto-provisioning, the save operation is honored. If ZTP is running in the background, a warning message is displayed on each login to notify the user that the system can reboot as a result of ZTP.

Disabling OSPF auto-provisioning

If the node is executing auto provisioning (auto-boot), a warning message is displayed when the user logs in. The warning message gives the user the option of terminating the auto-boot process. The auto-boot ospf flag is cleared only if the user logs into the discovered node and disables the flag using Telnet/SSH or SNMP.

Auto-boot OSPF provisioning is a one-step process. If the OSPF adjacency is successfully initiated to the neighbor and goes operationally up, OSPF advertises the NE profile to the neighbor.

The management VPRN is deleted only if the user explicitly deletes it using VPRN configuration commands.

CLI structure

The NE discover feature supports profiles for NE discovery information. You can configure multiple profiles and assign each profile to a different VPRN. Each VPRN can only have a single profile and therefore a single NEID and NEIP.

Use the commands in the following context to configure NE discovery profiles.

configure system network-element-discovery profile

Assigning the NE-discovery profile to IGP

You can assign an NE profile to advertise under a VPRN OSPF area. When you assign the profile to advertise, OSPF advertises the NE information to its neighbors through type 10 opaque LSA.

Use the following command to assign an NE profile to advertise under a VPRN OSPF area.

configure service vprn ospf area advertise-ne-profile

Aggregation node configuration

An aggregation node, attached to NMS through a VPRN service, aggregates all nodes to be discovered using the same VPRN. The node is configured with:

  • a management VPRN

  • a loopback address in VPRN

  • a physical interface in the VPRN with an optional unnumbered interface inheriting the IP address from the loopback IP (this is a light VPRN where the uplink is a SAP and not a spoke SDP)

  • optional VLAN DOT1Q support for the L3 interface

  • OSPF on the physical L3 interface in the VPRN (SAP)

  • SNMP (SNMPv3) on an L3 interface in the VPRN (SAP) toward the NMS

  • a MIB table build based on the OSPF type 10 opaque LSA and stored in the OSPF opaque database

This node converts the OSPF LSA type 10 opaque information arriving from the discovered nodes into an SNMP MIB table and updates the NMS with the MIB. The NMS uses the MIB to discover the node and opens a SSH or Telnet session to configure the node accordingly.

The node to be discovered is provisioned with a management VRF as described in Node discovery procedure. All of the necessary node information needed for the node discovery is advertised by OSPF using LSA type 10 opaque. Nodes can be chained together, so the LSA type 10 needs to be forwarded all the way to the aggregation node.

NMS discovers the node using SNMP MIB traps or it can walk the MIB table.

NMS connects to the discovered node using SSH or Telnet to update the configuration by CLI. The operator must ensure that none of their commands disable the management VPRN and disconnect the discovered node from NMS.

MIB requirements on the aggregation node

A new vendor-proprietary MIB table for node discovery, tmnxVRtrNeInfoTable, is defined as part of TIMETRA-VRTR-MIB.mib. This MIB table is used by the NMS to gather all node information by walking the table, for example, after an NMS reboot.

This MIB table is built on any node that receives OSPF type 10 LSA.

The MIB table should be built with a key of VRF and NEID and a data portion of neid, vendor identify, platform type, system-mac, neip-v4, and neip-v6.

The MIB parameters are:

  • The company name is configurable using the CLI and is a string, but by default, "Nokia" is sent.

    tmnxSysNEProfVendorId            OBJECT-TYPE
        SYNTAX      DisplayString
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfVendorId specifies the 
    vendor identifier."
        DEFVAL      { "Nokia" }
        ::= { tmnxSysNEProfEntry 11 }
  • The device type is configurable and is a string, but by default, the chassis-name and the chassis-type is sent.

    tmnxSysNEProfPlatformType        OBJECT-TYPE
        SYNTAX      DisplayString
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfPlatformType specifies 
    the product identifier.
            An empty string indicates this object is not 
    configured, the chassis name and chassis type will be 
    used."
        DEFVAL      { ''H }
        ::= { tmnxSysNEProfEntry 10 }
  • The tcIPRanDcnIpv4 and tcIpRanDcnIpV6 objects are the NEIPs configured using the CLI.

    tmnxSysNEProfNeipV4Type          OBJECT-TYPE
        SYNTAX      InetAddressType
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfNeipV4Type specifies 
    the IP address type of tmnxSysNEProfNeipV4.
         The value of tmnxSysNEProfNeipV4Type can be either 
    of 'ipv4(1)' or 'unknown (0)'.
           The value of 'unknown(0)' specifies no NEIP v4
    address is configured."
        DEFVAL      { unknown }
        ::= { tmnxSysNEProfEntry 5 }
    
    tmnxSysNEProfNeipV4              OBJECT-TYPE
        SYNTAX      InetAddress (SIZE (0|4))
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfNeipV4 indicates the 
    IPv4 address of the Network Element."
        DEFVAL      { ''H }
        ::= { tmnxSysNEProfEntry 6 }
    
    tmnxSysNEProfNeipV6Type          OBJECT-TYPE
        SYNTAX      InetAddressType
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfNeipV6Type specifies 
    the IP address type of tmnxSysNEProfNeipV6.
         The value of tmnxSysNEProfNeipV6Type can be either 
    of 'ipv6(2)' or 'unknown (0)'.
           The value of 'unknown(0)' specifies no NEIP v6 
    address is configured."
        DEFVAL      { unknown }
        ::= { tmnxSysNEProfEntry 7 }
    
    tmnxSysNEProfNeipV6              OBJECT-TYPE
        SYNTAX      InetAddress (SIZE (0|16))
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfNeipV6 indicates the 
    IPv6 address of the Network Element."
        DEFVAL      { ''H }
        ::= { tmnxSysNEProfEntry 8 }
    
    tmnxSysNEProfSystemMac           OBJECT-TYPE
        SYNTAX      MacAddress
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "The value of tmnxSysNEProfSystemMac specifies
    the system MAC address of the node.
           A value of all zeros indicates this object is
    not configured, the chassis MAC address will be used."
        DEFVAL      { '000000000000'H }
        ::= { tmnxSysNEProfEntry 9 }

The MIB walk is as follows:

tmnxVRtrNeInfoNeidHex.7.0.65.66.67 = STRING: 0:41:42:43

tmnxVRtrNeInfoNeipV4Type.7.0.65.66.67 = INTEGER: ipv4(1)

tmnxVRtrNeInfoNeipV4.7.0.65.66.67 = Hex-STRING: 80 09 0A 01

tmnxVRtrNeInfoNeipV4PrefixLen.7.0.65.66.67 = Gauge32: 32

tmnxVRtrNeInfoNeipV6Type.7.0.65.66.67 = INTEGER: ipv6(2)

tmnxVRtrNeInfoNeipV6.7.0.65.66.67 = Hex-STRING: 3F FE 00 00 00 00 00 00 00 00 00 00 80 09 0A 01

tmnxVRtrNeInfoNeipV6PrefixLen.7.0.65.66.67 = Gauge32: 128

tmnxVRtrNeInfoSystemMac.7.0.65.66.67 = STRING: e:0:0:0:0:1

tmnxVRtrNeInfoPlatformType.7.0.65.66.67 = STRING: Dut-B,7750 SR-12e_ndef

tmnxVRtrNeInfoVendorId.7.0.65.66.67 = STRING: NokiaNotDefault

SNMP traps and gets

The NMS should be able to walk the entire discovery table or get a specific row using the appropriate key. This is required when the NMS is rebooted or needs to update its entire database.

If you configure the following command, every time a node is updated, added, or removed from the OSPF opaque database (using LSA type 10 opaque update) the system sends a trap to notify the NMS of the change.

configure system network-element-discovery generate-traps

The following traps are sent:

  • {tmnxVRtrNeInfoNeidHex.4.0.65.66.67 00:41:42:43}

  • {tmnxVRtrNeInfoNeipV4Type.4.0.65.66.67 ipv4}

  • {tmnxVRtrNeInfoNeipV4.4.0.65.66.67 0x80:09:0a:01}

  • {tmnxVRtrNeInfoNeipV4PrefixLen.4.0.65.66.67 32}

  • {tmnxVRtrNeInfoNeipV6Type.4.0.65.66.67 ipv6}

  • {tmnxVRtrNeInfoNeipV6.4.0.65.66.67 0x3f:fe:00:00:00:00:00:00:00:00:00:00:80:09:0a:01}

  • {tmnxVRtrNeInfoNeipV6PrefixLen.4.0.65.66.67 128}

  • {tmnxVRtrNeInfoSystemMac.4.0.65.66.67 0e:00:00:00:00:01}

  • {tmnxVRtrNeInfoPlatformType.4.0.65.66.67 {Dut-B,7750 SR-12e_ndef}}

  • {tmnxVRtrNeInfoVendorId.4.0.65.66.67 NokiaNotDefault}