8. 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 will push the new configuration to the node and perform any other required modifications using CLI (SSH and/or Telnet).

8.1. 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. The aggregation node also generates traps as necessary to update the NMS when the configure system network-element-discovery generate-traps command is configured. In addition to the traps, the NMS can walk the MIB table to update its new view of the network.

The node can be discovered using an IPv4 or IPv6 NEIP but the advertisement protocol is always OSPFv2; OSPFv3 is not supported. If the NMS wants to discover a node in an IPv6 network, both OSPFv2 and OSPFv3 must be enabled. OSPFv2 will advertise the node information to the aggregation node to generate the traps and build the MIB table but OSPFv3 will be used to provide the routing information needed to reach that node using an IPv6 network.

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

  1. a management VPRN
  2. a network element profile configured under the config>system>network-element-discovery context
  3. a loopback or physical L3 interface in the VPRN with same IP address as the network element profile NEIP
  4. 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)
  5. an optional VLAN DOT1Q support for the L3 interface
  6. a temporary username and password. This could be the default.
  7. 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.
  8. SSH and/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.

8.1.1. Network Element Profiles

A network element profile is created for the system with all the information needed for node discovery using the commands below. This information will be flooded to the network using IGP.

CLI Syntax:
config>system>network-element-discovery
profile <profile name>
neid
neip
system-mac
platform-type
vendor-id

This profile can be assigned to a VPRN OSPFv2 area for advertisement. Only one profile can be created for each node.

If a value is not set, the following default values are used for these optional parameters:

  1. system-mac = chassis-mac
  2. platform-type = "chassis-name, chassis-type"
  3. vendor-id = "Nokia"

8.1.2. Assigning a Network Element Profile

When a network element profile is assigned to OSPFv2, its information will be advertised using LSA type 10 opaque. Use the following commands to assign a network element profile to OSPFv2:

CLI Syntax:
config>service>vprn
ospf
area 0
advertised-ne-profile <profile-name>
interface loopback
interface uplink

The network element information will not be added to the routing table (RIB) or forwarding table (FIB), 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 will not have any route entry in the RIB or FIB for the NEIP.

CLI Syntax:
config>system>network-element-discovery
profile <name-1>
neid 0x091001
neip 128.9.10.1
config>service>vprn 1
ospf
area 0
advertised-ne-profile <name-1>
interface loopback
interface uplink
interface loopback
loopback
address 128.9.10.1

8.1.3. OSPFv2 Opaque LSA Requirements

OSPF Opaque LSA packets are made up of the following, as shown in Figure 20.

  1. LSA ID: 202.255.238.0
  2. Opaque type value: 202
  3. Instance value: 255.238.0 (ffee00)
Figure 20:  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:

  1. Vendor identifier — vendor-id (vendor defined string)
    1. type — 0x8000
    2. length — length of identify string
    3. Default value — "Nokia"
  2. Equipment identifier — product-id (vendor defined string)
    1. type — 0x8001
    2. length — length of identify string
    3. default value — "chassis-name, chassis-type"
  3. System-Mac — node system MAC (node unique)
    1. type — 0x8002
    2. length — 6
    3. default value — chassis mac address
  4. NEID — Node hostname (customer defined)
    1. type — 0x8003
    2. length — 4
  5. NEIP IPv4 — loopback IPv4 address (preconfigured)
    1. type — 0x8004
    2. length — 4
  6. NEIP IPv6: loopback IPv6 address (preconfigured)
    1. type — 0x8005
    2. length — 16

8.1.4. 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 will prefer one over the other. In this case, all discovered routers must be configured with dual-stack OSPFv2 and OSPFv3.

8.2. 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.

8.2.1. 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.

8.2.2. 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.

  1. The subnet number is represented by the 8 most significant bits 00001001, which is 9 in decimal format. 9 is the default value.
  2. The basic ID is represented by the 16 least significant bits 10111111.11100000, which is 191.224 in decimal format.
  3. 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.

8.2.3. NEIP and NEID Auto-generate 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.

The following CLI commands configure the auto-generation of NEID and NEIP.

  1. The configure system network-element-discovery profile neid command configures the 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.
  2. The configure system network-element-discovery profile neip ipv4 and configure system network-element-discovery profile neip ipv6 commands configure the NEIP in IPv4 and IPv6 formats, respectively.
    When the NEIP is derived from the NEID, the NEID value is used as the subnet number and the host portion of the NEIP. The default vendor ID value is 140. The vendor ID value can be configured.

8.2.4. 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 Auto-generate Configuration. The NEID must be configured and staged as described in NEIP and NEID Auto-generate CLI Configuration.

8.2.4.1. Auto-generate 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 configure system network-element-discovery context
  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 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.

8.2.4.1.1. Auto-generate NEID configuration

When the auto-boot ospf flag is used without any options, the NEID is auto-generated 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.

  1. 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.
  2. 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.

8.2.4.2. The auto-boot ospf Flag and its 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 has options that can be set manually in the BOF or by editing the bof.cfg file. For information about the options, see the auto-boot ospf command description in the Classic CLI Command Reference Guide.

8.2.4.3. CLI Generation of the Loopback Address and Router ID from auto-boot ospf and its 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.

  1. NEID host must be set by the user.
  2. NEIP vendor-id-value is set to 140.
  3. 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.
  4. Port MTU is set to the default value for the port type.
  5. 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 as follows:

option neid—command: configure system network-element-discovery profile neid hex-string

option:neip-ipv4—command: configure system network-element-discovery profile neip ipv4 a.b.c.d

option: neip-ipv6—command: configure system network-element-discovery profile neip ipv6 x:x:x:x:x:x:x:x

option: no explicit neip-ipv4 or neip-ipv6 set—commands: configure system network-element-discovery profile neip ipv4 auto-generate and configure system network-element-discovery profile neip ipv6 auto-generate

option: vendor-id set and no explicit neip-ipv4 or neip-ipv6 value—commands: 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]

option: ospf-mtu—command: configure service vprn ospf area interface mtu

option: port-mtu—command: configure port ethernet mtu

8.2.4.3.1. 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.

  1. 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 and/or MDAs are discovered.
  2. It does not load any configuration file.
  3. If the user has set only the option neid for auto-boot ospf, the following occurs.
    1. 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.
    2. Default ports and default MTUs are set up automatically.
    3. The configuration is set up based on these default values.
  4. If the user has set additional options for auto-boot ospf, the following occurs.
    1. These values are used to generate the configuration as described in CLI Generation of the Loopback Address and Router ID from auto-boot ospf and its Options.
      Vendor ID is the most significant byte in the NEIP. By default, it is set to 140.
    2. Either all or some of these options can be set. The options that are not set remain at their default values.
    3. These configured options generate the configuration as described in CLI Generation of the Loopback Address and Router ID from auto-boot ospf and its Options.
  5. The configure system network-element-discovery generate-traps option should always be disabled because this feature applies only to non-aggregation nodes.

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.

The node can be configured to generate the NEIP automatically using configuration under the NE profile:

CLI Syntax:
config>system>network-element-discovery
generate traps
profile <profile name>
neid <value>
neip ipv4 auto-generate or
neip ipv6 auto-generate

If auto-boot ospf vendor-id 140 or configure system network-element-discovery profile profile-name vendor-id Nokia is set, the IP address is 140.9.c.d.

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.

  1. After node discovery, all management and operations are performed through telnet, SSH, or SNMP.
  2. The NE profile and management VPRN and its configuration that was auto-generated (as described in Auto-generate 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, auto-generated 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.

8.2.4.4. 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.

8.2.4.5. 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.

8.2.4.6. 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.

8.2.4.7. 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.

8.2.4.8. 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.

8.2.4.9. 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.

8.2.4.10. 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.

8.2.5. CLI Structure

The NE information is configured under the configure system network-element-discovery context using profiles. More than one profile can exist and each profile can be assigned to a different VPRN. Each VPRN can only have a single profile and, as such, a single NEID and NEIP.

8.2.5.1. Assigning the ne-discovery Profile to IGP

The advertise-ne-profile can be assigned under service vprn ospf area. When this profile is assigned, OSPF advertises the NE information to its neighbors through type 10 opaque LSA.

8.3. 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:

  1. a management VPRN
  2. a loopback address in VPRN
  3. 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)
  4. optional VLAN DOT1Q support for the L3 interface
  5. OSPF on the physical L3 interface in the VPRN (SAP)
  6. SNMP (SNMPv3) on an L3 interface in the VPRN (SAP) toward the NMS
  7. 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 will disable the management VPRN and disconnect the discovered node from NMS.

8.3.1. 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:

  1. The company name is configurable using the CLI and is a string, but by default, "Nokia" is sent.
    Example:
    tmnxSysNEProfVendorId OBJECT-TYPE
    SYNTAX DisplayString
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
    "The value of tmnxSysNEProfVendorId specifies the vendor identifier."
    DEFVAL { "Nokia" }
    ::= { tmnxSysNEProfEntry 11 }
  2. The device type is configurable and is a string, but by default, the chassis-name and the chassis-type is sent.
    Example:
    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 }
  3. The tcIPRanDcnIpv4 and tcIpRanDcnIpV6 objects are the NEIPs configured using the CLI.
    Example:
    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

8.3.2. SNMP Traps and Gets

The discovery table should be walkable by the NMS. The NMS can walk the entire 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.

In addition, every time a node is updated, added, or removed from the OSPF opaque database (using LSA type 10 opaque update) a trap is sent to the NMS to notify the NMS of the change if the configure system network-element-discovery generate-traps command is configured. These traps are:

  1. {tmnxVRtrNeInfoNeidHex.4.0.65.66.67 00:41:42:43}
  2. {tmnxVRtrNeInfoNeipV4Type.4.0.65.66.67 ipv4}
  3. {tmnxVRtrNeInfoNeipV4.4.0.65.66.67 0x80:09:0a:01}
  4. {tmnxVRtrNeInfoNeipV4PrefixLen.4.0.65.66.67 32}
  5. {tmnxVRtrNeInfoNeipV6Type.4.0.65.66.67 ipv6}
  6. {tmnxVRtrNeInfoNeipV6.4.0.65.66.67 0x3f:fe:00:00:00:00:00:00:00:00:00:00:80:09:0a:01}
  7. {tmnxVRtrNeInfoNeipV6PrefixLen.4.0.65.66.67 128}
  8. {tmnxVRtrNeInfoSystemMac.4.0.65.66.67 0e:00:00:00:00:01}
  9. {tmnxVRtrNeInfoPlatformType.4.0.65.66.67 {Dut-B,7750 SR-12e_ndef}}
  10. {tmnxVRtrNeInfoVendorId.4.0.65.66.67 NokiaNotDefault}