Node discovery provisioning using OSPF

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.

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

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

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.

[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" {
            }
        }
    }

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

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)

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

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.

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

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.

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.

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

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

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}