IP Addresses and Services Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

LPTS policers

Updated: August 12, 2026

Want to summarize with AI?

Explains how ingress policers protect the route processor by rate-limiting control traffic by flow type. Covers global and per-node configuration, effective hardware rates, CLI verification, and YANG statistics.

Local Packet Transport Services (LPTS) policers are ingress traffic controls that

classify route-processor-bound control packets by flow type
apply statically programmed rates at incoming ports, and
allow rate customization globally or for a specific node.

LPTS programs default policer rates during startup. Hardware optimization can produce an effective rate that is close to, but different from, the configured rate without affecting policer operation.

Table 1. Feature History Table
Feature Name	Release Information	Description
Monitor LPTS Host Path Drops via YANG Data Model	Release 25.4.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is supported on: 8011-32Y8L2H2FH 8011-12G12X4Y-A/D
Monitor LPTS Host Path Drops via YANG Data Model	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*) This feature is supported on: 8712-MOD-M 8011-4G24Y4H-I
Monitor LPTS Host Path Drops via YANG Data Model	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM
Monitor LPTS Host Path Drops via YANG Data Model	Release 7.3.2	This feature allows you to use the `Cisco-IOS-XR-lpts-pre-ifib-oper.yang` data model to monitor the policer action for Local Packet Transport Services (LPTS) flow type for all IOS XR platforms. To access this data model, see the Github repository.

Effective policer rates

Use show lpts pifib hardware police to compare current hardware rates with configured rates and to review accepted and dropped packet counts.

Note

The hardware can program a rate that differs from the requested value. The programmed rate is optimized for hardware performance and remains close to the configured value.

Configure the global LPTS policer rates

Use global Local Packet Transport Services (LPTS) policer configuration when every node requires the same flow-type rates.

Procedure

Configure and commit the global policer rates for the required flow types.

Example:

Router# configure
Router(config)# lpts pifib hardware police
Router(config-lpts-policer-global)# flow ospf unicast default rate 3000
Router(config-lpts-policer-global)# flow bgp default rate 4000
Router(config-lpts-policer-global)# commit

Verify the committed global configuration.

Example:

Router# show running-config lpts
lpts pifib hardware police
 flow ospf unicast default rate 3000
 flow bgp default rate 4000
!

Verify the effective hardware rates and packet counters.

Example:

Router# show lpts pifib hardware police
-------------------------------------------------------------
                Node 0/RP0/CPU0:
-------------------------------------------------------------
FlowType               Policer Type    Cur. Rate Burst     Accepted     Dropped      npu
---------------------- ------- ------- --------- --------- ------------ ------------ ---------
Fragment               2       np      542       1000      0            0            0
OSPF-mc-known          3       np      1627      1000      0            0            0
OSPF-mc-default        4       np      1084      1000      0            0            0
OSPF-uc-known          5       np      542       1000      0            0            0
OSPF-uc-default        6       np      2878      1000      0            0            0
BFD-default            10      np      8136      1000      0            0            0
BFD-MP-known           11      np      8136      1000      0            0            0
BGP-known              16      np      17000     1000      0            0            0
BGP-cfg-peer           17      np      1627      1000      0            0            0
BGP-default            18      np      3880      1000      0            0            0

Confirm that OSPF-uc-default and BGP-default have effective rates close to the configured values. Hardware rate optimization can cause a small difference.

All nodes use the global LPTS policer configuration for the selected flow types.

Configure LPTS policer rates for a node

Use location-specific Local Packet Transport Services (LPTS) configuration when a node requires rates that differ from the global policer configuration.

Before you begin

Identify the node location where the policer rates must apply.

Procedure

Configure the policer rates at the target node.

Example:

Router# configure
Router(config)# lpts pifib hardware police location 0/0/CPU0
Router(config-lpts-policer-local)# flow ospf unicast default rate 3000
Router(config-lpts-policer-local)# flow bgp default rate 4000
Router(config-lpts-policer-local)# commit

Verify the location-specific running configuration.
Example:
```
Router# show running-config lpts
lpts pifib hardware police location 0/0/CPU0
 flow ospf unicast default rate 3000
 flow bgp default rate 4000
!
```
The output lists the OSPF and BGP rates under the policer configuration for location 0/0/CPU0.

Verify the effective rates and counters for each Network Processing Unit (NPU) at the node.

Example:

Router# show lpts pifib hardware police location 0/0/CPU0
-------------------------------------------------------------
                Node 0/0/CPU0:
-------------------------------------------------------------
FlowType               Policer Type    Cur. Rate Burst     Accepted     Dropped      npu      
---------------------- ------- ------- --------- --------- ------------ ------------ ---------
Fragment               2       np      542       1000      0            0            0        
Fragment               2       np      542       1000      0            0            1        
OSPF-mc-known          3       np      1627      1000      0            0            0        
OSPF-mc-known          3       np      1627      1000      0            0            1        
OSPF-mc-default        4       np      1084      1000      0            0            0        
OSPF-mc-default        4       np      1084      1000      0            0            1        
OSPF-uc-known          5       np      542       1000      0            0            0        
OSPF-uc-known          5       np      542       1000      0            0            1        
OSPF-uc-default        6       np      2878      1000      0            0            0        
OSPF-uc-default        6       np      2878      1000      0            0            1        
BFD-default            10      np      8136      1000      0            0            0        
BFD-default            10      np      8136      1000      0            0            1        
BFD-MP-known           11      np      8136      1000      0            0            0        
BFD-MP-known           11      np      8136      1000      0            0            1        
BGP-known              16      np      17000     1000      0            0            0        
BGP-known              16      np      17000     1000      0            0            1        
BGP-cfg-peer           17      np      1627      1000      0            0            0        
BGP-cfg-peer           17      np      1627      1000      0            0            1        
BGP-default            18      np      3880      1000      0            0            0        
BGP-default            18      np      3880      1000      0            0            1

Confirm that OSPF-uc-default and BGP-default appear for each NPU and have effective rates close to the configured values.

The selected node uses its location-specific LPTS policer rates.

YANG data model fields for LPTS policer statistics

Use this reference to retrieve and interpret Local Packet Transport Services (LPTS) flow-type policer statistics through NETCONF.

Cisco IOS XR Release 7.3.2 and later supports the Cisco-IOS-XR-lpts-pre-ifib-oper.yang operational data model across Cisco IOS XR platforms.

This sample request retrieves hardware flow-policer statistics for node 0/0/CPU0:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter>
      <lpts-pifib xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-lpts-pre-ifib-oper">
        <nodes>
          <node>
            <node-name>0/0/CPU0</node-name>
            <pifib-hw-flow-policer-stats/>
          </node>
        </nodes>
      </lpts-pifib>
    </filter>
  </get>
</rpc>

The response can include these values for each flow type:

flow-type and flow-name: Numeric and descriptive flow identifiers.
type and type-name: Policer type identifiers.
domain-id and domain-name: LPTS domain identifiers.
npu-id: Network Processing Unit (NPU) identifier for the statistics.
policer-rate and burst-size: Programmed traffic-control values.
accepted and dropped: Packet counters.

This is a sample response snippet:

<police-info>
       <flow-type>23</flow-type>
       <flow-name>ICMP-local</flow-name>
       <type>2</type>
       <type-name>Global</type-name>
       <domain-id>0</domain-id>
       <domain-name>default</domain-name>
       <npu-id>255</npu-id>
       <policer-rate>0</policer-rate>
       <burst-size>750</burst-size>
       <accepted>2000</accepted>
       <dropped>1000</dropped>
      </police-info>
      <police-info>

An NPU ID of 255 represents the aggregate of all NPU counters. This aggregate provides one policer-statistics view for each flow type.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.