Node discovery provisioning using OSPF

A network element profile contains all information for node discovery. This information is flooded to the network using IGP.

configure system network-element-discovery profile

This profile can be assigned to a VPRN OSPFv2 area for advertisement. Only one profile can be created 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 an NE profile is assigned to OSPFv2, the profile 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, 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 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 that 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, SR OS will 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
----------------------------------------------

The following figure shows the OSPF Opaque LSA packet structure.

• LSA ID: 202.255.238.0

• Opaque type value: 202

• Instance value: 255.238.0 (ffee00)

OSPF Opaque LSA type 10 TLV contains the following information:

• Vendor identifier

  vendor-id (vendor-defined string)

  • type - 0x8000

  • length - length of identify string

  • default value - "Nokia"

• Equipment identifier

  product-id (vendor-defined string)

  • type - 0x8001

  • length - length of identify string

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

• System-Mac

  node system MAC (node unique)

  • type - 0x8002

  • length - 6

  • default value - chassis mac address

• NEID

  Node hostname (customer defined)

  • type - 0x8003

  • length - 4

• NEIP IPv4

  loopback IPv4 address (preconfigured)

  • type - 0x8004

  • length - 4

• NEIP IPv6

  loopback IPv6 address (preconfigured)

  • type - 0x8005

  • length - 16

Both IPv4 and IPv6 node discovery are supported. However, LSA type 10 is only advertised on OSPFv2, not OSPFv3. To use IPv6 or dual-stack, the operator must configure OSPFv2 under VPRN to advertise the node information using LSA type 10 opaque. In addition, OSPFV3 can 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), both values are sent in the OSPFv2 LSA type 10, but NMS will prefer 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.

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

• 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. The default vendor ID value is 140. The vendor ID value can be configured.

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.

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. NMS walks this MIB table to gather all node information, for example, after an NMS reboot.

The 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 as follows.

     tmnxSysNEProfVendorId            OBJECT-TYPE
         SYNTAX      DisplayString
         MAX-ACCESS  read-create
         STATUS      current
         DESCRIPTION
             "The value of tmnxSysNEProfVendorId specifies the vendor identifier."
         DEFVAL      { "Nokia" }
         ::= { tmnxSysNEProfEntry 11 }

     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 }

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

When a node is updated, added, or removed from the OSPF opaque database (using LSA type 10 opaque update), a trap is sent to notify the NMS of the change if the following command is configured.

configure system network-element-discovery generate-traps

These traps are as follows:

• {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}