Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Custom Profiles for Hardware Resources

This topic provides an overview of custom profiles for hardware resources

hw-profile

Using hw-db-profile you can statically reserve hardware resources. But hw-db-profile cannot be used for all hw resources because there are resources that need to be managed independently. You can use the custom profile infrastructure instead to customize hardware resource allocation as per application requirements. Using the custom profile infrastructure allows you to create application-specific dynamic hardware resource allocations.

In the following configuration stanza, the hardware profile (hw-profile) is the top level configuration statement under which you specify the currently active custom hardware profile that is applied on the system. hw-profile-name is the name of the currently active custom hardware profile that is applied to the system. Upon successful commit, the system restarts the PFE. Note that you can create multiple custom hardware profiles but only use one as the currently active custom hardware profile using this CLI.

Custom hardware profile

As discussed in the preceding section, the custom hardware profile (hw-profile-name) is user-defined and holds details for custom profiles created for hardware resources such as counters.

In the following configuration stanza, <hw-profile-name> is the name of the custom hardware profile that holds details for custom profiles created for counters (counter-profile <counter-profile>) hardware resource.

In the following configuration stanza, custom profiles are created for counters (hardware resources). Custom profiles created for counters are called counter profiles. In Junos OS release 25.3 only counter profiles are supported.

So the sequence of steps to follow is:

  • Create custom counter profiles. See counter-profiles

  • Create custom hardware profiles. Each custom hardware profile can be defined with one to many distinct custom profiles. See hw-profiles.

  • Apply one custom hardware profile as the active hardware profile. See hw-profile.

Custom counter profile

A custom counter profile provides a mechanism to allocate counter engines per application. The allocations are made based on the scale requirements of applications. Counter resources are provided through various counter engines. There are three types of counter engines based on the number of counters they support. 4k counter engine support 4K counters. Similarly, 8K and 16 counter engine supports 8K and 16K counters. Number of counter engines varies depending on platform. See counter-profiles.

In the following configuration stanza, <counter-profile-name> is the name of the custom counter profile. Under app, tcam-ingress, voq, and ifl-ingress, are the names of the applications that have been allocated counter hardware resources.

Example

The following example demonstrates setting counter resources for applications. Two custom counter profiles are created. Two custom hardware profiles are created for each custom counter profile. One custom hardware profile is set as the active hardware profile

The steps are as follows:

Create two custom counter profiles cntr1 and cntr2

Create two custom hardware profiles each for the two custom counter profiles

Set one custom hardware profile as the active hardware profile

Considerations in Counter Profile Management

Default behaviour

  • If no custom counter profile is defined, the platform uses the default statically allocated counter profile. This allocation will be same as existing allocation prior to the 25.3 release.

  • Once a custom profile is defined, only the application mentioned in custom counter profile will have counter allocation as configured by user.

VOQ Statistics - Reserved Counters

  • ACX7100 / ACX7509 platforms have one 8K counter engine internally reserved for Port VOQ statistics.

  • Other platforms reserve one 4K counter engine by default.

  • If a custom counter profile is configured without explicit VOQ allocation, the reserved engine supports only Port VOQ. For HQoS statistics, a custom counter profile with app voq needs to be configured.

TCAM and Policer Engine

  • It is mandatory to configure the TCAM and Policer applications (tcam-ingress, tcam-egress, policer-ingress, and policer-egress) when defining a custom counter profile in the 25.3 release till it is available for user to configure. TCAM and policer app cannot be configured with values other than their default profile values.

  • The configured values for these applications must match the platform’s default allocations exactly.

  • Any deviation from the default counter enignes (e.g., setting tcam-ingress counter-8k to 2 instead of the default 3) will result in a validation error during commit.

  • Counter engines are shared between counters and policers. Applications using policers must explicitly reserve the required number of counter engines to avoid resource conflicts.

Multicast Route Statistics

  • Starting from release 25.3, Multicast statistics are supported through the Counter Profile Infrastructure, enabling resource flexibility and application-specific allocation.

  • To ensure backward compatibility, the legacy CLI: set system packet-forwarding-options mcast stats-enable is retained (hidden) in applicable releases. This allows support for older configurations while transitioning to the new model.

  • Validations are introduced to prevent duplicate counter engine reservations for multicast, avoiding configuration conflicts between the legacy CLI and the new profile-based approach.

  • It is recommended that users explicitly configure multicast statistics using the custom counter profile, and remove any legacy CLI configuration to ensure clarity and avoid unintended behavior.

External Counters (external-cntr) in OP2 (ACX7332)

  • In ACX7332, TCAM uses counter engine in OP2 for IFF/FTF based filters. However, for policers and other uses, TCAM continues to use the internal counter engine. Hence allocation needs to be done accordingly.

  • external-cntr is allocated based on number of counter entries. Only tcam-ingress application can reserve the external-cntr entries and is set to 262142 entries.

Configuration guidelines

The following table summarizes the configuration recommendations for counter engines for each application. It is recommended that users configure the number of counter engines to match the number of application scale.

Table 1: Configuration Guidelines for Applications Using Custom Profiles

Application

Configuration Guidelines

storm-control

Storm-control relies on the counter engine to implement policing functionality. Therefore, configuring the counter engine beyond the application scale is not necessary.

VOQ

HQoS scale with statistics support can be increased based on available free counter engine resources.​

The increase in HQoS scale is not directly proportional to counter engine availability, as it also depends on other hardware resources."​

Counter engines are assigned at the system level for HQoS

tcam-ingress

Not applicable as counter engines cannot be modified.

perf-mon-ingress

TWAMP and inline sFlow functionality utilize the counter engine for timestamping and sequencing purposes respectively. Therefore, configuring the counter engine beyond the application scale is not necessary.

ifl-ingress

When IFLs are symmetrically distributed across multiple PFEs, a smaller number of counter engine entries may suffice— For example, with 16K IFLs split evenly between two PFEs (8K IFLs per PFE), 8K counter engine entries might be sufficient. This is because the counter engine itself is also distributed symmetrically across PFE.

However, if the same total number of IFLs (e.g., 16K IFLs) is configured on a single PFE, it is recommended to provision the full amount of counter engine entries (e.g., 16K) at the system level to ensure statistics can be collected for all interfaces.​

Above explanation holds good for physical IFL but not for logical IFLs.

policer-ingress

Not Applicable, as counter engines cannot be modified

tcam-egress

Not Applicable, as counter engines cannot be modified

perf-mon-egress

Same as perf-mon-ingress for inline Sflow application.

ifl-egress

Same as ifl-ingress

policer-egress

Not Applicable, as counter engines cannot be modified

multicast

Counter engines are assigned at the system level for multicast routes.​

The availability of statistics for multicast routes is also dependent on other HW resources (FEC-3 Hierarchy)

  • In platforms such as ACX7100-32C, and ACX7100-48L it is not possible to directly copy the default counter profile configuration into a custom profile due to internal reservation of certain apps. As a result, users must manually adjust the counter engines in the custom profile to match the behavior or scale of the default profile, if needed.

    For example, the default counter profile below is the counter engine allocation.

    Same scale as default counter profile can be achieved via below by adjusting the counter engines. (VOQ internally 8K is reserved. Internal reservation can be checked in show cntr-app-map).

  • For ACX7024, default counter profile allocation is as below.

    For custom profile configuration available 4k counter engine is less than default, as 1 4k is internally reserved to VOQ. Hence need to adjust either PERF_MON_INGRESS or PERF_MON_EGRESS app to 8k as show below.

Validation Examples

The following are a few validation examples where the system performs a check before committing the configuration statement.

Ifl symmetric validation for ingress and egress

Number of configured engines exceeds supported engines

App specific validation- Inline Sflow is configured, however counter engines required for sflow is not configured

Mandatory configuration of TCAM and policer app in the current release

Configure the same value as the default profile for TCAM app

Handling upgrade and downgrade scenarios

You must delete the hardware profile, all custom hardware profiles, and all custom counter profiles to downgrade to a Junos OS version that has no support for the custom profile infrastructure. To upgrade to a Junos OS version where custom profile is supported, follow the regular Junos OS upgrade procedure, and then start using the custom profile infrastructure.

Because prior to 25.3 release, multicast route statistics was supported using the CLI set system packet-forwarding-options mcast stats-enable, the system handles multicast route statistics for upgrade and downgrade procedures in the manner summarized in the following table.

Table 2: Multicast Route statistics support during upgrade or downgrade procedures

Scenario

Expected behavior

Upgrade to image with custom profile support - when multicast statistics is not configured on the device.

The upgrade will be successful. User can configure custom profile with multicast application, if required.

Upgrade to image with custom profile support - when multicast statistics is configured on the device.

  • The multicast statistics CLI command set system packet-forwarding-options mcast stats-enable will be hidden to user.

  • Counter-engine will be statically reserved for multicast application.

  • If any multicast statistics configuration has been made with set system packet-forwarding-options mcast stats-enable in the old Junos image, this configuration has to be deleted. Then a new custom profile has to be created for the multicast application using the new CLIs in the custom profile infrastructure.

  • Until if any previous multicast configuration is removed, the system will not allow to configure custom profile for multicast application using the new custom profile infrastructure CLIs.

    The sequence of steps are as below:

    • Delete the previous CLI configuration

      delete system packet-forwarding-options mcast stats-enable

    • Define custom counter profile for the multicast application. The following is an example of such a configuration.

      set system packet-forwarding-options custom-profiles counter-profiles cntr1 app multicast counter-16k 1
    • Define a custom hardware profile with this custom counter profile

      set system packet-forwarding-options custom-profiles hw-profiles hw1 counter-profile cntr1
    • Apply this custom hardware profile as the active hardware profile

      set system packet-forwarding-options hw-profile hw1

Downgrade/ rollback to older Junos OS image, where counter profile infrastructure is not supported, and custom profile configurations for multicast application.

Will fail the downgrade. To successfully downgrade to an older Junos OS version, the custom profile infrastructure CLI configurations for multicast application need to be deleted.

After downgrading to an older Junos image where custom profile infrastructure is not supported, user can configure multicast statistics support using the old multicast statistics CLI - set system packet-forwarding-options mcast stats-enable

Downgrade/ rollback to older Junos OS image, where counter profile infrastructure is not supported, and multicast statistic configuration has already been set using set system packet-forwarding-options mcast stats-enable

Downgrade to the older image will be successful and multicast counter-engine would be reserved after the image downgrade.

Troubleshooting - hw-profile

  • Use show commands show system packet-forwarding-options hw-profile and show system packet-forwarding-options hw-profile counter-profile to display any failure in counter profile and hardware profile activation.

  • You can also use PFE commands - show evo-pfemand cntr-info and show evo-pfemand cntr-app-map to diagnose the failure in PFE. ​ show evo-pfemand cntr-info will display the counter engines allocated to each feature. This should match the number of counter engines configured by user. show evo-pfemand cntr-app-map will display whether counter configuration is success or failure for each feature in PFE and the reason for failure.

Show command outputs when hw-profile is not configured - default hw profile

Show command outputs when hw-profile is configured

PFE debug commands - default counter profile

Troubleshooting - custom counter profile

Debug Commands- Counter profile configured

Caveats

  • Policers can only be allocated with 16K engines

  • Certain counters are reserved for internal use and are not available to users.

  • In ACX7332, TCAM uses counter engine in OP2 for IFF/FTF based filters. However, for policers and other uses, TCAM still continue to internal counter engine. Hence allocation needs to be done accordingly.

  • Ifl-ingress and ifl-egress counter engines must be symmetrically allocated.

  • Prior to 25.3 release, Multicast counter engines are shared with LSP/IP tunnel counter engines and only one of them can be enabled using respective CLI. Hence the counter-engine reserved by LSP/IP applications will continue to be reserved. When multicast stats is enabled via old CLI (set system packet-forwarding-options mcast stats-enable), it would continue to statically reserve the counter-engine shared with LSP/Transit. If multicast stats is enabled via counter-profile, it will use from the resources available to the custom counter-profile.

  • Port VOQ uses internally reserved counters. Once the user-configured counter engines for HQoS are exhausted, they may overlap with the remaining entries of the Port VOQ counters.

Limitations

  • The behavior will be non-deterministic if the application scales beyond the number of custom profile counter engines allocated. For example, if IFL scale is 8k, but only one 4k counter engine is configured, then it cannot be guaranteed which IFL statistics will be displayed.

  • BNG DB profile is not supported from hw-db-profile in cases where hw-db-profile and custom hardware profile co-exist on a system.

  • Because evo-pfemand is restarted, when a CLI successfully committed, existing stats are cleared.