Securing the Forwarding Plane
Forwarding plane refers to a router’s forwarding path involved in processing transit traffic or in processing traffic that is destined to the router. The traffic destined to the router is also sometimes termed for_us traffic. The forwarding plane constitutes the packet-forwarding, switching, and queuing components involved in the packet flow. This section introduces various forwarding plane features and provides configuration examples of each. The main features covered in forwarding plane security are ACLs, Unicast Reverse Path Forwarding (uRPF), and Local Packet Transport Services (LPTS).
Access Control Lists
ACL filtering allows the network administrator to control packet flow through the network. Such control helps limit undesirable network traffic and helps restrict network use by certain users or devices. ACLs provide the ability to permit or deny packets from passing through specific router interfaces. Access lists also find several uses in providing granularity and control to control plane protocols.
Following are some of the key features of IOS XR access lists:
- Named access lists: Cisco IOS XR uses named access lists only. Internally, the access list is treated as a string or name. IOS XR uses only named access lists. Even if a number is used to denote an access list, it is internally treated as a string or a name.
- Standard or Extended Keywords: IOS XR does not use standard and extended keywords in specifying an access list. An access list can include mixed Access Control Elements (ACE) that use only source-based filtering or both source- and destination-based filtering that may be combined with protocol port operations.
- Locally originated traffic: Cisco IOS XR egress ACLs do not filter traffic originated by the router.
- ACL numbering and resequence: Cisco IOS XR ACLs use line numbering to help replace a particular line in an ACL definition. An option is provided to resequence the ACL line numberings if required.
- Remarks: Cisco IOS XR ACLs provide the ability to insert remarks in an access list to help explain the purpose of the particular line in an ACL.
- Log messages: Cisco IOS XR provides the ability to log an ACL. Logging an ACL produces a syslog message when a packet matches a line with the log keyword. This operation is CPU intensive and must not be enabled for high speed traffic rates. Usually an ACL with a log keyword can be used for ACLs applied to vty lines. A log keyword may also be used for temporary debugging purposes, keeping in mind that its use is CPU intensive.
- ICMP unreachables: IOS XR ACL deny packet operation on an interface produces a rate-controlled ICMP unreachable message. This ICMP message can be disabled from the interface by using the CLI no ipv4 unreachables.
Example 6-13 shows the creation of an access list that has the following properties:
- ACL with name CRS-Core.
- Permits incoming LDP and BGP sessions from the peer address 67.13.1.1 destined to 67.13.2.1.
- The ACL permits any traffic destined to TCP ports 80 and 8080.
- The ACL permits SSH traffic from host 62.133.1.1.
- The rest of the traffic is denied.
Example 6-13. Configuring an ACL Named CRS-Core
RP/0/RP1/CPU0:CRS1-1(config)#ipv4 access-list CRS-Core RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp host 67.13.1.1 eq ldp host 67.13.2.1 RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp host 67.13.1.1 host 67.13.2.1 eq ldp RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp host 67.13.1.1 host 67.13.2.1 eq bgp RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp any eq 80 any RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp any any eq 80 RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp any eq 8080 any RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp any any eq 8080 RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit tcp host 62.133.1.1 any eq 22 RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit icmp 65.10.20.0 0.0.0.255 any echo RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#permit icmp 65.10.20.0 0.0.0.255 any echo- reply RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#commit RP/0/RP1/CPU0:CRS1-1(config-ipv4-acl)#exit RP/0/RP1/CPU0:CRS1-1(config)#
Example 6-14 shows the application of the access list ingress on the interface tenGigE 0/0/0/0.
Example 6-14. Applying ACL Named CRS-Core
RP/0/RP1/CPU0:CRS1-1#show access-lists ipv4 CRS-Core ipv4 access-list CRS-Core 10 permit tcp host 67.13.1.1 eq ldp host 67.13.2.1 20 permit tcp host 67.13.1.1 host 67.13.2.1 eq ldp 30 permit tcp host 67.13.1.1 host 67.13.2.1 eq bgp 40 permit tcp any eq www any 50 permit tcp any any eq www 60 permit tcp any eq 8080 any 70 permit tcp any any eq 8080 80 permit tcp host 62.133.1.1 any eq 22 90 permit icmp 65.10.20.0 0.0.0.255 any echo 91 permit icmp 65.10.20.0 0.0.0.255 any echo-reply ! Applying the access-list to an interface RP/0/RP1/CPU0:CRS1-1#configure t RP/0/RP1/CPU0:CRS1-1(config)#interface tenGigE 0/0/0/1 RP/0/RP1/CPU0:CRS1-1(config-if)#ipv4 access-group CRS-Core ingress RP/0/RP1/CPU0:CRS1-1(config-if)#commit
Example 6-15 shows the access list created in Example 6-14 from the hardware perspective of the node to which it is applied. An access list applied to the forwarding path may be queried using the hardware keyword to ensure that the configuration has been accepted by the linecard hardware.
Example 6-15. Access List in Hardware
RP/0/RP1/CPU0:CRS1-1#show access-lists ipv4 CRS-Core hardware ingress location 0/0/cpu0 ipv4 access-list CRS-Core 10 permit tcp host 67.13.1.1 eq ldp host 67.13.2.1 20 permit tcp host 67.13.1.1 host 67.13.2.1 eq ldp 30 permit tcp host 67.13.1.1 host 67.13.2.1 eq bgp 40 permit tcp any eq www any 50 permit tcp any any eq www 60 permit tcp any eq 8080 any 70 permit tcp any any eq 8080 80 permit tcp host 62.133.1.1 any eq 22 90 permit icmp 65.10.20.0 0.0.0.255 any echo 91 permit icmp 65.10.20.0 0.0.0.255 any echo-reply
Table 6-2 lists the key show and debug commands related to access lists.
Table 6-2. Key ACL Operations and debug Commands
|
Command |
Description |
|
show access-lists afi-all |
Shows configured access lists for IPv4 and IPv6 address families. |
|
show access-lists maximum [detail | <cr> ] |
Shows the maximum configurable and current configured number of ACLs. |
|
show access-lists usage pfilter location line_card_location |
Indicates which access lists are applied to the node and whether they are applied ingress or egress. |
|
show access-lists hardware {ingress | egress} location line_card_location |
Shows ACL information as applied to line card hardware. |
|
debug pfilter-ea errors location line_card_location |
Debugs any errors encountered when applying ACL. Should be used only if there is a problem with applying an ACL. |
Unicast RPF
Unicast Reverse Path Forwarding (uRPF) is another useful IOS XR feature that helps prevent malicious traffic from entering a service provider network. uRPF may be used in strict and loose modes. Enabling strict uRPF on an interface helps the forwarding path analyze the incoming traffic’s source address. If the reverse path back to the source address of incoming packet is not learned via the interface on which strict uRPF is enabled, the packet is dropped. Loose uRPF is useful when a case of asymmetric routing might be present on the network. In the case of loose uRPF, the route for the source interface must be in the routing table. Configuration options may also allow default routes to satisfy loose uRPF requirements.
The following command configures strict or loose uRPF at the interface level:
{ipv4 | ipv6} verify unicast source reachable-via {any | rx} [allow-default]
[allow-self-ping]
The explanation of this command follows:
- Using the any option after verify unicast source reachable-via enables loose uRPF.
- Using the rx option after verify unicast source reachable-via enables strict uRPF.
- The allow-default option allows uRPF check to be true against a default route. This option is equally applicable to loose and strict uRPF.
- The allow-self-ping option allows the router to ping itself and is applicable to both loose and strict uRPF.
Example 6-16 shows the enabling of strict uRPF on a CRS interface and depicts a CEF command to check whether the configuration has been enforced.
Example 6-16. Strict uRPF on the tenGigE Interface
RP/0/RP1/CPU0:CRS1-1(config)#interface tenGigE 0/0/0/1 RP/0/RP1/CPU0:CRS1-1(config-if)#ipv4 verify unicast source reachable-via rx RP/0/RP1/CPU0:CRS1-1(config-if)#commit ! ! The following show command shows if the feature has been enabled RP/0/RP1/CPU0:CRS1-1#show cef ipv4 interface tenGigE 0/0/0/1 TenGigE0/0/0/1 is up (if_handle 0x01080040) Interface last modified Jan 12 22:54:42, modify Reference count 2 Forwarding is enabled ICMP redirects are never sent IP MTU 1500, TableId 0xe0000000 IP unicast RPF check is enabled RPF mode strict Protocol Reference count 2 Primary IPV4 local address 65.10.20.2/32
Example 6-17 shows the strict uRPF in action. The router does not have a route to a source of traffic that comes from IP address 171.1.1.1; on receiving the traffic, the strict uRPF feature drops this traffic. Example 6-17 depicts a CEF-related show command for determining uRPF drop statistics.
Example 6-17. Strict uRPF on the tenGigE Interface
RP/0/RP1/CPU0:CRS1-1#show route 171.1.1.1 % Network not in table ! ! shows RPF statistics RP/0/RP1/CPU0:CRS1-1#show cef ipv4 interface tenGigE 0/0/0/1 rpf-statistics Unicast RPF drops 1000
Local Packet Transport Service
The forwarding plane security section has so far discussed features such as ACLs and uRPF, which filter packets based on certain criteria. This section discusses Local Packet Transport Service (LPTS). LPTS provides software architecture to deliver locally destined traffic to the correct node on the router and provides security against overwhelming the router resources with excessive traffic. LPTS achieves security by policing flows of locally destined traffic to a value that can be easily sustained by the CPU capabilities of the platform.
The first question you might ask is what sort of traffic constitutes locally destined traffic. Although routers are in the business of forwarding packets, there are scenarios in which the traffic may be locally destined, including the following:
- All IPv4, IPv6, and MPLS traffic related to routing protocols, or control plane such as MPLS LDP or RSVP. The control plane computations for protocols are done on the Router Processor (RP) of the router. Therefore, whenever routing or MPLS control plane traffic is received on a line card interface, it needs to be delivered to the RP of the router.
- MPLS packets with the Router Alert label
- IPv4, IPv6, or MPLS packets with a TTL less than 2
- IPv4 or IPv6 packets with options
- IP packets requiring fragmentation or reassembly
- Layer 2 keepalives
- Address Resolution Protocol (ARP) packets
- ICMP message generation and response
Table 6-3 lists the various types of locally destined traffic and indicates the router’s node on which the traffic may be processed.
Table 6-3. CRS-1 Release 3.6.0 for_us Packet Processing
|
Received Traffic Type |
Processed in Packet Switching Engine |
Processed by Line Card CPU |
Processed by Route Processor |
|
Transit Traffic |
|||
|
Transit Packets |
Undergoes configured features (ACL, QoS, and so on) |
- |
- |
|
Transit Packets, IP Options |
LPTS Policed |
X |
- |
|
Transit Packets, IP Option “Router Alert” |
LPTS Policed |
X |
X |
|
Packets failed BGP TTL Security Hack (BTSH) and Generalized TTL Security Management (GTSM) |
BTSH/GTSM |
- |
- |
|
Packets that require ARP resolution |
LPTS Policed |
X |
- |
|
Unicast Receive Traffic |
|||
|
ICMP echo request, packets requiring logging |
LPTS Policed |
X |
- |
|
Any other ICMP (also ICMP with options) |
LPTS Policed |
X |
- |
|
Management traffic (SSH, SNMP, XML, and so on) |
LPTS Policed |
- |
X |
|
Management traffic (Netflow, CDP) |
LPTS Policed |
X |
- |
|
Routing (BGP, OSPF, ISIS, and so on) |
LPTS Policed |
- |
X |
|
Multicast, Broadcast |
|||
|
Multicast control traffic (OSPF, PIM, HSRP, and so on) |
LPTS Policed |
- |
X |
|
First packet of multicast stream |
LPTS Policed |
X |
- |
|
Broadcasts |
LPTS Policed |
X |
X |
|
Special Cases |
|||
|
Traffic needing fragmentation |
LPTS Policed |
X |
- |
|
MPLS traffic needing fragmentation |
LPTS Policed |
X |
- |
|
L2 packets (keepalives and so on) |
LPTS Policed |
X |
- |
LPTS provides sort of a built-in firewall for an IOS XR router by taking preemptive measures for traffic flows destined to the router. The forthcoming discussions explain how LPTS provides its protection mechanisms.
Mechanics Behind LPTS: A High-Level Overview
Cisco IOS XR runs on platforms with a distributed architecture. Distributed architecture implies that the control plane and the forwarding planes are decoupled for meeting higher routing and forwarding performance objectives. As Table 6-3 in the preceding section shows, an IOS XR router might need to deliver different types of for_us packets to different nodes within the router. Additionally, IOS XR supports process placement on CRS-1 platforms using Distributed Route Processors (DRP). Therefore, a line card receiving a control plane packet needs to make complex decisions regarding the node to which a packet might need to be delivered, keeping in mind that the router may be using a DRP for distributing a control plane process. Furthermore, nonstop routing (NSR) features might require a control packet be replicated both to an active and a standby RP.
Figure 6-3 provides a high-level overview of LPTS.
)
Figure 6-3 Local Packet Transport Service
The process follows:
- On a CRS-1 router, the Physical layer Interface Module (PLIM) receives the frame.
- On receiving the packet and performing the necessary layer 1 and 2 checks, the PLIM extracts the layer 3 packet and passes it to the forwarding ASIC or the Packet Switching Engine (PSE) as it is commonly called.
- The L3 forwarding engine does a Forwarding Information Base (FIB) lookup and determines whether the packet is a locally destined for_us packet.
- The LPTS infrastructure maintains tables in the line card’s TCAM and also on the RP for handling the for_us packets. The table on the RP is a detailed list of all possible flows of traffic types that can be destined to the router. The detailed table on RP is called the IFIB. A smaller table that is a subset of IFIB exists on the line card and this table is referred to as the pIFIB. The pIFIB lists flows of critical traffic. These tables are populated by a set of processes known as a LPTS Port Arbitrator (lpts_pa) and LPTS flow manager (lpts_fm). A process called pifibm_server runs on the line card and is responsible for programming hardware for the policing values for different flows. To qualify for a match in the pIFIB, the incoming packet must exactly match the pIFIB table entry in a single lookup.
- Consider a packet that arrives on a line card and a pIFIB lookup returns a full match. The packet then gets assigned a Fabric Group Identifier (FGID) allocated by the lpts_pa process. FGID serves as an identifier that helps a packet traverse the path through the various ASICs on the switch fabric to be delivered to FabricQ asic on the destination node from where the packet finds its way to the primary/standby RP, DRP, or the line card CPU. The destination node could also be an RP, a DRP, or the line card CPU of the line card on which the packet was received. In case a line card pIFIB entry results in a partial match the incoming packet is referred to the IFIB maintained on the RP.
- The CPU on the RP, DRP, and line card run the software processes that decapsulate the packet and deliver them to the correct stack.
The discussion related to Figure 6-3 gives a simplified overview of LPTS mostly from the point of view of local packet delivery. However, a key feature of LPTS includes policing the locally destined flows to values deemed safe for CPU resources.
Consider Example 6-18, which shows the LPTS entries accompanying a BGP configuration.
Example 6-18. BGP Entries in LPTS
! show command indicating the committed BGP configuration
!
RP/0/RP1/CPU0:CRS1-1#show running-config router bgp
router bgp 102
bgp router-id 192.168.254.1
address-family ipv4 unicast
!
neighbor 65.10.20.1
remote-as 101
address-family ipv4 unicast
!
!
!
!
! Following show command shows the entries created in IFIB
RP/0/RP1/CPU0:CRS1-1#show lpts ifib brief | include BGP
BGP4 default 65.10.20.2.179 65.10.20.1.45 TCP any 0/RP1/CPU0
BGP4 default any.179 65.10.20.1 TCP any 0/RP1/CPU0
! Following show command shows entries in PIFIB.
! The output of the following show command is usually quite large and is
! modified to show only BGP entries in LPTS PIFIB
RP/0/RP1/CPU0:CRS1-1#show lpts pifib brief
RP/0/RP1/CPU0:CRS1-1#show lpts pifib brief
* - Any VRF; I - Local Interest;
X - Drop; R - Reassemble;
Type VRF-ID Local, Remote Address.Port L4 Interface Deliver
— — — — — — — — — — — — — — — — — — — — — — — — - — — — — — — — — — — — — — — — — -
ISIS * - - - any 0/RP1/CPU0
IPv4_frag * any any any any R
IPv4 default 224.0.0.1 any IGMP Lo0 0/RP1/CPU0
IPv4 default 224.0.0.2 any IGMP Lo0 0/RP1/CPU0
IPv4 default 224.0.0.22 any IGMP Lo0 0/RP1/CPU0
IPv4 default any any IGMP Lo0 0/RP1/CPU0
IPv4 default 224.0.1.40.496 any UDP Lo0 0/RP1/CPU0
IPv4 default 224.0.0.13 any 103 Lo0 [11295]
IPv4 default 224.0.0.1 any IGMP Lo1 0/RP1/CPU0
IPv4 default 224.0.0.2 any IGMP Lo1 0/RP1/CPU0
IPv4 default 224.0.0.22 any IGMP Lo1 0/RP1/CPU0
IPv4 default any any IGMP Lo1 0/RP1/CPU0
IPv4 default 224.0.0.13 any 103 Lo1 [11295]
IPv4 default 224.0.0.1 any IGMP Lo100 0/RP1/CPU0
IPv4 default 224.0.0.2 any IGMP Lo100 0/RP1/CPU0
IPv4 default 224.0.0.22 any IGMP Lo100 0/RP1/CPU0
IPv4 default any any IGMP Lo100 0/RP1/CPU0
IPv4 default 224.0.0.13 any 103 Lo100 [11295]
IPv4 default 224.0.0.1 any IGMP Lo101 0/RP1/CPU0
IPv4 default 224.0.0.2 any IGMP Lo101 0/RP1/CPU0
IPv4 default 224.0.0.22 any IGMP Lo101 0/RP1/CPU0
IPv4 default any any IGMP Lo101 0/RP1/CPU0
IPv4 default 224.0.0.13 any 103 Lo101 [11295]
IPv4 default 224.0.0.1 any IGMP Lo10 0/RP1/CPU0
IPv4 default 224.0.0.2 any IGMP Lo10 0/RP1/CPU0
IPv4 default 224.0.0.22 any IGMP Lo10 0/RP1/CPU0
IPv4 default any any IGMP Lo10 0/RP1/CPU0
IPv4 default 224.0.0.13 any 103 Lo10 [11295]
IPv4 default any.23 any TCP Mg0/RP1/CPU0/0 0/RP1/CPU0
IPv4 default any.161 any UDP Mg0/RP1/CPU0/0 0/RP1/CPU0
IPv4 default any.639 1.1.1.1 TCP any 0/RP1/CPU0
IPv4 default 10.0.0.11.646 10.0.0.21.57 TCP any 0/RP1/CPU0
IPv4 default 10.0.0.11.646 10.0.0.31.35 TCP any 0/RP1/CPU0
IPv4 default 10.10.20.31.23 10.10.20.10 TCP any 0/RP1/CPU0
IPv4 default 65.10.20.2.179 65.10.20.1. TCP any 0/RP1/CPU0
IPv4 default any.179 65.10.20.1 TCP any 0/RP1/CPU0
IPv4 default any.646 any UDP any 0/RP1/CPU0
IPv4 default any.3232 any UDP any [11295]
IPv4 default any.3503 any UDP any 0/RP1/CPU0
IPv4 default any.50051 any UDP any 0/RP1/CPU0
IPv4 default any.50052 any UDP any 0/RP1/CPU0
IPv4 default any.50053 any UDP any 0/RP1/CPU0
IPv4 default any.50054 any UDP any 0/RP1/CPU0
IPv4 default any any 103 any [11295]
IPv4 default any any 115 any 0/RP1/CPU0
IPv4 default any any 255 any 0/RP1/CPU0
IPv4 * any.ECHO any ICMP any XI
IPv4 * any.TSTAMP any ICMP any XI
IPv4 * any.MASKREQ any ICMP any XI
IPv4 * any any.179 TCP any 0/RP1/CPU0
IPv4 * any.179 any TCP any 0/RP1/CPU0
IPv4 * any any TCP any 0/RP1/CPU0
IPv4 * any any UDP any 0/RP1/CPU0
IPv4 * 224.0.0.5 any OSPF any 0/RP1/CPU0
IPv4 * 224.0.0.6 any OSPF any 0/RP1/CPU0
IPv4 * any any OSPF any 0/RP1/CPU0
IPv4 * any any any any 0/RP1/CPU0
IPv6_frag * any any any any R
IPv6 * any any.179 TCP any 0/RP1/CPU0
IPv6 * any.179 any TCP any 0/RP1/CPU0
IPv6 * any any TCP any 0/RP1/CPU0
IPv6 * any any UDP any 0/RP1/CPU0
IPv6 * any.ECHOREQ any ICMP6 any XI
IPv6 * any.NDRTRSLCT any ICMP6 any XI
IPv6 * any.NDRTRADV any ICMP6 any XI
IPv6 * any.NDNBRSLCT any ICMP6 any XI
IPv6 * any.NDNBRADV any ICMP6 any XI
IPv6 * any.NDREDIRECT any ICMP6 any XI
IPv6 * ff02::5 any OSPF any 0/RP1/CPU0
IPv6 * ff02::6 any OSPF any 0/RP1/CPU0
IPv6 * any any OSPF any 0/RP1/CPU0
IPv6 * any any any any 0/RP1/CPU0
RP/0/RP1/CPU0:CRS1-1#! Hardware Policing values in pifib
!
RP/0/RP1/CPU0:CRS1-1#show lpts pifib hardware police location 0/0/cpu0
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Node 0/0/CPU0:
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Burst = 100ms for all flow types
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
FlowType Policer Type Cur. Rate Def. Rate Accepted Dropped
— — — — — — — — — — — — — — - — — — - — — — — — — — — — — — — — — — — — — — — — — — — —
unconfigured-default 100 Static 500 500 0 0
Fragment 106 Static 1000 1000 0 0
OSPF-mc-known 107 Static 20000 20000 248647 0
OSPF-mc-default 111 Static 5000 5000 43431 0
OSPF-uc-known 161 Static 5000 5000 0 0
OSPF-uc-default 162 Static 1000 1000 0 0
ISIS-known 108 Static 20000 20000 536237 0
ISIS-default 112 Static 5000 5000 4 0
BGP-known 113 Static 25000 25000 41 0
BGP-cfg-peer 114 Static 10000 10000 5 0
BGP-default 115 Static 10000 10000 54 0
PIM-mcast 116 Static 23000 23000 0 0
PIM-ucast 117 Static 10000 10000 0 0
IGMP 118 Static 3500 3500 0 0
ICMP-local 119 Static 2500 2500 20 0
ICMP-app 120 Static 2500 2500 0 0
na 164 Static 2500 2500 0 0
ICMP-default 121 Static 2500 2500 0 0
LDP-TCP-known 122 Static 25000 25000 290 0
LDP-TCP-cfg-peer 152 Static 10000 10000 0 0
LDP-TCP-default 154 Static 10000 10000 0 0
LDP-UDP 158 Static 2500 2500 519490 0
All-routers 160 Static 10000 10000 0 0
LMP-TCP-known 123 Static 25000 25000 0 0
LMP-TCP-cfg-peer 153 Static 10000 10000 0 0
LMP-TCP-default 155 Static 10000 10000 0 0
LMP-UDP 159 Static 2500 2500 0 0
RSVP-UDP 124 Static 7000 7000 0 0
RSVP 125 Static 7000 7000 0 0
IKE 126 Static 1000 1000 0 0
IPSEC-known 128 Static 3000 3000 0 0
IPSEC-default 127 Static 1000 1000 0 0
MSDP-known 129 Static 1000 1000 0 0
MSDP-cfg-peer 130 Static 1000 1000 0 0
MSDP-default 131 Static 1000 1000 0 0
SNMP 132 Static 2000 2000 0 0
NTP 133 Static 500 500 0 0
SSH-known 134 Static 1000 1000 0 0
SSH-default 135 Static 1000 1000 0 0
HTTP-known 137 Static 1000 1000 0 0
HTTP-default 138 Static 1000 1000 0 0
SHTTP-known 139 Static 1000 1000 0 0
IFIB_FT_SHTTP_DEFAULT 140 Static 1000 1000 0 0
TELNET-known 141 Static 1000 1000 0 0
TELNET-default 142 Static 1000 1000 0 0
CSS-known 143 Static 1000 1000 0 0
CSS-default 144 Static 1000 1000 0 0
RSH-known 145 Static 1000 1000 0 0
RSH-default 146 Static 1000 1000 0 0
UDP-known 147 Static 25000 25000 0 0
UDP-listen 156 Static 4000 4000 0 0
UDP-cfg-peer 157 Static 4000 4000 0 0
UDP-default 101 Static 500 500 69 0
TCP-known 148 Static 25000 25000 0 0
TCP-listen 149 Static 25000 25000 0 0
TCP-cfg-peer 150 Static 25000 25000 0 0
TCP-default 102 Static 500 500 60 0
Mcast-known 151 Static 25000 25000 0 0
Mcast-default 103 Static 500 500 0 0
Raw-listen 104 Static 500 500 0 0
Raw-default 105 Static 500 500 0 0
Ip-Sla 163 Static 10000 10000 0 0
EIGRP 109 Static 20000 20000 0 0
RIP 110 Static 20000 20000 0 0
L2TPv3 165 Static 3000 3000 0 0
na 166 Static 100 100 0 0
— — — — — — — — — — — —
statistics:
Packets accepted by deleted entries: 1188045
Packets dropped by deleted entries: 0
Run out of statistics counter errors: 0
Example 6-18 configures BGP and uses it to demonstrate the LPTS concept. The example creates a BGP process for AS 102 and configures a neighbor 65.10.20.2. On configuring a BGP peer, LPTS creates a flow for the configured peer with TCP port 179. A BGP flow is also created in pIFIB with a destination node of 0/RP1/CPU0 because the BGP routing protocol runs on the RP of the router and the active RP is the destination node for BGP packets.
Example 6-18 shows the policer in line card hardware and shows three different policers for BGP, which exist regardless of BGP configuration. Policer 113 in the example for BGP flow type BGP-known signifies a well established BGP session that actively participates in BGP route advertisement. Policer 114 BGP-cfg-peer represents a new session or recently established session that has not yet elevated to a level of an established session. BGP-default identified by policer 115 represents a default entry for BGP flow. This flow also helps with any latency in hardware programming for new configurations or accounts for a TCP session that might be initiated to port 179 for debugging purposes. The example shows a higher policer rate of 25,000 packets per second (pps) for established sessions compared to 10,000 pps for all other categories of BGP traffic flows.
Configuring LPTS
The LPTS discussion so far has focused on default policers preprogrammed in hardware TCAMs on CRS-1 line cards. Release 3.6 of IOS XR provides the user the ability to configure LPTS policer values. The general syntax for LPTS policer configurations is listed as follows:
lpts pifib hardware police [location node-id]
flow {flow_type} {rate rate}
The flow rate is in packets per second (pps).
Example 6-19 demonstrates LPTS configuration.
Example 6-19. Configuring LPTS BGP-default Policer Value to 1000 PPS
RP/0/RP1/CPU0:CRS1-1(config)#lpts pifib hardware police RP/0/RP1/CPU0:CRS1-1(config-pifib-policer-global)#flow bgp default rate 1000 RP/0/RP1/CPU0:CRS1-1(config-pifib-policer-global)#commit ! ! show command to verify newly configured LPTS policer values ! RP/0/RP1/CPU0:CRS1-1#show lpts pifib hardware police location 0/0/cpu0 | inc BGP BGP-known 113 Static 25000 25000 0 0 BGP-cfg-peer 114 Static 10000 10000 0 0 BGP-default 115 Global 1000 10000 237 0
Example 6-19 shows a configuration change applied globally to all the line cards in the SDR or logical router to change the policer for BGP-default flow. Alternatively, a configuration may be created for a particular line card location that has the effect of overwriting the global LPTS policing configuration only for the location for which it is created.