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

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

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

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

7.1.3. OSPFv2 Opaque LSA Requirements

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

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

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

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

7.2.1. MIB Requirements on the Aggregation Node

A new vendor-proprietary MIB table for node discovery, tmnxVRtrNeInfoTable, is defined. 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

7.2.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}