Guest

Cisco 7300 Series Routers

PXF Information for Cisco 7304 Routers

  • Viewing Options

  • PDF (1.1 MB)
  • Feedback

Table of Contents

PXF Information for the Cisco 7304 Router

Contents

Enabling and Disabling PXF

PXF Features

PXF Feature Restrictions

General PXF Processing Restrictions

ACL Accounting Statistics in PXF Restrictions

Any Transport over MPLS Restrictions

Frame Relay on PXF Restrictions

EtherChannel Restrictions

GRE Restrictions

ICMP Restrictions

Layer 2 Tunneling Protocol Version 3 Restrictions

Multicast and Multicast VPN Restrictions

MPLS Restrictions

MPLS Traffic Engineering Restrictions

Network Address Translation(NAT) Restrictions

Network Address Translation Using Route Maps Restrictions

QoS Restrictions

Reverse Path Forwarding Restriction

WCCP Restrictions

Information About IP Accounting

IP Accounting Restrictions

PXF Configuration Examples

ACL Configuration Examples

Simple ACL (0 - 99)

Extended ACL (100 - 199)

Any Transport over MPLS Examples

EtherChannel Configuration Examples

GRE Configuration Examples

Basic GRE Configuration

Layer 2 Tunneling Protocol version 3 Examples

Multiprotocol Label Switching Examples

Netflow Configuration Examples

Network Address Translation(NAT) Examples

QoS Examples

Reverse Path Forwarding Examples

Using show Commands

Using the show version Command

Using the show c7300 and show pxf Commands

Using the show c7300 pxf accounting or show pxf accounting Command

PXF Information for the Cisco 7304 Router

Cisco Parallel eXpress Forwarding (PXF) is used to accelerate forwarding performance on the Cisco 7304 router. PXF is available on the NSE-100 and the NSE-150; the NPE-G100 does not support PXF.

The Cisco 7304 router processes packets via one of two processing paths, the PXF processing path or the Route Processor (RP) processing path. Packets directed through the PXF processing path are accelerated, although the PXF processing path is reserved for packets utilizing certain features (for a list of features supported in the PXF processing path and when those features were introduced in the PXF processing path, see the “PXF Features” section). All other packets are processed using the RP path. The RP path is also used when PXF processing, which is enabled by default, is disabled.

Enabling and Disabling PXF

When PXF processing is enabled, packets eligible for PXF acceleration are automatically PXF accelerated. No configuration, outside of ensuring PXF is enabled, is required to ensure packets that are eligible for PXF acceleration are PXF accelerated.

PXF processing is enabled by default. All packets eligible for PXF acceleration are automatically accelerated unless PXF processing is disabled.

To manually disable or enable the PXF processors, use the following global command:

Router(config)# [no] ip pxf


Note Before enabling the PXF processors, you must have IP routing and IP CEF switching turned on.


PXF Features

The following table shows Parallel eXpress Forwarding (PXF) features available for the Cisco 7304 router and the original Cisco IOS releases that supported these PXF features. This list also includes the first major Cisco IOS release for features that were introduced on special Cisco IOS release trains.


Note The NSE-150 was released on Cisco IOS Release 12.2(31)SB2. At the time of release, all features available in the PXF-processing path that were previously available for the NSE-100 were made available for the NSE-150.



Note All of the PXF features introduced in Cisco IOS Releases 12.1EX, 12.2YZ, and 12.2SZ were made available on Cisco IOS Release 12.2(18)S, which was the first release of 12.2S that supported the Cisco 7304 router. The only exception is that GRE tunnels mapped into MPLS VPNs are not VRF-aware in the PXF processing path in Cisco IOS Release 12.2(18)S.
Similarly, all of the features, including PXF features, that existed in the Cisco 7304 router on Cisco IOS Release 12.2S are supported in Cisco IOS Release 12.2SBC.



Note MPLS VPN-VRF Selection Based on IP Address was made unavailable in Cisco IOS Release 12.2(25)S. Currently, this feature is not available in any 12.2S release after Cisco IOS Release 12.2(25)S.
The feature was again made available in Cisco IOS Release 12.2SBC starting in Cisco IOS Release 12.2(27)SBC.


PXF Feature
PXF Subfeature
Description
Original NSE-100 Cisco IOS Release Support
Original NSE-150 Cisco IOS Release Support

ACL

Turbo ACL (input or output)

Match source IP address with mask

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match destination IP address with mask

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP protocol

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP TOS byte (precedence or DSCP)

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP L4 source port

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP L4 destination port

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

ACL Accounting1 (per ACE match statistics)

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Any Transport over MPLS (AToM)

Interworking Types

Frame Relay to Ethernet/VLAN (Bridged)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay to Ethernet/VLAN (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay to PPP (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay to AAL5 (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet/VLAN to AAL5 (Bridged)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet/VLAN to AAL5 (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet to VLAN (Bridged)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet to VLAN (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Transport Modes

AAL5/OAM

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet Port over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

HDLC over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

PPP over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

VLAN over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

AAL5 over MPLS

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM Cell Relay over MPLS (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM Port Mode Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM Port Mode Packed Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VC Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VP Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VC Packed Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VP Packed Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

EtherChannel Support

Fast EtherChannel Support

Release 12.2(31)SB2

Release 12.2(31)SB2

Gigabit EtherChannel Support

Release 12.2(31)SB2

Release 12.2(31)SB2

Generic Routing Encapsulation
(GRE)

GRE Support

Release 12.1(13)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

GRE Tunnel IP Source and Destination VRF Membership

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

QoS Pre-Classification on GRE Tunnel Interfaces

Release 12.1(13)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

NAT on GRE Tunnel Interfaces

Release 12.1(13)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

ICMP

Echo Reply

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Host Unreachable

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Fragmentation Required but DF Set

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

ACL Deny

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Time Exceeded

Release 12.1(10)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Layer 2 Tunneling Protocol, version 3 (L2TPv3)

Transport Modes

AAL5/OAM over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM Port Mode Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VC Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM VP Single Cell Relay (PA-A3)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet Port over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

HDLC over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

PPP over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

VLAN over L2TPv3

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Interworking Types

Frame Relay to Ethernet/VLAN (Bridged)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay to Ethernet/VLAN (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay to PPP (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet to VLAN (Bridged)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet to VLAN (Routed)

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Rewrite Options

VLAN ID Rewrite

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

VLAN Header Rewrite

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay DLCI Switching

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

L2TPv3 Options

0, 4, and 8 byte cookies

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

TTL set in tunnel header

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

IP ToS set, or reflect from inner IP header

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

DF bit set

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Path MTU Discovery

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Local Switching

ATM-to-ATM PVC Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM PVC Same-Port Switching

Release 12.2(27)SBC

Release 12.2(31)SB2

ATM-to-ATM PVP Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM PVP Same-Port Switching

Release 12.2(27)SBC

Release 12.2(31)SB2

ATM-to-Ethernet (Port Mode) Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

ATM-to-Ethernet (VLAN Mode) Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet (Port/VLAN) to Ethernet (Port/VLAN) Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Ethernet VLAN Same-Port Switching

Release 12.2(27)SBC

Release 12.2(31)SB2

ATM-to-Frame Relay Local Switching

Release 12.2(25)S4
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay-to-Frame Relay Local Switching

Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay Same-Port Switching

Release 12.2(27)SBC

Release 12.2(31)SB2

Multicast and Multicast VPN

Basic Multicast

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Basic Multicast using VRF-Lite

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Multicast packets using VRF and MPLS VPN

Release 12.2(25)S2
Release 12.2(27)SBC

Release 12.2(31)SB2

Multiprotocol Label Switching (MPLS)

MPLS Basic Support

Release 12.1(12c)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS VPN Support2

Release 12.1(12c)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS AToM—Ethernet over MPLS

Release 12.2(14)SZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS-CSC (Carrier Supporting Carrier)

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Inter-Autonomous Systems for MPLS VPNs

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS VPN—VRF Selection Based on Source IP Address

Note: This feature is not available on Cisco IOS Release 12.2S train starting in 12.2(25)S.

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

VRF-Lite (Multi-VRF CE)

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering

Basic PXF switching and accounting

Release 12.2(14)SZ3
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Load Balancing

Release 12.2(14)SZ3
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Auto Bandwidth

Release 12.2(14)SZ3
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—1-Hop Tunnel Support

Release 12.2(14)SZ3
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Support for MPLS Traffic Engineering over Frame Relay, 802.1q, and ATM subinterfaces

Release 12.2(14)SZ3
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Diff-Serv-Aware ISIS Support

Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Diff-Serv-Aware OSPF Support

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—ISIS Extensions

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—OSPF Extensions

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—RSVP Extensions

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Autoroute Calculation

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Autoroute Calculation (ISIS optimized)

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

MPLS Traffic Engineering—Node Exclusion List Support

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Scalability Enhancement

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Inter Area TE Support for OSPF

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Inter Area TE Support for ISIS

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Forwarding Adjacency Support for OSPF

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Forwarding Adjacency Support for ISIS

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Overload Avoidance Support for ISIS

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

MPLS Traffic Engineering—Configurable Tunnel Path Calculation

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(20)S
Release 12.2(27)SBC

Netflow

Accounting and export, v8

Autonomous system aggregation

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Destination prefix aggregation

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Protocol and port aggregation

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Source prefix aggregation

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Accounting and export, v5

Release 12.1(13)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Accounting and export, v9

BGP Next Hop support


Export main flow cache format


Export AS aggregation cache


Export protocol port aggregation cache


Export source prefix aggregation cache


Export destination prefix aggregation cache

Release 12.2(20)S
Release 12.2(27)SBC


Release 12.2(20)S
Release 12.2(27)SBC


Release 12.2(20)S
Release 12.2(27)SBC


Release 12.2(20)S
Release 12.2(27)SBC



Release 12.2(20)S
Release 12.2(27)SBC



Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2



Release 12.2(31)SB2



Release 12.2(31)SB2



Release 12.2(31)SB2




Release 12.2(31)SB2




Release 12.2(31)SB2

MPLS Egress Netflow Accounting

Release 12.2(31)SB2

Release 12.2(31)SB2

Network Address Translation (NAT)

Static NAT, Dynamic NAT, and NAT with overload

Network Address Translation support

Release 12.1(12c)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

NAT Route-Map Support using match criteria based on ACLs

Route-maps with dynamic NAT support

Release 12.2(33)SB

Release 12.2(33)SB

VRF-aware NAT with route-map defined mappings

Release 12.2(33)SB

Release 12.2(33)SB

Port Address Translation (overload) with route-map defined mappings

Release 12.2(33)SB

Release 12.2(33)SB

VRF-Aware NAT

Release 12.2(31)SB2

Release 12.2(31)SB2

Quality of Service (QoS)

Modular QoS Command-Line Interface Features

Class-Based Weighted Fair Queueing (the bandwidth command)

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match ACL (access group)

Release 12.1(9)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match Class of Service

Release 12.2(31)SB2

Release 12.2(31)SB2

Match Frame Relay Discard Eligibility

Release 12.2(31)SB2

Release 12.2(31)SB2

Match Frame Relay DLCI

Release 12.2(31)SB2

Release 12.2(31)SB2

Match Input Interface

Release 12.2(31)SB2

Release 12.2(31)SB2

Match IP DSCP

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP Precedence

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match IP RTP

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match MPLS Experimental Bits

Release 12.1(12c)EX
Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match QoS Groups

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Match VLAN ID

Release 12.2(31)SB2

Release 12.2(31)SB2

Marking ATM CLP Bit ( set atm-clp command and set-atm-clp action in police command)

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Marking CoS Values ( set cos command and set-cos-transmit action in police command )

Release 12.2(31)SB2

Release 12.2(31)SB2

Marking Frame Relay Discard Eligibility bits ( set fr-de command and set-frde-transmit action in police command)

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Marking IP Precedence

Release 12.1(9)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Marking IP DSCP

Release 12.1(9)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Marking MPLS experimental bits ( set mpls experimental command and set-mpls-exp-transmit action in police command)

Release 12.1(12c)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Marking QoS Groups

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Nested class maps

Release 12.1(9)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Port-level queueing and QoS for subinterface traffic

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Priority and Standard Queueing

Release 12.1(9)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Queue Limit Setting ( queue-limit command)

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Rate Limiting of QoS in Fast EtherChannel Bundles

Release 12.2(31)SB2

Release 12.2(31)SB2

Rate Limiting of QoS in Gigabit Etherchannel Bundles

Release 12.2(31)SB2

Release 12.2(31)SB2

Three-level Hierarchical Policy Maps

Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Policing per Modular QoS CLI class

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Policing in child policy of nested traffic policy in Frame Relay and 802.1q subinterfaces

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Policing (Hierarchical Ingress Policing)

Release 12.2(20)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Policing (Multiple Action Policer)

Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Shaping ( shape average command only)

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Traffic Shaping per VLAN or Frame Relay VC using nested policy maps

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Weighted Random Early Detection (WRED)—IP DSCP Based

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Weighted Random Early Detection—IP Precedence/EXP Based

Release 12.1(10)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

QoS MIB

Class-Based Quality of Service MIB support for Modular QoS CLI Features

Release 12.2(11)YZ
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Switching

CEF (IPv4)

Per-destination load balancing

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Reverse Path Forwarding (RPF)

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Layer 2 Encapsulations

ARPA

Encapsulation on Ethernet-type interfaces

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

802.1Q

Encapsulation on Ethernet-type interfaces or subinterfaces

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

SNAP

Ingress on Ethernet-type interfaces

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

PPP

Encapsulation on POS and DS3 interfaces

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

HDLC

Encapsulation on POS and DS3 interfaces

Release 12.1(9)EX
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

Frame Relay

Frame Relay Encapsulation

Release 12.1(10)EX2
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

AAL5 SNAP

Encapsulation on ATM interfaces/VCs

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

AAL5 MUX

Encapsulation on ATM interfaces/VCs

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

AAL5 NLPID

Encapsulation on ATM interfaces/VCs

Release 12.1(10)EX1
Release 12.2(18)S
Release 12.2(27)SBC

Release 12.2(31)SB2

PXF Feature Restrictions

The following sections document PXF restrictions:

General PXF Processing Restrictions

If you configure any PXF unsupported ingress feature for an interface, none of the data packets entering that interface are handled by the PXF processors. They are handled instead by the Route Processor (RP). Similarly, if you configure any unsupported egress feature for an interface, none of the output features for data packets exiting that interface are handled by the PXF processors. These output features are instead handled by the RP. Also, it is important to note that the ingress features for this punted packet will be re-executed in the processing path from scratch. Therefore, some packets are double-counted in both the RP and PXF processing paths and some functions that are based on packet statistics (such as the token bucket algorithm used with Traffic Policing) might be impacted by this double-counting.

ACL Accounting Statistics in PXF Restrictions

ACL Accounting allows users to track the number of packets that match an ACL entry through the use of show commands. Many show commands, such as show ip access-lists , display information about access lists. The outputs for many of these show commands have been enhanced to show the number of of both PXF-switched packets and RP-switched packets that match each ACL entry. Previously, the outputs for these show commands only showed the number of RP-switched packets that matched each ACL entry.

ACL Accounting for PXF was introduced in Cisco IOS Release 12.1(10)EX.

For ACL show command outputs, the ACL accounting for matches per access control entry are for security ACLs only. The numbers in these columns do not account for other types of access control entry use such as ACL-based matching in QoS service policy class-maps or other ACL uses.

Any Transport over MPLS Restrictions

  • There is no classification support when the interface is using Xconnect.
  • QoS on the input interface on the AToM circuit is limited to set and police configured in the default traffic class. The service policy must have the following format:
policy-map policy-map-name
class class-default
set qos-group qos-group-number
police bps burst-normal burst-max conform-action action exceed-action action
 

Output QoS on the Layer 2 circuit is limited to police configured in the default traffic class.

  • The following table shows which QoS commands are supported on AToM circuits:
  • QoS command
    Imposition
    Disposition
    In
    Out
    In
    Out

    match any

    Yes

    Yes

    Yes

    Yes

    match cos

    No

    No

    No

    No

    match input-interface

    No

    No

    No

    No

    match mpls exp

    No

    Yes

    Yes

    No

    match qos-group

    No

    Yes

    No

    Yes

    set cos

    No

    No

    No

    No

    set mpls exp

    Yes

    No

    No

    No

    set qos-group

    Yes

    No

    Yes

    No

    set srp-priority

    No

    No

    No

    No

Frame Relay on PXF Restrictions

  • Frame Relay traffic shaping is not supported in PXF.
  • The show frame-relay pvc command output only contains input packet count, output packet count, input byte count, output byte count, and dropped packets.
  • Frame Relay switching and other non-IP forwarding of Frame Relay packets are not supported by the PXF processors. These packets are supported in the Route Processor.
  • Point-to-Point Protocol (PPP) over Frame Relay is currently not supported on the Cisco 7304 router.
  • Standard IP features for Frame Relay can be configured on a per-subinterface basis.
  • Frame Relay fragmentation and Frame Relay header compression are not supported in PXF.
  • Support for WRED on class queues on a Frame Relay Virtual Circuit (VC) is available starting in Cisco IOS Release 12.2(11)YZ. WRED support on a Frame Relay VC was not available before this release.

EtherChannel Restrictions

There are no PXF-specific EtherChannel restrictions for Cisco 7304 routers.

For general restrictions on EtherChannel on the Cisco 7304 router, see Cisco 7304 Router Fast EtherChannel and Gigabit EtherChannel Notes .

GRE Restrictions

  • For GRE, PXF acceleration is limited to the unicast IPv4 payload. GRE traffic not handled in PXF is handled in the Route Processor switching path.
  • If any of the following elements are configured on a tunnel, GRE PXF acceleration will not occur:

Tunnel Checksum

Key

Path-mtu-discovery

Sequence

Udlr

  • PXF does not terminate fragmented GRE packets that need reassembly. Fragmented GRE packets that need reassembly are processed using the Route Processor.
  • Before terminating a GRE packet, PXF looks for the right tunnel that is able to terminate the packet. If the tunnel is not found, the packet is punted to the Route Processor.
  • Packets entering the router through a tunnel and leaving the router through the same or through a different tunnel are punted to the Route Processor. In other words, GRE packets that need successive de-encapsulation-encapsulation are not handled in the PXF processing path.
  • PXF does not support MPLS over GRE features. MPLS packets received on a GRE tunnel are processed using the PXF processor.

ICMP Restrictions

  • Destination unreachable messages (host unreachable, fragmentation required but DF set, and ACL Deny) are rate limited on a per-interface basis ( in some Cisco IOS releases, outgoing ACL deny packets are punted to the Route Processor for processing). The rate limit interval is 0.5 seconds.
  • The debug ip icmp command punts all ICMP handling to the Route Processor while also enabling ICMP debugging information.

Layer 2 Tunneling Protocol Version 3 Restrictions

  • There is no classification support when the interface is using Xconnect.
  • QoS on the input interface on the Layer 2 circuit is limited to set and police configured in the default traffic class. The service policy must have the following format:
policy-map policy-map-name
class class-default
set qos-group qos-group-number
police bps burst-normal burst-max conform-action action exceed-action action
 

Output QoS on the Layer 2 circuit is limited to police configured in the default traffic class.

  • Sequencing configuration will result in punting of all packets of that session.
  • Rewriting the VLAN ID or the VLAN Header may result in punting of packets egress from the tunnel if the VLAN Header is too far into the packet. This event can occur if the core facing interface is Ethernet and an L2TPv3 Header with a large cookie size is configured.
  • Frame Relay local switching is not supported.
  • Input classification on the Layer 2 interface connected to the CE is not supported.
  • 802.1p mapping to tunnel header IP ToS bits is not supported
  • Cell packing is not supported with L2TPv3
  • L2TPv3 over GRE is not supported.

Multicast and Multicast VPN Restrictions

  • By default, multicast traffic will not be load balanced across multiple equal cost paths.
  • The following protocols and features are supported by Multicast and Multicast VPN in the Cisco 7304 PXF processing path:

PIM-BIDIR

PIM-SSM

SDP

IGMP v1, IGMP v2, and IGMP v3

Auto-RP, BSR, and static RP addressing

PIM-SM

PIM-DM

NBMA (not for point-to-multipoint)

  • The following lists provides the more noteworthy protocols and features that are not supported by Multicast and Multicast VPN in the Cisco 7304 PXF processing path::

PGM

NAT on Multicast Traffic

Multicast traffic encapsulation in Unicast GRE

NBMA Mode for P2MP VCs/DLCIs

SSO and NSF (Cisco IOS limitation)

PIM-SSM Static Mapping (Cisco IOS limitation)

Multicast Load-balancing (using uGRE)

MSDP in certain Cisco IOS releases. Multicast and Multicast VPN were introduced in PXF in Cisco IOS Release 12.2(25)S2. MSDP did not work in both the PXF and the Route Processor packet paths in Cisco IOS Releases 12.2(25)S2 through 12.2(25)S5. MSDP was re-enabled for both the PXF and the Route Processor paths on the Cisco 7304 router using the NSE-100 in Cisco IOS Release 12.2(25)S6.
MSDP works on all versions of Cisco IOS Release 12.2(20)S (Route Processor path only), 12.2(27)SBC (PXF and, if punted, the Route Processor paths), and will work in the PXF processing path for future Cisco IOS releases that support the Cisco 7304 using the NSE-100.

  • The following scenarios will force packets to be punted to the Route Processor:

IP datagrams received with destination IP addresses in the range 224.0.0.0 to 224.0.0.255

IP datagrams received with IP header protocol field as 2 (IGMP)

All IP datagrams received on directly connected interfaces or hosts that are supposed to be forwarded by shared tree (*,G)

All IP datagrams to be forwarded by shared tree (*,G) when the control flag is marked as “SPT-Join”

All IP datagrams failing RPF check but have a valid oLIST after the (S,G) or (*,G) lookup will be punted if the packet entered from one of the interfaces in the oLIST

All IP datagrams exceeding the configured IP MTU

All IP datagrams if any one of the egress interfaces has an unsupported bit

All IP datagrams if ACL compilation has not occurred

All IP datagrams if ARP has not been resolved to any one of the egress interfaces

  • For multicast tunnel encapsulation, IP-in-IP for P packet generation and MPLS for P packet are both not supported in PXF.
  • Netflow cannot be applied to Multicast packets. No punting or warning messages will be seen if Netflow attempts to gather information about a Multicast packet.
  • The PXF will punt all multicast packets to the RP if you enable netflow for egress (ip flow egress) packets.

MPLS Restrictions

Load balancing will not be active for IP packets entering an MPLS VPN.

MPLS Traffic Engineering Restrictions

The following MPLS-TE features are not supported:

  • Diff-Serv-aware TE
  • MPLS-TE Interarea
  • MPLS-TE MIB
  • MPLS-TE FRR
  • MPL-TE FRR MIB

Network Address Translation (NAT) Restrictions

  • All ICMP ECHO (ping) and IP fragment packets that are entering an ip nat outside interface or going from an ip nat inside interface to an ip nat outside interface are punted to the Route Processor. Therefore, all ping packets are automatically punted to the Route Processor when ping-testing NAT on PXF on the Cisco 7304 router.
  • The first packet of a traffic flow that is mappable by NAT (meaning that the flow matches any ACL used by dynamic NAT or a static NAT entry) is punted to the Route Processor if its NAT entry is not found in PXF. The processing of this first packet in the Route Processor triggers the creation of a NAT entry in PXF, causing the subsequent packets in the traffic flow pair to be processed by the PXF processor.
  • The Cisco 7304 router supports 32,000 NAT entries in PXF. If this limit is exceeded, the traffic exceeding this limit is processed using the Route Processor.
  • Non-TCP/UDP IP traffic that is mappable by NAT is always punted to the Route Processor.
  • A single NAT half entry (an entry that does not contain the port information) in the Route Processor can trigger the creation of several NAT entries in PXF.
  • When viewing the show c7300 pxf interface or show pxf interface command output (in Cisco IOS Release 12.2(14)SZ, the show c7300 pxf interface command was changed to show pxf interface —the output below shows show pxf interface , but show c7300 pxf interface should be used in some cases), input and output NAT flags are both seen on the ip nat outside interface. No NAT feature flags can be seen on the ip nat inside interface, including input feature flags.

The following output illustrates this point. Note that interface POS 5/2 is the ip nat outside interface and that input and output NAT flags are seen on this interface:

Router# show running-config
 
interface POS5/1
ip address 192.168.0.10 255.255.255.0
ip nat inside
!
interface POS5/2
ip address 171.200.1.32 255.255.0.0
ip nat outside
!
...
 
Router# show pxf interface all
 
...
 
PXF-If:Y 00017 PO5/1 (Down, Processing Input)
Features:in=CEF [0x201], out=None [0x0] qstatus=XON
 
No NAT feature flags
 
Ingress Packets: 0 Input Drop Packets : 0
Egress Packets : 0 Output Drop Packets: 0
 
PXF-If:Y 00018 PO5/2 (Up, Processing Input)
Features:in=CEF NAT [0x300], out=NAT [0x2] qstatus=XON
 
Ingress Packets: 147 Input Drop Packets : 0
Egress Packets : 147 Output Drop Packets: 0
 
  • Packets from protocols that carry IP address or port information in the payload cannot be translated through NAT using PXF on Cisco 7304 routers. These packets are translated instead through NAT using the Route Processor.

The following is a list of some protocols that cannot be processed through NAT in PXF on the Cisco 7304 because they carry IP address or port information in the payload:

Cisco IP Phone to CallManager

CUSeeMe

DNS “A” and “PTR” Records

FTP

H.323v1 for NetMeeting V2.x

H.323v2 Call Signalling (FastConnect)

H.323v2 for NetMeeting V3.x

ICMP

IPv6 Protocol Translation - Fragmentation

IPv6 Protocol Translation - FTP

IPv6 Protocol Translation - PAT

IP Multicast, Source Translation

NetBIOS over TCP/IP

NetMeeting ILS Directory

NFS

PPTP

r-commands (rsh, rlogin, rexec)

RealAudio

Remote Procedure Call (RPC)

SQLNet

StreamWorks

TFTP

VDOLive

VXtreme

Windows Media Technology (NetShow)

  • For VRF-Aware NAT, inside VPN to VPN with NAT is not supported.

Network Address Translation Using Route Maps Restrictions

  • This feature will only provide support for route maps with NAT that have match criteria based on Access Control Lists (ACLs).
  • Static NAT entries cannot use route maps for NAT translation purposes. Only Dynamic NAT entries can use route maps for NAT translation purposes.
  • Multiple ACLs per route map statement is not supported for this feature.

For this reason, the following configuration would be supported:

route-map my-route-map 10
match ip address 101
 

While this configuration would not be supported:

route-map my-route-map 10
match ip address 101 102 103
 
  • Only one route-map statement is supported per policy.

For this reason, the following configuration would be supported:

route-map my-map 10
match ip address 101
 

While this configuration would not be supported:

route-map my-map 10
match ip address 101
route-map my-map 20
match ip address 102
 
  • This feature only provides support for NAT using route maps; Policy-Based Routing is not supported in the PXF processing path on the Cisco 7304 Router.
  • VRF-Aware NAT with route map defined mapping can use route maps for NAT translation purposes.
  • Port Address Translation, or overload , with route map defined mappings can use route maps for NAT translation purposes.
  • Route map statistics are not updated (Note: This is a NAT on IOS restriction, not a PXF-specific restriction).
  • If the route map configuration is changed while route map sessions are established, it is important to know that the established route map sessions are not automatically cleared (Note: This behavior is consistent with NAT on IOS behavior).

QoS Restrictions

  • User-defined (non class-default) classes within a policy-map must have at least one action attached to generate classification accounting information when using PXF on Cisco 7304 routers. (Note that the class-default class, in contrast, always exists from the PXF point of view, regardless of whether an action is explicitly defined or not.)

For example, the following policy map defines three classes. Comments after each class definition describe whether or not each of these classes will generate classification accounting information.

policy-map POL_1
class CLASS1 ! does NOT generate classification
! accounting information
class CLASS2
set ip precedence 6 ! generates classification accounting info
 
class class-default ! class-default always generates
! classification accounting info
 

If no actual action is required, a possible workaround is to use a police command with both conforming and exceeding action set as transmit.

For example:

policy-map QoS_MAP
class VIDEO
police rate percent 100 conform-action transmit exceed-action transmit
class CRITICAL
police rate percent 100 conform-action transmit exceed-action transmit
class PRIORITARY
police rate percent 100 conform-action transmit exceed-action transmit
class BULK
police rate percent 100 conform-action transmit exceed-action transmit
class SUPORT
 
  • The number of queues allocated for traffic classes per policy map in PXF was increased from four to eight in Cisco IOS Release 12.1(12c)EX1. Of these eight traffic class queues, one traffic class queue is still allocated for the default traffic class and another queue is allocated for priority queuing. Beginning in Cisco IOS Release 12.2(11)YZ , there is no longer a reserved queue for priority traffic. A queue will be designated for priority traffic based on the configuration of a priority class. One queue is still reserved for the default class traffic, and one queue is reserved for critical locally-sourced traffic (such as keepalives and routing protocol hellos), thus leaving six user-configurable queues.
  • In Cisco IOS Release 12.2(11)YZ or later images, eight traffic queues and eight traffic classes are supported per policy map in PXF. Of these eight traffic classes, one traffic class is reserved for the default traffic class and the other for critical locally-sourced traffic. Therefore, six independent classes exist for user configuration.
    It is important to note the difference between a queue and a class. A queue is allocated when a class contains a queueing command (such as bandwidth or priority ), while a class can contain any QoS actions.
    In Cisco IOS Release 12.2(20)S, 8 traffic queues are still available but 23 traffic classes were made available. In other words, up to 23 classes can be configured but only six of the non-default traffic classes can contain queueing commands.
    As of Cisco IOS Release 12.2(20)S5, a direct trade-off exists between the number of supported PXF logical interfaces and the number of supported QoS traffic classes per policy in PXF. The pxf max-logical-interfaces command can be used to determine how many PXF logical interfaces are supported by the router. If the router is configured to support 4,096 PXF logical interfaces ( pxf max-logical-interfaces 4k ), up to 63 QoS classes per policy can be supported in PXF. If the router is configured to support 16,384 logical interfaces (which is the default setting, or which can be restored using no pxf max-logical-interfaces 4k ), up to 23 QoS classes per policy can be supported in PXF.
  • The match command can be used to match ACLs. To classify PXF traffic, use the match access-group command to match the ACL to a class of traffic. Only Turbo ACLs are supported in PXF on the Cisco 7304 router. The following classification criteria, therefore, are among the classification criteria that are not supported:

Source or Destination MAC address

IP-Specific Values (in Cisco IOS Release 12.1EX-based releases only, match ip precedence , match ip dscp , and match ip rtp are available in all Cisco IOS releases that support the Cisco 7304 router except Cisco IOS Release 12.1EX )

QoS Group (QoS group matching was introduced in Cisco IOS Release 12.2(20)S)

  • Before Cisco IOS Release 12.2(20)S, the maximum number of match statements in a class map was 15. After Release 12.2(20)S, the maximum number of match statements in a class map became 31.
    When this restriction is violated, the configuration will still treat traffic as specified but the per-match statement accounting that occurs in the show policy-map command and in the Class-based QoS MIB will not occur.
  • Individual match statement counters are not supported on the classes of parent policy maps.
  • The maximum number of policy map levels for hierarchical policy maps is 2.
  • When specifying Low Latency Queuing (the priority command) in the CLI, the CLI requires that a kbps value be entered. The kbps value, however, is not used. The priority command is important in order to specify that traffic in the traffic class be sent to the priority queue, but the kbps value itself is not used but needs to be entered . Starting with Cisco IOS Release 12.2(11)YZ , the kbps value in the priority command is required. It is used as the mir (maximum information rate) to shape the priority queue to that rate.

However, starting in Cisco IOS Release 12.2(14)SZ, the kpbs value for the priority command is no longer configurable on the NSE-100. When a policy map containing a priority command is configured without a rate, the priority queue policy map gets all of the cir (all of the link bandwidth) and the priority class must drop all non-conforming traffic, leaving no guaranteed bandwidth for other traffic classes. A police command can be configured on the priority queue. The police rate is then used as the bandwidth for the priority queue and any remaining bandwidth can be assigned to other classes using the bandwidth command. This configuration only works if the exceed action of the police statement is drop .

  • The rsvp option is not available as an option with the random-detect dscp command.
  • The ability to match packets in a traffic class using the match atm-clp command is currently not available in PXF. The set atm-clp command can be used simultaneously with all other set options in an output service policy to mark IP precedence/DSCP or MPLS Exp bits together with the ATM CLP bit. However, the set-clp-transmit command when policing cannot be combined with other set commands. Note that for ATM-to-ATM traffic, the ingress CLP bit is preserved on the egress side unless explicitly changed via a set atm-clp or set-clp-transmit command in an output service policy.
  • The set command cannot be used in a parent policy map of a hierarchical service policy.
  • Only bandwidth and priority can be used in a child policy of a nested policy map on a 802.1Q subinterface or Frame Relay VC. The parent policy should have just a default class with a shape command to assign the MIR (maximum information rate) to the subinterface or VC and the child policy.
  • Traffic can only be shaped on an interface using shape average . Other traffic shaping options, such as shape peak , are not currently implemented in PXF.
  • The queue-limit command can only be used on a class that does not have the priority or random-detect commands. For classes with random-detect , the max-threshold value is used to calculate the class queue size using the WRED formula. Support for configurable class queue sizes, either via the queue-limit command or the random-detect maximum threshold, is available only in Cisco IOS Release 12.2(11)YZ or later.
  • In Cisco IOS Release 12.2(20)S, changes were made to support more types of hierarchical policy map configuration and the following new restrictions occurred as a result of the new configuration capabilities:

When the service-policy command is entered inside a class map to create a hierarchical service policy, up to 23 classes inside hierarchical service policies are supported per policy map. Note that this restriction is per policy map, not per hierarchical service policy, so a user can have multiple hierarchical service policies in one policy map as long as the aggregate total of classes in the hierarchical service policies does not exceed 23 classes. The default traffic class in the child policy is counted as one of these 23 classes.

The bandwidth and priority commands are allowed in a child policy map only when the parent class map has the shape command. The parent class must be the default class and the parent policy map cannot have additional classes.

  • In Cisco IOS Release 12.2(27)SBC, three-level hierarchical policy maps were supported for the first time. The following restrictions are applicable to three-level hierarchical policy map configurations:

In any hierarchical configuration, the top-level policy must be class-default only and must only be used for traffic shaping. Traffic shaping cannot be used on any lower-level policy in two-level and three-level hierarchical policies.
In cases where the three-level hierarchy configuration is being used on a virtual interface, the shape command in the default traffic class of the grandparent policy is used to assign bandwidth to the subinterface.

In three-level hierarchy configurations, the parent policy (middle-level policy) can use bandwidth , priority , random-detect , police , and set . Traffic shaping, however, cannot be performed (it should be performed at the top-level policy).

In three-level hierarchy configurations, a class with police or set cannot have a child policy. It is important to note that, in this configuration, you can only have policing in the parent level and have a child policy if the class map in the traffic policy is using class-default.

In three-level hierarchy configurations, a bottom-level policy can only contain police .

Queuing features ( bandwidth and priority ) cannot be used in the bottom-level policy of a three-level hierarchical policy.

  • In Cisco IOS Release 12.2(20)S, the port-level queueing and QoS for subinterface traffic feature was made available. The port-level queueing and QoS for subinterface traffic feature allows port-level QoS configurations to be applied to 802.1q subinterfaces and DLCIs. QoS features can still be applied specifically to 802.1q subinterfaces and DLCIs and the QoS configurations on the 802.1q subinterfaces and DLCIs will always take precedence over the port-level QoS configurations when the 802.1q subinterfaces or DLCI configurations conflict with the port-level QoS configurations.

    It is important to note that Frame Relay and Ethernet ports still cannot match on specific DLCIs or 802.1q subinterfaces, but that traffic on these DLCIs and 802.1q subinterfaces can be matched via other match criteria.
  • When matching traffic for a class, a QoS group match takes priority over an ACL match or an MPLS Experimental value match.
  • The purpose of Hierarchical Ingress Policing is to first police the aggregate default traffic and then police (via marking) or drop the traffic belonging to each nested traffic class.

    In a Hierarchical Ingress Policing configuration, the child policy map can have up to 23 user-defined classes and the service policy containing the child policy can only be configured on the default traffic class. The default traffic class must also be the only class on the parent policy map.

    Also, it should be noted in Hierarchical Ingress Policing configurations that drops occurring in the child class are not recredited to the parent class.
  • In Cisco IOS Release 12.2(20)S2, CBWFQ, LLQ and Traffic Shaping implementations on a Cisco 7304 router using an NSE-100 were changed to account for all Layer 2 per-packet transmission overhead.

Traditionally, Cisco IOS platforms have accounted for Layer 2 headers only. This change means CRCs and any mandatory interpacket overhead are also accounted for. In the case of serial links, this means including the CRC and the one mandatory HDLC flag per packet. In the case of Ethernet, this means including the CRC, the 8-byte preamble, and the 12-byte minimum interpacket gap.

The following overheads were added to ensure flow control mechanisms were not overly triggered:

Ethernet packets: 24 bytes

Serial packets (including POS): 3 bytes

ATM packets: AAL5 cell tax overhead (this is not new in Cisco IOS Release 12.2(20)S2)

This change in accounting was for scheduling only. Traffic Policing still considers the datagram and the Layer 2 header when accounting for overhead.

Reverse Path Forwarding Restriction

If Reverse Path Forwarding (RPF) is configured on an interface with secondary addresses, all packets received on that interface will be processed by the Route Processor.

For instance, assume the following ACL configuration is enabled.

access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 101 permit ip 192.168.2.0 0.0.0.255 any
access-list 102 permit ip 192.168.1.0 0.0.0.255 any
access-list 103 permit ip 192.168.2.0 0.0.0.255 any
 
class-map class1
match access-group 102
class-map class2
match access-group 103
 
policy-map policy1
class class1
set ip precedence 1
class class2
set ip precedence 2
 
interface Gig0/0
ip address 192.168.1.1 255.255.0.0
ip access-group 101 in
service-policy input policy1
 

After these ACLs have been used to sort traffic, imagine the show access-list command is entered to retrieve information about the ACLs. Note that the output of this command only provides statistics for security ACLs and not for the instances where the QoS service policies match against the ACL.

Router# show access-list
Extended IP access list 101
10 permit ip any 192.168.1.0 0.0.0.255 (880902 matches)
20 permit ip any 192.168.2.0 0.0.0.255 (620084 matches)
Extended IP access list 102
10 permit ip any 192.168.1.0 0.0.0.255
Extended IP access list 103
10 permit ip any 192.168.2.0 0.0.0.255
 

WCCP Restrictions

WCCP is not supported in PXF.

Information About IP Accounting

IP Accounting is a very useful accounting feature in Cisco IOS. IP Accounting (Layer 3) collects the number of bytes and packets processed by the network element on a source and destination IP address basis.

IP Accounting (Layer 3) maintains two accounting databases: an active database and a checkpoint database. The active collection process always updates the active database and therefore constantly increments the counters while packets pass the router. To get a snapshot of the traffic statistics, a CLI command or SNMP request can be executed to copy the current status from the active database to the checkpoint database.

IP Accounting Restrictions

  • If you configure any PXF unsupported ingress feature for an interface, none of the data packets entering that interface are handled by the PXF processors. Instead, they are handled by the Route Processor (RP).
  • If you configure any unsupported egress feature for an interface, none of the output features for data packets exiting that interface are handled by the PXF processors. These output features are instead handled by the RP. Also, it is important to note that the ingress features for this punted packet will be re-executed in the processing path from scratch. Therefore, some packets are double-counted in both the RP and PXF processing paths, and some functions that are based on packet statistics, such as the token bucket algorithm used with Traffic Policing, might be impacted by this double-counting.
  • IP accounting disables autonomous switching, SSE switching, and distributed switching (dCEF) on the interface.
  • IP accounting causes packets to be switched on the RP/Route Switch Processor (RSP) instead of the Versatile Interface Processor (VIP) or PXF processors for PXF platforms (Cisco 7300 routers), which can cause performance degradation and high CPU utilization.

PXF Configuration Examples

This section provides various configuration examples for PXF features and includes the following examples:

ACL Configuration Examples

Simple ACL (0 - 99)

Match Source IP Address with Mask

access-list access-list-number {deny | permit} source [source-wildcard]
access-list access-list-number {permit} source [source-wildcard]

Extended ACL (100 - 199)

Match Source and Destination IP Address with Mask

access-list access-list-number {deny | permit} IP source source-wildcard destination destination-wildcard
 

Match IP Protocol

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard
 

Match IP TOS Byte

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [tos tos]
 

Match IP Precedence Value

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence]
 

Match IP DSCP Value

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [DSCP dscp]
 

Match IP L4 Source and/or Destination Port

access-list access-list-number {deny | permit} {tcp | udp} source source-wildcard [operator [source-port]] destination destination-wildcard [operator [destination-port]]
 

ACL Accounting

The following command output shows the number of times a packet matched each ACL. If this output was from a Cisco 7304 router running Cisco IOS Release 12.1(9)EX, the number of matches for each access control entry (ACE) would indicate the number of RP-switched packets that matched the ACE. If this output was from a Cisco 7304 router running Cisco IOS Release 12.1(10)EX or later, the number of matches for each ACE is the sum of all RP-switched and PXF-switched packets that matched the ACE.

Router# show ip access-lists source_only
Extended IP access list source_only (Compiled)
permit udp host 1.1.1.3 eq snmp host 2.1.1.3 (994598 matches)
permit udp host 1.1.1.3 eq snmptrap host 2.1.1.3 (994598 matches)
deny udp host 1.1.1.3 eq xdmcp host 2.1.1.3 (994596 matches)
deny udp host 1.1.1.3 eq ntp host 2.1.1.3 (994595 matches)

Any Transport over MPLS Examples

See Any Transport over MPLS .

EtherChannel Configuration Examples

See Cisco 7304 Router Fast EtherChannel and Gigabit EtherChannel Notes .

GRE Configuration Examples

Basic GRE Configuration

In the following example, a simple GRE tunnel is configured to connect router A to router B through the IP network. The following elements of the configuration should be noted:

  • The tunnel source can be any physical IP address that exists on the router or a loopback address.
  • The tunnel source can be specified either by IP address or interface name.
  • For the tunnel to be in the up/up state, a route to the tunnel destination must exist. In the following examples, the static route is used to specify these routes.

Router A

interface tunnel 0
ip address 8.0.0.5
tunnel source 16.3.0.5
tunnel destination 16.5.0.0

ip route 16.5.0.0 255.255.255.0 16.3.0.10

Router B

interface tunnel 0
ip address 8.0.0.10
tunnel source 16.5.0.0
tunnel destination 16.3.0.5

ip route 16.3.0.5 255.255.255.0 16.5.0.10

Quality of Service Pre-Classification Example

When packets are encapsulated by tunnels and sent through a physical interface, any QoS feature configured on the interface sees the tunnel (outer) header only. Therefore, different packets travelling across the same tunnel will have the same tunnel headers and QoS will treat these packets identically even when the physical interface is congested.

In most cases, this configuration is not desirable; QoS needs be applied based on the original (inner) packet header. For this to happen, the packet must be classified prior to encapsulation and the classification information should be made available at the time QoS is applied.

The interface level qos pre-classify command forces packet to be classified before encapsulation in the tunnel occurs.

The diagram below represents the configuration where QoS Pre-Classification is applied in the following example:

 

 

QoS Pre-Classification Example on Router A

 

class-map match-all source_address

match access-group 5

policy-map set_ip

class source_address

set ip precedence 2

interface Loopback0

ip address 25.0.0.5 255.255.255.0

!

(Note that QoS Pre-Classification is not configured on the tunnel interface.)

interface Tunnel0

ip address 8.0.0.5 255.255.255.0

tunnel source Loopback0

tunnel destination 5.0.0.5

.

(Note that QoS Pre-Classification is applied to the outgoing interface.)

interface POS2/1

ip address 16.3.0.5 255.255.255.0

service-policy output set_ip

no keepalive

clock source internal

end

!

ip route 0.0.0.0 0.0.0.0 tunnel0

ip route 5.0.0.5 255.255.255.255 16.3.0.10

access-list 5 permit 16.21.0.0 0.0.0.255

Even if a packet with a source address that matches the access list specified above is injected, no QoS is applied on the tunneled packet. This can be seen from the show policy-map interface pos2/1 command.

Router# show policy-map interface pos2/1
POS2/1
 
Service-policy output:set_ip
 
Class-map:set_ip (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:access-group 5
QoS Set
ip precedence 3
Packets marked 0
 
Class-map:class-default (match-any)
87532 packets, 7355760 bytes
5 minute offered rate 68000 bps, drop rate 0 bps
Match:any

 

This is because the packet is encapsulated and the original (inner) header that matches the access list is not visible. For the header to become visible after encapsulation, the qos pre-classify command needs to be configured on the tunnel.

interface t0

ip address 8.0.0.5

tunnel source 16.3.0.5

tunnel destination 16.5.0.5

qos pre-classify

Now the show policy-map interface pos2/1 command shows tunneled packets matching the class map and QoS being applied to the tunneled packets.

Router# show policy-map interface pos2/1
POS2/1
 
Service-policy output:set_ip
 
Class-map:set_ip (match-all)
3328 packets, 279552 bytes
5 minute offered rate 15000 bps, drop rate 0 bps
Match:access-group 5
QoS Set
ip precedence 2
Packets marked 3328
 
Class-map:class-default (match-any)
2 packets, 370 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:any
 

Mapping a GRE Tunnel Into an MPLS VPN

In this case, the GRE tunnel runs between the Customer Edge (CE) and Provider Edge (PE). When going into the MPLS cloud, the PE first terminates the tunnel before imposing a label. When going into the CE, the PE encapsulates the packet after disposing the incoming label. The network diagram for this example is below:

On the CE

interface Loopback0

ip address 25.0.0.5 255.255.255.0

!

interface Tunnel0

ip address 7.0.0.5 255.255.255.0

(Note that the loopback address is used as the tunnel source.)

tunnel source Loopback0

tunnel destination 5.0.0.5

.

(The following command sets the default route to the tunnel.)

ip route 0.0.0.0 0.0.0.0 Tunnel0

(The following command specifies the route to the tunnel destination.)

ip route 5.0.0.5 255.255.255.255 16.3.0.10

On the PE

interface Loopback0

ip address 5.0.0.5 255.255.255.255

!

interface Tunnel1

ip address 7.0.0.10 255.255.255.0

tunnel source Loopback0

tunnel destination 25.0.0.5

!

(The following command specifies a route to the tunnel destination.)

ip route 25.0.0.5 255.255.255.255 16.5.0.5

Configuring a Basic VRF-Aware GRE Tunnel

interface tunnel0

ip vrf forwarding green

ip address 10.3.3.3 255.255.255.0

tunnel source loop 0

tunnel destination 10.5.5.5

tunnel vrf blue

Layer 2 Tunneling Protocol version 3 Examples

See Layer 2 Tunneling Protocol Version 3 .

Multiprotocol Label Switching Examples

Basic MPLS Configuration

ip cef

mpls ip

mpls label range minumum maximum

mpls label protocol { ldp | tdp }

interface interface-name number

mpls ip

mpls label protocol { ldp | tdp }

An example with values:

interface gigabitethernet0/1
ip address 74.0.0.1 255.0.0.0
no keepalive
negotiation auto
mpls label protocol ldp
tag-switching ip

Defining an MPLS VPN

The following configuration is for the Provider Edge (PE) connecting to the Customer Edge (CE) router. Basic MPLS must also be configured for this configuration to work properly.

ip vrf vrf-name

rd vpn-route-distinguisher

route-target [ import | export | both ] route-target-vpn-ext-community

interface interface-name number

ip vrf forwarding vrf-name

An example with values:

ip vrf v11
rd 11:11
route-target export 11:11
route-target import 11:11

interface gigabitethernet0/0
ip vrf forwarding v11
ip address 80.0.0.1 255.0.0.0
no keepalive
negotiation auto

Verifying MPLS VPN Operation

show ip vrf

show ip vrf [ brief | detail | interfaces } vrf-name

show ip route vrf vrf-name

show ip protocols vrf vrf-name

show ip cef vrf vrf-name

show ip interface interface-number

show ip bgp vpnv4 all [ tags ]

show tag-switching forwarding vrf vrf-name [ prefix mask / length ] [ detail ]

show mpls interface [ interfaces | detail | all ]

show mpls forwarding-table [ prefix | detail | interface | label | vrf | lsp tunnel ]

Configuring BGP Provider Edge to Provider Edge Routing Sessions

router bgp autonomous-system

neighbor [ ip-address | peer-group-name ] remote-as number

neighbor ip-address update-source loopback0

neighbor ip-address activate

An example with values:

router bgp 1
no synchronization
no bgp default ipv4-unicast
bgp log-neighbor-changes
redistribute connected
neighbor 71.71.71.71 remote-as 1
neighbor 71.71.71.71 update-source loopback0
neighbor 71.71.71.71 activate
no auto-summary

Configuring BGP Provider Edge to Customer Edge Routing Sessions

router bgp autonomous-system

neighbor [ ip-address | peer-group-name ] remote-as number

neighbor ip-address activate

An example with values:

router bgp 1
address-family ipv4 vrf v12
neighbor 42.0.0.1 remote-as 65001
neighbor 42.0.0.1 activate
no auto-summary
no synchronization
exit-address-family

Configuring RIP Provider Edge to Customer Edge Routing Sessions

router rip

version 2

address-family ipv4 [ unicast ] vrf vrf-name

version 2

network prefix

network prefix

address-family ipv4 [ unicast ] vrf vrf-name

redistribute rip

An example with values:

router rip
version 2

address-family ipv4 vrf v11
version 2
network 11.0.0.0
network 30.0.0.0

address-family ipv4 vrf v11
redistribute rip

Configuring a Static Route to a Provider Edge or Customer Edge Routing Session

ip route vrf vrf-name address mask address

An example with values:

ip route vrf v11 11.11.11.11 255.255.255.255 40.0.0.3

Configuring an OSPF Session Between Provider Edge and Customer Edge

router ospf process-id vrf vpn-name

network ip-address subnet-mask area area-id

network ip-address subnet-mask area area-id

address-family ipv4 vrf vrf-name

redistribute ospf process-id match internal route-type-number external route-type-number

An example with values:

router ospf 200 vrf v11
network 40.0.0.0 0.255.255.255 area 5
network 54.54.54.54 0.0.0.0 area 5

address-family ipv4 vrf v11
redistribute ospf 200 match internal external 1 external 2

Configuring a Basic VRF-Aware GRE Tunnel

interface tunnel0

ip vrf forwarding green

ip address 10.3.3.3 255.255.255.0

tunnel source loop 0

tunnel destination 10.5.5.5

tunnel vrf blue

MPLS Traffic Engineering

In addition to the example given below, the following document might also be useful in configuring MPLS Traffic Engineering:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/traffeng.htm

A sample MPLS configuration that includes traffic engineering is given below. Note the use of the tunnel mpls traffic-eng command options throughout the example for MPLS traffic engineering.

Router# show running-config
Building configuration...
 
Current configuration :3785 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname l7300
!
boot bootldr bootdisk:c7300-boot-mz
logging snmp-authfail
logging queue-limit 100
mpls label protocol tdp
mpls ldp logging neighbor-changes
tag-switching tdp router-id Loopback0
 
interface Loopback0
ip address 5.0.0.5 255.255.255.255
 
interface Tunnel1
ip unnumbered Loopback0
load-interval 30
tunnel destination 20.0.0.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng auto-bw
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng bandwidth 10
tunnel mpls traffic-eng path-option 1 explicit name path
 
interface POS2/1
ip address 16.11.0.5 255.255.255.0
no ip mroute-cache
load-interval 30
no keepalive
mpls traffic-eng tunnels
clock source internal
ip rsvp bandwidth 133000 133000
!
interface POS2/2
ip address 16.7.0.5 255.255.255.0
no ip mroute-cache
load-interval 30
no keepalive
mpls traffic-eng tunnels
clock source internal
ip rsvp bandwidth 133000 133000
 
router ospf 1
log-adjacency-changes
network 5.0.0.0 0.0.0.255 area 0
network 8.0.0.0 0.0.0.255 area 0
network 16.7.0.0 0.0.0.255 area 0
network 16.11.0.0 0.0.0.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
 
ip explicit-path name path enable
next-address 16.7.0.10
next-address 16.17.0.10
!
ip explicit-path name PATH enable
next-address 16.11.0.10
next-address 16.17.0.10
 

 

Configuring AAL5NLPID

interface atm3/0.1 point-to-point

pvc 5/50

encapsulation aal5nlpid

Ethernet over MPLS

For Ethernet over MPLS examples, see the “Configuration Examples” section of the MPLS AToM—Ethernet over MPLS document.

VRF Selection Based on Source IP Address

For VRF Selection Based on Source IP Address examples, see the “Configuration Examples” section of the MPLS VPN—VRF Selection Based on Source IP Address document.

Matching and Marking MPLS Experimental Bits

See the “QoS Examples” section of this document.

Other MPLS-related Commands

mpls ip propagate ttl

mpls ip default-route

mpls ldp explicit null

interface interface-name number

mpls mtu bytes

Netflow Configuration Examples

Autonomous System (AS)

BGP must be enabled in order for this configuration to work properly.

ip flow-export version 5 [origin-as | peer-as]
!
interface POS4/0
ip address 172.16.1.1 255.255.255.0
ip route-cache flow
...
!
ip flow-aggregation cache as
cache entries 1024
cache timeout inactive 10
cache timeout active 1
export destination 172.16.2.10 9995
enabled
 

BGP Next Hop

ip flow-export version 9 [origin-as | peer-as] bgp-nexthop
 

An example with values:

ip flow-export version 9 peer-as bgp-nexthop
ip flow-aggregation cache as
cache timeout active 1
export version 9
export destination 16.16.16.10 7777
enabled
 

Protocol-Port

interface POS4/0
ip address 172.16.1.1 255.255.255.0
ip route-cache flow
...
!
ip flow-aggregation cache protocol-port
cache entries 1024
cache timeout inactive 10
cache timeout active 1
export destination 172.16.2.10 9995
enabled
 

Source-Prefix

interface POS4/0
ip address 172.16.1.1 255.255.255.0
ip route-cache flow
...
!
ip flow-aggregation cache source-prefix
cache entries 1024
cache timeout inactive 10
cache timeout active 1
export destination 172.16.2.10 9995
enabled
 

Destination-Prefix

interface POS4/0
ip address 172.16.1.1 255.255.255.0
ip route-cache flow
...
!
ip flow-aggregation cache destination-prefix
cache entries 1024
cache timeout inactive 10
cache timeout active 1
export destination 172.16.2.10 9995
enabled
 

MPLS Egress Netflow Accounting

See MPLS Egress Netflow Accounting .

Network Address Translation (NAT) Examples

Inside to Outside Static Translation

The following example shows how to map internal, unregistered stub network host addresses to external, registered IP addresses on a static, one-to-one basis. In this case, internal local IP addresses 1.1.1.2 and 1.1.1.1 are statically mapped to addresses 2.2.2.3 and 2.2.2.2 for packets leaving the internal stub network.

interface Ethernet2/1
ip address 1.0.0.3 255.0.0.0
ip nat inside
!
ip nat inside source static 1.1.1.2 2.2.2.3
ip nat inside source static 1.1.1.1 2.2.2.2
 

Inside to Outside Dynamic Translation

In the example below, addresses from three different internal stub networks are translated using different pools of outside addresses. The access lists 1, 2, and 3 correspond to pools pool1, pool3, and pool5, respectively.

interface FastEthernet1/0
ip address 10.0.0.1 255.0.0.0
ip nat inside
!
interface FastEthernet3/0
ip address 30.0.0.1 255.0.0.0
ip nat inside
!
interface FastEthernet5/0
ip address 50.0.0.1 255.0.0.0
ip nat inside
!
ip nat pool pool1 20.1.0.1 20.1.255.254 netmask 255.0.0.0
ip nat pool pool2 40.1.0.1 40.1.255.254 netmask 255.0.0.0
ip nat pool pool3 60.1.0.1 60.1.255.254 netmask 255.0.0.0
ip nat inside source list 1 pool pool1
ip nat inside source list 2 pool pool2
ip nat inside source list 3 pool pool3
!
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 2 permit 30.0.0.0 0.255.255.255
access-list 3 permit 50.0.0.0 0.255.255.255

 

Overloading an Inside Global Address (or Port Address Translation [PAT])

Overloading an inside global address is used to conserve inside global addresses by allowing the router to use one global address for many local addresses. When overloading is configured, information such as UDP/TCP ports are used to translate the global address back to the correct local address.

The following example creates a pool of addresses named net-208. The pool contains addresses from 171.69.233.208 to 171.69.233.233. Access list 1 allows packets having the source address from 192.168.1.0 to 192.168.1.255. If no translation exists, packets matching access list 1 are translated to an address from the pool. The router allows multiple local addresses (192.168.1.0 to 192.168.1.255) to use the same global address. The router retains port numbers to differentiate the connections.

ip nat pool net-208 171.69.233.208 171.69.233.233 netmask 255.255.255.240
ip nat inside source list 1 pool net-208 overload
!
interface serial0
ip address 171.69.232.182 255.255.255.240
ip nat outside
!
interface ethernet0
ip address 192.168.1.94 255.255.255.0
ip nat inside
!
access-list 1 permit 192.168.1.0 0.0.0.255
 
 

Translating Outside to Inside Addresses

Static Outside to Inside

ip nat outside source static global-ip local-ip

Dynamic Outside to Inside

ip nat pool name start-ip end-ip { netmask netmask | prefix-length prefix-length}

access-list access-list-number permit source [source-wildcard]

ip nat outside source list access-list-number pool name

In the following example, the addresses in the local network are being used legitimately by someone else on the Internet. An extra translation is required to access that external network. Pool net-10 is a pool of outside local IP addresses. The statement ip nat outside source list 1 pool net-10 translates the addresses of hosts from the outside overlapping network to addresses in that pool.

ip nat pool net-208 171.69.233.208 171.69.233.223 prefix-length 28
ip nat pool net-10 10.0.1.0 10.0.1.255 prefix-length 24
ip nat inside source list 1 pool net-208
ip nat outside source list 1 pool net-10
!
interface serial 0
ip address 171.69.232.192 255.255.255.240
ip nat outside
!
interface ethernet0
ip address 192.168.1.94 255.255.255.0
ip nat inside
access-list 1 permit 192.168.1.0 0.0.0.255
 
It is also possible to have different ACLs to select different inside address pools, the same as the earlier example of multiple pools for different inside to outside translations.
interface FastEthernet2/0
ip address 20.0.0.1 255.0.0.0
ip nat outside
!
interface FastEthernet4/0
ip address 40.0.0.1 255.0.0.0
ip nat outside
!
interface FastEthernet6/0
ip address 60.0.0.1 255.0.0.0
ip nat outside
!
ip nat pool pool1inside 10.1.0.1 10.255.255.254 netmask 255.0.0.0
ip nat pool pool2inside 30.1.0.1 30.255.255.254 netmask 255.0.0.0
ip nat pool pool3inside 50.1.0.1 50.255.255.254 netmask 255.0.0.0
ip nat outside source list 4 pool pool1inside
ip nat outside source list 5 pool pool2inside
ip nat outside source list 6 pool pool3inside
 

TCP Load Distribution

In the following example, the goal is to define a virtual address, connections to which are distributed among a set of real hosts. The pool defines the addresses of the real hosts. The access list defines the virtual address. If a translation does not already exist, TCP packets from serial 0 (the outside interface) in which the destination matches the access list are translated to an address from the pool.

ip nat pool real-hosts 192.168.15.2 192.168.15.15 prefix-length 28 type rotary
ip nat inside destination list 2 pool real-hosts
!
interface serial 0
ip address 192.168.15.129 255.255.255.240
ip nat outside
!
interface ethernet 0
ip address 192.168.15.17 255.255.255.240
ip nat inside
!
access-list 2 permit 192.168.15.1

 

Configuring Outside to Inside Static Translation with Port

When translating addresses to an interface’s address, outside-initiated connections to services on the inside network (such as e-mail) will require additional configuration to send the connection to the correct inside host. This command allows the user to map certain services to certain inside hosts.

ip nat inside source static { tcp | udp } localaddr localport globaladdr globalport

In this example, outside-initiated connections to the SMTP port (25) will be sent to the inside host 192.168.10.1:

ip nat inside source static tcp 192.168.10.1 25 171.69.232.209 25
 

Basic Route-Map

route-map name [permit | deny] number
match ip address access-list-number
 

Dynamic NAT Route-Map

ip nat pool poolP 131.108.2.1 131.108.2.254 prefix-length 24
ip nat pool poolQ 131.118.2.1 131.118.2.254 prefix-length 24
 
ip nat inside source route-map MAP-P pool poolP
ip nat inside source route-map MAP-Q pool poolQ
 
access-list 108 permit ip 10.1.1.0 0.0.0.255 131.108.1.0 0.0.0.255
access-list 118 permit ip 10.1.1.0 0.0.0.255 131.118.1.0 0.0.0.255
 
route-map MAP-P permit 10
match ip address 108
 
route-map MAP-Q permit 10
match ip address 118
 

VRF-Aware NAT

VRF-Aware NAT is documented as NAT Integration with MPLS VPNs.
For VRF-Aware NAT configuration examples, see the NAT Integration with MPLS VPNs document.

Verifying NAT

show c7300 nat pxf statistics

show ip nat translations

show ip nat statistics

QoS Examples

Class-Based Weighted Fair Queueing

policy-map child-policy-map-name
class class-map-name
bandwidth [kbps | percent percentage]
bandwidth remaining percent percentage
 

Fast EtherChannel and Gigabit EtherChannel with QoS Rate Limiting

See Cisco 7304 Router Fast EtherChannel and Gigabit EtherChannel Notes .

 

Nested Policy Map Example (Two-Level)

The following example shows how to configure a nested policy map. Nested policy maps are used to apply QoS features (in the case of PXF on the Cisco 7304, traffic shaping is the QoS feature although other QoS features are supported) to subinterfaces such as Frame Relay virtual circuits (VCs) and Virtual Local Area Networks (VLANs).

policy-map child-policy-map-name
class class-map-name
priority
police rate-in-bps
class class-map-name
bandwidth [kbps | percent percentage]
 
policy-map parent-policy-map-name
class class-default
shape average cir
service-policy child-policy-map-name
 
interface interface-type interface-number
service-policy parent-policy-name
 

Nested Policy Map Example (Three-Level)

class-map TRAFFIC
match access-group name TRAFFIC_ACL

class-map SAA
match access-group name SAA_ACL

class QUEUING
match access-group name TRAFFIC_ACL
match access-group name SAA_ACL
policy-map POLICING
class TRAFFIC
police 1024000 128000 128000 conform-action set-dscp-transmit af41 exceed-action set-dscp-transmit af42

policy-map EGRESS_QUEUING
class QUEUING
bandwidth remaining percent 50
random-detect dscp-based
service-policy POLICING

policy-map SHAPING
class class-default
shape average 10240000
service-policy EGRESS_QUEUING
 

Matching ACL

class-map [match-all | match-any] class-map-name
match access-group [access-list-number | name named-access-list]
 

Matching ACL to Match FTP Packets to a Class of Traffic

class-map match-all ftp-class
match access-group 109
 
access-list 109 permit tcp any any eq ftp
 

Matching CoS Values

class-map [match-all | match-any] class-map-name
match cos cos-value [cos-value [cos-value [cos-value]]]

Matching Frame Relay DE

class-map [match-all | match-any] class-map-name
match fr-de
 

Matching Frame Relay DLCIs

class-map [match-all | match-any] class-map-name
match fr-dlci {dlci-number | dlci-number1-dlci-number2 | dlci-number1 dlci-number2 dlci-number3 ...}
 

Matching Input Interface

class-map [match-all | match-any] class-map-name
match input-interface interface-name
 

Matching IP DSCP

class-map [match-all | match-any] class-map-name
match ip dscp ip-dscp-value ip-dscp values ...(up to 8 ip-dscp values)
 

Matching IP Precedence

class-map [match-all | match-any] class-map-name
match ip precedence ip-prec-value ip-prec-value...(up to 8 ip-prec values)
 

Matching IP RTP

class-map [match-all | match-any] class-map-name
match ip rtp ip-rtp-value ip-rtp-value...(up to 8 ip-rtp values)

Matching MPLS Exp Bit

class-map match-all mpls
match mpls experimental 7
 

Matching QoS Group

class mpls
match qos-group 6
 

Matching VLAN ID

class-map [match-all | match-any] class-map-name
match-vlan {vlan-id | vlanid1-vlanid2 | vlan-id1 vlan-id2 vlan-id3...}
 

Marking ATM CLP

policy-map policy-map-name
class class-map-name
set atm-clp atm-clp-value
 

Marking Class of Service Values (Using set Command)

policy-map policy-map-name
class class-map-name
set cos cos-value

Marking Class of Service Values (Using police Command)

policy-map mpls
class mpls
police 200000 300000 200000 conform-action set-cos-transmit 0 exceed-action set-cos-transmit 1 violate-action set-cos-transmit 2
 

Marking Frame Relay DE Bits (Using set Command)

policy-map mpls
class mpls
set fr-de
 

Marking Frame Relay DE Bits (Using police Command)

policy-map mpls
class mpls
police 200000 300000 200000 conform-action set-frde-transmit 7 exceed-action set-frde-transmit 3 violate-action set-frde-transmit 4
 

Marking IP Precedence

policy-map policy-map-name
class class-map-name
set ip precedence precedence-value
 

Marking IP DSCP

policy-map policy-map-name
class class-map-name
set ip dscp dscp-value
 

Marking MPLS Exp Bit

policy-map policy-map-name
class class-map-name
set mpls experimental mpls-exp-value

police 200000 300000 200000 conform-action set-mpls-exp-transmit 1 exceed-action set-mpls-exp-transmit 2 violate-action set-mpls-exp-transmit 3
 

Marking Quality of Service Groups

The following examples shows how to mark QoS groups using the set and the police commands:

policy-map mpls
class mpls
set qos-group 7
 
policy-map mpls
class mpls
police 200000 300000 200000 conform-action set-qos-transmit 7 exceed-action set-qos-transmit 3 violate-action set-qos-transmit 4
 

Low Latency Queueing (Priority Queueing)

Low Latency Queueing Before Cisco IOS Release 12.2(14)SZ—Priority Queue Gets All Bandwidth and Other Queues Get Leftover Bandwidth

policy-map policy-map-name
class class-map-name
priority kpbs
 

Low Latency Queueing After Cisco IOS Release 12.2(14)SZ—Priority Queue is Left to Police Rate and Other Classes Get Leftover Bandwidth

policy-map policy-map-name
class class-map-name
priority
police bps burst-normal burst-max conform-action action exceed-action action [violate-action action]
 

Note In this configuration, the priority queue will get all of the bandwidth if the exceed-action action is set to no drop.


Port-Level Queueing and QoS for Subinterface Traffic

In Cisco IOS Release 12.2(20)S, the port-level queuing feature was introduced to allow port-level QoS policy configurations to apply to Frame Relay DLCIs and 802.1q subinterfaces. The following points are important characteristics of this feature:

  • A traffic policy can be applied either at the interface level or onto the selected Frame Relay DLCI or 802.1q subinterface.
  • If a traffic policy is applied directly to a Frame Relay DLCI or an 802.1q subinterface, this policy overrides the interface-level traffic policy. The interface-level traffic policy configuration will be ignored by the Frame Relay DLCI or the 802.1q subinterface in this configuration.

Frame Relay DLCIs and 802.1q subinterfaces without an individual policy are aggregated and subject to the interface-level policy. Note that these Frame Relay DLCIs and 802.1q subinterfaces are aggregated; they do not get the port-level policy applied to each individual Frame Relay DLCI or 802.1q interface that does not have an individual policy.

Before Cisco IOS Release 12.2(20)S, QoS policies for Frame Relay DLCIs and 802.1q subinterfaces had to be configured directly onto the DLCI or the subinterface.

Quality of Service for Virtual Private Networks

interface interface-name
qos pre-classify
 

Queue Limit Setting

policy-map policy-map-name
class class-map-name
queue-limit number-of-packet
 

Traffic Policing (Basic)

policy-map policy-map-name
class class-map-name
police bps burst-normal burst-max conform-action action exceed-action action [violate-action action]
 

Traffic Policing (Hierarchical Ingress Policing)

policy-map child
class c1
police x1 y1 conform action1 exceed action2
class c2
police x2 y2 conform action3 exceed action4
 
policy-map parent
class class-default
police x3 y3 conform action5 exceed action6
service-policy child
 

Traffic Policing (Multiple Action Policer)

police cir 1000000 bc 2000000
conform-action transmit
exceed-action set-prec-transmit 4
exceed-action set-frde
violate-action set-prec-transmit 2
violate-action set-frde-transmit
end
 

Traffic Shaping

policy-map policy-map-name
class class-map-name
shape average cir
 

Weighted Random Early Detection (WRED)—IP Precedence Example

policy-map wred
class class-default
random-detect exponential-weight-constant weight
random-detect precedence [IP-precedence minimum-threshold maximum-threshold max-probability-denominator]
bandwidth [kbps | percent percentage]
 

Weighted Random Early Detection (WRED)—IP DSCP Example

policy-map wred
class class-default
random-detect dscp-based
random-detect dscp dscp-codepoint-value
 

Modular QoS CLI Example

In the following example, all FTP traffic leaving interface POS4/0 is forwarded with the IP precedence bit marked as 1 while all World Wide Web traffic is forwarded with the IP precedence bit marked as 2. In this configuration, all other IP traffic marks the IP precedence bit as 5 and is forwarded using the priority queue while HTTP traffic is forwarded using the default queue.

Note that traffic with the IP precedence marked as 5 is classified using an access list.

access-list 109 permit tcp any any eq ftp
access-list 110 permit tcp any any eq www
access-list 111 permit ip any any eq precedence 5
 
class-map match-all ftp-class
match access-group 109
 
class-map match-all www-class
match access-group 110
 
class-map match-all prec5-class
match access-group 111
 
policy-map intpos40
class ftp-class
set ip precedence 1
class www-class
set ip precedence 2
class prec5-class
priority 1
 
interface pos4/0
service-policy output intpos40
 

Frame Relay Modular QoS CLI Example

For Frame Relay virtual circuit QoS configuration, see the “Nested Policy Map Example (Two-Level)” section.

In the following example, all FTP traffic leaving subinterface POS4/0.1 is forwarded with the IP precedence bit marked as 7.

access-list 109 permit tcp any any eq ftp
 
class-map match-all ftp-class
match access-group 109
 
policy-map ftp-low-priority
class ftp-class
set ip precedence 7
 
interface pos4/0.1 point-to-point
ip address 10.1.1.1 255.0.0.0
frame-relay interface-dlci 100
service-policy output ftp-low-priority

 

Reverse Path Forwarding Examples

Accept packets whose source IP is reachable via the interface on which the packet was received or is from a default route; drop others.

ip verify unicast reverse-path
or
ip verify unicast source reachable-via rx allow-default
 

Use an ACL to filter packets whose source IP is not reachable via the interface on which the packet was received.

ip verify unicast reverse-path 109
or
ip verify unicast source reachable-via rx 109
 

Accept packets whose source IP address exists in the Forwarding Information Base (FIB); drop others.

ip verify unicast source reachable-via any
 

Use an ACL to filter packets whose source IP address does not exist in the Forwarding Information Base (FIB).

ip verify unicast source reachable-via any 109
 

Accept packets whose source IP and destination IP matches one of the interface primary or secondary addresses, which is necessary if a self-ping capability is required. If allow-self-ping is not configured, self-ping packets are dropped.

ip verify unicast reverse-path allow-self-ping 109
or
ip verify unicast source reachable-via rx allow-self-ping 109
or
ip verify unicast source reachable-via any allow-self-ping 109

 

Using show Commands

Use the global show version or show c7300 commands to obtain information about the hardware and software installed on your router. Examples of each follow.


Note You might notice that there is not as much accounting information provided by 7304 show commands as there is for other routers. Because of the overhead involved, accounting information available from the PXF processors is currently kept to an absolute minimum.
There can be a significant amount of overhead involved in maintaining such information within the PXF processors and then retrieving it from the Route Processor for inclusion in show commands or in MIB variables. As a result, only essential accounting is done within the PXF processors.


Using the show version Command

Use the show version command to display the configuration of the system hardware and the software version.

The following example of the show version command identifies an NSE-100 installed in a Cisco 7304 router:

Router# show version
Cisco Internetwork Operating System Software
IOS (tm) 7300 Software (C7300-JS-M), Version 12.1(9)RELEASED, CISCO N
Copyright (c) 1986-2001 by cisco Systems, Inc.
Compiled Fri 20-Apr-01 01:53 by biff
Image text-base: 0x40008970, data-base: 0x40BF2000
 
ROM: System Bootstrap, Version 12.1(9) [biff], RELEASED
 
WStar_TOP uptime is 15 hours, 20 minutes
System returned to ROM by power-on
System restarted at 23:49:08 UTC Thu Apr 26 2001
System image file is "disk0:c7300-js-mz.121-99.DAILY_BUILD_20010419"
 
cisco 7300 (NSE100) processor (revision A) with 114688K/16384K bytes of memory.
Processor board ID
R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2, 1024KB L3 Cache
4 slot midplane, Version 65.48
 
Last reset from power-on
X.25 software, Version 3.0.0.
PXF processor tmc0 is running.
PXF processor tmc1 is running.
1 FastEthernet/IEEE 802.3 interface(s)
2 Gigabit Ethernet/IEEE 802.3 interface(s)
10 Packet over SONET network interface(s)
509K bytes of non-volatile configuration memory.
 
16064K bytes of ATA compact flash disk at bootdisk (Sector size 512 bytes).
31369K bytes of ATA compact flash disk at disk 0 (Sector size 512 bytes).

Configuration register is 0x100

Using the show c7300 and show pxf Commands

Use the show c7300 and show pxf commands and subcommands to obtain information about the router.

 

  • show c7300 info

Show system information

  • show pxf or
    show c7300 pxf

Show PXF information (This command was modified to show pxf for the Cisco 7304 router. The Cisco IOS releases prior to Cisco IOS Release 12.2(14)SZ that support the Cisco 7304 still require that show c7300 pxf be entered to gather PXF interface information.)

  • show c7300

Show slots information

Router> show c7300 info
Network IO Interrupt Throttling:
throttle count=0, timer count=0
active=0, configured=1
netint usec=3999, netint mask usec=200
 
C7300 Midplane EEPROM:
Hardware Revision : 2.0
Chassis MAC Address : 0001.6444.8200
MAC Address block size : 256
Number of Slots : 4
Chassis Serial Number : SCA053200L9
PCB Serial Number : SAA05290365
Part Number : 73-5916-02
Board Revision : A0
Fab Version : 01
RMA Test History : 00
RMA Number : 0-0-0-0
RMA History : 00
Deviation Number : 0-0
Product Number :
Top Assy. Part Number : 68-0000-00
Manufacturing Test Data : 00 00 00 00 00 00 00 00
Field Diagnostics Data : 00 00 00 00 00 00 00 00
Calibration Data : Minimum: 0 dBmV, Maximum: 0 dBmV
Calibration values :
EEPROM format version 4
EEPROM contents (hex):
0x00: 04 FF 40 02 A1 41 02 00 C3 06 00 01 64 44 82 00
0x10: 43 01 00 01 04 C2 8B 53 43 41 30 35 33 32 30 30
0x20: 4C 39 C1 8B 53 41 41 30 35 32 39 30 33 36 35 82
0x30: 49 17 1C 02 42 41 30 02 01 03 00 81 00 00 00 00
0x40: 04 00 80 00 00 00 00 CB 94 20 20 20 20 20 20 20
0x50: 20 20 20 20 20 20 20 20 20 20 20 20 20 87 44 00
0x60: 00 00 C4 08 00 00 00 00 00 00 00 00 C5 08 00 00
0x70: 00 00 00 00 00 00 C8 09 00 00 00 00 00 00 00 00
0x80: 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 
C7300 NSE Mainboard EEPROM:
Hardware Revision : 2.3
PCB Serial Number : CAB0532JYYX
Part Number : 73-5198-02
Board Revision : A0
Fab Version : 02
RMA Test History : 00
RMA Number : 0-0-0-0
RMA History : 00
Deviation Number : 0-0
Product Number : 7300-NSE-100
Top Assy. Part Number : 68-1002-02
Manufacturing Test Data : 00 00 00 00 00 00 00 00
Field Diagnostics Data : 00 00 00 00 00 00 00 00
Calibration Data : Minimum: 0 dBmV, Maximum: 0 dBmV
Calibration values :
EEPROM format version 4
EEPROM contents (hex):
0x00: 04 FF 40 02 8B 41 02 03 C1 8B 43 41 42 30 35 33
0x10: 32 4A 59 59 58 82 49 14 4E 02 42 41 30 02 02 03
0x20: 00 81 00 00 00 00 04 00 80 00 00 00 00 CB 94 37
0x30: 33 30 30 2D 4E 53 45 2D 31 30 30 20 20 20 20 20
0x40: 20 20 20 87 44 03 EA 02 C4 08 00 00 00 00 00 00
0x50: 00 00 C5 08 00 00 00 00 00 00 00 00 C8 09 00 00
0x60: 00 00 00 00 00 00 00 C7 34 F6 44 F6 44 F6 44 F6
0x70: 44 12 00 8C 07 05 00 8D 19 00 D3 07 05 00 82 21
0x80: 00 D3 07 05 00 AC 32 00 D3 07 05 01 04 78 00 D3
0x90: 07 05 02 71 00 00 00 00 00 00 00 F3 DB FF FF FF
0xA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 
C7300 NSE Daughterboard EEPROM:
Hardware Revision : 2.1
PCB Serial Number : CAB0531JYA6
Part Number : 73-5673-03
Board Revision : A0
Fab Version : 03
RMA Test History : 00
RMA Number : 0-0-0-0
RMA History : 00
Deviation Number : 0-0
Product Number : 7300-NSE-100
Top Assy. Part Number : 68-1002-02
Manufacturing Test Data : 00 00 00 00 00 00 00 00
Field Diagnostics Data : 00 00 00 00 00 00 00 00
Calibration Data : Minimum: 0 dBmV, Maximum: 0 dBmV
Calibration values :
EEPROM format version 4
EEPROM contents (hex):
0x00: 04 FF 40 02 8C 41 02 01 C1 8B 43 41 42 30 35 33
0x10: 31 4A 59 41 36 82 49 16 29 03 42 41 30 02 03 03
0x20: 00 81 00 00 00 00 04 00 80 00 00 00 00 CB 94 37
0x30: 33 30 30 2D 4E 53 45 2D 31 30 30 20 20 20 20 20
0x40: 20 20 20 87 44 03 EA 02 C4 08 00 00 00 00 00 00
0x50: 00 00 C5 08 00 00 00 00 00 00 00 00 C8 09 00 00
0x60: 00 00 00 00 00 00 00 C7 34 F6 44 F6 44 F6 44 F6
0x70: 44 10 00 7C 07 05 00 8D 12 00 8C 07 05 00 8D 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 F8 BC FF FF FF
0xA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 
ROMMON Last Error Info:
count: 19, reason: reset
pc: 0x402765E8, error address: 0x00000000
Stack Trace:
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000
FP: 0x00000000, PC: 0x00000000

Using the show c7300 pxf accounting or show pxf accounting Command

The following is an example of the show c7300 pxf accounting or show pxf accounting command with sample output (not all Cisco IOS releases have both commands, but both commands produce the same output):

Router> show c7300 pxf accounting
PXF Utilization: 0 %
PXF Packet Counters:
Ingress from GE : 18 Egress to GE : 34
Ingress from LCs: 329 Egress to LCs: 8
Ingress from RP : 42 Egress to RP : 347