This chapter provides a reference for the system configure mode commands.

Use this command to go into the delay-profile mode to edit the parameters of the "interfaces" profile. In this mode, the user is able to edit the delay measurement profile parameters.

None

Configure mode

This command was introduced in OcNOS version 5.1.

The following commands are to edit the delay-profile parameters.

delay-profile interfaces mode

This command was introduced in OcNOS version 5.1.

Use this command to enable EVPN MPLS IRB (Integrated Routing & Bridging) feature.

None

The following table list the qualifiers for TCAM group.

 

Use this command to configure different forwarding profiles in hardware.

Use show-running configuration or show forwarding profile limit to verify the selected profile.

Use this no command to set the forwarding table size to the default.

For details about these profiles, see show forwarding profile limit.

The default forwarding profile are as below

 

Configure mode

This command was introduced before OcNOS version SP 1.0. The no version of the command was introduced in OcNOS version 5.0.

Use this command to enable or disable ingress IPv4 or IPv6, egress IPv6 filter groups, EVPN-MPLS,VxLAN filter and TWAMP IPv4 or IPv6 groups. Disabling filter groups increases the configurable filter entries.

Disabling a TCAM filter group is not allowed if the group has any entries configured in hardware. Group dependent entries must be explicitly removed before disabling the TCAM group.

The twamp-ipv4 hardware profile sets up a PMF group to manage TWAMP IPv4 traffic, enabling precise hardware time stamping of TWAMP packets. These packets are identified by their source IP, destination IP, source UDP port, and destination UDP port. When a packet is recognized as a TWAMP packet, the bcmFieldActionOam action is applied, directing the packet to the OAMP module for time stamping. Additionally, the bcmFieldActionForward action is used to ensure the packet is encapsulated with the correct FEC. If the packet includes MPLS labels, the predefined qualifiers will not match. In this scenario, user-defined qualifiers are added to the same PMF group to identify the TWAMP packet.

The twamp-ipv6 hardware profile establishes two PMF groups to manage TWAMP IPv6 traffic, differentiating between MPLS and non-MPLS traffic due to the inability to fit user-defined qualifiers in a single PMF group. These groups ensure accurate hardware time stamping of TWAMP packets, identified by their source IPv6, destination IPv6, source UDP port, and destination UDP port. When a packet is recognized as a TWAMP packet, the bcmFieldActionOam action is applied, sending the packet to the OAMP module for time stamping. Additionally, the bcmFieldActionForward action ensures the packet is encapsulated with the correct FEC. If the packet includes MPLS labels, the predefined qualifiers will not match. In this case, user-defined qualifiers are added to identify the TWAMP packet, and since the IPv6 qualifiers cannot be included in the same group, they are created in a separate group.

By default, all filter groups are disabled.

Configure mode

This command was introduced before OcNOS version 1.3 and changed in OcNOS version 3.0.

 

 

Use this command to enable or disable ingress IPv4 or IPv6, egress IPv6 filter groups, EVPN-MPLS,VxLAN filter and TWAMP IPv4 or IPv6 groups. Disabling filter groups increases the configurable filter entries.

Disabling a TCAM filter group is not allowed if the group has any entries configured in hardware. Group dependent entries must be explicitly removed before disabling the TCAM group.

For better utilization of TCAM resources it is recommended to enable large groups first and then smaller groups.

By default, all filter groups are disabled.

Configure mode

This command was introduced before OcNOS version 1.3 and changed in OcNOS version 3.0.

 

 

 

Use this command to globally enable or disable hardware-based flow control.

By default flow control is disabled.

Configure mode

This command was introduced in OcNOS version 3.0.

Use this command to set the number of service-queue counts to create in hardware.

Use the no form of this command to set the service queue profile to default

By default, profile1 is enabled.

Configure mode

This command was introduced before OcNOS version 1.3.

This command is only available on Qumran platforms.

Use this command to enable or disable filter statistics in hardware.

In Q1, By default, only ingress-acl statistics profile is enabled. Other statistics profiles are disabled.

In Q2, By default, voq-full-color, cfm-ccm statistics profile is enabled. Other statistics profiles are disabled. The voq-full-color cannot be disabled.

Configure mode

This command was introduced before OcNOS version 1.3 and this command is applicable for Qumran. The voq- full-color and voq-fwd-drop,cfm-slm,cfm-lm and cfm-ccm options are applicable for Qumran2.

Table 9-50 provides details of scalable numbers of each statistics profiles and the applications that use the statistics profiles. For example, the ingress-acl profile is used by ACL, QoS, and PBR applications and all of them share the statistics entries from this profile. So, consuming 8k statistics entries for ACL application means that QOS and PBR applications do not get any statistics.

There are limitations on the number of statistics profiles that can be enabled at a time. This limitation is based on the stages that each profile uses. Table 9-50 shows the four stages: ingress, ingress queuing, egress1, and egress2; and only two statistics profiles per stage can be configured.

For example, if both the ingress-acl and mpls-acl profiles are configured, then no more profiles that use the “ingress stage” can be enabled because only two profiles are allowed per stage. To use another “ingress-based” profile, you must first disable at least one of the profiles that are currently using the ingress stage.

None

Configure mode

This command was introduced in OcNOS version 6.3.5.

 

Use this global command to trap ICMP redirect packets to the CPU and on interface to enable ICMP redirects in kernel.

Use the no form of this command to disable the ICMP redirect message on an interface.

None

None

Configure and Interface mode

This command was introduced in OcNOS version 3.0.

Use this command to enable load-balancing configurations in hardware.

Use the no option to reset the load balancing to default settings.

This form unsets load balancing globally:

This form resets load balancing globally to default settings:

 

By default, load balancing is enabled for ECMP and LAG.

This form sets hashing based on IPv4 fields:

 

This form sets hashing based on IPv6 fields:

 

This form sets hashing based on L2 fields:

 

This form sets hashing on an MPLS fields:

Following additional parameters are supported on Dune DNX boards:

 

 

Configure mode

This command was introduced before OcNOS version 3.0.

 

Use this command to display the forwarding profile table sizes.

None

None

Exec mode

This command was introduced before OcNOS version SP 1.0.

None

This command was introduced before OcNOS version 3.0.

 

Table 9-52 explains the output fields.

When a TCAM group is enabled in the device, no hardware resource (bank) is associated with the group. Thus, dedicated count will be initially zero. Total count will be same as shared count which is calculated based on the group width. Group width is determined by width consumed by the qualifiers or width consumed by the actions.

Example of show output when qos-ext group is enabled on QMX device is shown below:

When an entry is created on the group for the first time, either a single bank or a bank pair is allocated to the group. A group consuming single bank or a bank pair is decided by group width. Groups like qos, ingress-l2, and ingress-ipv4 consume single bank and groups like qos-ext, qos-policer, ingress-l2-ext, ingress-ipv4-ext, ingress-ipv4-qos, ingress-ipv6, ingress-ipv6-qos, egress-l2, and egress-ipv4 consume a bank pair.

An example of output when a single entry is created in hardware for qos-ext group on QMX device is shown below:

In the above example, dedicated entry count has increased to 2048 as a bank pair is allocated for the group. Unallocated banks capacity is calculated for qos-ext group and counted under shared entries as 8448.

An example of output when 2048 entries are created in hardware for qos-ext group and ingress-l2 and ingress-ipv4-ext groups is enabled with no entries created on those groups for QMX device is shown below:

In the above example, note that the number of entries between ingress-l2 and ingress-ipv4-ext groups vary as ingress-l2 group is a 160-bit wide group consuming only one bank at a time. On the other hand, ingress-ipv4-ext group is 320 bit wide group consuming a group pair at a time. With a bank pair already being consumed by qos-ext group, ingress-ipv4-ext group gets possible total entries of 8448 in comparison to 10496 by qos-ext group.

When all the created entry count goes beyond the entries of dedicated bank pair (or a bank), group will be allocated with another bank pair (or a bank) and subsequently shared pool count will reduce across all other groups.

An example of output when 2049 entries are created in hardware for qos-ext group with ingress-l2 and ingress-ipv4-ext groups enabled with no entries created on those groups for QMX device is shown below:

When a bank is consumed by ingress-l2 group, effect on qos-ext group will still be the count of a bank pair with one bank not usable for qos-ext group even if it is available. The bank can be used by groups which consume single bank.

An example of output when an entry is created in hardware for ingress-l2 group with qos-ext and ingress-ipv4-ext groups in the state as mentioned in above example is shown below:

In the above example scenario, it can be noted that the used entry percentage for qos-ext group jumped from 20 to 24 as a result of drastic reduction in total entry count due to bank movement from shared pool to dedicated bank.

Hardware doesn’t optimize the utilization of banks when entries are removed from one of the banks resulting in entries used shown up less than capacity of one bank but still multiple banks would be dedicated to a group.

An extended example of above scenario with 10 entries removed from qos-ext group is shown below:

It can be noted that the used entry count has come down to 2039 which is less than the capacity of bank pair i.e. 2048. However, since entries are used up across two set of bank pairs, both bank pairs will still be dedicated. If there is a need to recover bank pair from dedicated pool, all the entries should be deleted and re-created in hardware.

TCAM groups are further divided into sub-categories which can share the dedicated banks between the groups. TCAM groups such as ingress-l2, ingress-l2-ext, ingress-ipv4, ingress-ipv4-ext, ingress-ipv4-qos, qos, qos-ext, qos-policer are considered under default sub-category and don't serve IPv6 traffic. TCAM groups such as ingress-ipv6, ingress-ipv6-qos, and qos-ipv6 are meant for IPv6 traffic and are considered under IPv6 sub-category.

Only four 320-bit wide groups that belong to same sub-category can be created. For default sub-category, number is limited to three as system group will be created by default.

When three default sub-category groups are created along with one group from IPv6 sub-category, one of the default sub-category group will share the bank pair with IPv6 group. This will result in dedicated count to be shown lesser by the number that the other shared group is consuming. With every single resource consumed by one group will reduce the same number from other shared group.

An example of above scenario is shown below:

Note that ingress-ipv4-qos group has shared the resource with ingress-ipv6 group. TCAM group ingress-ipv4-qos has consumed 1 entry and ingress-ipv6 group has consumed 17 entries. Hence, dedicated count for ingress-ipv4-qos group is shown as 2031 (2048 - 17) and dedicated count for ingress-ipv6 group is shown as 2047 (2048 - 1).

Entries created on other TCAM groups affect the capacity of a particular TCAM group. This dependency is explained in the section Operational details of TCAM profiles.

In this section maximum configurable entries per group when no entries created on other groups are listed below.

Device supports configuration of only one egress group in the system. Hence out of the egress groups cfm-domain-name-str, egress-l2 and egress-ipv4, only one egress group can be enabled.

In other words, solution with CFM features enabled, cannot have egress security filters.

Configuration of ingress groups are subject to the sub-category to which a group belongs. Sub-category of each group is shown below:

Use this command to display the information of Graceful Restart capable MPLS clients to NSM that are currently shutdown. Use the option LDP or RSVP to see the particular module information.

Privileged Exec mode

This command was introduced before OcNOS version 5.0.

Use this command to display the traffic class-to-hardware-queue mapping in hardware.

N/A

N/A

Exec mode

This command was introduced before OcNOS version 1.3.

This command is only available on Qumran platforms.

When service-queue profile1 is set:

When service-queue profile2 is set: