Datapath resource management

The 7220 IXR-D1/D2/D3/D4/D5 and 7220-IXR H2/H3/H4 systems have forwarding pipelines that access a set of shared banks that are partitioned to support the following types of forwarding table entries:

  • Learned MAC addresses

  • IP host entries

  • IP longest-prefix-match routes

The default settings for the shared bank allocations can be changed through different configuration parameters as follows:

  • 7220 IXR-D1/D2/D3 systems support configuration of the alpm mode (ALPM = algorithmic longest prefix match), the requested-extra-ip-host-entries value, and the ipv6-128bit-lpm-entries value.
    • For alpm, three settings are supported: disabled, enabled and high-scale. alpm disabled completely disables ALPM mode, and provides maximum resources to be split between IP host entries and MAC table entries. aplm enabled uses more shared table resources, suitable for supporting moderate IP FIB scale. alpm high-scale is only available on D2/D3 systems and uses all available shared resources for IP FIB tables, resulting in only the base allocation for IP host entries and MAC table entries.
    • requested-extra-ip-host-entries should be configured with the number of IP host entries needed beyond the base allocation. It is possible, depending on the alpm mode setting that not all the requested entries can be allocated. The allocated number of entries can viewed in info from state, as discussed in the section Displaying datapath resource management information
  • 7220 IXR-D4/D5 systems support configuration of only the alpm mode, and only two settings are available:
    • enabled: this enables ALPM using less shared table resources, supporting only moderate IP FIB scale
    • high-scale: this enables ALPM using more shared table resources, supporting the highest possible IP FIB scale
  • 7220 IXR-H2/H3 systems support configuration of the ipv6-128bit-lpm-entries value. For more information, see LPM table partitioning.

LPM table partitioning

On 7220 IXR-D1/D2/D3 and 7220 IXR-H2/H3 systems, IP FIB scale depends on the partitioning of the hardware LPM table.

If the ipv6-128bit-lpm-entries parameter is configured to be greater than zero, the hardware LPM table is partitioned into two sub-blocks: a single-wide sub-block and a double-wide sub-block:

  • The single-wide sub-block can store IPv4 routes (each consuming half of a single-wide entry) and IPv6 routes up to /64 prefix length (each consuming a single-wide entry).

  • The size of the double-wide sub-block is controlled by the ipv6-128bit-lpm-entries parameter, and this sub-block can store IPv6 routes up to /128 prefix length (each consuming a double-wide entry).

    It can also store IPv4 routes and IPv6 routes up to /64 prefix length; inside the double-wide sub-block, IPv4 routes consume half of a single-wide entry, and IPv6 routes up to /64 prefix length require a double-wide entry.

Changing datapath resource management settings

You can change the datapath resource management settings discussed in LPM table partitioning in order to provider higher scale for one entry type at the expense of lower scale for another entry type.

This is illustrated in the following examples.

Configure Settings for 7220 IXR-D1

The following example changes datapath resource management settings on a 7220 IXR-D1 system. This configuration enables ALPM to achieve higher IP FIB scale and it requests an extra 32K IPv4 host entries on top of the fixed base amount of 16K entries. Any remaining datapath resources, if any, will be allocated to storing MAC addresses. This configuration also sets the hardware LPM table partition to the default value of 1024.

--{ * candidate shared default }--[  ]--
# info platform resource-management unified-forwarding-resources
    platform {
        resource-management {
            unified-forwarding-resources {
                alpm enabled
                requested-extra-ip-host-entries 32768
                ipv6-128bit-lpm-entries 1024
            }
        }
    }

Configure Settings for 7220 IXR-D5

The following example changes datapath resource management settings on a 7220 IXR-D5 system. This configuration enables ALPM (but not in the high-scale mode) to achieve moderate IP FIB scale and leave more resources for IP host and MAC table entries. 

--{ * candidate shared default }--[  ]--
# info platform resource-management unified-forwarding-resources
    platform {
        resource-management {
            unified-forwarding-resources {
                alpm enabled
            }
        }
    }

Restart XDP to activate changes

Datapath resource management configuration changes do not take effect immediately when the changes are committed; they take effect the next time XDP is restarted. The following example shows a tools command that restarts XDP:

--{ running }--[  ]--
# tools system app-management application xdp_lc_1 restart
/system/app-management/application[name=xdp_lc_1]:
    Application 'xdp_lc_1' was killed with signal 9

/system/app-management/application[name=xdp_lc_1]:
    Application 'xdp_lc_1' was restarted

On 7220 IXR-D1, D2, D3, D4, and D5 systems and 7220 IXR-H2, H3, and H4 systems, this command also restarts XDP-CPM, which causes a temporary loss of management connectivity.

Displaying datapath resource management information

Use the info from state command to display the allocated number of extra host entries and extra MAC address entries allocated from datapath resource management shared banks.

--{ running }--[  ]--
# info from state platform resource-management unified-forwarding-resources
    platform {
        resource-management {
            unified-forwarding-resources {
                xdp-restart-required true
                alpm enabled
                requested-extra-ip-host-entries 32768
                allocated-extra-ip-host-entries 32768
                allocated-extra-mac-entries 0
                ipv6-128bit-lpm-entries 1024
            }
        }
    }

In the example, the xdp-restart-required leaf is shown as true if a change has been committed to one or more of the configurable values in the unified-forwarding-resources container, but XDP has not yet been restarted. Until XDP is restarted, the operational values are still the values initialized at the last XDP restart.