IOS devices have the concept of control plane policing. IOS-XR doesn't use that concept but instead uses a very comprehensive and powerful Local Packet Transport Services. In this document it is explained how LPTS works and how you can work with it, monitor and verify it.
LPTS is the concept of reflexive ACL's, punt policers and has an "internal" FIB or iFIB that directs certain packets to various nodes. IOS-XR can handle certain traffic on the linecard (such as BFD, Netflow and ARP) and these packets are instructed by LPTS to be handled by the local CPU rather then the RSP CPU.
At the same time, there are ACL's in place that allow for instance the punting of Telnet traffic and then per host if configured so, but another component of LPTS called MPP, the Management Plane Protection.
Generally, the default values for LPTS provide the level of protection you are after. However there are some rare circumstances whereby you want to tune the values of LPTS in order to get the service levels you need. LPTS is very dynamic in nature and pierces holes into the protection system as particular items are configured.
The LPTS policers work on a per NP basis. So if the LPTS police value is set to 1000pps that means that every NP on the LC can punt with 1000pps to the RSP CPU or LC CPU. This is something to take into consideration when evaluating the A9K-8T-x cards who have 8 NPU's per LC.
Take extreme care when changing the LPTS policer values.
High level overview
From a birds eye view, LPTS looks like this:
The NPU has a table that tells it where to send packet to (LC or RSP) as part of the "internal FIB" or iFIB. These packets are punted at a pre-defined rate, they can be tuned in XR release 4.x and later. Also in the TCAM which is used in the ASR9K for ACLs (amongst others), are lists that define which packets we want to allow and not. This will be discussed in the MPP section of this document.
LPTS is composed of a (set of) dynamic ACL's (which are created as part of user configuration dynamically, or automitcally inserted as peerings establish), an internal "routing table" (iFIB) and a set of policers for different punt reasons.
0) LPTS has Hardware policers on line cards to limit traffic sent to local or remote nodes
0) LPTS entries in TCAM classifies packets to select a policer to apply
0) The policer value can be tuned to 0 (to drop all packet matching classification criteria)
0) Polices on protocol (BGP, OSPF, SSH) and flow state (BGP established, BGP configured, and BGP listen)
0) Policing done on the LC Hardware ASIC before packets hit RP/LC CPU
0) Filters are automatically and dynamically installed by the IOS XR infrastructure
So for-me packets are undergoing the Pre iFIB classification and policing upon which they are directed by the iFIB, which is the second level of filtering to the destination node.
One of the great strenghts with LPTS is the dynamic ACL creation. This is configuration driven and no user intervention is required.
In addition to that, LPTS has different flow categories based on the state of the protocol. For instance, BGP has 3 different states:
Unknown is the flow whereby we have TCP port 179 traffic, but we have no neighbor configured from that source. Policed very heavily.
Configured is the entry whereby we know the source address of the peer, but the session is not yet established (no known source port from the peer), Policed moderately.
Established is where we have all the L3 and L4 data from the session. Lightly policed.
The entries for configured is driven by the configuration of the neighbor statement under the router BGP section.
Established is dynamically inserted when the peer establishes.
You could theoretically police the unknown to a rate of zero.
The following table can be seen with the output of the command:
show lpts pifib hardware entry brief loc 0/3/cpu0 | i 179
If you use the command
RP/0/RSP0/CPU0:A9K-TOP#show lpts pifib hardware entry location 0/3/CPU0 | be 33.33.1
You can check the detailed entry of the PiFIB (policer)
Source IP : 188.8.131.52 the remote address
Is Fragment : 0 fragments allowed
Interface : any expected source interface
M/L/T/F : 0/IPv4_STACK/0/BGP-known
DestNode : 48 where the packets are sent to
DestAddr : 48
L4 Protocol : TCP
TCP flag byte : any additional security checks at TCP level
Source port : Port:179
Destination Port : 11293
Accepted/Dropped : 117866/0 packets accepted and denied
# of TCAM entries : 1 number of tcam entries burnt for this PiFIB entry
HPo/HAr/HBu/Cir : 1924676/2500pps/2500ms/2500pps
State : Entry in TCAM status of the entry
Configuring LPTS police rates
You can configure the LPTS Policers on a PiFIB bases and also the punt policers can be adjusted.
The following commands apply. Note that this is on a per linecard basis. All NPU's on that linecard will get reconfigured.
RP/0/RSP0/CPU0:A9K-BNG(config)#lpts punt police location 0/0/CPU0 protocol ?
In there you can enter the linecard you wish to specifically reconfigure
The policer flow values
And the TCAM entries (this is new in XR420)
As you've seen LPTS can dynamically create "ACL" entries for dynamic firewalling and for MPP. This command limits the number of TCAM entries that LPTS can use so that space is available for other purposes such as regular ACL's, QOS matching, EFP matching etc.
LPTS static-police and police differences
The command “police” is used to check policer values, accept/drop counts for packets matching LPTS TCAM(mostly L3 packets) entries whereas “static-police” is used to check policer values.
Accept/drop counts for packets matching static punt reasons programmed in search structures (Mostly L2 and exception packets).
“policer” is for dynamic flows (like BGP, OSPF, etc protocols directed by RSP)
“static-policer” is for pseudo Static flows (like BFD, CFM directed by the LC) These are hard-coded and include Exception processing packets.
There is a CLI to change few of the exception processing as well (for e.g. ICMP unreachable)
LPTS is not SNMP enabled (request has been filed and is in the works, no target release defined at time of writing). Though there are very inventive ways to monitor LPTS and generate alerts. There is a TCL script that you can use with EEM in order to get some level of alerting.
Attached to this article is the script package and here is how you set it up:
LPTS stats cannot be cleared by LPTS commands or qos counter clearing.
You can clear LPTS stats by clearing hte np controller stats:
"clear controllers np counters all location <>”
MPP: Managed Plane Protection
In the standard configuration all interfaces have access to the Telnet, SSH and SNMP daemons.
Inband vs Out of band
All linecard interfaces are designated to be inband, meaning they can transport user traffic as well as management traffic.
The mgmt interfaces on the RSP are designated out of band. This means that they can't transport user traffic but only management traffic.
Out-of-band interfaces can't "speak" to other interfaces as they are desginated for managment traffic. So eventhough there is a route in the system that would send traffic out of the mgmt interface, Fabric enabled interfaces on the LC can't
Here an example of out of band and the restrictions that it imposes on the forwarding
By default when the service is configured, there are no mpp restrictions. All interfaces are able to accept the mgmt traffic for the service you defined. For example, when the telnet server is configured, LPTS reports the following binding:
RP/0/RSP0/CPU0:A9K-BNG#show lpts bindings brief | i (any.23 )
Tue Feb 28 12:00:55.195 EDT
0/RSP0/CPU0 TCP LR IPV4 TCP default any any,23 any
This means that every for me packet with port 23 as the dest port will get serviced.
Now when configuring MPP the bindings output changes:
allow Telnet peer
address ipv4 184.108.40.206
address ipv4 220.127.116.11/28
In this configuration example I am designating two interfaces as inband, so they will still be able to forward transient traffic and allow inbound telnet traffic. At the same time I allow telnet from any host on Gig0/0/0/10 and only telnet from a few peers on Te0/1/0/0.
The LPTS bindings are dynamically changed as per following output:
RP/0/RSP0/CPU0:A9K-BNG#show lpts bindings brief | i (any.23 )
Tue Feb 28 12:06:48.339 EDT
0/RSP0/CPU0 TCP LR IPV4 TCP default Gi0/0/0/10 any,23 any << Any source can access my telnet on this intf
0/RSP0/CPU0 TCP LR IPV4 TCP default Mg0/RSP0/CPU0/0 any,23 any << Dedicated inband
0/RSP0/CPU0 TCP LR IPV4 TCP default Te0/1/0/0 any,23 18.104.22.168 << /32 host access for telnet on dedicated intf
0/RSP0/CPU0 TCP LR IPV4 TCP default Te0/1/0/0 any,23 22.214.171.124/28 << Hosts from this subnet on this intf
We can also look at the pre internal fib (piFIB) and check the entries there: