What can I help you with?
NVIDIA UFM-SDN Appliance User Manual v4.18.4

Defining Routing Chain Policy File

In order to define a port group policy file, set the parameter 'rch_policy_file' in the opensm configuration file.

Copy
Copied!
            

rch_policy_file /etc/opensm/conf/chains_policy_file

The first unicast engine in a routing chain must include all switches and HCA's in the fabric (topology id must be 0). The path-bit parameter value is path-bit 0 and it cannot be changed.

The routing chains policy file details the routing engines (and their fallback engines) used for the fabric's routing. The policy file should be composed of one or more paragraphs which defines an engine (or a fallback engine). Each paragraph should begin with the line 'unicast-step' and end with the line 'end-unicast-step'.

For example:

Copy
Copied!
            

unicast-step …routing engine qualifiers… end-unicast-step

Note

Unlike unicast-step and end-unicast-step which do not require a colon, all qualifiers must end with a colon (':'). Also - a colon is a predefined mark that must not be used inside qualifier values. An inclusion of a colon in the qualifier values will result in the policy's failure.

Routing Engine Qualifiers

Parameter

Description

Example

id

‘id’ is man dato ry. Without an id qualifier for each engine, the policy fails.

  • Legal values - size_t value (0 is illegal).

  • The engines in the policy chain are set according to an ascending id order, so it is highly crucial to verify that the id that is given to the engines match the order in which you would like the engines to be set.

is: 1

engine

This is a mandatory qualifier that describes the routing algorithm used within this unicast step.

Currently, on the first phase of routing chains, legal values are minhop/ftree/updn.

engine: minhop

use

This is an optional qualifier that enables one to describe the usage of this unicast step. If undefined, an empty string is used as a default.

use: ftree routing for for yellow stone nodes

config

This is an optional qualifier that enables one to define a separate opensm config file for a specific unicast step. If undefined, all parameters are taken from main opensm configuration file.

config: /etc/config/opensm2.cfg

topology

Define the topology that this engine uses.

  • Legal value - id of an existing topology that is defined in topologies policy (or zero that represents the entire fabric and not a specific topology).

  • Default value - If unspecified, a routing engine will relate to the entire fabric (as if topology zero was defined).

  • Notice: The first routing engine (the engine with the lowest id) MUST be configured with topology: 0 (entire fabric) or else, the routing chain parser will fail.

topology: 1

fallback-to

This is an optional qualifier that enables one to define the current unicast step as a fallback to another unicast step. This can be done by defining the id of the unicast step that this step is a fallback to.

  • If undefined, the current unicast step is not a fallback.

  • If the value of this qualifier is a non-existent engine id, this step will be ignored.

  • A fallback step is meaningless if the step it is a fallback to did not fail.

  • It is impossible to define a fallback to a fallback step (such definition will be ignored)

-

path-bit

This is an optional qualifier that enables one to define a specific lid offset to be used by the current unicast step. Setting lmc > 0 in main opensm configuration file is a prerequisite for assigning specific path-bit for the routing engine.

Default value is 0 (if path-bit is not specified)

Path-bit: 1

Dump Files per Routing Engine

Each routing engine on the chain will dump its own data files if the appropriate log_flags is set (for instance 0x43).

The files that are dumped by each engine are:

  • opensm-lid-matrix.dump

  • opensm-lfts.dump

  • opensm.fdbs

  • opensm-subnet.lst

These files should contain the relevant data for each engine topology.

Note

sl2vl and mcfdbs files are dumped only once for the entire fabric and NOT by every routing engine.

  • Each engine concatenates its ID and routing algorithm name in its dump files names, as follows:

    • opensm-lid-matrix.2.minhop.dump

    • opensm.fdbs.3.ftree

    • opensm-subnet.4.updn.lst

  • In case that a fallback routing engine is used, both the routing engine that failed and the fallback engine that replaces it, dump their data.

    If, for example, engine 2 runs ftree and it has a fallback engine with 3 as its id that runs minhop, one should expect to find 2 sets of dump files, one for each engine:

    • opensm-lid-matrix.2.ftree.dump

    • opensm-lid-matrix.3.minhop.dump

    • opensm.fdbs.2.ftree

    • opensm.fdbs.3.munhop

© Copyright 2025, NVIDIA. Last updated on Jul 3, 2025.