THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED "AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2012 Cisco Systems, Inc. All rights reserved.

IP Application Services Configuration Guide, Cisco IOS Release 15.2S

- Configuring Enhanced Object Tracking

- Finding Feature Information

- Restrictions for Enhanced Object Tracking

- Information About Enhanced Object Tracking

- Feature Design of Enhanced Object Tracking

- Interface State Tracking

- Scaled Route Metrics

- IP SLA Operation Tracking

- Enhanced Object Tracking and Embedded Event Manager

- Benefits of Enhanced Object Tracking

- How to Configure Enhanced Object Tracking

- Tracking the Line-Protocol State of an Interface

- Tracking the IP-Routing State of an Interface

- Tracking IP-Route Reachability

- Tracking the Threshold of IP-Route Metrics

- Tracking the State of an IP SLAs Operation

- Tracking the Reachability of an IP SLAs IP Host

- Configuring a Tracked List and Boolean Expression

- Configuring a Tracked List and Threshold Weight

- Configuring a Tracked List and Threshold Percentage

- Configuring Track List Defaults

- Configuration Examples for Enhanced Object Tracking

- Example: Interface Line Protocol

- Example: Interface IP Routing

- Example: IP-Route Reachability

- Example: IP-Route Threshold Metric

- Example: IP SLAs IP Host Tracking

- Example: Boolean Expression for a Tracked List

- Example: Threshold Weight for a Tracked List

- Example: Threshold Percentage for a Tracked List

- Additional References

- Feature Information for Enhanced Object Tracking

- Glossary

- Configuring IP Services

- Finding Feature Information

- Information About IP Services

- Cisco IP Accounting

- How to Configure IP Services

- Configuring IP Accounting

- Configuration Examples for IP Services

- Example: Configuring IP Accounting

- Additional References

- Feature Information for IP Services

- Configuring IPv4 Broadcast Packet Handling

- Finding Feature Information

- Information About IPv4 Broadcast Packet Handling

- IP Unicast Address

- IP Broadcast Address

- IP Directed Broadcast Address

- IP Directed Broadcasts

- IP Multicast Addresses

- Early IP Implementations

- DHCP and IPv4 Broadcast Packets

- UDP Broadcast Packet Forwarding

- UDP Broadcast Packet Flooding

- IP Broadcast Flooding Acceleration

- Default UDP Port Numbers

- Default IP Broadcast Address

- UDP Broadcast Packet Case Study

- UDP Broadcast Packet Forwarding

- UDP Broadcast Packet Flooding

- How to Configure IP Broadcast Packet Handling

- Enabling IP Directed Broadcasts Without an Access List

- Enabling IP Directed Broadcasts with an Access List

- Enabling Forwarding of UDP Broadcast Packets to a Specific Host

- Enabling Forwarding of UDP Broadcast Packets to a Range of Hosts

- Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers Without Nonvolatile Memory

- Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers with Nonvolatile Memory

- Changing the IP Broadcast Address to Any IP Address on One or More Interfaces in a Router

- Configuring UDP Broadcast Packet Flooding

- Configuration Examples for IP Broadcast Packet Handling

- Example: Enabling IP Directed Broadcasts with an Access List

- Example: Configuring UDP Broadcast Packet Flooding

- Additional References

- Feature Information for IPv4 Broadcast Packet Handling

- Configuring TCP

- Finding Feature Information

- Prerequisites for TCP

- Information About TCP

- TCP Services

- TCP Connection Establishment

- TCP Connection Attempt Time

- TCP Selective Acknowledgment

- TCP Time Stamp

- TCP Maximum Read Size

- TCP Path MTU Discovery

- TCP Sliding Window

- TCP Outgoing Queue Size

- TCP MSS Adjustment

- How to Configure TCP

- Configuring the MSS Value and MTU for Transient TCP SYN Packets

- Configuration Examples for TCP

- Example: Configuring the TCP MSS Adjustment

- Additional References

- Feature Information for TCP

- Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Finding Feature Information

- Prerequisites for UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Information About UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Benefits of the UDP Forwarding Support for Virtual Router Groups Feature

- How to Configure UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Configuration Examples for UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Example: Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Additional References

- Feature Information for UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Configuring WCCP

- Finding Feature Information

- Prerequisites for WCCP

- Restrictions for WCCP

- Information About WCCP

- WCCP Overview

- Layer 2 Forwarding Redirection and Return

- Hardware Acceleration

- WCCPv1 Configuration

- WCCPv2 Configuration

- WCCPv2 Support for Services Other Than HTTP

- WCCPv2 Support for Multiple Routers

- WCCPv2 MD5 Security

- WCCPv2 Web Cache Packet Return

- WCCPv2 Load Distribution

- WCCP Bypass Packets

- WCCP Service Groups

- WCCP--Check All Services

- WCCP Interoperability with NAT

- WCCP Troubleshooting Tips

- How to Configure WCCP

- Configuring WCCP

- Configuring Closed Services

- Registering a Router to a Multicast Address

- Using Access Lists for a WCCP Service Group

- Enabling WCCP Interoperability with NAT

- Verifying and Monitoring WCCP Configuration Settings

- Configuration Examples for WCCP

- Example: Changing the Version of WCCP on a Router

- Example: Configuring a General WCCPv2 Session

- Example: Setting a Password for a Router and Content Engines

- Example: Configuring a Web Cache Service

- Example: Running a Reverse Proxy Service

- Example: Registering a Router to a Multicast Address

- Example: Using Access Lists

- Example: WCCP Outbound ACL Check Configuration

- Example: Verifying WCCP Settings

- Example: Enabling WCCP Interoperability with NAT

- Additional References

- Feature Information for WCCP

Configuring Enhanced Object Tracking

Before the introduction of the Enhanced Object Tracking feature, the Hot Standby Router Protocol (HSRP) had a simple tracking mechanism that allowed you to track the interface line-protocol state only. If the line-protocol state of the interface went down, the HSRP priority of the router was reduced, allowing another HSRP router with a higher priority to become active.

The Enhanced Object Tracking feature separates the tracking mechanism from HSRP and creates a separate standalone tracking process that can be used by other Cisco IOS processes and HSRP. This feature allows tracking of other objects in addition to the interface line-protocol state.

A client process such as HSRP, Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP), can register its interest in tracking objects and then be notified when the tracked object changes state.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Restrictions for Enhanced Object Tracking

Enhanced Object Tracking is not stateful switchover (SSO)-aware and cannot be used with Hot Standby Routing Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP) in SSO mode.

Information About Enhanced Object Tracking

- Feature Design of Enhanced Object Tracking

- Interface State Tracking

- Scaled Route Metrics

- IP SLA Operation Tracking

- Enhanced Object Tracking and Embedded Event Manager

- Benefits of Enhanced Object Tracking

Feature Design of Enhanced Object Tracking

The Enhanced Object Tracking feature provides complete separation between the objects to be tracked and the action to be taken by a client when a tracked object changes. Thus, several clients such as HSRP, VRRP, or GLPB can register their interest with the tracking process, track the same object, and each take different action when the object changes.

Each tracked object is identified by a unique number that is specified on the tracking CLI. Client processes use this number to track a specific object.

The tracking process periodically polls the tracked objects and notes any change of value. The changes in the tracked object are communicated to interested client processes, either immediately or after a specified delay. The object values are reported as either up or down.

You can configure a combination of tracked objects in a list and a flexible method for combining objects using Boolean logic. This functionality includes the following capabilities:

- Threshold--The tracked list can be configured to use a weight or percentage threshold to measure the state of the list. Each object in a tracked list can be assigned a threshold weight. The state of the tracked list is determined by whether the threshold has been met.

- Boolean "and" function--When a tracked list has been assigned a Boolean "and" function, each object defined within a subset must be in an up state so that the tracked object can become up.

- Boolean "or" function--When the tracked list has been assigned a Boolean "or" function, at least one object defined within a subset must be in an up state so that the tracked object can become up.

With CSCtg75700, a maximum of 1000 objects can be tracked. Although 1000 tracked objects can be configured, each tracked object uses CPU resources. The amount of available CPU resources on a router depends on variables such as traffic load and how other protocols are configured and run. The ability to use 1000 tracked objects depends on the available CPU. Testing should be conducted on site to ensure that the service works under the specific site traffic conditions.

Interface State Tracking

An IP-routing object is considered up when the following criteria exist:

- IP routing is enabled and active on the interface.

- The interface line-protocol state is up.

- The interface IP address is known. The IP address is configured or received through Dynamic Host Configuration Protocol (DHCP) or IP Control Protocol (IPCP) negotiation.

Interface IP routing will go down when one of the following criteria exists:

- IP routing is disabled globally.

- The interface line-protocol state is down.

- The interface IP address is unknown. The IP address is not configured or received through DHCP or IPCP negotiation.

Tracking the IP-routing state of an interface using the track interface ip routing command can be more useful in some situations than just tracking the line-protocol state using the track interface line-protocol command, especially on interfaces for which IP addresses are negotiated. For example, on a serial interface that uses the PPP, the line protocol could be up (link control protocol [LCP] negotiated successfully), but IP could be down (IPCP negotiation failed).

The track interface ip routing command supports the tracking of an interface with an IP address acquired through any of the following methods:

- Conventional IP address configuration

- PPP/IPCP

- DHCP

- Unnumbered interface

You can configure Enhanced Object Tracking to consider the carrier-delay timer when tracking the IP-routing state of an interface by using the carrier-delay command in tracking configuration mode.

Scaled Route Metrics

The track ip route command enables tracking of a route in the routing table. If a route exists in the table, the metric value is converted into a number. To provide a common interface to tracking clients, normalize route metric values to the range from 0 to 255, where 0 is connected and 255 is inaccessible. Scaled metrics can be tracked by setting thresholds. Up and down state notification occurs when the thresholds are crossed. The resulting value is compared against threshold values to determine the tracking state as follows:

- State is up if the scaled metric for that route is less than or equal to the up threshold.

- State is down if the scaled metric for that route is greater than or equal to the down threshold.

Tracking uses a per-protocol configurable resolution value to convert the real metric to the scaled metric. The table below shows the default values used for the conversion. You can use the track resolution command to change the metric resolution default values.

Table 1

Metric Conversion

Route Type1

Metric Resolution

Static

10

Enhanced Interior Gateway Routing Protocol (EIGRP)

2560

Open Shortest Path First (OSPF)

1

Intermediate System-to-Intermediate System (IS-IS)

10

1 RIP is scaled directly to the range from 0 to 255 because its maximum metric is less than 255.

For example, a change in 10 in an IS-IS metric results in a change of 1 in the scaled metric. The default resolutions are designed so that approximately one 2-Mbps link in the path will give a scaled metric of 255.

Scaling the very large metric ranges of EIGRP and IS-IS to a 0 to 255 range is a compromise. The default resolutions will cause the scaled metric to exceed the maximum limit with a 2-Mb/s link. However, this scaling allows a distinction between a route consisting of three Fast-Ethernet links and a route consisting of four Fast-Ethernet links.

IP SLA Operation Tracking

Object tracking of IP Service Level Agreements (SLAs) operations allows tracking clients to track the output from IP SLAs objects and use the provided information to trigger an action.

Cisco IOS IP SLAs is a network performance measurement and diagnostics tool that uses active monitoring. Active monitoring is the generation of traffic in a reliable and predictable manner to measure network performance. Cisco IOS software uses IP SLAs to collect real-time metrics such as response time, network resource availability, application performance, jitter (interpacket delay variance), connect time, throughput, and packet loss.

These metrics can be used for troubleshooting, for proactive analysis before problems occur, and for designing network topologies.

Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code can return OK, OverThreshold, and several other return codes. Different operations can have different return-code values, so only values common to all operation types are used.

Two aspects of an IP SLAs operation can be tracked: state and reachability. The difference between these aspects is the acceptance of the OverThreshold return code. The table below shows the state and reachability aspects of IP SLAs operations that can be tracked.

Table 2

Comparison of State and Reachability Operations

Tracking

Return Code

Track State

State

OK

(all other return codes)

Up

Down

Reachability

OK or OverThreshold

(all other return codes)

Up

Down

Enhanced Object Tracking and Embedded Event Manager

Enhanced Object Tracking (EOT) is now integrated with Embedded Event Manager (EEM) to allow EEM to report on status change of a tracked object and to allow EOT to track EEM objects. A new type of tracking object--a stub object--is created. The stub object can be modified by an external process through a defined Application Programming Interface (API). See the Embedded Event Manager Overview document in the Cisco IOS XENetwork Management Configuration Guide for more information on how EOT works with EEM.

Benefits of Enhanced Object Tracking

- Increases the availability and speed of recovery of a network.

- Decreases the number of network outages and their duration.

- Enables client processes such as VRRP and GLBP to track objects individually or as a list of objects. Prior to the introduction of this functionality, the tracking process was embedded within HSRP.

How to Configure Enhanced Object Tracking

- Tracking the Line-Protocol State of an Interface

- Tracking the IP-Routing State of an Interface

- Tracking IP-Route Reachability

- Tracking the Threshold of IP-Route Metrics

- Tracking the State of an IP SLAs Operation

- Tracking the Reachability of an IP SLAs IP Host

- Configuring a Tracked List and Boolean Expression

- Configuring a Tracked List and Threshold Weight

- Configuring a Tracked List and Threshold Percentage

- Configuring Track List Defaults

Tracking the Line-Protocol State of an Interface

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track timer interface {seconds | msec milliseconds}

4.   track object-number interface type number line-protocol

5.   carrier-delay

6.   delay {up seconds [down [seconds] | [up seconds] down seconds]}

7.   end

8.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track timer interface {seconds | msec milliseconds}

(Optional) Specifies the interval in which the tracking process polls the tracked object.

- The default interval that the tracking process polls interface objects is 1 second.

Note

All polling frequencies can be configured down to 500 milliseconds, overriding the minimum 1-second interval configured using the msec keyword and milliseconds argument.

Example:

Device(config)# track timer interface 5

Step 4 track object-number interface type number line-protocol

Tracks the line-protocol state of an interface and enters tracking configuration mode.

Example:

Device(config)# track 3 interface ethernet 0/1 line-protocol

Step 5 carrier-delay

(Optional) Enables EOT to consider the carrier-delay timer when tracking the status of an interface.

Example:

Device(config-track)# carrier-delay

Step 6 delay {up seconds [down [seconds] | [up seconds] down seconds]}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 30

Step 7 end

Exits to privileged EXEC mode.

Example:

Device(config-track)# end

Step 8 show track object-number

(Optional) Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 3

Example

The following example shows the state of the line protocol on an interface when it is tracked:

Device# show track 3

Track 3

Interface Ethernet0/1 line-protocol

Line protocol is Up

1 change, last change 00:00:05

Tracked by:

HSRP Ethernet0/3 1

Tracking the IP-Routing State of an Interface

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track timer interface {seconds | msec milliseconds}

4.   track object-number interface type number ip routing

5.   carrier-delay

6.   delay {up seconds [down seconds] | [up seconds] down seconds}

7.   end

8.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track timer interface {seconds | msec milliseconds}

(Optional) Specifies the interval in which the tracking process polls the tracked object.

- The default interval that the tracking process polls interface objects is 1 second.

Note

All polling frequencies can be configured down to 500 milliseconds, overriding the minimum 1-second interval configured using the msec keyword and milliseconds argument.

Example:

Device(config)# track timer interface 5

Step 4 track object-number interface type number ip routing

Tracks the IP-routing state of an interface and enters tracking configuration mode.

- IP-route tracking tracks an IP route in the routing table and the ability of an interface to route IP packets.

Example:

Device(config)# track 1 interface ethernet 0/1 ip routing

Step 5 carrier-delay

(Optional) Enables EOT to consider the carrier-delay timer when tracking the status of an interface.

Example:

Device(config-track)# carrier-delay

Step 6 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 30

Step 7 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Step 8 show track object-number

Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 1

Example

The following example shows the state of IP routing on an interface when it is tracked:

Device# show track 1

Track 1

Interface Ethernet0/1 ip routing

IP routing is Up

1 change, last change 00:01:08

Tracked by:

HSRP Ethernet0/3 1

Tracking IP-Route Reachability

Perform this task to track the reachability of an IP route. A tracked object is considered up when a routing table entry exists for the route and the route is accessible.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track timer ip route {seconds | msec milliseconds}

4.   track object-number ip route ip-address/prefix-length reachability

5.   delay {up seconds [down seconds] | [up seconds] down seconds}

6.   ip vrf vrf-name

7.   end

8.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track timer ip route {seconds | msec milliseconds}

(Optional) Specifies the interval in which the tracking process polls the tracked object.

- The default interval that the tracking process polls IP-route objects is 15 seconds.

Note

All polling frequencies can be configured down to 500 milliseconds, overriding the minimum 1-second interval configured using the msec keyword and milliseconds argument.

Example:

Device(config)# track timer ip route 20

Step 4 track object-number ip route ip-address/prefix-length reachability

Tracks the reachability of an IP route and enters tracking configuration mode.

Example:

Device(config)# track 4 ip route 10.16.0.0/16 reachability

Step 5 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 30

Step 6 ip vrf vrf-name

(Optional) Configures a VPN routing and forwarding (VRF) table.

Example:

Device(config-track)# ip vrf VRF2

Step 7 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Step 8 show track object-number

(Optional) Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 4

Example

The following example shows the state of the reachability of an IP route when it is tracked:

Device# show track 4

Track 4

IP route 10.16.0.0 255.255.0.0 reachability

Reachability is Up (RIP)

1 change, last change 00:02:04

First-hop interface is Ethernet0/1

Tracked by:

HSRP Ethernet0/3 1

Tracking the Threshold of IP-Route Metrics

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track timer ip route {seconds | msec milliseconds}

4.   track resolution ip route {eigrp | isis | ospf | static} resolution-value

5.   track object-number ip route ip-address/prefix-length metric threshold

6.   delay {up seconds [down seconds] | [up seconds] down seconds}

7.   ip vrf vrf-name

8.   threshold metric {up number [down number] | down number [up number ]}

9.   end

10.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track timer ip route {seconds | msec milliseconds}

(Optional) Specifies the interval in which the tracking process polls the tracked object.

- The default interval that the tracking process polls IP-route objects is 15 seconds.

Note

All polling frequencies can be configured down to 500 milliseconds, overriding the minimum 1-second interval configured using the msec keyword and milliseconds argument.

Example:

Device(config)# track timer ip route 20

Step 4 track resolution ip route {eigrp | isis | ospf | static} resolution-value

(Optional) Specifies resolution parameters for a tracked object.

- Use this command to change the default metric resolution values.

Example:

Device(config)# track resolution ip route eigrp 300

Step 5 track object-number ip route ip-address/prefix-length metric threshold

Tracks the scaled metric value of an IP route to determine if it is above or below a threshold and enters tracking configuration mode.

- The default down value is 255, which equates to an inaccessible route.

- The default up value is 254.

Example:

Device(config)# track 6 ip route 10.16.0.0/16 metric threshold

Step 6 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 30

Step 7 ip vrf vrf-name

(Optional) Configures a VRF table.

Example:

Device(config-track)# ip vrf VRF1

Step 8 threshold metric {up number [down number] | down number [up number ]}

(Optional) Sets a metric threshold other than the default value.

Example:

Device(config-track)# threshold metric up 254 down 255

Step 9 end

Exits to privileged EXEC mode.

Example:

Device(config-track)# end

Step 10 show track object-number

(Optional) Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 6

Example

The following example shows the metric threshold of an IP route when it is tracked:

Device# show track 6

Track 6

IP route 10.16.0.0 255.255.0.0 metric threshold

Metric threshold is Up (RIP/6/102)

1 change, last change 00:00:08

Metric threshold down 255 up 254

First-hop interface is Ethernet0/1

Tracked by:

HSRP Ethernet0/3 1

Tracking the State of an IP SLAs Operation

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track object-number ip sla operation-number state

4.   delay {up seconds [down seconds | [up seconds] down seconds}

5.   end

6.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track object-number ip sla operation-number state

Tracks the state of an IP SLAs object and enters tracking configuration mode.

With CScsf08092, the track rtr command was replaced by the track ip sla command.

Example:

Device(config)# track 2 ip sla 4 state

Step 4 delay {up seconds [down seconds | [up seconds] down seconds}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 60 down 30

Step 5 end

Exits to privileged EXEC mode.

Example:

Device(config-track)# end

Step 6 show track object-number

(Optional) Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 2

Example

The following example shows the state of the IP SLAs tracking:

Device# show track 2

Track 2

IP SLA 1 state

State is Down

1 change, last change 00:00:47

Latest operation return code: over threshold

Latest RTT (millisecs) 4

Tracked by:

HSRP Ethernet0/1 3

Tracking the Reachability of an IP SLAs IP Host

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track object-number ip sla operation-number reachability

4.   delay {up seconds [down seconds] | [up seconds] downseconds}

5.   end

6.   show track object-number

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track object-number ip sla operation-number reachability

Tracks the reachability of an IP SLAs IP host and enters tracking configuration mode.

Note

With CScsf08092, the track rtr command was replaced by the track ip sla command.

Example:

Device(config)# track 2 ip sla 4 reachability

Step 4 delay {up seconds [down seconds] | [up seconds] downseconds}

(Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.

Example:

Device(config-track)# delay up 30 down 10

Step 5 end

Exits to privileged EXEC mode.

Example:

Device(config-track)# end

Step 6 show track object-number

(Optional) Displays tracking information.

- Use this command to verify the configuration.

Example:

Device# show track 3

Example

The following example shows whether the route is reachable:

Device# show track 3

Track 3

IP SLA 1 reachability

Reachability is Up

1 change, last change 00:00:47

Latest operation return code: over threshold

Latest RTT (millisecs) 4

Tracked by:

HSRP Ethernet0/1 3

Configuring a Tracked List and Boolean Expression

Perform this task to configure a tracked list of objects and a Boolean expression to determine the state of the list. A tracked list contains one or more objects. The Boolean expression enables two types of calculations by using either "and" or "or" operators. For example, when you configure tracking for two interfaces using the "and" operator up means that both interfaces are up, and down means that either interface is down.

You may configure a tracked list state to be measured using a weight or percentage threshold. See the Configuring a Tracked List and Threshold Weight section and the Configuring a Tracked List and Threshold Percentage section.

Before You Begin

An object must exist before it can be added to a tracked list.

Note

The "not" operator is specified for one or more objects and negates the state of the object.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track track-number list boolean {and | or}

4.   object object-number [not]

5.   delay {up seconds [down seconds] | [up seconds] down seconds}

6.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track track-number list boolean {and | or}

Configures a tracked list object and enters tracking configuration mode.

Example:

Device(config)# track 100 list boolean and

Step 4 object object-number [not]

Specifies the object to be tracked.

- Theobject-number argument has a valid range from 1 to 500. There is no default. The optional not keyword negates the state of the object.

Note

The example means that when object 3 is up, the tracked list detects object 3 as down.

Example:

Device(config-track)# object 3 not

Step 5 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a tracking delay in seconds between up and down states.

Example:

Device(config-track)# delay up 3

Step 6 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Configuring a Tracked List and Threshold Weight

Perform this task to configure a list of tracked objects, to specify that weight be used as the threshold, and to configure a weight for each of the objects in the list of tracked objects. A tracked list contains one or more objects. Enhanced object tracking uses a threshold weight to determine the state of each object by comparing the total weight of all objects that are up against a threshold weight for each object.

You can also configure a tracked list state to be measured using a Boolean calculation or threshold percentage. See the Configuring a Tracked List and Boolean Expression section and the Configuring a Tracked List and Threshold Percentage section.

Before You Begin

An object must exist before it can be added to a tracked list.

Note

You cannot use the Boolean "not" operator in a weight or percentage threshold list.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track track-number list threshold weight

4.   object object-number [weight weight-number]

5.   threshold weight {up number down number | up number | down number}

6.   delay {up seconds [down seconds] | [up seconds] down seconds}

7.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track track-number list threshold weight

Configures a tracked list object and enters tracking configuration mode. The keywords are as follows:

- threshold --Specifies that the state of the tracked list is based on a threshold.

- weight --Specifies that the threshold is based on a specified weight.

Example:

Device(config)# track 100 list threshold weight

Step 4 object object-number [weight weight-number]

Specifies the object to be tracked. The object-number argument has a valid range from 1 to 500. There is no default. The optional weight keyword specifies a threshold weight for each object.

Example:

Device(config-track)# object 3 weight 30

Step 5 threshold weight {up number down number | up number | down number}

Specifies the threshold weight.

- up number --Valid range is from 1 to 255.

- down number--Range depends upon what you select for the up keyword. For example, if you configure 25 for up, you will see a range from 0 to 24 for down.

Example:

Device(config-track)# threshold weight up 30

Step 6 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a tracking delay in seconds between up and down states.

Example:

Device(config-track)# delay up 3

Step 7 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Configuring a Tracked List and Threshold Percentage

Perform this task to configure a tracked list of objects, to specify that a percentage will be used as the threshold, and to specify a percentage for each object in the list. A tracked list contains one or more objects. Enhanced object tracking uses the threshold percentage to determine the state of the list by comparing the assigned percentage of each object to the list.

You may also configure a tracked list state to be measured using a Boolean calculation or threshold weight. See the Configuring a Tracked List and Boolean Expression section and the Configuring a Tracked List and Threshold Weight section.

Note

You cannot use the Boolean "not" operator in a weight or percentage threshold list.

Before You Begin

An object must exist before it can be added to a tracked list.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track track-number list threshold percentage

4.   object object-number

5.   threshold percentage {up number [down number ] | down number [up number]}

6.   delay {up seconds [down seconds] | [up seconds] down seconds}

7.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track track-number list threshold percentage

Configures a tracked list object and enters tracking configuration mode. The keywords are as follows:

- threshold --Specifies that the state of the tracked list is based on a threshold.

- percentage --Specifies that the threshold is based on a percentage.

Example:

Device(config)# track 100 list threshold percentage

Step 4 object object-number

Specifies the object to be tracked.

- The object-number argument has a valid range from 1 to 500. There is no default.

Example:

Device(config-track)# object 3

Step 5 threshold percentage {up number [down number ] | down number [up number]}

Specifies the threshold percentage.

- up number--Valid range is from 1 to 100.

- down number --Range depends upon what you have selected for the up keyword. For example, if you specify 25 as up, a range from 26 to 100 is displayed for the down keyword.

Example:

Device(config-track)# threshold percentage up 30

Step 6 delay {up seconds [down seconds] | [up seconds] down seconds}

(Optional) Specifies a tracking delay in seconds between up and down states.

Example:

Device(config-track)# delay up 3

Step 7 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Configuring Track List Defaults

Perform this task to configure a default delay value for a tracked list, a default object, and default threshold parameters for a tracked list.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   track track-number

4.   default {delay | object object-number | threshold percentage}

5.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 track track-number

Enters tracking configuration mode.

Example:

Device(config)# track 3

Step 4 default {delay | object object-number | threshold percentage}

Specifies a default delay value for a tracked list, a default object, and default threshold parameters for a tracked list.

- delay --Reverts to the default delay.

- object object-number--Specifies a default object for the track list. The valid range is from 1 to 1000.

- threshold percentage--Specifies a default threshold percentage.

Example:

Device(config-track)# default delay

Step 5 end

Returns to privileged EXEC mode.

Example:

Device(config-track)# end

Configuration Examples for Enhanced Object Tracking

- Example: Interface Line Protocol

- Example: Interface IP Routing

- Example: IP-Route Reachability

- Example: IP-Route Threshold Metric

- Example: IP SLAs IP Host Tracking

- Example: Boolean Expression for a Tracked List

- Example: Threshold Weight for a Tracked List

- Example: Threshold Percentage for a Tracked List

Example: Interface Line Protocol

In the following example, the tracking process is configured to track the line-protocol state of GigabitEthernet interface 1/0/0. HSRP on GigabitEthernet interface 0/0/0 then registers with the tracking process to be informed of any changes to the line-protocol state of GigabitEthernet interface 1/0/0. If the line protocol on GigabitEthernet interface 1/0/0 goes down, the priority of the HSRP group is reduced by 10.

Router A Configuration

Device(config)# track 100 interface GigabitEthernet1/0/0 line-protocol

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.0.21 255.255.0.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.0.1

Device(config-if)# standby 1 priority 110

Device(config-if)# standby 1 track 100 decrement 10

Router B Configuration

Device(config)# track 100 interface GigabitEthernet1/0/0 line-protocol

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.0.22 255.255.0.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.0.1

Device(config-if)# standby 1 priority 105

Device(config-if)# standby 1 track 100 decrement 10

Example: Interface IP Routing

In the following example, the tracking process is configured to track the IP-routing capability of GigabitEthernet interface 1/0/0. HSRP on GigabitEthernet interface 0/0/0 then registers with the tracking process to be informed of any changes to the IP-routing state of GigabitEthernet interface 1/0/0. If the IP-routing state on GigabitEthernet interface 1/0/0 goes down, the priority of the HSRP group is reduced by 10.

If both serial interfaces are operational, Router A will be the HSRP active router because it has the higher priority. However, if IP on GigabitEthernet interface 1/0/0 in Router A fails, the HSRP group priority will be reduced and Router B will take over as the active router, thus maintaining a default virtual gateway service to hosts on the 10.1.0.0 subnet.

See the figure below for a sample topology.

Figure 1

Topology for IP-Routing Support

Router A Configuration

Device(config)# track 100 interface GigabitEthernet1/0/0 ip routing

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.0.21 255.255.0.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.0.1

Device(config-if)# standby 1 priority 110

Device(config-if)# standby 1 track 100 decrement 10

Router B Configuration

Device(config)# track 100 interface GigabitEthernet1/0/0 ip routing

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.0.22 255.255.0.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.0.1

Device(config-if)# standby 1 priority 105

Device(config-if)# standby 1 track 100 decrement 10

Example: IP-Route Reachability

In the following example, the tracking process is configured to track the reachability of IP route 10.2.2.0/24:

Router A Configuration

Device(config)# track 100 ip route 10.2.2.0/24 reachability

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.1.21 255.255.255.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.1.1

Device(config-if)# standby 1 priority 110

Device(config-if)# standby 1 track 100 decrement 10

Router B Configuration

Device(config)# track 100 ip route 10.2.2.0/24 reachability

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.1.22 255.255.255.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.1.1

Device(config-if)# standby 1 priority 105

Device(config-if)# standby 1 track 100 decrement 10

Example: IP-Route Threshold Metric

In the following example, the tracking process is configured to track the threshold metric of IP route 10.2.2.0/24:

Router A Configuration

Device(config)# track 100 ip route 10.2.2.0/24 metric threshold

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.1.21 255.255.255.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.1.1

Device(config-if)# standby 1 priority 110

Device(config-if)# standby 1 track 100 decrement 10

Router B Configuration

Device(config)# track 100 ip route 10.2.2.0/24 metric threshold

!

Device(config)# interface GigabitEthernet0/0/0

Device(config-if)# ip address 10.1.1.22 255.255.255.0

Device(config-if)# standby 1 preempt

Device(config-if)# standby 1 ip 10.1.1.1

Device(config-if)# standby 1 priority 105

Device(config-if)# standby 1 track 100 decrement 10

Example: IP SLAs IP Host Tracking

The following example shows how to configure IP host tracking for IP SLAs operation 1 prior to CSCsf08092:

Device(config)# ip sla 1

Device(config-ip-sla)# icmp-echo 10.51.12.4

Device(config-ip-sla-echo)# timeout 1000

Device(config-ip-sla-echo)# threshold 2

Device(config-ip-sla-echo)# frequency 3

Device(config-ip-sla-echo)# request-data-size 1400

Device(config-ip-sla-echo)# exit

Device(config)# ip sla schedule 1 start-time now life forever

Device(config-ip-sla)# track 2 rtr 1 state

Device(config-ip-sla)# exit

Device(config)# track 3 rtr 1 reachability

Device(config-track)# exit

Device(config)# interface ethernet0/1

Device(config-if)# ip address 10.21.0.4 255.255.0.0

Device(config-if)# no shutdown

Device(config-if)# standby 3 ip 10.21.0.10

Device(config-if)# standby 3 priority 120

Device(config-if)# standby 3 preempt

Device(config-if)# standby 3 track 2 decrement 10

Device(config-if)# standby 3 track 3 decrement 10

The following example shows how to configure IP host tracking for IP SLAs operation 1 prior to CSCsf08092:

Device(config)# ip sla 1

Device(config-ip-sla)# icmp-echo 10.51.12.4

Device(config-ip-sla-echo)# threshold 2

Device(config-ip-sla-echo)# timeout 1000

Device(config-ip-sla-echo)# frequency 3

Device(config-ip-sla-echo)# request-data-size 1400

Device(config-ip-sla-echo)# exit

Device(config)# ip sla schedule 1 start-time now life forever

Device(config)# track 2 ip sla 1 state

Device(config-track)# exit

Device(config)# track 3 ip sla 1 reachability

Device(config-track)# exit

Device(config)# interface ethernet0/1

Device(config-if)# ip address 10.21.0.4 255.255.0.0

Device(config-if)# no shutdown

Device(config-if)# standby 3 ip 10.21.0.10

Device(config-if)# standby 3 priority 120

Device(config-if)# standby 3 preempt

Device(config-if)# standby 3 track 2 decrement 10

Device(config-if)# standby 3 track 3 decrement 10

Example: Boolean Expression for a Tracked List

In the following example, a track list object is configured to track two GigabitEthernet interfaces when both interfaces are up and when either interface is down:

Device(config)# track 1 interface GigabitEthernet2/0/0 line-protocol

Device(config)# track 2 interface GigabitEthernet2/1/0 line-protocol

Device(config-track)# exit

Device(config)# track 100 list boolean and

Device(config-track)# object 1

Device(config-track)# object 2

In the following example, a track list object is configured to track two GigabitEthernet interfaces when either interface is up and when both interfaces are down:

Device(config)# track 1 interface GigabitEthernet2/0/0 line-protocol

Device(config)# track 2 interface GigabitEthernet2/1/0 line-protocol

Device(config-track)# exit

Device(config)# track 101 list boolean or

Device(config-track)# object 1

Device(config-track)# object 2

The following configuration example shows that tracked list 4 has two objects and one object state is negated (if the list is up, the list detects that object 2 is down):

Device(config)# track 4 list boolean and

Device(config-track)# object 1

Device(config-track)# object 2 not

Example: Threshold Weight for a Tracked List

In the following example, three GigabitEtherent interfaces in tracked list 100 are configured with a threshold weight of 20 each. The down threshold is configured to 0 and the up threshold is configured to 40:

Device(config)# track 1 interface GigabitEthernet2/0/0 line-protocol

Device(config)# track 2 interface GigabitEthernet2/1/0 line-protocol

Device(config)# track 3 interface GigabitEthernet2/2/0 line-protocol

Device(config-track)# exit

Device(config)# track 100 list threshold weight

Device(config-track)# object 1 weight 20

Device(config-track)# object 2 weight 20

Device(config-track)# object 3 weight 20

Device(config-track)# threshold weight  up 40 down 0

In the example above the track-list object goes down only when all three serial interfaces go down, and comes up again only when at least two interfaces are up (because 20 + 20 >= 40). The advantage of this configuration is that it prevents the track-list object from coming up if two interfaces are down and the third interface is flapping.

The following configuration example shows that if object 1 and object 2 are down, then track list 4 is up, because object 3 satisfies the up threshold value of up 30. But, if object 3 is down, both objects 1 and 2 need to be up in order to satisfy the threshold weight.

Device(config)# track 4 list threshold weight

Device(config-track)# object 1 weight 15

Device(config-track)# object 2 weight 20

Device(config-track)# object 3 weight 30

Device(config-track)# threshold weight up 30 down 10

This configuration may be useful to you if you have two small bandwidth connections (represented by object 1 and 2) and one large bandwidth connection (represented by object 3). Also the down 10 value means that once the tracked object is up, it will not go down until the threshold value is lower or equal to 10, which in this example means that all connections are down.

Example: Threshold Percentage for a Tracked List

In the following example, four GigabitEthernet interfaces in track list 100 are configured for an up threshold percentage of 75. The track list is up when 75 percent of the interfaces are up and down when fewer than 75 percent of the interfaces are up.

Device(config)# track 1 interface GigabitEthernet2/0/0 line-protocol

Device(config)# track 2 interface GigabitEthernet2/1/0 line-protocol

Device(config)# track 3 interface GigabitEthernet2/2/0 line-protocol

Device(config)# track 4 interface GigabitEthernet2/3/0 line-protocol

Device(config-track)# exit

Device(config)# track 100 list threshold percentage

Device(config-track)# object 1

Device(config-track)# object 2

Device(config-track)# object 3

Device(config-track)# object 4

Device(config-track)# threshold percentage up 75

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Embedded Event Manager

Embedded Event Manager Overview

HSRP concepts and configuration tasks

Configuring HSRP

GLBP concepts and configuration tasks

Configuring GLBP

IP SLAs commands

Cisco IOS IP SLAs Command Reference

VRRP concepts and configuration tasks

Configuring VRRP

GLBP, HSRP, and VRRP commands

Cisco IOS IP Application Services Command Reference

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

--

MIBs

MIBs

MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

RFCs

RFCs

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for Enhanced Object Tracking

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 3

Feature Information for Enhanced Object Tracking

Feature Name

Releases

Feature Configuration Information

Enhanced Tracking Support

15.2(1)S

The Enhanced Tracking Support feature separates the tracking mechanism from HSRP and creates a separate standalone tracking process that can be used by other Cisco IOS processes as well as HSRP. This feature allows tracking of other objects in addition to the interface line-protocol state.

The following commands were introduced or modified by this feature: debug track, delay tracking,ip vrf, show track, standby track, threshold metric, track interface,track ip route, track timer.

FHRP--Enhanced Object Tracking Integration with Embedded Event Manager

15.2(1)S

EOT is now integrated with EEM to allow EEM to report on a status change of a tracked object and to allow EOT to track EEM objects.

The following commands were introduced or modified by this feature: action track read, action track set, default-state,event resource, event rf,event track, show track, track stub.

FHRP--Enhanced Object Tracking of IP SLAs Operations

15.2(1)S

This feature enables First Hop Redundancy Protocols (FHRPs) and other Enhanced Object Tracking (EOT) clients to track the output from IP SLAs objects and use the provided information to trigger an action.

The following command was introduced by this feature: track rtr.

FHRP--Object Tracking List

15.2(1)S

This feature enhances the tracking capabilities to enable the configuration of a combination of tracked objects in a list, and a flexible method of combining objects using Boolean logic.

The following commands were introduced or modified by this feature: show track, threshold percentage, threshold weight, track list, track resolution.

Glossary

DHCP--Dynamic Host Configuration Protocol. DHCP is a protocol that delivers IP addresses and configuration information to network clients.

GGSN--Gateway GPRS Support Node. A wireless gateway that allows mobile cell phone users to access the public data network (PDN) or specified private IP networks. The GGSN function is implemented on the Cisco routers.

GLBP--Gateway Load Balancing Protocol. Provides automatic router backup for IP hosts that are configured with a single default gateway on an IEEE 802.3 LAN. Multiple first-hop routers on the LAN combine to offer a single virtual first-hop IP router while sharing the IP packet forwarding load. Other routers on the LAN may act as redundant (GLBP) routers that will become active if any of the existing forwarding routers fail.

GPRS--General Packet Radio Service. A 2.5G mobile communications technology that enables mobile wireless service providers to offer their mobile subscribers with packet-based data services over GSM networks.

GSM network--Global System for Mobile Communications network. A digital cellular technology that is used worldwide, predominantly in Europe and Asia. GSM is the world's leading standard in digital wireless communications.

Home Agent--A Home Agent is a router on the home network of the Mobile Node (MN) that maintains an association between the home IP address of the MN and its care-of address, which is the current location of the MN on a foreign or visited network. The HA redirects packets by tunneling them to the MN while it is away from the home network.

HSRP--Hot Standby Router Protocol. Provides high network availability and transparent network topology changes. HSRP creates a Hot Standby router group with a lead router that services all packets sent to the Hot Standby address. The lead router is monitored by other routers in the group, and if it fails, one of these standby routers inherits the lead position and the Hot Standby group address.

IPCP--IP Control Protocol. The protocol used to establish and configure IP over PPP.

LCP--Link Control Protocol. The protocol used to establish, configure, and test data-link connections for use by PPP.

PDSN--Packet Data Serving Node. The Cisco PDSN is a standards-compliant, wireless gateway that enables packet data services in a Code Division Multiplex Access (CDMA) environment. Acting as an access gateway, the Cisco PDSN provides simple IP and Mobile IP access, foreign-agent support, and packet transport for Virtual Private Networks (VPN).

PPP--Point-to-Point Protocol. Provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. PPP is most commonly used for dial-up Internet access. Its features include address notification, authentication via CHAP or PAP, support for multiple protocols, and link monitoring.

VRF--VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a provider edge router.

VRRP--Virtual Router Redundancy Protocol. Eliminates the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router that controls the IP addresses associated with a virtual router is called the master, and forwards packets sent to these IP addresses. The election process provides dynamic failover in the forwarding responsibility should the master become unavailable. Any of the virtual router IP addresses on a LAN can then be used as the default first-hop router by end hosts.

Configuring IP Services

This module describes how to configure optional IP services. For a complete description of the IP services commands in this chapter, refer to the Cisco IOS IP Application Services Command Reference. To locate documentation of other commands that appear in this module, use the master command list, or search online.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Information About IP Services

- Cisco IP Accounting

Cisco IP Accounting

Cisco IP accounting support provides basic IP accounting functions. By enabling IP accounting, users can see the number of bytes and packets switched through the Cisco IOS software on a source and destination IP address basis. Only transit IP traffic is measured and only on an outbound basis; traffic generated by the software or terminating in the software is not included in the accounting statistics. To maintain accurate accounting totals, the software maintains two accounting databases: an active and a checkpointed database.

Cisco IP accounting support also provides information identifying IP traffic that fails IP access lists. Identifying IP source addresses that violate IP access lists alerts you to possible attempts to breach security. The data also indicates that you should verify IP access list configurations. To make this functionality available to users, you must enable IP accounting of access list violations using the ip accounting access-violations interface configuration command. Users can then display the number of bytes and packets from a single source that attempted to breach security against the access list for the source destination pair. By default, IP accounting displays the number of packets that have passed access lists and were routed.

How to Configure IP Services

- Configuring IP Accounting

Configuring IP Accounting

To configure IP accounting, perform this task for each interface.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   ip accounting-threshold threshold

4.   ip accounting-list ip-address wildcard

5.   ip accounting-transits count

6.   interface type number

7.   ip accounting [access-violations] [output-packets]

8.   ip accounting mac-address {input | output}

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 ip accounting-threshold threshold

(Optional) Sets the maximum number of accounting entries to be created.

Example:

Router(config)# ip accounting-threshold 500

Step 4 ip accounting-list ip-address wildcard

(Optional) Filters accounting information for hosts.

Example:

Router(config)# ip accounting-list 192.31.0.0 0.0.255.255

Step 5 ip accounting-transits count

(Optional) Controls the number of transit records that will be stored in the IP accounting database.

Example:

Router(config)# ip accounting-transits 100

Step 6 interface type number

Specifies the interface and enters interface configuration mode.

Example:

Router(config)# interface GigabitEthernet 1/0/0

Step 7 ip accounting [access-violations] [output-packets]

Configures basic IP accounting.

- Use the optional access-violations keyword to enable IP accounting with the ability to identify IP traffic that fails IP access lists.

- Use the optional output-packets keyword to enable IP accounting based on the IP packets output on the interface.

Example:

Router(config-if)# ip accounting access-violations

Step 8 ip accounting mac-address {input | output}

(Optional) Configures IP accounting based on the MAC address of received (input) or transmitted (output) packets.

Example:

Router(config-if)# ip accounting mac-address output

Configuration Examples for IP Services

- Example: Configuring IP Accounting

Example: Configuring IP Accounting

The following example shows how to enable IP accounting based on the source and destination MAC address and based on IP precedence for received and transmitted packets:

Router# configure terminal

Router(config)# interface ethernet 0/5

Router(config-if)# ip accounting mac-address input

Router(config-if)# ip accounting mac-address output

Router(config-if)# ip accounting precedence input

Router(config-if)# ip accounting precedence output

The following example shows how to enable IP accounting with the ability to identify IP traffic that fails IP access lists and with the number of transit records that will be stored in the IP accounting database limited to 100:

Router# configure terminal

Router(config)# ip accounting-transits 100

Router(config)# interface ethernet 0/5

Router(config-if)# ip accounting output-packets

Router(config-if)# ip accounting access-violations

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

IP application services commands

Cisco IOS IP Application Services Command Reference

Standards and RFCs

Standard

Title

RFC 1256

ICMP Router Discovery Messages

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IP Services

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 4

Feature Information for IP Services

Feature Name

Releases

Feature Information

IP Precedence Accounting

15.2(1)S

The IP Precedence Accounting feature provides accounting information for IP traffic based on the precedence of any interface. This feature calculates the total packet and byte counts for an interface that receives or sends IP packets and sorts the results based on the IP precedence. This feature is supported on all interfaces and subinterfaces and supports CEF, dCEF, flow, and optimum switching.

The following command was introduced by this feature: show interface precedence, ip accounting precedence.

Configuring IPv4 Broadcast Packet Handling

This module explains what IPv4 broadcast packets are, when they are used, and how to customize your router's configuration for situations when the default behavior for handling IPv4 broadcast packets isn't appropriate.

This module also explains some common scenarios that require customizing IPv4 broadcast packet handling by routers. For example, UDP forwarding of Dynamic Host Configuration Protocol (DHCP) traffic to ensure broadcast packets sent by DHCP clients can reach DHCP servers that are not on the same network segment as the client. Configuration tasks and examples are also provided in this module.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Information About IPv4 Broadcast Packet Handling

- IP Unicast Address

- IP Broadcast Address

- IP Directed Broadcast Address

- IP Directed Broadcasts

- IP Multicast Addresses

- Early IP Implementations

- DHCP and IPv4 Broadcast Packets

- UDP Broadcast Packet Forwarding

- UDP Broadcast Packet Flooding

- IP Broadcast Flooding Acceleration

- Default UDP Port Numbers

- Default IP Broadcast Address

- UDP Broadcast Packet Case Study

IP Unicast Address

An IP unicast address is not a broadcast addresses. A packet with an unicast destination IP address is intended for a specific IP host. For example, 172.16.1.1/32. Only the intended host of a unicast packets receives and processes the packet. This term is often used in conjunction with references to types of IP broadcast traffic. For example, a network administrator considering upgrading a router in a network must consider the amount of unicast, multicast, and broadcast traffic because each type of traffic can have a different effect on the performance of the router.

IP Broadcast Address

IP broadcast packets are sent to the destination IP broadcast address 255.255.255.255 (or the older but still occasionally used IP broadcast address of 000.000.000.000). The broadcast destination IP addresses 255.255.255.255 and 000.000.000.000 are used when a packet is intended for every IP-enabled device on a network.

Note

Packets that use the broadcast IP address as the destination IP address are known as broadcast packets.

If routers forwarded IP broadcast packets by default, the packets would have to be forwarded out every interface that is enabled for IP because the 255.255.255.255 IP destination address is assumed to be reachable via every IP enabled interface in the router. Forwarding IP broadcast packets out every interface that is enabled for IP would result in what is known as a broadcast storm (network overload due to high levels of broadcast traffic). In order to avoid the IP packet broadcast storm that would be created if a router forwarded packets with a broadcast IP destination address out every IP-enabled interface, the default behavior for a router is to not forward broadcast packets. This is a key difference between routing IP traffic at Layer 3 versus bridging it at Layer 2. Layer 2 bridges by default forward IP broadcast traffic out every interface that is in a forwarding state, which can lead to scalability problems.

Some TCP/IP protocols use the IP broadcast address to either communicate with all of the hosts on a network segment or to identify the IP address of a specific host on a network segment. For example:

- Routing Information Protocol (RIP) version 1 sends routing table information using the IP broadcast address so that any other host on the network segment running RIP version 1 can receive and process the updates.

- The Address Resolution Protocol (ARP) is used to determine the Layer 2 MAC address of the host that owns a specific Layer 3 IP address. ARP sends an IP broadcast packet (that is also a Layer 2 broadcast frame) on the local network. All of the hosts on the local network receive the ARP broadcast packet because it is sent to as a Layer 2 broadcast frame. All of the hosts on the local network process the ARP packet because it is sent to the IP broadcast address. Only the host that owns the IP address indicated in the data area of the ARP packet responds to the ARP broadcast packet.

IP Directed Broadcast Address

An IP directed broadcast is intended to reach all hosts on a remote network. A router that needs to send data to a remote IP host when only the IP network address is known uses an IP directed broadcast to reach the remote host. For example, a directed broadcast sent by a host with an IP address of 192.168.100.1 with a destination IP address of 172.16.255.255 is intended only for hosts that are in the 172.16.0.0 address space (hosts that have an IP address that begins with 172.16.0.0).

An IP directed broadcast packet is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a Layer 2 broadcast frame (MAC address of FFFF.FFFF.FFFF). Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast. For example, only a router with an interface connected to a network using an IP address in the 172.16.0.0/16 address space such as 172.16.1.1/16 can determine that a packet sent to 172.16.255.255 is a directed broadcast and convert it to a Layer 2 broadcast that is received by all hosts on the local network. The other routers in the network that are not connected to the 172.16.0.0/16 network forward packets addressed to 172.16.255.255 as if they were for a specific IP host.

All of the hosts on the remote network receive IP directed broadcasts after they are converted to Layer 2 broadcast frames. Ideally only the intended destination host will fully process the IP directed broadcast and respond to it. However, IP directed broadcasts can be used for malicious purposes. For example, IP directed broadcasts are used in "smurf" Denial of Service (DoS) attack and derivatives thereof. In a "smurf" attack, the attacker sends Internet Control Message Protocol (ICMP) echo requests (pings) to a directed broadcast address using the source IP address of the device that is the target of the attack. The target is usually a host inside a company's network such as a web server. The ICMP echo requests are sent to an IP directed broadcast address in the company's network that causes all the hosts on the target subnet to send ICMP echo replies to the device under attack. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host that is under attack. For information on how IP directed broadcasts are used in DoS attacks, search the Internet for "IP directed broadcasts," "denial of service," and "smurf attacks."

Due to the security implications of allowing a router to forward directed broadcasts and the reduction in applications that require directed broadcasts, IP directed broadcasts are disabled by default in Cisco IOS Release 12.0 and later releases. If your network requires support for IP directed broadcasts, you can enable it on the interfaces that you want to translate the IP directed broadcasts to Layer 2 broadcasts using the ip directed-broadcast command. For example, if your router is receiving IP directed broadcasts on Fast Ethernet interface 0/0 for the network address assigned to Fast Ethernet interface 0/1, and you want the IP directed broadcasts to be translated to Layer 2 broadcasts out interface Fast Ethernet interface 0/1, configure the ip directed-broadcast command on Fast Ethernet interface 0/1. You can specify an access list to control which IP directed broadcasts are translated to Layer 2 broadcasts. When an access list is specified, only those IP packets permitted by the access list are eligible to be translated from directed broadcasts to Layer 2 broadcasts. For example, if you know that the only legitimate source IP address of any IP directed broadcasts in your network is 192.168.10.2, create an extended IP access list allowing traffic from 192.168.10.2 and assign the access list with the ip directed-broadcastaccess-list command.

IP Directed Broadcasts

IP directed broadcasts are dropped by default. Dropping IP directed broadcasts reduces the risk of DoS attacks.

You can enable forwarding of IP directed broadcasts on an interface where the broadcast becomes a physical broadcast. You enable the translation of directed IP broadcast packets to Layer 2 broadcast frames on the interface that is connected to the IP network that the IP directed broadcast is addressed to. For example, if you need to translate IP directed broadcasts with the IP destination address of 172.16.10.255 to Layer 2 broadcast frames, you enable the translation on the interface that is connected to IP network 172.16.10.0/24.

You can specify an access list to control which directed broadcasts are forwarded. When an access list is specified, only those IP packets permitted by the access list are eligible to be translated from directed broadcasts to physical broadcasts.

IP directed broadcasts are disabled by default in Cisco IOS Release 12.0 and newer releases.

IP Multicast Addresses

IP multicast addresses are intended to reach an arbitrary subset of the hosts on a local network. IP broadcast addresses create a problem because every host must receive and process the data in each packet to determine if it contains information that the host must process further. IP multicast addresses resolve this problem by using well-known IP addresses that a host must be configured to recognize before it will process packets addressed to it. When a host receives an IP multicast packet, the host compares the IP multicast address with the list of multicast addresses it is configured to recognize. If the host is not configured to recognize the IP multicast address, the host ignores the packet instead of processing it further to analyze the data in the packet. Because the host can ignore the packet it spends less time and fewer resources than it would have had to spend if the packet had been an IP broadcast that had to be processed all the way to the data layer before it was discarded.

The range of IP addresses reserved for Class D multicast addresses is 224.0.0.0 to 239.255.255.255/32 (255.255.255.255).

Most of the TCP/IP routing protocols use IP multicast addresses to send routing updates and other information to hosts on the same local network that are running the same routing protocol. Many other applications such as audio/video streaming over the Internet use IP multicast addresses. For a list of the currently assigned IP multicast addresses see Internet Multicast Addresses.

Information on configuring network devices for IP multicast support is available in the following documentation:

- Cisco IOS IP Multicast Configuration Guide

- Cisco IOS IP Multicast Command Reference

Early IP Implementations

Several early IP implementations do not use the current broadcast address standard of 255.255.255.255. Instead, they use the old standard, which calls for all zeros (000.000.000.000) instead of all ones to indicate broadcast addresses. Many of these implementations do not recognize an all-1s broadcast address and fail to respond to the broadcast correctly. Others forward all-1s broadcasts by default, which causes a serious network overload known as a broadcast storm. Implementations that exhibit these problems include systems based on versions of Berkeley Standard Distribution (BSD) UNIX prior to Version 4.3.

DHCP and IPv4 Broadcast Packets

DHCP requires that the client (host requiring information from the DHCP server) send broadcast packets to find a DHCP server to request configuration information from. If the DHCP server is not on the same network segment as the client that is sending the DHCP broadcasts, the router must be configured to forward the DHCP requests to the appropriate network.

For more information on DHCP, see RFC 2131 Dynamic Host Configuration Protocol, at http://www.ietf.org/rfc/rfc2131.txt.

UDP Broadcast Packet Forwarding

UDP broadcast packets are used by TCP/IP protocols such as DHCP and applications that need to send the same data to multiple hosts concurrently. Because routers by default do not forward broadcast packets you need to customize your router's configuration if your network has UDP broadcast traffic on it. One option for forwarding UDP broadcast packets is to use the UDP forwarding feature. UDP forwarding rewrites the broadcast IP address of a UDP packet to either a unicast (specific host) IP address or a directed IP broadcast. After the address is rewritten the UDP packet is forwarded by all of the routers in the path to the destination network without requiring additional configuration changes on the other routers.

You can enable forwarding of UDP broadcast packets, such as DHCP requests, to a host, or to multiple hosts on the same target network. When a UDP broadcast packet is forwarded, the destination IP address is rewritten to match the address that you configure. For example, the ip helper-address 172.16.10.2 command rewrites the IP destination address from 255.255.255.255 to 172.16.10.2.

To enable UDP broadcast packet forwarding to specific host, use a specific host IP address as the helper address when you configure the ip helper-address address command. To enable UDP broadcast packet forwarding to a range of hosts to allow for load sharing and redundancy, use an IP directed broadcast address as the helper address when you configure the ip helper-address address command.

UDP Broadcast Packet Flooding

You can allow IP broadcasts to be flooded throughout your network in a controlled fashion using the database created by theLayer 2 bridging Spanning Tree Protocol (STP). Enabling this feature also prevents flooding loops. In order to support this capability, the Cisco IOS software on your router must include support for transparent bridging, and transparent bridging must be configured on each interface that is to participate in the flooding. If bridging is not configured on an interface, the interface is still able to receive broadcasts. However, the interface will never forward broadcasts it receives, and the router will never use that interface to send broadcasts received on a different interface.

Packets that are forwarded to a single network address using the IP helper address mechanism can be flooded. Only one copy of the packet is sent on each network segment.

In order to be considered for flooding, packets must meet the following criteria. (These are the same conditions used to consider packet forwarding using IP helper addresses.)

- The packet must be a MAC-level broadcast (FFFF.FFFF.FFFF).

- The packet must be an IP-level broadcast (255.255.255.255).

- The packet must be a Trivial File Transfer Protocol (TFTP), Domain Name System (DNS), Time, NetBIOS, Neighbor Discovery (ND), or BOOTP packet, or a UDP protocol specified by the ip forward-protocol udp global configuration command.

- The time-to-live (TTL) value of the packet must be at least two.

If you want to send the flooded UDP packets to a specific host, you can change the Layer 3 IP broadcast address of the flooded UDP packets with the ip broadcast-address command in interface configuration mode. The address of the flooded UDP packets can be set to any desired IP address. The source address of the flooded UDP packet is never changed. The TTL value of the flooded UDP packet is decremented.

After a decision has been made to send the datagram out on an interface (and the destination IP address possibly changed), the datagram is handed to the normal IP output routines and is, therefore, subject to access lists if they are present on the output interface.

If no actual bridging is desired, you can configure a type-code bridging filter that will deny all packet types from being bridged. Refer to the "Configuring Transparent Bridging" module of the Cisco IOS Bridging and IBM Networking Configuration Guide for more information about using access lists to filter bridged traffic. The Spanning-Tree database is still available to the IP forwarding code to use for the flooding.

IP Broadcast Flooding Acceleration

You can accelerate flooding of UDP datagrams using the spanning-tree algorithm. Used in conjunction with the ip forward-protocol spanning-tree command in global configuration mode, this feature boosts the performance of spanning-tree-based UDP flooding by a factor of about four to five times. The feature, called turbo flooding, is supported over Ethernet interfaces configured for Advanced Research Projects Agency (ARPA) encapsulated, FDDI, and high-level data link control (HDLC)-encapsulated serial interfaces. However, it is not supported on Token Ring interfaces. As long as the Token Rings and the non-HDLC serial interfaces are not part of the bridge group being used for UDP flooding, turbo flooding will behave normally.

Default UDP Port Numbers

If a helper address is specified and UDP forwarding is enabled, broadcast packets destined to the following port numbers are forwarded by default:

- Time service (port 37)

- IEN-116 Name Service (port 42)

- TACACS service (port 49)

- Domain Naming System (port 53)

- BOOTP client and server packets (ports 67 and 68)

- TFTP (port 69)

- NetBIOS Name Server (port 137)

- NetBIOS Datagram Server (port 138)

Default IP Broadcast Address

The Cisco IOS software supports sending IP broadcasts on both LANs and WANs. There are several ways to indicate an IP broadcast address. The default is an address consisting of all ones (255.255.255.255), although the software can be configured to generate any form of IP broadcast address such as all zeros (0.0.0.0), and directed broadcasts such as 172.16.255.255. Cisco IOS software can receive and process most IP broadcast addresses.

UDP Broadcast Packet Case Study

This case study is from a trading floor application in a financial company. The workstations (WS1, WS2, and WS3) in the following figure receive financial data from the feed network. The financial data is sent using UDP broadcasts.

Figure 4

Topology that Requires UDP Broadcast Forwarding

The following sections explain the possible solutions for this application:

UDP Broadcast Packet Forwarding

The first option is UDP broadcast packet using helper addresses. To configure helper addressing, you must specify the ip helper-address command on every interface on every router that receives a UDP broadcast that needs to be forwarded. On router 1 and router 2 in the figure below, IP helper addresses can be configured to move data from the server network to the trader networks. However IP helper addressing was determined not to be an optimal solution for this type of topology because each router receives unnecessary broadcasts from the other router, as shown in the figure below.

Figure 2

Flow of UDP Packets

In this case, router 1 receives each broadcast sent by router 2 three times, one for each segment, and router 2 receives each broadcast sent by router 1 three times, one for each segment. When each broadcast is received, the router must analyze it and determine that the broadcast does not need to be forwarded. As more segments are added to the network, the routers become overloaded with unnecessary traffic, which must be analyzed and discarded.

When IP helper addressing is used in this type of topology, no more than one router can be configured to forward UDP broadcasts (unless the receiving applications can handle duplicate broadcasts). This is because duplicate packets arrive on the trader network. This restriction limits redundancy in the design and can be undesirable in some implementations.

To configure routers to send UDP broadcasts bidirectionally in this type of topology, a second ip helper address command must be applied to every router interface that receives UDP broadcasts. As more segments and devices are added to the network, more ip helper address commands are required to reach them, so the administration of these routers becomes more complex over time.

Note

Bidirectional traffic in this topology significantly impacts router performance.

Although IP helper addressing is well-suited to nonredundant, nonparallel topologies that do not require a mechanism for controlling broadcast loops, IP helper addressing does not work well in this topology. To improve performance, the network designers considered four other alternatives:

- Setting the broadcast address on the servers to all ones (255.255.255.255)--This alternative was dismissed because the servers have more than one interface, causing server broadcasts to be sent back onto the feed network. In addition, some workstation implementations do not allow all 1s broadcasts when multiple interfaces are present.

- Setting the broadcast address of the servers to the major network broadcast IP address--This alternative was dismissed because the TCP/IP implementation on the servers does not allow the use of major network IP broadcast addresses when the network is subnetted.

- Eliminating the subnets and letting the workstations use Address Resolution Protocol (ARP) to learn addresses--This alternative was dismissed because the servers cannot quickly learn an alternative route in the event of a primary router failure.

- UDP broadcast packet flooding--This alternative uses the spanning-tree topology created with transparent bridging to forward UDP broadcast packets in a redundant topology while avoiding loops and duplicate broadcast traffic.

UDP Broadcast Packet Flooding

UDP flooding uses the spanning-tree algorithm to forward packets in a controlled manner. Bridging is enabled on each router interface for the sole purpose of building the spanning tree. The spanning tree prevents loops by stopping a broadcast from being forwarded out an interface on which the broadcast was received. The spanning tree also prevents packet duplication by placing certain interfaces in the blocked state (so that no packets are forwarded) and other interfaces in the forwarding state (so that packets that need to be forwarded are forwarded).

Before you can enable UDP flooding, the router must be running software that supports transparent bridging and bridging must be configured on each interface that is to participate in the flooding. If bridging is not configured for an interface, the interface will receive broadcasts, but the router will not forward those broadcasts and will not use that interface as a destination for sending broadcasts received on a different interface.

When configured for UDP flooding, the router uses the destination address specified by the ip broadcast-address command on the output interface to assign a destination address to a flooded UDP datagram. Thus, the destination address might change as the datagram propagates through the network. The source address, however, does not change.

With UDP flooding, both routers shown in the figure below use a spanning-tree to control the network topology for the purpose of forwarding broadcasts. The bridge protocol command can specify either the dec keyword (for the Digital Equipment Corporation (DEC) spanning-tree protocol) or the ieee keyword (for the IEEE Ethernet protocol). All routers in the network must enable the same spanning-tree protocol. The ip forward-protocol spanning-tree command uses the database created by the bridge protocol command. Only one broadcast packet arrives at each segment, and UDP broadcasts can traverse the network in both directions.

Because bridging is enabled only to build the spanning-tree database, use access lists to prevent the spanning-tree from forwarding non-UDP traffic.

The router configuration specifies a path cost for each interface to determine which interface forwards or blocks packets. The default path cost for Ethernet is 100. Setting the path cost for each interface on router 2 to 50 causes the spanning-tree algorithm to place the interfaces in router 2 in forwarding state. Given the higher path cost (100) for the interfaces in router 1, the interfaces in router 1 are in the blocked state and do not forward the broadcasts. With these interface states, broadcast traffic flows through router 2. If router 2 fails, the spanning-tree algorithm will place the interfaces in router 1 in the forwarding state, and router 1 will forward broadcast traffic.

With one router forwarding broadcast traffic from the server network to the trader networks, you should configure the other router to forward unicast traffic. For that reason, each router enables the ICMP Router Discovery Protocol (IRDP), and each workstation on the trader networks runs the IRDP daemon. On router 1, the preference keyword of the ip irdp command sets a higher IRDP preference than does the configuration for router 2, which causes each IRDP daemon to use router 1 as its preferred default gateway for unicast traffic forwarding. Users of those workstations can use the netstat -rn command to see how the routers are being used.

On the routers, the holdtime, maxadvertinterval, and minadvertinterval keywords of the ip irdp command reduce the advertising interval from the default so that the IRDP daemons running on the hosts expect to see advertisements more frequently. With the advertising interval reduced, the workstations will adopt router 2 more quickly if router 1 becomes unavailable. With this configuration, when a router becomes unavailable, IRDP offers a convergence time of less than one minute.

IRDP is preferred over the Routing Information Protocol (RIP) and default gateways for the following reasons:

- RIP takes longer to converge.

- Configuration of router 1 as the default gateway on each Sun workstation on the trader networks would allow those Sun workstations to send unicast traffic to router 1, but would not provide an alternative route if router 1 becomes unavailable.

The figure below shows how data flows when the network is configured for UDP flooding.

Figure 3

Data Flow with UDP Flooding and IRDP

Note

This topology is broadcast intensive--broadcasts sometimes consume 20 percent of the 10-MB Ethernet bandwidth. However, this is a favorable percentage when compared to the configuration of IP helper addressing, which, in the same network, causes broadcasts to consume up to 50 percent of the 10-MB Ethernet bandwidth.

If the hosts on the trader networks do not support IRDP, Hot Standby Routing Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP) can be used to select which router will handle unicast traffic. These protocols allow the standby router to take over quickly if the primary router becomes unavailable.

Enable turbo flooding on the routers to increase the performance of UDP flooding.

Note

Turbo flooding increases the amount of processing that is done at interrupt level, which increases the CPU load on the router. Turbo flooding may not be appropriate on routers that are already under high CPU load or that must also perform other CPU-intensive activities.

How to Configure IP Broadcast Packet Handling

- Enabling IP Directed Broadcasts Without an Access List

- Enabling IP Directed Broadcasts with an Access List

- Enabling Forwarding of UDP Broadcast Packets to a Specific Host

- Enabling Forwarding of UDP Broadcast Packets to a Range of Hosts

- Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers Without Nonvolatile Memory

- Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers with Nonvolatile Memory

- Changing the IP Broadcast Address to Any IP Address on One or More Interfaces in a Router

- Configuring UDP Broadcast Packet Flooding

Enabling IP Directed Broadcasts Without an Access List

Perform this task to permit the forwarding of IP directed broadcasts from any source.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   ip address address mask

5.   ip directed-broadcast

6.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/1

Step 4 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 5 ip directed-broadcast

Enables IP directed broadcasts on the interface.

- Configure this command on the interface that is connected to the IP network address of the directed broadcast packets.

- In this example the directed broadcast packets are addressed to 172.16.10.255.

Example:

Router(config-if)# ip directed-broadcast

Step 6 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Enabling IP Directed Broadcasts with an Access List

Perform this task to limit the forwarding of IP directed broadcasts by applying an access list to the ip directed-broadcast command.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   access-list 100-199 permit ip source-address mask destination-address mask

4.   interface type number

5.   ip address address mask

6.   ip directed-broadcast access-list

7.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 access-list 100-199 permit ip source-address mask destination-address mask

Creates an access list to limit the IP directed broadcasts that are forwarded.

- In this example the IP directed broadcasts are sent by the host with the IP address of 10.4.9.167 to the IP directed broadcast address 172.16.10.255.

Example:

Router(config)# access-list 100 permit ip 10.4.9.167 0.0.0.0 172.16.10.0 0.0.0.255

Step 4 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/0

Step 5 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 6 ip directed-broadcast access-list

Enables IP directed broadcasts on the interface for broadcast packets that are allowed by the access list you assigned. Configure this command on the interface that is connected to the IP network address of the directed broadcast packets.

- In this example the directed broadcast packets are addressed to 172.16.10.255.

Example:

Router(config-if)# ip directed-broadcast 100

Step 7 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Enabling Forwarding of UDP Broadcast Packets to a Specific Host

Perform this task to enable UDP broadcast packet forwarding to a single host.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   ip forward-protocol udp

4.   interface type number

5.   ip address address mask

6.   ip helper-address address

7.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 ip forward-protocol udp

Enables forwarding of UDP broadcast packets.

Example:

Router(config)# ip forward-protocol udp

Step 4 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/1

Step 5 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 6 ip helper-address address

Enables an IP helper address for the interface that is receiving the UDP broadcast packets.

- In this example the IP destination address of the IP UDP broadcast packets is rewritten to 172.16.10.2.

Example:

Router(config-if)# ip helper-address 172.16.10.2

Step 7 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Enabling Forwarding of UDP Broadcast Packets to a Range of Hosts

Perform this task to enable UDP broadcast packet forwarding to a range of hosts to allow for load sharing between the destination hosts and to provide redundancy if one or more of the destination hosts fail.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   ip forward-protocol udp

4.   interface type number

5.   ip address address mask

6.   ip helper-address address

7.   exit

8.   interface type number

9.   ip address address mask

10.   ip directed-broadcast

11.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 ip forward-protocol udp

Enables forwarding of UDP broadcast packets.

Example:

Router(config)# ip forward-protocol udp

Step 4 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/0

Step 5 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 192.168.10.1 255.255.255.0

Step 6 ip helper-address address

Enables an IP helper address for the interface that is receiving the UDP broadcast packets.

- In this example an IP directed broadcast address is used. The IP destination address of the IP UDP broadcast packets is rewritten to 172.16.10.255.

- All of the hosts on the 172.16.10.0/24 network that support the application or service that the UDP broadcast packets are intended for will respond to the UDP broadcast packets.

Note

This often results in the source of the UDP broadcast packets receiving responses from two or more hosts. In most circumstances the source of the UDP broadcast packets accepts the first response and ignores any subsequent responses. In some situations the source of the UDP broadcast packets cannot handle duplicate responses and reacts by reloading, or other unexpected behavior.

Example:

Router(config-if)# ip helper-address 172.16.10.255

Step 7 exit

Returns to global configuration mode.

Example:

Router(config-if)# exit

Step 8 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/1

Step 9 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 10 ip directed-broadcast

Enables IP directed broadcasts on the interface that is transmitting the UDP broadcasts.

Example:

Router(config-if)# ip directed-broadcast

Step 11 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers Without Nonvolatile Memory

If you router does not have NVRAM, and you need to change the IP broadcast address to 0.0.0.0, you must change the IP broadcast address manually by setting jumpers in the processor configuration register. Setting bit 10 causes the device to use all 0s. Bit 10 interacts with bit 14, which controls the network and host portions of the broadcast address. Setting bit 14 causes the device to include the network and host portions of its address in the broadcast address. The table below shows the combined effect of setting bits 10 and 14.

Table 5

Configuration Register Settings for Broadcast Address Destination

Bit 14

Bit 10

Address (<net><host>)

Out

Out

<ones><ones>

Out

In

<zeros><zeros>

In

In

<net><zeros>

In

Out

<net><ones>

For additional information on setting the hardware jumpers on your router, see the hardware documentation that was supplied with you router.

Changing the Default IP Broadcast Address for All Interfaces to 0.0.0.0 on Routers with Nonvolatile Memory

Cisco IOS-based routers with NVRAM have software configuration registers that allow you to modify several behaviors of the router such as where it looks for images to load, what IP broadcast address it uses, and the console line speed. The factory default value for the configuration register is 0x2102 where 0X indicates this a hexadecimal number. The config-register command is used to modify the settings of the software configuration registers.

Information on configuring other behaviors with the software configuration registers using the config-register command is available in the following documentation:

- "Loading and Managing System Images" chapter of the Cisco IOS Configuration Fundamentals Configuration Guide

- Cisco IOS Configuration Fundamentals Command Reference

Caution

You need to be very careful when you change the software configuration registers on your router because if you inadvertently alter the console port line speed, you will not be able to configure the router with a terminal server on the console port unless you know the speed that you set for the console port, and you know how to change the line speed for your terminal application. If your router is configured for alternate access to the CLI such as using Telnet or a web browser, you can use this method to log in to the router and change the software configuration register back to 0x2102.

Perform this task to set the IP broadcast address on every interface to 0.0.0.0 while maintaining the remainder of the default values for the software configuration register settings.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   config-register value

4.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 config-register value

Sets the IP broadcast address to 0.0.0.0 on every interface while maintaining the remainder of the default values for the other software configuration register settings.

Example:

Router(config)# config-register 0x2502

Step 4 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config)# end

Changing the IP Broadcast Address to Any IP Address on One or More Interfaces in a Router

Perform this task if you network requires an IP broadcast address other than 255.255.255.255 or 0.0.0.0, or you want to change the IP broadcast address to 0.0.0.0 on a subset of the interfaces on the router instead of on all of the interfaces on the router.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   ip address address mask

5.   ip broadcast-address address

6.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/1

Step 4 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 5 ip broadcast-address address

Specifies the IP broadcast address

- In this example IP broadcasts are sent to 172.16.10.255.

Example:

Router(config-if)# ip broadcast-address 172.16.10.255

Step 6 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Configuring UDP Broadcast Packet Flooding

Before You Begin

The version of Cisco IOS software on your router must support transparent bridging.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   bridge number protocol ieee

4.   ip forward-protocol spanning-tree

5.   ip forward-protocol turbo-flood

6.   ip forward-protocol udp

7.   interface type number

8.   ip address address mask

9.   bridge-group number

10.   interface type number

11.   ip address address mask

12.   bridge-group number

13.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 bridge number protocol ieee

Enables spanning-tree bridging and specifies the bridging protocol.

Example:

Router(config)# bridge 1 protocol ieee

Step 4 ip forward-protocol spanning-tree

Enables using the spanning-tree forwarding table to flood broadcast packets.

Example:

Router(config)# ip forward-protocol spanning-tree

Step 5 ip forward-protocol turbo-flood

(Optional) Enables fast forwarding of broadcast packets using the spanning-tree forwarding table.

Example:

Router(config)# ip forward-protocol turbo-flood

Step 6 ip forward-protocol udp

Enables forwarding of UDP broadcasts.

Example:

Router(config)# ip forward-protocol udp

Step 7 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/0

Step 8 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 192.168.10.1 255.255.255.0

Step 9 bridge-group number

Places the interface in the spanning-tree bridge group specified.

Example:

Router(config-if)# bridge-group 1

Step 10 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config-if)# interface fastethernet 0/1

Step 11 ip address address mask

Assigns an IP address to the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 12 bridge-group number

Places the interface in the spanning-tree bridge group specified.

Example:

Router(config-if)# bridge-group 1

Step 13 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Configuration Examples for IP Broadcast Packet Handling

- Example: Enabling IP Directed Broadcasts with an Access List

- Example: Configuring UDP Broadcast Packet Flooding

Example: Enabling IP Directed Broadcasts with an Access List

The following example shows how to enable IP directed broadcasts with an access list to control the directed broadcasts that are forwarded.

Router(config)# access-list 100 permit ip 10.4.9.167 0.0.0.0 172.16.10.0 0.0.0.255

Router(config)# interface fastethernet 0/0

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Router(config-if)# ip directed-broadcast 100

Example: Configuring UDP Broadcast Packet Flooding

Router(config)# bridge 1 protocol ieee

Router(config)# ip forward-protocol spanning-tree

Router(config)# ip forward-protocol turbo-flood

Router(config)# ip forward-protocol udp

Router(config)# interface fastethernet 0/0

Router(config-if)# ip address 192.168.10.1 255.255.255.0

Router(config-if)# bridge-group 1

Router(config)# interface fastethernet 0/1

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Router(config-if)# bridge-group 1

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Currently assigned IP multicast addresses

Internet Multicast Addresses http://www.iana.org/assignments/multicast-addresses

Configuration fundamentals configuration tasks

Cisco IOS Configuration Fundamentals Configuration Guide

Configuration fundamentals commands

Cisco IOS Configuration Fundamentals Command Reference

Cisco IOS bridging and IBM networking configuration tasks

Cisco IOS Bridging and IBM Networking Configuration Guide

Cisco IOS bridging and IBM networking commands

Cisco IOS Bridging and IBM Networking Command Reference

Cisco IOS IP multicast configuration tasks

Cisco IOS IP Multicast Configuration Guide

Cisco IOS IP Multicast commands

Cisco IOS IP Multicast Command Reference

Standards

Standard

Title

IEEE Spanning-Tree Bridging

802.1D MAC Bridges

http://www.ieee802.org/1/pages/802.1D-2003.html

MIBs

MIB

MIBs Link

--

No new or modified MIBs are supported, and support for existing MIBs has not been modified.

RFCs

RFC

Title

RFC 1812

Requirements for IP Version 4 Routers http://www.ietf.org/rfc/rfc1812.txt

RFC 2131

Dynamic Host Configuration Protocol http://www.ietf.org/rfc/rfc2131.txt .

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IPv4 Broadcast Packet Handling

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 6

Feature Information for IP Broadcast Packet Handling

Feature Name

Releases

Feature Information

IP Directed Broadcasts

15.2(1)S

Enables the translation of a directed broadcast to physical broadcasts.

The following command was introduced or modified by this feature: ip directed-broadcast.

UDP Broadcast Packet Forwarding

15.2(1)S

Enables the forwarding of UDP broadcast packets.

The following commands were introduced or modified by this feature: ip forward-protocol, ip helper-address.

Flooding Packets Using spanning-tree

15.2(1)S

Enables the forwarding of UDP broadcast packets using the spanning-tree forwarding table.

The following commands were introduced or modified by this feature: ip forward-protocol spanning-tree, ip forward-protocol turbo-flood.

Specifying an IP Broadcast Address

15.2(1)S

Specifies the IP broadcast address for an interface.

The following command was introduced or modified by this feature: ip broadcast-address.

Configuring TCP

TCP is a protocol that specifies the format of data and acknowledgments used in data transfer. TCP is a connection-oriented protocol because participants must establish a connection before data can be transferred. By performing flow control and error correction, TCP guarantees reliable, in-sequence delivery of packets. TCP is considered a reliable protocol because it will continue to request an IP packet that is dropped or received out of order until it is received. This module explains concepts related to TCP and how to configure TCP in a network.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for TCP

TCP Time Stamp, TCP Selective Acknowledgment, and TCP Header Compression

Because TCP time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. To allow TCP header compression over a serial link, the TCP time-stamp option is disabled. If you want to use TCP header compression over a serial line, TCP time stamp and TCP selective acknowledgment must be disabled. Both features are disabled by default. Use the no ip tcp selective-ack command to disable the TCP selective acknowledgment once it is enabled.

Information About TCP

- TCP Services

- TCP Connection Establishment

- TCP Connection Attempt Time

- TCP Selective Acknowledgment

- TCP Time Stamp

- TCP Maximum Read Size

- TCP Path MTU Discovery

- TCP Sliding Window

- TCP Outgoing Queue Size

- TCP MSS Adjustment

TCP Services

TCP provides reliable transmission of data in an IP environment. TCP corresponds to the transport layer (Layer 4) of the Open Systems Interconnection (OSI) reference model. Among the services that TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing.

With stream data transfer, TCP delivers an unstructured stream of bytes that are identified by sequence numbers. This service benefits applications because they do not have to divide data into blocks before handing it off to TCP. Instead, TCP groups bytes into segments and passes them to IP for delivery.

TCP offers reliability by providing connection-oriented, end-to-end reliable packet delivery through an internetwork. It does this by sequencing bytes with a forwarding acknowledgment number that indicates to the destination the next byte that the source expects to receive. Bytes that are not acknowledged within a specified time period are retransmitted. The reliability mechanism of TCP allows devices to handle lost, delayed, duplicate, or misread packets. A timeout mechanism allows devices to detect lost packets and request retransmission.

TCP offers efficient flow control, which means that the receiving TCP process indicates the highest sequence number that it can receive without overflowing its internal buffers when sending acknowledgments back to the source.

TCP offers full-duplex operation, and TCP processes can both send and receive data at the same time.

TCP multiplexing allows numerous simultaneous upper-layer conversations to be multiplexed over a single connection.

TCP Connection Establishment

To use reliable transport services, TCP hosts must establish a connection-oriented session with one another. Connection establishment is performed by using a "three-way handshake" mechanism.

A three-way handshake synchronizes both ends of a connection by allowing both sides to agree upon the initial sequence numbers. This mechanism guarantees that both sides are ready to transmit data. The three-way handshake is necessary so that packets are not transmitted or retransmitted during session establishment or after session termination.

Each host randomly chooses a sequence number, which is used to track bytes within the stream that the host is sending. The three-way handshake proceeds in the following manner:

- The first host (Host A) initiates a connection by sending a packet with the initial sequence number (X) and the synchronize/start (SYN) bit set to indicate a connection request.

- The second host (Host B) receives the SYN, records the sequence number X, and replies by acknowledging (ACK) the SYN (with an ACK = X + 1). Host B includes its own initial sequence number (SEQ = Y). An ACK = 20 means that the host has received bytes 0 through 19 and expects byte 20 next. This technique is called forward acknowledgment.

- Host A acknowledges all bytes that Host B has sent with a forward acknowledgment indicating the next byte Host A expects to receive (ACK = Y + 1). Data transfer can then begin.

TCP Connection Attempt Time

You can set the amount of time the software will wait before attempting to establish a TCP connection. The connection attempt time is a host parameter and pertains to traffic that originated at the device and not to traffic going through the device. To set the TCP connection attempt time, use the ip tcp synwait-time command in global configuration mode. The default is 30 seconds.

TCP Selective Acknowledgment

The TCP Selective Acknowledgment feature improves performance if multiple packets are lost from one TCP window of data.

Prior to this feature, because of limited information available from cumulative acknowledgments, a TCP sender could learn about only one lost packet per-round-trip time. An aggressive sender could choose to resend packets early, but such re-sent segments might have already been successfully received.

The TCP selective acknowledgment mechanism helps improve performance. The receiving TCP host returns selective acknowledgment packets to the sender, informing the sender of data that has been received. In other words, the receiver can acknowledge packets received out of order. The sender can then resend only missing data segments (instead of everything since the first missing packet).

Prior to selective acknowledgment, if TCP lost packets 4 and 7 out of an 8-packet window, TCP would receive acknowledgment of only packets 1, 2, and 3. Packets 4 through 8 would need to be re-sent. With selective acknowledgment, TCP receives acknowledgment of packets 1, 2, 3, 5, 6, and 8. Only packets 4 and 7 must be re-sent.

TCP selective acknowledgment is used only when multiple packets are dropped within one TCP window. There is no performance impact when the feature is enabled but not used. Use the ip tcp selective-ack command in global configuration mode to enable TCP selective acknowledgment.

Refer to RFC 2018 for more details about TCP selective acknowledgment.

TCP Time Stamp

The TCP time-stamp option provides improved TCP round-trip time measurements. Because the time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. To allow TCP header compression over a serial link, the TCP time-stamp option is disabled. Use the ip tcp timestamp command to enable the TCP time-stamp option.

Refer to RFC 1323 for more details on TCP time stamps.

TCP Maximum Read Size

The maximum number of characters that TCP reads from the input queue for Telnet and relogin at one time is very large (the largest possible 32-bit positive number) by default. To change the TCP maximum read size value, use the ip tcp chunk-size command in global configuration mode.

Note

We do not recommend that you change this value.

TCP Path MTU Discovery

Path MTU Discovery is a method for maximizing the use of the available bandwidth in the network between endpoints of a TCP connection, which is described in RFC 1191. IP Path MTU Discovery allows a host to dynamically discover and cope with differences in the maximum allowable maximum transmission unit (MTU) size of the various links along the path. Sometimes a device is unable to forward a datagram because it requires fragmentation (the packet is larger than the MTU that you set for the interface with the interface configuration command), but the "do not fragment" (DF) bit is set. The intermediate gateway sends a "Fragmentation needed and DF bit set" Internet Control Message Protocol (ICMP) message to the sending host, alerting the host to the problem. On receiving this message, the host reduces its assumed path MTU and consequently sends a smaller packet that will fit the smallest packet size of all links along the path.

By default, TCP Path MTU Discovery is disabled. Existing connections are not affected irrespective of whether this feature is enabled or disabled.

Customers using TCP connections to move bulk data between systems on distinct subnets would benefit most by enabling this feature. Customers using remote source-route bridging (RSRB) with TCP encapsulation, serial tunnel (STUN), X.25 Remote Switching (also known as XOT or X.25 over TCP), and some protocol translation configurations might also benefit from enabling this feature.

Use the ip tcp path-mtu-discovery global configuration command to enable Path MTU Discovery for connections initiated by the device when the device is acting as a host.

For more information about Path MTU Discovery, refer to the "Configuring IP Services" module of the IP Application Services Configuration Guide.

TCP Sliding Window

A TCP sliding window provides an efficient use of network bandwidth because it enables hosts to send multiple bytes or packets before waiting for an acknowledgment.

In TCP, the receiver specifies the current window size in every packet. Because TCP provides a byte-stream connection, window sizes are expressed in bytes. A window is the number of data bytes that the sender is allowed to send before waiting for an acknowledgment. Initial window sizes are indicated at connection setup, but might vary throughout the data transfer to provide flow control. A window size of zero means "Send no data." The default TCP window size is 4128 bytes. We recommend that you keep the default value unless your device is sending large packets (greater than 536 bytes). Use the ip tcp window-size command to change the default window size.

In a TCP sliding-window operation, for example, the sender might have a sequence of bytes to send (numbered 1 to 10) to a receiver who has a window size of five. The sender then places a window around the first five bytes and transmits them together. The sender then waits for an acknowledgment.

The receiver responds with an ACK = 6, indicating that it has received bytes 1 to 5 and is expecting byte 6 next. In the same packet, the receiver indicates that its window size is 5. The sender then moves the sliding window five bytes to the right and transmits bytes 6 to 10. The receiver responds with an ACK = 11, indicating that it is expecting sequenced byte 11 next. In this packet, if the receiver indicates that its window size is 0, the sender cannot send any more bytes until the receiver sends another packet with a window size greater than 0.

TCP Outgoing Queue Size

The default TCP outgoing queue size per connection is five segments if the connection has a TTY associated with it (such as a Telnet connection). If no TTY connection is associated with a connection, the default queue size is 20 segments. Use the ip tcp queuemax command to change the five-segment default value.

TCP MSS Adjustment

The TCP MSS Adjustment feature enables the configuration of the maximum segment size (MSS) for transient packets that traverse a device, specifically TCP segments with the SYN bit set. Use the ip tcp adjust-mss command in interface configuration mode to specify the MSS value on the intermediate device of the SYN packets to avoid truncation.

When a host (usually a PC) initiates a TCP session with a server, the host negotiates the IP segment size by using the MSS option field in the TCP SYN packet. The value of the MSS field is determined by the MTU configuration on the host. The default MSS value for a PC is 1500 bytes.

The PPP over Ethernet (PPPoE) standard supports a Maximum Transmission Unit (MTU) of only 1492 bytes. The disparity between the host and PPPoE MTU size can cause the device in between the host and the server to drop 1500-byte packets and terminate TCP sessions over the PPPoE network. Even if the path MTU (which detects the correct MTU across the path) is enabled on the host, sessions may be dropped because system administrators sometimes disable ICMP error messages that must be relayed from the host for path MTU to work.

The ip tcp adjust-mss command helps prevent TCP sessions from being dropped by adjusting the MSS value of the TCP SYN packets.

The ip tcp adjust-mss command is effective only for TCP connections passing through the device.

In most cases, the optimum value for the max-segment-size argument of the ip tcp adjust-mss command is 1452 bytes. This value plus the 20-byte IP header, the 20-byte TCP header, and the 8-byte PPPoE header add up to a 1500-byte packet that matches the MTU size for the Ethernet link.

See the "Configuring the MSS Value and MTU for Transient TCP SYN Packets" section for configuration instructions.

How to Configure TCP

- Configuring the MSS Value and MTU for Transient TCP SYN Packets

Configuring the MSS Value and MTU for Transient TCP SYN Packets

Perform this task to configure the maximum size segment (MSS) for transient packets that traverse a device, specifically TCP segments with the SYN bit set, and to configure the MTU size of IP packets.

If you are configuring the ip mtu command on the same interface as the ip tcp adjust-mss command, we recommend that you use the following commands and values:

- ip tcp adjust-mss 1452

- ip mtu 1492

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   ip tcp adjust-mss max-segment-size

5.   ip mtu bytes

6.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 interface type number

Configures an interface type and enters interface configuration mode.

Example:

Device(config)# interface GigabitEthernet 1/0/0

Step 4 ip tcp adjust-mss max-segment-size

Adjusts the MSS value of TCP SYN packets going through a device.

- The max-segment-size argument is the maximum segment size, in bytes. The range is from 500 to 1460.

Example:

Device(config-if)# ip tcp adjust-mss 1452

Step 5 ip mtu bytes

Sets the MTU size of IP packets, in bytes, sent on an interface.

Example:

Device(config-if)# ip mtu 1492

Step 6 end

Exits to global configuration mode.

Example:

Device(config-if)# end

Configuration Examples for TCP

- Example: Configuring the TCP MSS Adjustment

Example: Configuring the TCP MSS Adjustment

Figure 5

Example Topology for TCP MSS Adjustment

The following example shows how to configure and verify the interface adjustment value for the example topology displayed in the figure below:

Configure the interface adjustment value on router B:

Router_B(config)# interface GigabitEthernet 2/0/0

Router_B(config-if)# ip tcp adjust-mss 500

Telnet from router A to router C with B having the Maximum Segment Size (MSS) adjustment configured:

Router_A# telnet 192.168.1.1

Trying 192.168.1.1... Open

Observe the debug output from router C:

Router_C# debug ip tcp transactions

Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)]

Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 500, MSS is 500

Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751

Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 500

Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]

The MSS gets adjusted to 500 on Router B as configured.

The following example shows the configuration of a Point-to-Point Protocol over Ethernet (PPPoE) client with the MSS value set to 1452:

Device(config)# vpdn enable

Device(config)# no vpdn logging

Device(config)# vpdn-group 1

Device(config-vpdn)# request-dialin

Device(config-vpdn-req-in)# protocol pppoe

Device(config-vpdn-req-in)# exit

Device(config-vpdn)# exit

Device(config)# interface GigabitEthernet 0/0/0

Device(config-if)# ip address 192.168.100.1.255.255.255.0

Device(config-if)# ip tcp adjust-mss 1452

Device(config-if)# ip nat inside

Device(config-if)# exit

Device(config)# interface ATM 0

Device(config-if)# no ip address

Device(config-if)# no atm ilmi-keepalive

Device(config-if)# pvc 8/35

Device(config-if)# pppoe client dial-pool-number 1

Device(config-if)# dsl equipment-type CPE

Device(config-if)# dsl operating-mode GSHDSL symmetric annex B

Device(config-if)# dsl linerate AUTO

Device(config-if)# exit

Device(config)# interface Dialer 1

Device(config-if)3 ip address negotiated

Device(config-if)# ip mtu 1492

Device(config-if)# ip nat outside

Device(config-if)# encapsulation ppp

Device(config-if)# dialer pool 1

Device(config-if)# dialer-group 1

Device(config-if)# ppp authentication pap callin

Device(config-if)# ppp pap sent-username sohodyn password 7 141B1309000528

Device(config-if)# ip nat inside source list 101 Dialer1 overload

Device(config-if)# exit

Device(config)# ip route 0.0.0.0.0.0.0.0 Dialer1

Device(config)# access-list permit ip 192.168.100.0.0.0.0.255 any

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

IP Application Services commands

IP Application Services Command Reference

Standards and RFCs

Standard/RFC

Title

RFC 793

Transmission Control Protocol

RFC 1191

Path MTU discovery

RFC 1323

TCP Extensions for High Performance

RFC 2018

TCP Selective Acknowledgment Options

RFC 2581

TCP Congestion Control

RFC 3168

The Addition of Explicit Congestion Notification (ECN) to IP

RFC 3782

The NewReno Modification to TCP's Fast Recovery Algorithm

RFC 4022

Management Information Base for the Transmission Control Protocol (TCP)

MIBs

MIB

MIBs Link

CISCO-TCP-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for TCP

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 7

Feature Information for TCP

Feature Name

Releases

Feature Information

TCP MSS Adjust

15.2(1)S

The TCP MSS Adjust feature enables the configuration of the maximum segment size (MSS) for transient packets that traverse a router, specifically TCP segments in the SYN bit set.

The following commands were introduced or modified by this feature: ip adjust-mss, ip tcp adjust-mss.

Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

User Datagram Protocol (UDP) forwarding is a feature used in Cisco IOS software to forward broadcast and multicast packets received for a specific IP address. Virtual Router Group (VRG) support, implemented with the Hot Standby Routing Protocol (HSRP), allows a set of routers to be grouped as a logical router that answers to a well-known IP address. The UDP Forwarding Support for IP Redundancy Virtual Router Groups feature enables UDP forwarding to be VRG aware; this results in packets getting forwarde only to the active router in the VRG.

This module explains the concepts related UDP forwarding and VRG support and describes how to configure UDP forwarding support for IP Redundancy Virtual Router Groups in a network.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for UDP Forwarding Support for IP Redundancy Virtual Router Groups

- The UDP Forwarding Support for Virtual Router Groups feature is available only on platforms that support VRGs.

Information About UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Benefits of the UDP Forwarding Support for Virtual Router Groups Feature

Benefits of the UDP Forwarding Support for Virtual Router Groups Feature

Forwarding is limited to the active router in the VRG instead of all routers within the VRG. Prior to the implementation of this feature, the only VRG support was HSRP. Within a VRG that is formed by HSRP, the forwarding of UDP-based broadcast and multicast packets is done by all the routers within the VRG. This process can cause some DHCP servers to operate incorrectly. The UDP Forwarding Support for VRGs feature limits forwarding to the active router in the VRG.

VRG awareness is achieved with IP Redundancy Service (IRS). The IRS application programming interface (API) provides notification updates of a specific VRG, addition and deletion of a VRG, and querying of the current state of a VRG. A state change notification is provided to avoid the performance impact of querying the state of the VRG each time it is needed. The UDP forwarding code caches the VRG state for each required helper address that is defined. Each time the UDP forwarding code needs to execute, it checks the current state of the VRG associated with the helper address and forwards packets only to VRGs that are active.

How to Configure UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   no shutdown

5.   ip address ip-address mask

6.   ip helper-address address redundancy vrg-name

7.   standby group-number ip ip-address

8.   standby group-number name group-name

9.   end

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies an interface and enters interface configuration mode.

Example:

Router(config)# interface fastethernet 0/0

Step 4 no shutdown

Restarts a disabled interface.

Example:

Router(config-if)# no shutdown

Step 5 ip address ip-address mask

Sets a primary address for the interface.

Example:

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Step 6 ip helper-address address redundancy vrg-name

Enables UDP forwarding support for the VRG.

Example:

Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1

Step 7 standby group-number ip ip-address

Activates HSRP.

Example:

Router(config-if)# standby 1 ip 172.16.10.254

Step 8 standby group-number name group-name

Configures the name of the standby group.

Example:

Router(config-if)# standby 1 name vrg1

Step 9 end

Exits the current configuration mode and returns to privileged EXEC mode.

Example:

Router(config-if)# end

Configuration Examples for UDP Forwarding Support for IP Redundancy Virtual Router Groups

- Example: Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

Example: Configuring UDP Forwarding Support for IP Redundancy Virtual Router Groups

The following example shows how to configure UDP Forwarding Support for IP Redundancy Virtual Router Groups:

Router(config)# interface fastethernet 0/0

Router(config-if)# no shutdown

Router(config-if)# ip address 172.16.10.1 255.255.255.0

Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1

Router(config-if)# standby 1 ip 172.16.10.254

Router(config-if)# standby 1 name vrg1

Router(config-if)# end

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

IP application services commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS IP Application Services Command Reference

Standards

Standard

Title

No new or modified standards are supported, and support for existing standards has not been modified

--

MIBs

MIB

MIBs Link

No new or modified MIBs are supported, and support for existing MIBs has not been modified

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

RFCs

RFC

Title

No new or modified RFCs are supported, and support for existing RFCs has not been modified

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for UDP Forwarding Support for IP Redundancy Virtual Router Groups

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 8

Feature Information for UDP Forwarding Support for IP Redundancy Virtual Router Groups

Feature Name

Releases

Feature Information

UDP Forwarding Support for IP Redundancy Virtual Router Group

Cisco IOS XE 3.1.0SG

12.2(50)SY

12.2(15)T

15.0(1)SY

15.2(1)S

UDP forwarding is a feature used in Cisco IOS software to forward broadcast and multicast packets received for a specific IP address. Virtual Router Group (VRG) support is implemented with the Hot Standby Routing Protocol (HSRP) and it allows a set of routers to be grouped as a logical router that answers to a well-known IP address. The UDP Forwarding Support for IP Redundancy Virtual Router Groups feature enables UDP forwarding to be VRG aware, resulting in forwarding only to the active router in the VRG.

The following command was introduced or modified: ip helper-address.

Configuring WCCP

The Web Cache Communication Protocol (WCCP) is a Cisco-developed content-routing technology that intercepts IP packets and redirects those packets to a destination other than that specified in the IP packet. Typically the packets are redirected from their destination web server on the Internet to a content engine that is local to the client. In some WCCP deployment scenarios, redirection of traffic may also be required from the web server to the client. WCCP enables you to integrate content engines into your network infrastructure.

Cisco IOS Release 12.1 and later releases allow the use of either WCCP Version 1 (WCCPv1) or Version 2 (WCCPv2).

The tasks in this document assume that you have already configured content engines on your network. For specific information on hardware and network planning associated with Cisco Content Engines and WCCP, see the Cisco Content Engines documentation at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/webscale/content/index.htm

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for WCCP

- To use WCCP, IP must be configured on the interface connected to the Internet and another interface must be connected to the content engine.

- The interface connected to the content engine must be a Fast Ethernet or Gigabit Ethernet interface.

- Only Catalyst 6500 series switches with a PFC4 support the following hardware capabilities:

- WCCP generic routing encapsulation (GRE) decapsulation in hardware

- WCCP Egress Mask assignment in hardware

- WCCP Exclude capability in hardware

Restrictions for WCCP

General

The following limitations apply to WCCPv1 and WCCPv2:

- WCCP works only with IPv4 networks.

- WCCP bypasses Network Address Translation (NAT) when Cisco Express Forwarding is enabled.

WCCPv1

The following limitations apply to WCCPv1:

- WCCPv1 supports the redirection of HTTP (TCP port 80) traffic only.

- WCCPv1 does not allow multiple routers to be attached to a cluster of content engines.

WCCPv2

The following limitations apply to WCCPv2:

- WCCP works only with IPv4 networks.

- For routers servicing a multicast cluster, the Time To Live (TTL) value must be set at 15 or fewer.

- Service groups can comprise up to 32 content engines and 32 routers.

- All content engines in a cluster must be configured to communicate with all routers servicing the cluster.

- Multicast addresses must be from 224.0.0.0 to 239.255.255.255.

WCCP VRF Support

In Cisco IOS Release 12.2(33)SRE, this feature is supported only on Cisco 7200 NPE-G2 and Cisco 7304-NPE-G100 routers.

This feature is supported in Cisco IOS Release 12.2(50)SY on Catalyst 6000 series switches with a PFC4.

Layer 2 Forwarding and Return

The following limitations apply to WCCP Layer 2 Forwarding and Return:

- Layer 2 redirection requires that content engines be directly connected to an interface on each WCCP router. Unless multicast IP addresses are used, WCCP configuration of the content engine must reference the directly connected interface IP address of the WCCP router and not a loopback IP address or any other IP address configured on the WCCP router.

Cisco Catalyst 4500 Series Switches

The following limitations apply to Cisco Catalyst 4500 series switches:

- Catalyst 4500 series switches do not support WCCPv1.

- Up to eight service groups are supported at the same time on the same client interface.

- The Layer 2 (L2) rewrite forwarding method is supported, but generic routing encapsulation (GRE) is not.

- Direct L2 connectivity to content engines is required; Layer 3 (L3) connectivity of one or more hops away is not supported.

- Ternary content addressable memory (TCAM) friendly mask-based assignment is supported, but the hash bucket-based method is not.

- Redirect ACL for WCCP on a client interface is not supported.

- Incoming traffic redirection on an interface is supported, but outgoing traffic redirection is not.

- When TCAM space is exhausted, traffic is not redirected; it is forwarded normally.

- The WCCP version 2 standard allows for support of up to 256 distinct masks. However, a Catalyst 4500 series switch supports only mask assignment tables with a single mask.

Cisco Catalyst 6500 Series Switches

The following limitation apply to Cisco Catalyst 6500 series switches:

- With a Policy Feature Card 2 (PFC2), Cisco IOS Release 12.2(17d)SXB and later releases support WCCP.

- With a PFC3, Cisco IOS Release 12.2(18)SXD1 and later releases support WCCP.

- With a PFC4, Cisco IOS Release 12.2(50)SY and later releases support WCCP and introduce support for WCCP GRE decapsulation, WCCP mask assignment, and WCCP exclude capability in hardware.

- To use the WCCP Layer 2 PFC redirection feature, configure WCCP on the Catalyst 6500 series switch and configure accelerated WCCP on the cache engine as described in the Transparent Caching document.

- Cisco Application and Content Networking System (ACNS) software releases later than Release 4.2.2 support WCCP Layer 2 Policy Feature Card (PFC) redirection hardware acceleration.

- A content engine configured for mask assignment that tries to join a farm where the selected assignment method is hash remains out of the farm as long as the cache engine assignment method does not match that of the existing farm.

- When WCCP Layer 2 PFC redirection is the forwarding method for a service group, the packet counters in the show ip wccp service-number command output display flow counts instead of packet counts.

Catalyst 6500 Series Switches and Cisco 7600 Series Routers Access Control Lists

When WCCP is using the mask assignment, any redirect list is merged with the mask information from the appliance and the resulting merged ACL is passed down to the Catalyst 6500 series switch or Cisco 7600 series router hardware. Only Permit or Deny ACL entries from the redirect list in which the protocol is IP or exactly matches the service group protocol are merged with the mask information from the appliance.

The following restrictions apply to the redirect-list ACL:

- The ACL must be an IPv4 simple or extended ACL.

- Only individual source or destination port numbers may be specified; port ranges cannot be specified.

- The only valid matching criteria in addition to individual source or destination port numbers are dscp or tos.

- The use of fragments, time-range, or options keywords, or any TCP flags is not permitted.

If the redirect ACL does not meet the restrictions shown, the system will log the following error message:

WCCP-3-BADACE: Service <service group>, invalid access-list entry (seq:<sequence>, reason:<reason>)

WCCP continues to redirect packets, but the redirection is carried out in software (NetFlow Switching) until the access list is adjusted.

Information About WCCP

- WCCP Overview

- Layer 2 Forwarding Redirection and Return

- Hardware Acceleration

- WCCPv1 Configuration

- WCCPv2 Configuration

- WCCPv2 Support for Services Other Than HTTP

- WCCPv2 Support for Multiple Routers

- WCCPv2 MD5 Security

- WCCPv2 Web Cache Packet Return

- WCCPv2 Load Distribution

- WCCP Bypass Packets

- WCCP Service Groups

- WCCP--Check All Services

- WCCP Interoperability with NAT

- WCCP Troubleshooting Tips

WCCP Overview

WCCP uses Cisco Content Engines (or other content engines running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.

WCCP enables Cisco IOS XE routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a content engine. The word "transparent" in this case means that the end user does not know that a requested file (such as a web page) came from the content engine instead of from the originally specified server.

A content engine receiving a request attempts to service it from its own local cache. If the requested information is not present, the content engine issues its own request to the originally targeted server to get the required information. A content engine retrieving the requested information forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.

WCCP enables a series of content engines, called a content engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their content engines to manage heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cluster member to work in parallel, resulting in linear scalability. Clustering content engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 content engines to scale to your desired capacity.

Layer 2 Forwarding Redirection and Return

WCCP uses either generic routing encapsulation (GRE) or Layer 2 (L2) to redirect or return IP traffic. When WCCP forwards traffic via GRE, the redirected packets are encapsulated within a GRE header. The packets also have a WCCP redirect header. When WCCP forwards traffic using L2, the original MAC header of the IP packet is overwritten and replaced with the MAC header for the WCCP client.

Using L2 as a forwarding method allows direct forwarding to the content engine without further lookup. Layer 2 redirection requires that the router and content engines are directly connected, that is, on the same IP subnetwork.

When WCCP returns traffic via GRE, the returned packets are encapsulated within a GRE header. The destination IP address is the address of the router and the source address is the address of the WCCP client. When WCCP returns traffic via L2, the original IP packet is returned without any added header information. The router to which the packet is returned will recognize the source of the packet and prevent redirection.

The WCCP redirection method does not have to match the return method.

L2 forwarding, return, or redirection are typically used for hardware accelerated platforms. Depending on your release, L2 forwarding, return, and redirection can also be used for software switching platforms.

For content engines running Application and Content Networking System (ACNS) software, use the wccp custom-web-cache command with the l2-redirect keyword to configure L2 redirection. For content engines running Cisco Wide Area Application Services (WAAS) software, use the wccp tcp-promiscuous command with the l2-redirect keyword to configure L2 redirection.

For information about Cisco ACNS commands used to configure Cisco Content Engines, see the Cisco ACNS Software Command Reference.

For more information about WAAS commands used to configure Cisco Content Engines, see theCisco Wide Area Application Services Command Reference.

Hardware Acceleration

Catalyst 6500 series switches and Cisco 7600 series routers provide WCCP Layer 2 Policy Feature Card (PFC) redirection hardware acceleration. Hardware acceleration allows Cisco Content Engines to perform a L2 MAC address rewrite redirection method when directly connected to a compatible switch or router.

Redirection processing is accelerated in the switching or routing hardware, which is more efficient than L3 redirection with Generic Routing Encapsulation (GRE). L2 redirection takes place on the switch or router, and is not visible to the Multilayer Switch Feature Card (MSFC). The WCCP L2 PFC redirection feature requires no configuration on the MSFC. The show ip wccp {service-number | web-cache} detail command displays which redirection method is in use for each content engine.

In order for the router or switch to make complete use of hardware redirection, the content engine must be configured with L2 redirection and mask assignment.

Use the ip wccp web-cache accelerated command on hardware-based platforms to enforce the use of L2 redirection and mask assignment. Using this command configures the router to form a service group and redirect packets with an appliance only if the appliance is configured for L2 and mask assignment.

The following guidelines apply to WCCP Layer 2 PFC redirection:

- The WCCP Layer 2 PFC redirection feature sets the IP flow mask to full-flow mode.

- You can configure the Cisco Cache Engine software Release 2.2 or later releases to use the WCCP Layer 2 PFC redirection feature.

- L2 redirection takes place on the PFC and is not visible to the MSFC. The show ip wccp {service-number | web-cache} detail command on the MSFC displays statistics for only the first packet of an L2 redirected flow, which provides an indication of how many flows, rather than packets, are using L2 redirection. You can view information about L2 redirected flows by entering the show platform flow ip command. The PFC3 provides hardware acceleration for GRE. If you use WCCP Layer 3 redirection with GRE, there is hardware support for encapsulation, but the PFC3 does not provide hardware support for decapsulation of WCCP GRE traffic.

WCCPv1 Configuration

With WCCPv1, only a single router services a cluster. In this scenario, this router is the device that performs all the IP packet redirection. The figure below illustrates the WCCPv1 configuration.

Figure 6

WCCPv1 Configuration

Content is not duplicated on the content engines. The benefit of using multiple content engines is that you can scale a caching solution by clustering multiple physical content engines to appear as one logical cache.

The following sequence of events details how WCCPv1 configuration works:

1. Each content engine is configured by the system administrator with the IP address of the control router. Up to 32 content engines can connect to a single control router.

2. The content engines send their IP addresses to the control router using WCCP, indicating their presence. Routers and content engines communicate to each other via a control channel; this channel is based on UDP port 2048.

3. This information is used by the control router to create a cluster view (a list of caches in the cluster). This view is sent to each content engine in the cluster, essentially making all the content engines aware of each other. A stable view is established after the membership of the cluster remains the same for a certain amount of time.

4. When a stable view has been established, one content engine is elected as the lead content engine. (The lead is defined as the content engine seen by all the content engines in the cluster with the lowest IP address). This lead content engine uses WCCP to indicate to the control router how IP packet redirection should be performed. Specifically, the lead content engine designates how redirected traffic should be distributed across the content engines in the cluster.

WCCPv2 Configuration

Multiple routers can use WCCPv2 to service a content engine cluster. In WCCPv1, only one router could redirect content requests to a cluster. The figure below illustrates a sample configuration using multiple routers.

Figure 7

Cisco Content Engine Network Configuration Using WCCPv2

The subset of content engines within a cluster and routers connected to the cluster that are running the same service is known as a service group. Available services include TCP and UDP redirection.

In WCCPv1, the content engines were configured with the address of the single router. WCCPv2 requires that each content engine be aware of all the routers in the service group. To specify the addresses of all the routers in a service group, you must choose one of the following methods:

- Unicast--A list of router addresses for each of the routers in the group is configured on each content engine. In this case the address of each router in the group must be explicitly specified for each content engine during configuration.

- Multicast--A single multicast address is configured on each content engine. In the multicast address method, the content engine sends a single-address notification that provides coverage for all routers in the service group. For example, a content engine could indicate that packets should be sent to a multicast address of 224.0.0.100, which would send a multicast packet to all routers in the service group configured for group listening using WCCP (see the ip wccp group-listen or the ipv6 wccp group-listen interface configuration command for details).

The multicast option is easier to configure because you need only specify a single address on each content engine. This option also allows you to add and remove routers from a service group dynamically, without needing to reconfigure the content engines with a different list of addresses each time.

The following sequence of events details how WCCPv2 configuration works:

1. Each content engine is configured with a list of routers.

2. Each content engine announces its presence and a list of all routers with which it has established communications. The routers reply with their view (list) of content engines in the group.

3. When the view is consistent across all content engines in the cluster, one content engine is designated as the lead and sets the policy that the routers need to deploy in redirecting packets.

WCCPv2 Support for Services Other Than HTTP

WCCPv2 allows redirection of traffic other than HTTP (TCP port 80 traffic), including a variety of UDP and TCP traffic. WCCPv1 supported the redirection of HTTP (TCP port 80) traffic only. WCCPv2 supports the redirection of packets intended for other ports, including those used for proxy-web cache handling, File Transfer Protocol (FTP) caching, FTP proxy handling, web caching for ports other than 80, and Real Audio, video, and telephony applications.

To accommodate the various types of services available, WCCPv2 introduced the concept of multiple service groups. Service information is specified in the WCCP configuration commands using dynamic services identification numbers (such as 98) or a predefined service keyword (such as web-cache). This information is used to validate that service group members are all using or providing the same service.

The content engines in a service group specify traffic to be redirected by protocol (TCP or UDP) and up to eight source or destination ports. Each service group has a priority status assigned to it. The priority of a dynamic service is assigned by the content engine. The priority value is in the range of 0 to 255 where 0 is the lowest priority. The predefined web-cache service has an assigned priority of 240.

WCCPv2 Support for Multiple Routers

WCCPv2 allows multiple routers to be attached to a cluster of cache engines. The use of multiple routers in a service group allows for redundancy, interface aggregation, and distribution of the redirection load. WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently.

WCCPv2 MD5 Security

WCCPv2 provides optional authentication that enables you to control which routers and content engines become part of the service group using passwords and the Hashed Message Authentication Code--Message Digest (HMAC MD5) standard. Shared-secret MD5 one-time authentication (set using the ip wccp [password [0 | 7] password] global configuration command) enables messages to be protected against interception, inspection, and replay.

WCCPv2 Web Cache Packet Return

If a content engine is unable to provide a requested object it has cached due to error or overload, the content engine will return the request to the router for onward transmission to the originally specified destination server. WCCPv2 provides a check on packets that determines which requests have been returned from the content engine unserviced. Using this information, the router can then forward the request to the originally targeted server (rather than attempting to resend the request to the content engine cluster). This process provides error handling transparency to clients.

Typical reasons why a content engine would reject packets and initiate the packet return feature include the following:

- Instances when the content engine is overloaded and has no room to service the packets

- Instances when the content engine is filtering for certain conditions that make caching packets counterproductive (for example, when IP authentication has been turned on)

WCCPv2 Load Distribution

WCCPv2 can be used to adjust the load being offered to individual content engines to provide an effective use of the available resources while helping to ensure high quality of service (QoS) to the clients. WCCPv2 allows the designated content engine to adjust the load on a particular content engine and balance the load across the content engines in a cluster. WCCPv2 uses three techniques to perform load distribution:

- Hot spot handling--Allows an individual hash bucket to be distributed across all the content engines. Prior to WCCPv2, information from one hash bucket could go to only one content engine.

- Load balancing--Allows the set of hash buckets assigned to a content engine to be adjusted so that the load can be shifted from an overwhelmed content engine to other members that have available capacity.

- Load shedding--Enables the router to selectively redirect the load to avoid exceeding the capacity of a content engine.

The use of these hashing parameters prevents one content engine from being overloaded and reduces the potential for bottlenecking.

WCCP Bypass Packets

WCCP intercepts IP packets and redirects those packets to a destination other than the destination that is specified in the IP header. Typically the packets are redirected from a web server on the Internet to a web cache that is local to the destination.

Occasionally a web cache cannot manage the redirected packets appropriately and returns the packets unchanged to the originating router. These packets are called bypass packets and are returned to the originating router using either Layer 2 forwarding without encapsulation (L2) or encapsulated in generic routing encapsulation (GRE). The router decapsulates and forwards the packets normally. The VRF associated with the ingress interface (or the global table if there is no VRF associated) is used to route the packet to the destination.

GRE is a tunneling protocol developed by Cisco that encapsulates packet types from a variety of protocols inside IP tunnels, creating a virtual point-to-point link over an IP network.

WCCP Service Groups

WCCP is a component of Cisco IOS software that redirects traffic with defined characteristics from its original destination to an alternative destination. The typical application of WCCP is to redirect traffic bound for a remote web server to a local web cache to improve response time and optimize network resource usage.

The nature of the selected traffic for redirection is defined by service groups (see figure below) specified on content engines and communicated to routers by using WCCP. The maximum number of service groups allowed across all VRFs is 256.

WCCPv2 supports up to 32 routers per service group. Each service group is established and maintained independently.

WCCPv2 uses service groups based on logical redirection services, deployed for intercepting and redirecting traffic. The standard service is web cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the content engines. This service is referred to as a well-known service, because the characteristics of the web cache service are known by both the router and content engines. A description of a well-known service is not required beyond a service identification. To specify the standard web cache service, use the ip wccp or the ipv6 wccp command with the web-cache keyword.

Note

More than one service can run on a router at the same time, and routers and content engines can be part of multiple service groups at the same time.

Figure 8

WCCP Service Groups

The dynamic services are defined by the content engines; the content engine instructs the router which protocol or ports to intercept, and how to distribute the traffic. The router itself does not have information on the characteristics of the dynamic service group's traffic, because this information is provided by the first content engine to join the group. In a dynamic service, up to eight ports can be specified within a single protocol.

Cisco Content Engines, for example, use dynamic service 99 to specify a reverse-proxy service. However, other content engine devices may use this service number for some other service.

WCCP--Check All Services

An interface may be configured with more than one WCCP service. When more than one WCCP service is configured on an interface, the precedence of a service depends on the relative priority of the service compared to the priority of the other configured services. Each WCCP service has a priority value as part of its definition. When an interface is configured with more than one WCCP service, the precedence of the packets is matched against service groups in priority order.

Note

The priority of a WCCP service group cannot be configured via Cisco IOS software.

With the ip wccp check services all or the ipv6 wccp check services all command, WCCP can be configured to check all configured services for a match and perform redirection for those services if appropriate. The caches to which packets are redirected can be controlled by a redirect ACL and by the service priority.

If no WCCP services are configured with a redirect ACL, the services are considered in priority order until a service is found that matches the IP packet. If no services match the packet, the packet is not redirected. If a service matches the packet and the service has a redirect ACL configured, then the IP packet will be checked against the ACL. If the packet is rejected by the ACL, the packet will not be passed down to lower priority services unless the ip wccp check services all or the ipv6 wccp check services all command is configured. When the ip wccp check services all or the ipv6 wccp check services all command is configured, WCCP will continue to attempt to match the packet against any remaining lower priority services configured on the interface.

WCCP Interoperability with NAT

To redirect traffic using WCCP to a router running WAAS software that is also configured with NAT, enable the ip nat inside or the ipv6 nat inside command on the WAAS interface. If you are not able to configure the ip nat inside or theipv6 nat inside command on the WAAS interface, disable Cisco Express Forwarding. You must also update the WCCP redirect ACL to include a private address to ensure that pretranslated traffic is redirected.

WCCP Troubleshooting Tips

CPU usage may be very high when WCCP is enabled. The WCCP counters enable a determination of the bypass traffic directly on the router and can indicate whether the cause is high CPU usage due to enablement of WCCP. In some situations, 10 percent bypass traffic may be normal; in other situations, 10 percent may be high. However, any figure above 25 percent should prompt a closer investigation of what is occurring in the web cache.

If the counters suggest that the level of bypass traffic is high, the next step is to examine the bypass counters in the content engine and determine why the content engine is choosing to bypass the traffic. You can log in to the content engine console and use the CLI to investigate further. The counters allow you to determine the percent of traffic being bypassed.

How to Configure WCCP

The following configuration tasks assume that you have already installed and configured the content engines you want to include in your network. You must configure the content engines in the cluster before configuring WCCP functionality on your routers or switches. Refer to the Cisco Cache Engine User Guide for content engine configuration and setup tasks.

Configuring WCCP

Perform this task to configure WCCP.

Until you configure a WCCP service using the ip wccp{web-cache | service-number} global configuration command, WCCP is disabled on the router. The first use of a form of the ip wccp command enables WCCP. By default WCCPv2 is used for services, but you can use WCCPv1 functionality instead.

Use the ip wccp web-cache password command to set a password for a router and the content engines in a service group. MD5 password security requires that each router and content engine that wants to join a service group be configured with the service group password. The password must be up to eight characters in length. Each content engine or router in the service group will authenticate the security component in a received WCCP packet immediately after validating the WCCP message header. Packets failing authentication will be discarded.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   ip wccp [vrf vrf-name] {web-cache | service-number} [group-address multicast-address] [redirect-list access-list] [group-list access-list] [password password [0 | 7] ]

4.   interface type number

5.   ip wccp [vrf vrf-name] {web-cache | service-number} redirect {in | out}

6.   exit

7.   interface type number

8.   ip wccp redirect exclude in

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 ip wccp [vrf vrf-name] {web-cache | service-number} [group-address multicast-address] [redirect-list access-list] [group-list access-list] [password password [0 | 7] ]

Specifies a web-cache or dynamic service to enable on the router, specifies a VRF-name to associate with the service group, specifies the IP multicast address used by the service group, specifies any access lists to use, specifies whether to use MD5 authentication, and enables the WCCP service.

Example:

Device(config)# ip wccp web-cache password password1

Step 4 interface type number

Targets an interface number for which the web cache service will run, and enters interface configuration mode.

Example:

Device(config)# interface ethernet0/0

Step 5 ip wccp [vrf vrf-name] {web-cache | service-number} redirect {in | out}

Enables packet redirection on an outbound or inbound interface using WCCP.

- As indicated by the out and in keyword options, redirection can be specified for outbound interfaces or inbound interfaces.

Example:

Device(config-if)# ip wccp web-cache redirect in

Step 6 exit

Exits interface configuration mode.

Example:

Device(config-if)# exit

Step 7 interface type number

Targets an interface number on which to exclude traffic for redirection, and enters interface configuration mode.

Example:

Device(config)# interface GigabitEthernet 0/2/0

Step 8 ip wccp redirect exclude in

(Optional) Excludes traffic on the specified interface from redirection.

Example:

Device(config-if)# ip wccp redirect exclude in

Configuring Closed Services

Perform this task to specify the number of service groups for WCCP, to configure a service group as a closed or open service, and to optionally specify a check of all services.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   Enter one of the following commands:

- ip wccp [vrf vrf-name] service-number [service-list service-access-list mode {open | closed}]

- or

- ip wccp [vrf vrf-name] web-cache mode {open | closed}

4.   ip wccp check services all

5.   ip wccp [vrf vrf-name ] {web-cache | service-number}

6.   exit

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 Enter one of the following commands:

Configures a dynamic WCCP service as closed or open.

or

Configures a web-cache service as closed or open.

Note

When configuring the web-cache service as a closed service, you cannot specify a service access list.

Note

When configuring a dynamic WCCP service as a closed service, you must specify a service access list.

- ip wccp [vrf vrf-name] service-number [service-list service-access-list mode {open | closed}]

- or

- ip wccp [vrf vrf-name] web-cache mode {open | closed}

Example:

Device(config)# ip wccp 90 service-list 120 mode closed

or

Device(config)# ip wccp web-cache mode closed

Step 4 ip wccp check services all

(Optional) Enables a check of all WCCP services.

- Use this command to configure WCCP to check the other configured services for a match and perform redirection for those services if appropriate. The caches to which packets are redirected can be controlled by the redirect ACL and not just the service description.

Note

The ip wccp check services all command is a global WCCP command that applies to all services and is not associated with a single service.

Example:

Device(config)# ip wccp check services all

Step 5 ip wccp [vrf vrf-name ] {web-cache | service-number}

Specifies the WCCP service identifier.

- You can specify the standard web-cache service or a dynamic service number from 0 to 255.

- The maximum number of services that can be specified is 256.

Example:

Device(config)# ip wccp 201

Step 6 exit

Exits to privileged EXEC mode.

Example:

Device(config)# exit

Registering a Router to a Multicast Address

If you decide to use the multicast address option for your service group, you must configure the router to listen for the multicast broadcasts on an interface.

For network configurations where redirected traffic needs to traverse an intervening router, the router being traversed must be configured to perform IP multicast routing. You must configure the following two components to enable traversal over an intervening router:

- Enable IP multicast routing using the ip multicast-routing global configuration command.

- Enable the interfaces to which the cache engines will connect to receive multicast transmissions using the ip wccp group-listen interface configuration command.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   ip multicast-routing [vrf vrf-name] [distributed]

4.   ip wccp [vrf vrf-name] {web-cache | service-number} group-address multicast-address

5.   interface type number

6.   ip pim {sparse-mode | sparse-dense-mode | dense-mode [proxy-register {list access-list | route-map map-name}]}

7.   ip wccp [vrf vrf-name] {web-cache | service-number} group-listen

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 ip multicast-routing [vrf vrf-name] [distributed]

Enables IP multicast routing.

Example:

Device(config)# ip multicast-routing

Step 4 ip wccp [vrf vrf-name] {web-cache | service-number} group-address multicast-address

Specifies the multicast address for the service group.

Example:

Device(config)# ip wccp 99 group-address 239.1.1.1

Step 5 interface type number

Enables the interfaces to which the content engines will connect to receive multicast transmissions for which the web cache service will run, and enters interface configuration mode.

Example:

Device(config)# interface ethernet 0/0

Step 6 ip pim {sparse-mode | sparse-dense-mode | dense-mode [proxy-register {list access-list | route-map map-name}]}

(Optional) Enables Protocol Independent Multicast (PIM) on an interface.

Note

To ensure correct operation of the ip wccp group-listen command on Catalyst 6500 series switches and Cisco 7600 series routers, you must enter the ip pim command in addition to the ip wccp group-listen command.

Example:

Device(config-if)# ip pim dense-mode

Step 7 ip wccp [vrf vrf-name] {web-cache | service-number} group-listen

Configures an interface to enable or disable the reception of IP multicast packets for WCCP.

Example:

Device(config-if)# ip wccp 99 group-listen

Using Access Lists for a WCCP Service Group

Perform this task to configure the device to use an access list to determine which traffic should be directed to which content engines.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   access-list access-list-number remark remark

4.   access-list access-list-number permit {source [source-wildcard] | any} [log]

5.   access-list access-list-number remark remark

6.   access-list access-list-number deny {source [source-wildcard] | any} | [log]

7.    Repeat some combination of Steps 3 through 6 until you have specified the sources on which you want to base your access list.

8.   ip wccp [vrf vrf-name] web-cache group-list access-list

9.   ip wccp [vrf vrf-name] web-cache redirect-list access-list

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Device# configure terminal

Step 3 access-list access-list-number remark remark

(Optional) Adds a user-friendly comment about an access list entry.

- A remark of up to 100 characters can precede or follow an access list entry.

Example:

Device(config)# access-list 1 remark Give access to user1

Step 4 access-list access-list-number permit {source [source-wildcard] | any} [log]

Creates an access list that enables or disables traffic redirection to the cache engine and permits the specified source based on a source address and wildcard mask.

- Every access list needs at least one permit statement; it does not need to be the first entry.

- Standard IP access lists are numbered 1 to 99 or 1300 to 1999.

- If the source-wildcard is omitted, a wildcard mask of 0.0.0.0 is assumed, meaning match on all bits of the source address.

- Optionally use the keyword any as a substitute for the source source-wildcard to specify the source and source wildcard of 0.0.0.0 255.255.255.255.

- In this example, host 172.16.5.22 is allowed to pass the access list.

Example:

Device(config)# access-list 1 permit 172.16.5.22 0.0.0.0

Step 5 access-list access-list-number remark remark

(Optional) Adds a user-friendly comment about an access list entry.

- A remark of up to 100 characters can precede or follow an access list entry.

Example:

Device(config)# access-list 1 remark Give access to user1

Step 6 access-list access-list-number deny {source [source-wildcard] | any} | [log]

Denies the specified source based on a source address and wildcard mask.

- If the source-wildcard is omitted, a wildcard mask of 0.0.0.0 is assumed, meaning match on all bits of the source address.

- Optionally use the abbreviation any as a substitute for the source source-wildcard to specify the source and source wildcard of 0.0.0.0 255.255.255.255.

- In this example, host 172.16.7.34 is denied passing the access list.

Example:

Device(config)# access-list 1 deny 172.16.7.34 0.0.0.0

Step 7 Repeat some combination of Steps 3 through 6 until you have specified the sources on which you want to base your access list.

Remember that all sources not specifically permitted are denied by an implicit deny statement at the end of the access list.

Step 8 ip wccp [vrf vrf-name] web-cache group-list access-list

Indicates to the device from which IP addresses of content engines to accept packets.

Example:

Device(config) ip wccp web-cache group-list 1

Step 9 ip wccp [vrf vrf-name] web-cache redirect-list access-list

(Optional) Disables caching for certain clients.

Example:

Device(config)# ip wccp web-cache redirect-list 1

Enabling WCCP Interoperability with NAT

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   ip nat inside

5.   ip wccp service-number redirect in

6.   exit

7.   interface type number

8.   ip nat outside

9.   ip wccp service-number redirect in

10.   exit

11.   interface type number

12.   ip nat inside

13.   ip wccp redirect exclude in

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies an interface on which to enable NAT and enters interface configuration mode.

- This is the LAN-facing interface.

Example:

Router(config)# interface ethernet 1

Step 4 ip nat inside

Designates that traffic originating from or destined for the interface is subject to NAT and indicates that the interface is connected to the inside network (the network subject to NAT translation).

Example:

Router(config-if)# ip nat inside

Step 5 ip wccp service-number redirect in

Enables packet redirection on an inbound interface using WCCP.

Example:

Router(config-if)# ip wccp 61 redirect in

Step 6 exit

Exits interface configuration mode and returns to global configuration mode.

Example:

Router(config-if)# exit

Step 7 interface type number

Specifies an interface on which to enable NAT and enters interface configuration mode.

- This is the WAN-facing interface.

Example:

Router(config)# interface ethernet 2

Step 8 ip nat outside

Designates that traffic originating from or destined for the interface is subject to NAT and indicates that the interface is connected to the outside network.

Example:

Router(config-if)# ip nat outside

Step 9 ip wccp service-number redirect in

Enables packet redirection on an inbound interface using WCCP.

Example:

Router(config-if)# ip wccp 62 redirect in

Step 10 exit

Exits interface configuration mode and returns to global configuration mode.

Example:

Router(config-if)# exit

Step 11 interface type number

Specifies an interface on which to enable NAT and enters interface configuration mode.

- This is the WAAS-facing interface.

Example:

Router(config)# interface ethernet 3

Step 12 ip nat inside

Designates that traffic originating from or destined for the interface is subject to NAT and indicates that the interface is connected to the inside network (the network subject to NAT translation).

Example:

Router(config-if)# ip nat inside

Step 13 ip wccp redirect exclude in

Configures an interface to exclude packets received on an interface from being checked for redirection..

Example:

Router(config-if)# ip wccp redirect exclude in

Verifying and Monitoring WCCP Configuration Settings

SUMMARY STEPS

1.   enable

2.   show ip wccp [vrf vrf-name] [web-cache |service-number] [detail view]

3.   show ip interface

4.   more system:running-config

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2 show ip wccp [vrf vrf-name] [web-cache |service-number] [detail view]

Displays global information related to WCCP, including the protocol version running, the number of content engines in the router service group, which content engine group is allowed to connect to the router, and which access list is being used.

- vrf vrf-name--(Optional) Virtual routing and forwarding (VRF) instance associated with a service group.

- service-number--(Optional) Dynamic number of the web-cache service group being controlled by the content engine. The range is from 0 to 99. For web caches that use Cisco Content Engines, the reverse proxy service is indicated by a value of 99.

- web-cache--(Optional) statistics for the web-cache service.

- detail--(Optional) other members of a particular service group or web cache that have or have not been detected.

- view--(Optional) information about a router or all web caches.

Example:

Device# show ip wccp 24 detail

Step 3 show ip interface

Displays status about whether any ip wccp redirection commands are configured on an interface; for example, "Web Cache Redirect is enabled / disabled."

Example:

Device# show ip interface

Step 4 more system:running-config

(Optional) Displays contents of the running configuration file (equivalent to the show running-config command).

Example:

Device# more system:running-config

Configuration Examples for WCCP

- Example: Changing the Version of WCCP on a Router

- Example: Configuring a General WCCPv2 Session

- Example: Setting a Password for a Router and Content Engines

- Example: Configuring a Web Cache Service

- Example: Running a Reverse Proxy Service

- Example: Registering a Router to a Multicast Address

- Example: Using Access Lists

- Example: WCCP Outbound ACL Check Configuration

- Example: Verifying WCCP Settings

- Example: Enabling WCCP Interoperability with NAT

Example: Changing the Version of WCCP on a Router

The following example shows how to change the WCCP version from the default of WCCPv2 to WCCPv1, and enabling the web-cache service in WCCPv1:

Router# show ip wccp

% WCCP version 2 is not enabled

Router# configure terminal

Router(config)# ip wccp version 1

Router(config)# end

Router# show ip wccp

% WCCP version 1 is not enabled

Router# configure terminal

Router(config)# ip wccp web-cache

Router(config)# end

Router# show ip wccp

Global WCCP information:

Router information:

Router Identifier:                   10.4.9.8

Protocol Version:                    1.0

.

.

.

Example: Configuring a General WCCPv2 Session

Device# configure terminal

Device(config)# ip wccp web-cache group-address 224.1.1.100 password password1

Device(config)# ip wccp source-interface GigabitEthernet 0/1/0

Device(config)# ip wccp check services all

Configures a check of all WCCP services.

Device(config)# interface GigabitEthernet 0/1/0

Device(config-if)# ip wccp web-cache redirect in

Device(config-if)# exit

Device(config)# interface GigabitEthernet 0/2/0

Device(config-if)# ip wccp redirect exclude in

Device(config-if)# exit

Example: Setting a Password for a Router and Content Engines

Router# configure terminal

Router(config)# ip wccp web-cache password password1

Example: Configuring a Web Cache Service

Device# configure terminal

Device(config)# ip wccp web-cache

Device(config)# interface GigabitEthernet 0/1/0

Device(config-if)# ip wccp web-cache redirect in

Device(config-if)# exit

Device# copy running-config startup-config

The following example shows how to configure a session in which redirection of HTTP traffic arriving on Gigabit Ethernet interface 0/1/0 is enabled:

Device# configure terminal

Device(config)# interface GigabitEthernet 0/1/0

Device(config-if)# ip wccp web-cache redirect in

Device(config-if)# exit

Device# show ip interface GigabitEthernet 0/1/0

.

.

.

WCCP Redirect inbound is enabled

WCCP Redirect exclude is disabled

.

.

.

Example: Running a Reverse Proxy Service

The following example assumes that you are configuring a service group using Cisco cache engines, which use dynamic service 99 to run a reverse proxy service:

Router# configure terminal

Router(config)# ip wccp 99

Router(config)# interface gigabitethernet 0/1/0

Router(config-if)# ip wccp 99 redirect out

Example: Registering a Router to a Multicast Address

Device# configure terminal

Device(config)# ip wccp web-cache group-address 224.1.1.100

Device(config)# interface gigabitethernet 0/1/0

Device(config-if)# ip wccp web cache group-listen

The following example shows a router configured to run a reverse proxy service, using the multicast address of 224.1.1.1. Redirection applies to packets outgoing via Gigabit Ethernet interface 0/1/0:

Device# configure terminal

Device(config)# ip wccp 99 group-address 224.1.1.1

Device(config)# interface gigabitethernet 0/1/0

Device(config-if)# ip wccp 99 redirect out

Example: Using Access Lists

To achieve better security, you can use a standard access list to notify the device which IP addresses are valid addresses for a content engine attempting to register with the current device. The following example shows a standard access list configuration session where the access list number is 10 for some sample hosts:

Device(config)# access-list 10 permit host 10.1.1.1

Device(config)# access-list 10 permit host 10.1.1.2

Device(config)# access-list 10 permit host 10.1.1.3

Device(config)# ip wccp web-cache group-list 10

To disable caching for certain clients, servers, or client/server pairs, you can use WCCP access lists. The following example shows that any requests coming from 10.1.1.1 to 10.3.1.1 will bypass the cache, and that all other requests will be serviced normally:

Device(config)# ip wccp web-cache redirect-list 120

Device(config)# access-list 120 deny tcp host 10.1.1.1 any

Device(config)# access-list 120 deny tcp any host 10.3.1.1

Device(config)# access-list 120 permit ip any any

The following example configures a device to redirect web-related packets received via Gigabit Ethernet interface 0/1/0, destined to any host except 209.165.200.224:

Device(config)# access-list 100 deny ip any host 209.165.200.224

Device(config)# access-list 100 permit ip any any

Device(config)# ip wccp web-cache redirect-list 100

Device(config)# interface gigabitethernet 0/1/0

Device(config-if)# ip wccp web-cache redirect in

Example: WCCP Outbound ACL Check Configuration

The following configuration example shows that the access list prevents traffic from network 10.0.0.0 leaving Gigabit Ethernet interface 0/1/0. Because the outbound ACL check is enabled, WCCP does not redirect that traffic. WCCP checks packets against the ACL before they are redirected.

Device(config)# ip wccp web-cache

Device(config)# ip wccp check acl outbound

Device(config)# interface gigabitethernet 0/1/0

Device(config-if)# ip access-group 10 out

Device(config-if)# exit

Device(config)# ip wccp web-cache redirect-list redirect-out

Device(config)# access-list 10 deny 10.0.0.0 0.255.255.255

Device(config)# access-list 10 permit any

If the outbound ACL check is disabled, the HTTP packets from network 10.0.0.0 would be redirected to a web cache. Users with that network address could retrieve web pages even though the network administrator wanted to prevent it.

Example: Verifying WCCP Settings

The following example shows how to verify your configuration changes by using the more system:running-config command in privileged EXEC mode. The following example shows that both the web cache service and dynamic service 99 are enabled on the device:

Device# more system:running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname router4

!

enable secret 5 $1$nSVy$faliJsVQXVPW.KuCxZNTh1

enable password password1

!

ip subnet-zero

ip wccp web-cache

ip wccp 99

ip domain-name cisco.com

ip name-server 10.1.1.1

ip name-server 10.1.1.2

ip name-server 10.1.1.3

!

!

!

interface GigabitEthernet0/1/1

ip address 10.3.1.2 255.255.255.0

no ip directed-broadcast

ip wccp web-cache redirect in

ip wccp 99 redirect in

no ip route-cache

no ip mroute-cache

!

interface GigabitEthernet0/1/0

ip address 10.4.1.1 255.255.255.0

no ip directed-broadcast

ip wccp 99 redirect in

no ip route-cache

no ip mroute-cache

!

interface Serial0

no ip address

no ip directed-broadcast

no ip route-cache

no ip mroute-cache

shutdown

!

interface Serial1

no ip address

no ip directed-broadcast

no ip route-cache

no ip mroute-cache

shutdown

!

ip default-gateway 10.3.1.1

ip classless

ip route 0.0.0.0 0.0.0.0 10.3.1.1

no ip http server

!

!

!

line con 0

transport input none

line aux 0

transport input all

line vty 0 4

password password1

login

!

end

The following example shows how to display global statistics related to WCCP:

Device# show ip wccp web-cache detail

WCCP Client information:

WCCP Client ID:      10.1.1.2

Protocol Version:    2.0

State:               Usable

Redirection:         L2

Packet Return:       L2

Packets Redirected:  0

Connect Time:        00:20:34

Assignment:          MASK

Mask  SrcAddr    DstAddr    SrcPort DstPort

----  -------    -------    ------- -------

0000: 0x00000000 0x00001741 0x0000  0x0000

Value SrcAddr    DstAddr   SrcPort DstPort CE-IP

----- -------    -------   ------- ------- -----

0000: 0x00000000 0x00000000 0x0000 0x0000 0x3C010102 (10.1.1.2)

0001: 0x00000000 0x00000001 0x0000 0x0000 0x3C010102 (10.1.1.2)

0002: 0x00000000 0x00000040 0x0000 0x0000 0x3C010102 (10.1.1.2)

0003: 0x00000000 0x00000041 0x0000 0x0000 0x3C010102 (10.1.1.2)

0004: 0x00000000 0x00000100 0x0000 0x0000 0x3C010102 (10.1.1.2)

0005: 0x00000000 0x00000101 0x0000 0x0000 0x3C010102 (10.1.1.2)

0006: 0x00000000 0x00000140 0x0000 0x0000 0x3C010102 (10.1.1.2)

For more information about the show ip wccp web-cache command, see the Cisco IOS IP Application Services Command Reference.

Example: Enabling WCCP Interoperability with NAT

Router(config)# interface ethernet1 ! This is the LAN-facing interface

Router(config-if)# ip nat inside

Router(config-if)# ip wccp 61 redirect in

Router(config-if)# exit

Router(config)# interface ethernet2 ! This is the WAN-facing interface

Router(config-if)# ip nat outside

Router(config-if)# ip wccp 62 redirect in

Router(config-if)# exit

Router(config)# interface ethernet3 ! This is the WAAS-facing interface

Router(config-if)# ip nat inside

Router(config-if)# ip wccp redirect exclude in

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Cisco ACNS software configuration information

- Cisco ACNS Software Caching Configuration Guide, Release 4.2

- Cisco ACNS Software listing page on Cisco.com

IP access list overview, configuration tasks, and commands

Cisco IOS Security Command Reference

IP addressing and services commands and configuration tasks

- Cisco IOS IP Addressing Services Configuration Guide

- Cisco IOS IP Addressing Services Command Reference

WCCP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS IP Application Services Command Reference

Standards

Standard

Title

No new or modified standards are supported, and support for existing standards has not been modified.

--

MIBs

MIB

MIBs Link

No new or modified MIBs are supported, and support for existing MIBs has not been modified.

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

RFCs

RFC

Title

No new or modified RFCs are supported, and support for existing RFCs has not been modified.

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for WCCP

Table 9

Feature Information for WCCP

Feature Name

Releases

Feature Information

WCCP Increased Services

15.2(1)S

The WCCP Increased Services feature increases the number of services supported by WCCP to a maximum of 256 across all VRFs.

The following commands were modified by this feature: ip wccp, ip wccp check services all, ip wccp outbound-acl-check, show ip wccp.

WCCP Redirection on Inbound Interfaces

15.2(1)S

15.3(1)S

The WCCP Redirection on Inbound Interfaces feature enables interfaces to be configured for input redirection for a particular WCCP service. When this feature is enabled on an interface, all packets arriving at that interface are compared against the specified WCCP service. If the packets match, they will be redirected.

The following commands were introduced or modified by this feature: ip wccp redirect-list.

WCCP Version 2

15.2(1)S

The WCCP Version 2 feature provides several enhancements and features to the WCCP protocol, including:

- The ability of multiple routers to service a content engine cluster.

- Redirection of traffic other than HTTP (TCP port 80 traffic), including a variety of UDP and TCP traffic.

- Optional authentication that enables you to control which routers and content engines become part of the service group using passwords and the HMAC MD5 standard.

- A check on packets that determines which requests have been returned from the content engine unserviced.

- Load adjustments for individual content engines to provide an effective use of the available resources while helping to ensure high quality of service (QoS) to the clients.

The following commands were introduced or modified by this feature: clear ip wccp, ip wccp, ip wccp group-listen, ip wccp redirect, ip wccp redirect exclude in, ip wccp version, show ip wccp.

WCCP VRF Support

15.2(1)S

The WCCP VRF Support feature provides enhancements to the existing WCCPv2 protocol which support VRF awareness.

The following commands were introduced or modified by this feature: clear ip wccp, debug ip wccp, ip wccp, ip wccp group-listen, ip wccp redirect, show ip wccp.