Cisco Express Forwarding is enabled by default on most Cisco platforms running Cisco IOS software Release 12.0 or later. When Cisco Express Forwarding is enabled on a router, the Route Processor (RP) performs the express forwarding.

To find out if Cisco Express Forwarding is enabled on your platform, enter the show ip cefcommand. If Cisco Express Forwarding is enabled, you receive output that looks like this:

Router# show ip cef 
Prefix              Next Hop            Interface
[...]
10.2.61.8/24        192.168.100.1       FastEthernet1/0/0
                    192.168.101.1       FastEthernet6/1
[...]

If Cisco Express Forwarding is not enabled on your platform, the output for the show ip cefcommand looks like this:

Router# show ip cef
%CEF not running

Distributed Cisco Express Forwarding is enabled by default on the Catalyst 6500 series switch, the Cisco 7500 series router, and the Cisco 12000 Series Internet Router. When distributed Cisco Express Forwarding is enabled on your platform, the line cards perform the express forwarding.

If Cisco Express Forwarding is not enabled on your platform, use the ip cefcommand to enable (central) Cisco Express Forwarding or the ip cef distributed command to enable distributed Cisco Express Forwarding.

Central Cisco Express Forwarding or distributed Cisco Express Forwarding has the following restrictions:

• The Cisco 12000 Series Internet routers operate only in distributed Cisco Express Forwarding mode. On these routers, you must not disable distributed Cisco Express Forwarding on an interface.
• If you enable Cisco Express Forwarding and then create an access list that uses the logkeyword, the packets that match the access list are not Cisco Express Forwarding switched. They are process switched. Logging disables Cisco Express Forwarding.
• Distributed Cisco Express Forwarding switching cannot be configured on the same VIP card on which distributed fast switching is configured.
• Distributed Cisco Express Forwarding is not supported on Cisco 7200 series routers.

See the Additional References for links to more information on the features and functionality of Cisco Express Forwarding.

The traffic matrix statistics (TMS) feature allows an administrator to gather the following data:

• The number of packets and number of bytes that travel across the backbone from internal and external sources. The counts of packets and bytes are called TMS and are useful for determining how much traffic a backbone handles. You can analyze TMS using the following methods:
  • Collecting and viewing TMS through the application of the Network Data Analyzer (NDA)
  • Reading the TMS that reside on the backbone router
• The neighbor autonomous systems of a Border Gateway Protocol (BGP) destination. You can view these systems by reading the tmasinfo_ascii file on the backbone router.

The following sections explain how to collect and view the TMS using the command-line interface (CLI) and the NDA. For detailed instructions on using the NDA, see the Network Data Analyzer Installation and User Guide .

TMS enables an administrator to capture and analyze data on traffic entering a backbone that is running BGP. The TMS feature also allows an administrator to determine the neighbor autonomous systems of a BGP destination. TMS are counted during packet forwarding by Cisco Express Forwarding nonrecursive accounting.

By enabling a backbone router to gather TMS, you can determine the amount of traffic that enters the backbone from sites outside of the backbone. You can also determine the amount of traffic that is generated within the backbone. This information helps you optimize and manage traffic across the backbone.

The following paragraphs explain how Cisco Express Forwarding nonrecursive accounting aggregates packet statistics for Interior Gateway Protocol (IGP) routes and their dependent BGP routes.

A BGP network deployed by a service provider might have the following components:

• IGP routes that describe the next hop to which traffic should be sent
• BGP routes that specify an intermediate address to which traffic should be sent

The intermediate address specified for the BGP route might be several hops away from the provider edge (PE) router. The next hop for the BGP route is the next hop for the intermediate address of the BGP route. The BGP route is called recursive, because it points through an intermediate address to an IGP route that provides the next hop for forwarding. However, a route lookup results in a next hop that is not directly reachable, as is the case with the BGP route's intermediate address. A recursive lookup to an IGP route is used to decide how to reach the indirect next hop.

Cisco Express Forwarding represents IGP routes as nonrecursive entries and BGP routes as recursive entries that resolve through nonrecursive entries.

Cisco Express Forwarding nonrecursive accounting counts the packets for all of the Cisco Express Forwarding recursive entries (from BGP routes) that resolve through a Cisco Express Forwarding nonrecursive entry and the packets for the nonrecursive entry (from IGP routes). The number of packets is totalled in one location.

The packets forwarded based on a nonrecursive Cisco Express Forwarding entry can be split into two bins based on whether the input interface of the backbone router is configured as internal or external. Thus, all packets that arrive on external interfaces (external to the region of interest) and are forwarded based on a given IGP route (either directly or through a recursive BGP route) are counted together.

The following example shows how Cisco Express Forwarding nonrecursive accounting counts packets when BGP routes resolve to one IGP route and when they do not.

A multiaccess network access point (NAP) has BGP routes referring to hosts on the NAP network.

• If the network is advertised as a single IGP route, all of the BGP routes to the various hosts at that NAP resolve to a single IGP route. Cisco Express Forwarding nonrecursive accounting counts the number of packets sent to all BGP destinations.
• If a network administrator instead advertises individual host routes from the NAP network to the IGP, Cisco Express Forwarding nonrecursive accounting counts packets to those hosts separately.

You can determine the amount of traffic that enters the backbone from sites outside of the backbone if you enable a backbone router to gather TMS. You can also determine the amount of traffic that is generated within the backbone. This information helps you optimize and manage traffic across the backbone. The two figures below help illustrate the traffic statistics you can gather using TMS.

The figure below shows a sample network with backbone routers and links. The traffic that travels through the backbone is the area of interest for TMS collection. TMS are collected during packet forwarding. The backbone is represented by the darkly shaded routers and bold links. The lighter shaded and unshaded routers are outside the backbone.

Figure 1

Sample Network with Backbone Routers and Links

The figure below shows an exploded view of the backbone router that links the Los Angeles point of presence (POP) in the figure above to the Atlanta POP. The bold line represents the backbone link going to the Atlanta POP.

The figure below shows the following types of traffic that travel through the backbone router:

• The dotted line marked A represents traffic entering the backbone from a router that is not part of the backbone. This is called external traffic.
• The dotted lines marked B and D represent traffic that is exiting the backbone. This is called internal traffic.
• The dotted line marked C represents traffic that is not using the backbone and is not of interest to TMS.

Figure 2

Types of Traffic That Travel Through a Backbone Router

You can determine the amount of traffic the backbone handles by enabling a backbone router to track the number of packets and bytes that travel through the backbone router. You can separate the traffic into the categories "internal" and "external." You separate the traffic by designating incoming interfaces on the backbone router as internal or external.

Once you enable a backbone router to collect TMS, the router starts counters, which dynamically update when network traffic passes through the backbone router. You can retrieve a snapshot of the TMS, either through a command to the backbone router or through the NDA.

External traffic (path A in the figure above) is the most important for determining the amount of traffic that travels through a backbone router. Internal traffic (paths B and D in the figure above) is useful for ensuring that you are capturing all of the TMS data. When you receive a snapshot of the TMS, the packets and bytes are displayed in internal and external categories.

Once TMS are collected, you have three options for viewing the data:

• TMS Displayed with the NDA Display Module
  
• Nonrecursive Accounting Information Displayed
  

Before you perform the task to interpret the statistics in the tmstats_ascii file (an optional procedure described in the Interpreting the tmstats File section), you need to understand the following:

VERSION 1|ADDR
<address>
|AGGREGATION
TrafficMatrix.ascii|SYSUPTIME
<seconds>|
routerUTC
<routerUTC>
|NTP
<synchronized|unsynchronized>|DURATION
<aggregateTime>
|

p|
<destPrefix/Mask>
|
<creationSysUpTime>
|
<internalPackets>
|
<internalBytes>
|
<externalPackets>
|
<externalBytes>

t|
<headAddr><tun_id>
|
<creationSysUpTime>
|

<internalPackets>
|
<internalBytes>
|
<externalPackets>
|
<externalBytes>

Before viewing the statistics in thetmsasinfo file (an optional procedure described in the Viewing Information in the tmsasinfo File), you need to understand the following:

VERSION 1|ADDR
<address>
|AGGREGATION 
ASList.ascii|SYSUPTIME
<seconds>|routerUTC
 
<routerUTC>
|DURATION
<aggregateTime>
|

<nonrecursivePrefix/Mask>
|
<AS>
|
<destinationPrefix/Mask>

1.    enable

2.    configure terminal

3.    ip cef accounting {[non-recursive] [per-prefix] [prefix-length]}

4.    exit

This section contains information about and instructions for enabling a backbone router to collect TMS for Cisco Express Forwarding. Enabling a backbone router to collect TMS requires enabling nonrecursive accounting and setting the interfaces on the router to collect internal or external TMS. The internal and external settings are used only for TMS collection. The interfaces are set to internal by default.

Note	Make sure you configure the collection of internal and external TMS on the incoming interface of the backbone router.

You can perform these tasks either through the CLI or through the NDA. The following sections explain each procedure:

• Using the CLI to Enable a Backbone Router to Collect TMS
  
• Enabling the NDA to Collect TMS on a Backbone Router
  

1.    more system:/vfiles/tmstats_ascii

2.    Interpret the header and record information in the tmstats_ascii file.

Router# more system:/vfiles/tmstats_ascii
VERSION 1|ADDR 172.27.32.24|AGGREGATION TrafficMatrix.ascii|SYSUPTIME 41428|routerUTC 3104467160|NTP unsynchronized|DURATION 1|
p|10.1.0.0/16|242|1|50|2|100
p|172.27.32.0/22|242|0|0|0|0

1.    more system:/vfiles/tmsasinfo

2.    View the header and record information in the tmasinfo file.

Router# more system:/vfiles/tmsasinfo
 
VERSION 1|ADDR 10.10.10.10|AGGREGATION ASList.ascii|SYSUPTIME 619855|routerUTC 3334075555|DURATION 0
10.1.1.2/32|65535|192.168.1.0/24
This is an example of a tmsasinfo file. The example contains a header information and one record. The header information and each record begin on a separate line. A bar (|) separates consecutive fields within a header or record.

1.    show ip cef summary

2.    show ip cef interface - type number detail

Router# show ip cef summary
IP CEF with switching (Table Version 19), flags=0x0
  19 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 1
  19 leaves, 17 nodes, 19960 bytes, 58 inserts, 39 invalidations
  0 load sharing elements, 0 bytes, 0 references
  universal per-destination load sharing algorithm, id E3296D5B
  3(1) CEF resets, 0 revisions of existing leaves
  Resolution Timer: Exponential (currently 1s, peak 1s)
  0 in-place/0 aborted modifications
  refcounts:  4628 leaf, 4608 node
Adjacency Table has 7 adjacencies

Router# show ip cef summary
IP Distributed CEF with switching (Table Version 36), flags=0x0
  16 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 1
  19 leaves, 17 nodes, 19960 bytes, 39 inserts, 20 invalidations
  0 load sharing elements, 0 bytes, 0 references
  universal per-destination load sharing algorithm, id E3296D5B
  2(0) CEF resets, 0 revisions of existing leaves
  Resolution Timer: Exponential (currently 1s, peak 1s)
  0 in-place/0 aborted modifications
  refcounts:  4628 leaf, 4608 node

Router# show ip cef ethernet 0/0 detail
IP Distributed CEF with switching (Table Version 136808) 
 45800 routes, 8 unresolved routes (0 old, 8 new) 
 45800 leaves, 2868 nodes, 8444360 bytes,
 136808 inserts, 91008 invalidations 
 1 load sharing elements, 208 bytes, 1 references 
 1 CEF resets, 1 revisions of existing leaves 
 refcounts: 527343 leaf, 465638 node
 172.29.233.33/32, version 7417, cached adjacency 172.29.233.33 
 0 packets, 0 bytes, 
   Adjacency-prefix
   via 172.29.233.33, Ethernet0/0, 0 dependencies 
 next hop 172.29.233.33, Ethernet0/0
   valid cached adjacency
 0 packets, 0 bytes switched through the prefix
 tmstats: external 0 packets, 0 bytes
      internal 0 packets, 0 bytes