Cisco IOS IP Application Services Configuration Guide, Release 12.4

Cisco IOS IP Application Services
Configuration Guide
Release 12.4
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Customer Order Number: DOC-7817478=

Text Part Number: 78-17478-01
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.
CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work,
Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP,
CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital,
the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink,
Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo,
Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet,
The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the
United States and certain other countries.
All other trademarks mentioned in this document or Website 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. (0601R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the
document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
Cisco IOS IP Application Services Configuration Guide

© 2005–2006 Cisco Systems, Inc. All rights reserved.
CONTENTS
About Cisco IOS Software Documentation for Release 12.4 xix
Documentation Objectives xix
Audience xix
Documentation Organization for Cisco IOS Release 12.4 xx
Document Conventions xxvi
Obtaining Documentation xxvii

Cisco.com xxvii
Product Documentation DVD xxviii
Ordering Documentation xxviii
Documentation Feedback xxviii
Cisco Product Security Overview xxix

Reporting Security Problems in Cisco Products xxix
Obtaining Technical Assistance xxx

Cisco Technical Support & Documentation Website xxx
Submitting a Service Request xxx
Definitions of Service Request Severity xxxi
Obtaining Additional Publications and Information xxxi
Using Cisco IOS Software for Release 12.4 xxxiii
Understanding Command Modes xxxiii
Getting Help xxxiv

Example: How to Find Command Options xxxv
Using the no and default Forms of Commands xxxviii
Saving Configuration Changes xxxviii
Filtering Output from the show and more Commands xxxix
Finding Additional Feature Support Information xxxix
PART 1: IP SERVICES
Configuring IP Services 3
Contents 3
How to Configure IP Services 3
Managing IP Connections 3
Enabling ICMP Protocol Unreachable Messages 4

78-17478-01 iii
Contents
Enabling ICMP Redirect Messages 4

Enabling ICMP Mask Reply Messages 5
Understanding Path MTU Discovery 5
Setting the MTU Packet Size 6
Enabling IP Source Routing 6
Configuring a DRP Server Agent 7
Enabling the DRP Server Agent 7
Limiting the Source of DRP Queries 8
Configuring Authentication of DRP Queries and Responses 8
Configuring IP Accounting 9
Configuring IP MAC Accounting 10
Configuring IP Precedence Accounting 11
Monitoring and Maintaining the IP Network 11
Clearing Caches, Tables, and Databases 11
Monitoring and Maintaining the DRP Server Agent 12
Displaying System and Network Statistics 12
IP Services Configuration Examples 12
ICMP Services: Example 12
DRP Server Agent: Example 13
IP Accounting: Example 13
PART 2: IP ACCESS LISTS
Configuring IP Access Lists 17
Contents 17
Information About Access Lists 17

How Access Lists Work 18
How to Configure Access Lists 18
Creating Standard and Extended Access Lists Using Numbers 18
Creating Standard and Extended Access Lists Using Names 21
Specifying IP Extended Access Lists with Fragment Control 23
Benefits of Fragment Control in an IP Extended Access List 25
Enabling Turbo Access Control Lists 26
Configuring Turbo ACLs 26
Verifying Turbo ACLs 27
Applying Time Ranges to Access Lists 27
Including Comments About Entries in Access Lists 28
Applying Access Lists 28
Controlling Access to a Line or Interface 29

iv 78-17478-01
Contents
Controlling Policy Routing and the Filtering of Routing Information 29

Controlling Dialer Functions 29
Clearing the Access List Counters 30
Configuration Examples for Access Lists 30
Numbered Access List: Example 30
Turbo Access Control List: Example 31
Implicit Masks in Access Lists: Example 31
Extended Access List: Example 32
Named Access List: Example 32
IP Extended Access List with Fragment Control: Example 33
Time Range Applied to an IP Access List: Example 33
Commented IP Access List Entry: Examples 33
Distributed Time-Based Access Lists 35
Feature Overview 35
Benefits 36
Related Documents 36
Supported Platforms 36
Supported Standards, MIBs, and RFCs 36
Configuration Tasks 37
Defining a Time Range 37
Referencing the Time Range 37
Verifying Distributed Time-Based Access Lists 38
Monitoring and Maintaining Distributed Time-Based Access Lists 38
Configuration Examples 38
Command Reference 39
Glossary 40
IP Access List Entry Sequence Numbering 41
Contents 41
Restrictions for IP Access List Entry Sequence Numbering 41
Information About IP Access Lists 42

Purpose of IP Access Lists 42
How an IP Access List Works 42
IP Access List Process and Rules 42
Helpful Hints for Creating IP Access Lists 43
Source and Destination Addresses 43
Wildcard Mask and Implicit Wildcard Mask 44
Transport Layer Information 44

78-17478-01 v
Contents
IP Access List Entry Sequence Numbering 44

Benefits 44
Sequence Numbering Behavior 44
How to Use Sequence Numbers in an IP Access List 45
Sequencing Access-List Entries and Revising the Access List 45
What to Do Next 48
Configuration Examples for IP Access List Entry Sequence Numbering 48
Resequencing Entries in an Access List: Example 48
Adding Entries with Sequence Numbers: Example 49
Entry without Sequence Number: Example 49
Additional References 50
Standards 50
MIBs 50
RFCs 51
Technical Assistance 51
ACL IP Options Selective Drop 53
Contents 53
Restrictions for ACL IP Options Selective Drop 53
Information About ACL IP Options Selective Drop 54

How the ACL IP Options Selective Drop Feature Works 54
Benefits of Using the ACL IP Options Selective Drop Feature 54
How to Configure ACL IP Options Selective Drop 54

Configuring Your Router and Verifying the ACL IP Options Selective Drop Feature 54
What to Do Next 55
Configuration Examples for the ACL IP Options Selective Drop Feature 55
IP Options Configuration: Example 55
Standards 57
MIBs 57
RFCs 57
ACL Support for Filtering IP Options 59
Contents 59

vi 78-17478-01
Contents
Restrictions for the ACL Support for Filtering IP Options Feature 59
Information About ACL Support for Filtering IP Options 60

IP Options 60
Benefits of Using the ACL Support for Filtering IP Options Feature 61
How to Configure the ACL Support for Filtering IP Options Feature 61

Configuring Access Lists to Filter Packets That Contain IP Options 61
ACL Support for Filtering IP Options: Example 63
Configuring the Access List to Filter Packets That Contain IP Options: Example 63
Where to Go Next 63
Standards 64
MIBs 64
RFCs 64
ACL TCP Flags Filtering 67
Contents 67
Restrictions for ACL TCP Flags Filtering 67
Information About the ACL TCP Flags Filtering Feature 68

Benefits of Using the ACL TCP Flags Filtering Feature 68
How to Configure ACL TCP Flags Filtering 69
Configuring the ACE to Filter TCP Packets and Verifying the Configuration 69
Configuration Examples for the ACL TCP Flags Filtering Feature 70
Configuring the ACE to Filter TCP Packets Based on TCP Flags: Example 71
Standards 71
MIBs 72
RFCs 72
ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry 73
Contents 73
Restrictions for the ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry
Feature 74

78-17478-01 vii
Contents
Information About the ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry
Feature 74
Benefits of Using the ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry
Feature 74
How to Configure an Access List Entry with Noncontiguous Ports 74
Configuring an Access Control Entry with Noncontiguous Ports 74
Consolidating Access List Entries with Noncontiguous Ports into One Access List Entry 76
Configuration Examples for the ACL—Support for Noncontiguous Ports on an Access List Entry
Feature 78
Creating an Access list Entry with Noncontiguous Ports: Example 78
Consolidating Some Existing Access List Entries into One Access List Entry with Noncontiguous Ports:
Example 78
Standards 79
MIBs 80
RFCs 80
PART 3: TCP
Configuring TCP Performance Parameters 83
Contents 83
How to Configure TCP Performance Parameters 83

Setting the TCP Connection Attempt Time 84
Enabling TCP Path MTU Discovery 84
Enabling TCP Selective Acknowledgment 84
Enabling TCP Time Stamp 85
Setting the TCP Maximum Read Size 85
Setting the TCP Window Size 86
Setting the TCP Outgoing Queue Size 86
TCP Window Scaling 87
Feature Overview 87
Benefits 87
Related Features and Technologies 88
Supported Platforms 88
Supported Standards, MIBs, and RFCs 89

viii 78-17478-01
Contents
Prerequisites 89
Configuration Tasks 89
Setting the TCP Window Size 90
Verifying the Window Scaling Configuration 90
Troubleshooting Tips 90
Glossary 91
TCP Congestion Avoidance 93
Contents 93
MIBs 94
TCP Explicit Congestion Notification 95
Contents 95
How to Configure TCP Explicit Congestion Notification 96

Enabling Explicit Congestion Notification 96
Prerequisites 96
Verifying the Configuration of Explicit Congestion Notification 97
Configuration Examples for TCP Explicit Congestion Notification 99

Running Configuration: Example 99
MIBs 101
RFCs 101
PART 4: SERVER LOAD BALANCING
Configuring Server Load Balancing 105
IOS SLB Functions and Capabilities 106

Algorithms for Server Load Balancing 107
Weighted Round Robin 107
Weighted Least Connections 107

78-17478-01 ix
Contents
Port-Bound Servers 108

Client-Assigned Load Balancing 108
Content Flow Monitor Support 108
Sticky Connections 108
Maximum Connections 108
Delayed Removal of TCP Connection Context 109
TCP Session Reassignment 109
Automatic Server Failure Detection 109
Automatic Unfail 109
Slow Start 109
SynGuard 109
Dynamic Feedback Protocol for IOS SLB 110
Alternate IP Addresses 110
Transparent Web Cache Balancing 110
NAT 110
Redundancy Enhancement—Stateless Backup 111
Restrictions 111
IOS SLB Configuration Task List 112

Specifying a Server Farm 113
Specifying a Load-Balancing Algorithm 113
Specifying a Bind ID 114
Specifying a Real Server 114
Configuring Real Server Attributes 114
Enabling the Real Server for Service 115
Specifying a Virtual Server 115
Associating a Virtual Server with a Server Farm 115
Configuring Virtual Server Attributes 115
Adjusting Virtual Server Values 116
Preventing Advertisement of Virtual Server Address 116
Enabling the Virtual Server for Service 116
Configuring IOS SLB Dynamic Feedback Protocol 117
Configuring NAT 117
Implementing IOS SLB Stateless Backup 117
How IOS SLB Stateless Backup Works 117
Configuring IOS SLB Stateless Backup 118
Enabling HSRP 119
Customizing Group Attributes 119
Verifying the IOS SLB Stateless Backup Configuration 119
Verifying IOS SLB 120
Verifying IOS SLB Installation 120

x 78-17478-01
Contents
Verifying Server Failure Detection 121

Troubleshooting IOS SLB 122
Monitoring and Maintaining IOS SLB 123

IOS SLB Network Configuration Example 124
NAT Configuration Example 125
HSRP Configuration Example 127
IOS SLB Stateless Backup Configuration Example 130
PART 5: WEB CACHE SERVICES USING WCCP
Configuring Web Cache Services Using WCCP 133
Understanding WCCP 133

Understanding WCCPv1 Configuration 134
Understanding WCCPv2 Configuration 135
WCCPv2 Features 136

Support for Services Other than HTTP 136
Support for Multiple Routers 137
MD5 Security 137
Web Cache Packet Return 137
Load Distribution 137
Restrictions for WCCPv2 138
Configuring WCCP 138

Specifying a Version of WCCP 138
Configuring a Service Group Using WCCPv2 139
Specifying a Web Cache Service 140
Excluding Traffic on a Specific Interface from Redirection 140
Registering a Router to a Multicast Address 140
Using Access Lists for a WCCP Service Group 141
Setting a Password for a Router and Cache Engines 141
Verifying and Monitoring WCCP Configuration Settings 142
WCCP Configuration Examples 142

Changing the Version of WCCP on a Router Example 143
Performing a General WCCPv2 Configuration Example 143
Running a Web Cache Service Example 143
Running a Reverse Proxy Service Example 144
Registering a Router to a Multicast Address Example 144
Using Access Lists Example 144
Setting a Password for a Router and Cache Engines Example 145

78-17478-01 xi
Contents
Verifying WCCP Settings Example 145
WCCP Bypass Counters 147
Contents 147
Information About WCCP Bypass Counters 147

WCCP Bypass Packets 147
How to Display WCCP Bypass Counters 148
Displaying WCCP Bypass Counters 148
WCCP Web Cache Configuration: Example 149

Standards 150
MIBs 150
RFCs 150
WCCP Outbound ACL Check 153
Contents 153
Information About WCCP Outbound ACL Check 153

WCCP 154
ACLs 154
How to Configure WCCP Outbound ACL Check 154
Enabling the WCCP Outbound ACL Check 155
Configuration Examples for WCCP Outbound ACL Check 156
WCCP Outbound ACL Check Configuration: Example 156
Standards 157
MIBs 157
RFCs 157
WCCP Increased Services 159
Contents 159
Information About WCCP Increased Services 159

xii 78-17478-01
Contents
WCCP Service Groups 160
How to Configure WCCP Increased Services 160

Configuring Service Groups 160
Configuration Examples for WCCP Increased Services 161
WCCP Services Configuration: Example 161
Standards 162
MIBs 162
RFCs 162
ip wccp 164
ip wccp check services all 168
show ip wccp 169
Feature Information for WCCP Increased Services 174
PART 6: FIRST HOP REDUNDANCY PROTOCOLS
FHRP Features Roadmap 177
Configuring GLBP 181
Contents 181
Prerequisites for GLBP 181

Information About GLBP 182
GLBP Overview 182
GLBP Active Virtual Gateway 182
GLBP Virtual MAC Address Assignment 183
GLBP Virtual Gateway Redundancy 184
GLBP Virtual Forwarder Redundancy 184
GLBP Gateway Priority 184
GLBP Gateway Weighting and Tracking 185
GLBP Benefits 185
How to Configure GLBP 186
Customizing GLBP 186
Configuring GLBP Authentication 188
How GLBP MD5 Authentication Works 188
Benefits of GLBP MD5 Authentication 189
Configuring GLBP MD5 Authentication Using a Key String 189

78-17478-01 xiii
Contents
Configuring GLBP MD5 Authentication Using a Key Chain 190

Configuring GLBP Text Authentication 192
Configuring GLBP Weighting Values and Object Tracking 194
Enabling and Verifying GLBP 196
Prerequisites 196
Examples 197
Troubleshooting the Gateway Load Balancing Protocol 198
Prerequisites 198
Configuration Examples for GLBP 199
Customizing GLBP Configuration: Example 199
GLBP MD5 Authentication Using Key Strings: Example 200
GLBP MD5 Authentication Using Key Chains: Example 200
GLBP Text Authentication: Example 200
GLBP Weighting: Example 200
Enabling GLBP Configuration: Example 201
Standards 201
MIBs 201
RFCs 202
Glossary 203
Feature Information for GLBP 203
Configuring HSRP 205

Contents 205
Restrictions for Configuring HSRP 205
Information About HSRP 206

HSRP Operation 206
HSRP Benefits 207
HSRP Terminology 208
HSRP Groups and Group Attributes 208
HSRP Addressing 208
HSRP Messages and States 209
HSRP and ARP 209
HSRP Object Tracking 210
HSRP Support for MPLS VPNs 210
How to Configure HSRP 210
Enabling HSRP 211

xiv 78-17478-01
Contents
Prerequisites 211
Delaying the Initialization of HSRP on an Interface 213
Configuring HSRP Priority and Preemption 215
HSRP Priority and Preemption 215
How Object Tracking Affects the Priority of an HSRP Router 215
Configuring HSRP Object Tracking 217
Configuring HSRP Authentication 219
How HSRP MD5 Authentication Works 219
Benefits of HSRP MD5 Authentication 220
Restrictions 220
Configuring HSRP MD5 Authentication Using a Key String 220
Configuring HSRP MD5 Authentication Using a Key Chain 222
Troubleshooting HSRP MD5 Authentication 224
Configuring HSRP Text Authentication 225
Customizing HSRP 227
HSRP Timers 227
HSRP MAC Refresh Interval 227
Configuring Multiple HSRP Groups for Load Balancing 229
Enabling HSRP Support for ICMP Redirects 231
ICMP Redirects to Active HSRP Routers 231
ICMP Redirects to Passive HSRP Routers 232
ICMP Redirects to Non-HSRP Routers 232
Passive HSRP Router Advertisements 233
ICMP Redirects Not Sent 233
Configuring HSRP Virtual MAC Addresses or BIA MAC Addresses 234
Restrictions 235
Linking IP Redundancy Clients to HSRP Groups 236
Prerequisites 236
Changing to HSRP Version 2 237
HSRP Version 2 Design 237
Restrictions 238
Configuring SSO-Aware HSRP (Cisco IOS Release 12.2(25)S) 239
SSO Dual-Route Processors and Cisco Nonstop Forwarding 240
HSRP and SSO Working Together 240
Enabling SSO Aware HSRP 240
Verifying SSO Aware HSRP 241
Enabling HSRP MIB Traps 243
Configuration Examples for HSRP 244

78-17478-01 xv
Contents
HSRP Priority and Preemption: Example 244

HSRP Object Tracking: Example 245
HSRP MD5 Authentication Using Key Strings: Example 245
HSRP MD5 Authentication Using Key Chains: Example 245
HSRP MD5 Authentication Using Key Strings and Key Chains: Example 246
HSRP Text Authentication: Example 246
Multiple HSRP for Load Balancing: Example 246
HSRP Support for ICMP Redirect Messages: Example 248
HSRP Virtual MAC Addresses and BIA MAC Address: Example 248
Linking IP Redundancy Clients to HSRP Groups: Example 248
HSRP Version 2: Example 249
SSO-Aware HSRP (Cisco IOS Release 12.2(25)S): Example 249
HSRP MIB Traps: Example 250
Standards 251
MIBs 251
RFCs 251
Glossary 252
Feature Information for HSRP 252
Configuring VRRP 255
Contents 255
Restrictions for VRRP 256

Information About VRRP 256
VRRP Operation 256
VRRP Benefits 258
Multiple Virtual Router Support 259
VRRP Router Priority and Preemption 259
VRRP Advertisements 260
VRRP Object Tracking 260
How to Configure VRRP 260
Customizing VRRP 261
How Object Tracking Affects the Priority of a VRRP Router 261
Enabling VRRP 263
Disabling VRRP on an Interface 264
Configuring VRRP Object Tracking 265
Restrictions 265

xvi 78-17478-01
Contents
Configuring VRRP Authentication 267

How VRRP MD5 Authentication Works 267
Restrictions 268
Configuring VRRP MD5 Authentication Using a Key String 268
Configuring VRRP MD5 Authentication Using a Key Chain 269
Verifying the VRRP MD5 Authentication Configuration 271
Configuring VRRP Text Authentication 272
Enabling the Router to Send SNMP VRRP Notifications 274
Configuration Examples for VRRP 275
Configuring VRRP: Example 275
VRRP Object Tracking: Example 276
VRRP Object Tracking Verification: Example 276
VRRP MD5 Authentication Configuration Using a Key String: Example 277
VRRP MD5 Authentication Configuration Using a Key Chain: Example 277
VRRP Text Authentication: Example 277
Disabling a VRRP Group on an Interface: Example 277
VRRP MIB Trap: Example 278
Standards 278
MIBs 279
RFCs 279
Feature Information for VRRP 280
Glossary 282
PART 7: ENHANCED OBJECT TRACKING
Configuring Enhanced Object Tracking 285
Contents 285
Information About Enhanced Object Tracking 285

Feature Design of Enhanced Object Tracking 286
Benefits of Enhanced Object Tracking 286
How to Configure Enhanced Object Tracking 286
Tracking the Line-Protocol State of an Interface 287
Examples 288
Tracking the IP-Routing State of an Interface 288
Examples 290
Tracking IP-Route Reachability 290

78-17478-01 xvii
Contents
Examples 291
Tracking the Threshold of IP-Route Metrics 292
Scaled Route Metrics 292
Examples 294
Tracking IP SLAs Operations 294
Tracking the State of an IP SLAs Operation 295
Examples 296
Tracking the Reachability of an IP SLAs IP Host 296
Examples 297
Configuring a Tracked List and Boolean Expression 298
Prerequisites 298
Configuring a Tracked List and Threshold Weight 299
Prerequisites 299
Restrictions 300
Configuring a Tracked List and Threshold Percentage 301
Prerequisites 301
Restrictions 301
Configuring the Track List Defaults 302
Configuration Examples for Enhanced Object Tracking 303
Interface Line Protocol: Example 304
Interface IP Routing: Example 304
IP-Route Reachability: Example 305
IP-Route Threshold Metric: Example 306
IP SLAs IP Host Tracking: Example 306
Boolean Expression for a Tracked List: Example 306
Threshold Weight for a Tracked List: Example 307
Threshold Percentage for a Tracked List: Example 308
Standards 308
MIBs 308
RFCs 309
Glossary 310
Feature Information for Enhanced Object Tracking 310

xviii 78-17478-01
About Cisco IOS Software Documentation for
Release 12.4
This chapter describes the objectives, audience, organization, and conventions of Cisco IOS software
documentation. It also provides sources for obtaining documentation, technical assistance, and
additional publications and information from Cisco Systems. It contains the following sections:
• Documentation Objectives, page xix
• Audience, page xix
• Documentation Organization for Cisco IOS Release 12.4, page xx
• Document Conventions, page xxvi
• Obtaining Documentation, page xxvii
• Documentation Feedback, page xxviii
• Cisco Product Security Overview, page xxix
• Obtaining Technical Assistance, page xxx
• Obtaining Additional Publications and Information, page xxxi
Documentation Objectives
Cisco IOS software documentation describes the tasks and commands available to configure and
maintain Cisco networking devices.
Audience
The Cisco IOS software documentation set is intended primarily for users who configure and maintain
Cisco networking devices (such as routers and switches) but who may not be familiar with the
configuration and maintenance tasks, the relationship among tasks, or the Cisco IOS software commands
necessary to perform particular tasks. The Cisco IOS software documentation set is also intended for
those users experienced with Cisco IOS software who need to know about new features, new
configuration options, and new software characteristics in the current Cisco IOS software release.

78-17478-01 xix
About Cisco IOS Software Documentation for Release 12.4
Documentation Organization for Cisco IOS Release 12.4

The Cisco IOS Release 12.4 documentation set consists of the configuration guide and command
reference pairs listed in Table 1 and the supporting documents listed in Table 2. The configuration guides
and command references are organized by technology. For the configuration guides:
• Some technology documentation, such as that for DHCP, contains features introduced in
Releases 12.2T and 12.3T and, in some cases, Release 12.2S. To assist you in finding a particular
feature, a roadmap document is provided.
• Other technology documentation, such as that for OSPF, consists of a chapter and accompanying
Release 12.2T and 12.3T feature documents.
Note In some cases, information contained in Release 12.2T and 12.3T feature documents augments or
supersedes content in the accompanying documentation. Therefore it is important to review all
feature documents for a particular technology.
Table 1 lists the Cisco IOS Release 12.4 configuration guides and command references.
Table 1 Cisco IOS Release 12.4 Configuration Guides and Command References
Configuration Guide and Description

Command Reference Titles
IP
Cisco IOS IP Addressing Services The configuration guide is a task-oriented guide to configuring IP addressing and
Configuration Guide, Release 12.4 services, including Network Address Translation (NAT), Domain Name System
(DNS), and Dynamic Host Configuration Protocol (DHCP). The command
Cisco IOS IP Addressing Services
reference provides detailed information about the commands used in the
Command Reference, Release 12.4
configuration guide.
Cisco IOS IP Application Services The configuration guide is a task-oriented guide to configuring IP application
Configuration Guide, Release 12.4 services, including IP access lists, Web Cache Communication Protocol
(WCCP), Gateway Load Balancing Protocol (GLBP), Server Load Balancing
Cisco IOS IP Application Services
(SLB), Hot Standby Router Protocol (HSRP), and Virtual Router Redundancy
Protocol (VRRP). The command reference provides detailed information about
the commands used in the configuration guide.
Cisco IOS IP Mobility The configuration guide is a task-oriented guide to configuring Mobile IP and
Configuration Guide, Release 12.4 Cisco Mobile Networks. The command reference provides detailed information
about the commands used in the configuration guide.
Cisco IOS IP Mobility
Cisco IOS IP Multicast The configuration guide is a task-oriented guide to configuring IP multicast,
Configuration Guide, Release 12.4 including Protocol Independent Multicast (PIM), Internet Group Management
Protocol (IGMP), Distance Vector Multicast Routing Protocol (DVMRP), and
Cisco IOS IP Multicast
Multicast Source Discovery Protocol (MSDP). The command reference provides
detailed information about the commands used in the configuration guide.
Cisco IOS IP Routing Protocols The configuration guide is a task-oriented guide to configuring IP routing
Configuration Guide, Release 12.4 protocols, including Border Gateway Protocol (BGP), Intermediate
System-to-Intermediate System (IS-IS), and Open Shortest Path First (OSPF).
Cisco IOS IP Routing Protocols
The command reference provides detailed information about the commands used
in the configuration guide.

xx 78-17478-01
Table 1 Cisco IOS Release 12.4 Configuration Guides and Command References (continued)

Cisco IOS IP Switching The configuration guide is a task-oriented guide to configuring IP switching
Configuration Guide, Release 12.4 features, including Cisco Express Forwarding, fast switching, and Multicast
Distributed Switching (MDS). The command reference provides detailed
Cisco IOS IP Switching
information about the commands used in the configuration guide.
Cisco IOS IPv6 The configuration guide is a task-oriented guide to configuring IP version 6
Configuration Guide, Release 12.4 (IPv6), including IPv6 broadband access, IPv6 data-link layer, IPv6 multicast
routing, IPv6 quality of service (QoS), IPv6 routing, IPv6 services and
Cisco IOS IPv6
management, and IPv6 tunnel services. The command reference provides
Cisco IOS Optimized Edge Routing The configuration guide is a task-oriented guide to configuring Optimized Edge
Configuration Guide, Release 12.4 Routing (OER) features, including OER prefix learning, OER prefix monitoring,
OER operational modes, and OER policy configuration. The command reference
Cisco IOS Optimized Edge Routing
provides detailed information about the commands used in the configuration
guide.
Security and VPN
Cisco IOS Security The configuration guide is a task-oriented guide to configuring various aspects of
Configuration Guide, Release 12.4 security, including terminal access security, network access security, accounting,
traffic filters, router access, and network data encryption with router
Cisco IOS Security
authentication. The command reference provides detailed information about the
commands used in the configuration guide.
QoS
Cisco IOS Quality of Service Solutions The configuration guide is a task-oriented guide to configuring quality of service
Configuration Guide, Release 12.4 (QoS) features, including traffic classification and marking, traffic policing and
shaping, congestion management, congestion avoidance, and signaling. The
Cisco IOS Quality of Service Solutions
command reference provides detailed information about the commands used in
the configuration guide.
LAN Switching
Cisco IOS LAN Switching The configuration guide is a task-oriented guide to local-area network (LAN)
Configuration Guide, Release 12.4 switching features, including configuring routing between virtual LANs
(VLANs) using Inter-Switch Link (ISL) encapsulation, IEEE 802.10
Cisco IOS LAN Switching
encapsulation, and IEEE 802.1Q encapsulation. The command reference
guide.
Multiprotocol Label Switching (MPLS)
Cisco IOS Multiprotocol Label Switching The configuration guide is a task-oriented guide to configuring Multiprotocol
Configuration Guide, Release 12.4 Label Switching (MPLS), including MPLS Label Distribution Protocol, MPLS
traffic engineering, and MPLS Virtual Private Networks (VPNs). The command
Cisco IOS Multiprotocol Label Switching
Network Management
Cisco IOS IP SLAs The configuration guide is a task-oriented guide to configuring the Cisco IOS IP
Configuration Guide, Release 12.4 Service Level Assurances (IP SLAs) feature. The command reference provides
Cisco IOS IP SLAs

78-17478-01 xxi

Cisco IOS NetFlow The configuration guide is a task-oriented guide to NetFlow features, including
Configuration Guide, Release 12.4 configuring NetFlow to analyze network traffic data, configuring NetFlow
aggregation caches and export features, and configuring Simple Network
Cisco IOS NetFlow
Management Protocol (SNMP) and NetFlow MIB features. The command
Cisco IOS Network Management The configuration guide is a task-oriented guide to network management
Configuration Guide, Release 12.4 features, including performing basic system management, performing
troubleshooting and fault management, configuring Cisco Discovery Protocol,
Cisco IOS Network Management
configuring Cisco Networking Services (CNS), configuring DistributedDirector,
and configuring Simple Network Management Protocol (SNMP). The command
Voice
Cisco IOS Voice The configuration library is a task-oriented collection of configuration guides,
Configuration Library, Release 12.4 application guides, a troubleshooting guide, feature documents, a library preface, a
voice glossary, and more. It also covers Cisco IOS support for voice call control
Cisco IOS Voice
protocols, interoperability, physical and virtual interface management, and
troubleshooting. In addition, the library includes documentation for IP telephony
applications. The command reference provides detailed information about the
commands used in the configuration library.
Wireless/Mobility
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring a
Gateway GPRS Support Node Cisco IOS Gateway GPRS Support Node (GGSN) in a 2.5G General Packet Radio
Configuration Guide, Release 12.4 Service (GPRS) and 3G Universal Mobile Telecommunication System (UMTS)
network. The command reference provides detailed information about the
Cisco IOS Mobile Wireless
Gateway GPRS Support Node
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring the
Home Agent Cisco Mobile Wireless Home Agent, which is an anchor point for mobile terminals
Configuration Guide, Release 12.4 for which Mobile IP or Proxy Mobile IP services are provided. The command
Home Agent
Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and configuring the
Packet Data Serving Node Cisco Packet Data Serving Node (PDSN), a wireless gateway between the mobile
Configuration Guide, Release 12.4 infrastructure and standard IP networks that enables packet data services in a Code
Division Multiple Access (CDMA) environment. The command reference provides
Packet Data Serving Node

xxii 78-17478-01

Cisco IOS Mobile Wireless The configuration guide is a task-oriented guide to understanding and
Radio Access Networking configuring Cisco IOS Radio Access Network products. The command reference
Configuration Guide, Release 12.4 provides detailed information about the commands used in the configuration
guide.
Radio Access Networking
Long Reach Ethernet (LRE) and Digital Subscriber Line (xDSL)
Cisco IOS Broadband and DSL The configuration guide is a task-oriented guide to configuring broadband access
Configuration Guide, Release 12.4 aggregation and digital subscriber line features. The command reference
Cisco IOS Broadband and DSL
guide.
Cisco IOS Service Selection Gateway The configuration guide is a task-oriented guide to configuring Service Selection
Configuration Guide, Release 12.4 Gateway (SSG) features, including subscriber authentication, service access, and
accounting. The command reference provides detailed information about the
Cisco IOS Service Selection Gateway
Dial—Access
Cisco IOS Dial Technologies The configuration guide is a task-oriented guide to configuring lines, modems,
Configuration Guide, Release 12.4 and ISDN services. This guide also contains information about configuring
dialup solutions, including solutions for remote sites dialing in to a central office,
Cisco IOS Dial Technologies
Internet service providers (ISPs), ISP customers at home offices, enterprise WAN
system administrators implementing dial-on-demand routing, and other
corporate environments. The command reference provides detailed information
about the commands used in the configuration guide.
Cisco IOS VPDN The configuration guide is a task-oriented guide to configuring Virtual Private
Configuration Guide, Release 12.4 Dialup Networks (VPDNs), including information about Layer 2 tunneling
protocols, client-initiated VPDN tunneling, NAS-initiated VPDN tunneling, and
Cisco IOS VPDN
multihop VPDN. The command reference provides detailed information about
the commands used in the configuration guide.
Asynchronous Transfer Mode (ATM)
Cisco IOS Asynchronous Transfer Mode The configuration guide is a task-oriented guide to configuring Asynchronous
Configuration Guide, Release 12.4 Transfer Mode (ATM), including WAN ATM, LAN ATM, and multiprotocol over
ATM (MPOA). The command reference provides detailed information about the
Cisco IOS Asynchronous Transfer Mode
WAN
Cisco IOS Wide-Area Networking The configuration guide is a task-oriented guide to configuring wide-area
Configuration Guide, Release 12.4 network (WAN) features, including Layer 2 Tunneling Protocol Version 3
(L2TPv3); Frame Relay; Link Access Procedure, Balanced (LAPB); and X.25.
Cisco IOS Wide-Area Networking
The command reference provides detailed information about the commands used
in the configuration guide.

78-17478-01 xxiii

System Management
Cisco IOS Configuration Fundamentals The configuration guide is a task-oriented guide to using Cisco IOS software to
Configuration Guide, Release 12.4 configure and maintain Cisco routers and access servers, including information
about using the Cisco IOS command-line interface (CLI), loading and
Cisco IOS Configuration Fundamentals
maintaining system images, using the Cisco IOS file system, using the Cisco IOS
Web browser user interface (UI), and configuring basic file transfer services. The
command reference provides detailed information about the commands used in
the configuration guide.
Cisco IOS The configuration guide is a task-oriented guide to configuring and managing
Interface and Hardware Component interfaces and hardware components, including dial shelves, LAN interfaces,
Configuration Guide, Release 12.4 logical interfaces, serial interfaces, and virtual interfaces. The command
Cisco IOS
Interface and Hardware Component
IBM Technologies
Cisco IOS Bridging and IBM Networking The configuration guide is a task-oriented guide to configuring:
Configuration Guide, Release 12.4
• Bridging features, including transparent and source-route transparent (SRT)
Cisco IOS Bridging bridging, source-route bridging (SRB), Token Ring Inter-Switch Link
Command Reference, Release 12.4 (TRISL), and Token Ring Route Switch Module (TRRSM).
Cisco IOS IBM Networking • IBM network features, including data-link switching plus (DLSw+), serial
Command Reference, Release 12.4 tunnel (STUN), and block serial tunnel (BSTUN); Logical Link Control,
type 2 (LLC2), and Synchronous Data Link Control (SDLC); IBM Network
Media Translation, including SDLC Logical Link Control (SDLLC) and
Qualified Logical Link Control (QLLC); downstream physical unit (DSPU),
Systems Network Architecture (SNA) service point, SNA Frame Relay
Access, Advanced Peer-to-Peer Networking (APPN), native client interface
architecture (NCIA) client/server topologies, and IBM Channel Attach.
The two command references provide detailed information about the commands
used in the configuration guide.
Additional and Legacy Protocols
Cisco IOS AppleTalk The configuration guide is a task-oriented guide to configuring the AppleTalk
Configuration Guide, Release 12.4 protocol. The command reference provides detailed information about the
Cisco IOS AppleTalk
Cisco IOS DECnet The configuration guide is a task-oriented guide to configuring the DECnet
Configuration Guide, Release 12.4 protocol. The command reference provides detailed information about the
Cisco IOS DECnet
Cisco IOS ISO CLNS The configuration guide is a task-oriented guide to configuring International
Configuration Guide, Release 12.4 Organization for Standardization (ISO) Connectionless Network Service
(CLNS). The command reference provides detailed information about the
Cisco IOS ISO CLNS

xxiv 78-17478-01

Cisco IOS Novell IPX The configuration guide is a task-oriented guide to configuring the Novell
Configuration Guide, Release 12.4 Internetwork Packet Exchange (IPX) protocol. The command reference provides
Cisco IOS Novell IPX
Cisco IOS Terminal Services The configuration guide is a task-oriented guide to configuring terminal services,
Configuration Guide, Release 12.4 including DEC, local-area transport (LAT), and X.25 packet
assembler/disassembler (PAD). The command reference provides detailed
Cisco IOS Terminal Services
information about the commands used in the configuration guide.
Table 2 lists the documents and resources that support the Cisco IOS Release 12.4 software
configuration guides and command references.
Table 2 Cisco IOS Release 12.4 Supporting Documents and Resources
Document Title Description

Cisco IOS Master Commands List, An alphabetical listing of all the commands documented in the Cisco IOS
Release 12.4 Release 12.4 command references.
Cisco IOS New, Modified, Replaced, A listing of all the new, modified, replaced and removed commands since
and Removed Commands, Release 12.4 Cisco IOS Release 12.3, grouped by Release 12.3T maintenance release and
ordered alphabetically within each group.
Cisco IOS New and Modified A listing of all the new, modified, and replaced commands since Cisco IOS
Commands, Release 12.3 Release 12.2, grouped by Release 12.2T maintenance release and ordered
alphabetically within each group.
Cisco IOS System Messages, Listings and descriptions of Cisco IOS system messages. Not all system messages
Volume 1 of 2 indicate problems with your system. Some are purely informational, and others
may help diagnose problems with communications lines, internal hardware, or the
Cisco IOS System Messages,
system software.
Volume 2 of 2
Cisco IOS Debug Command Reference, An alphabetical listing of the debug commands and their descriptions.
Release 12.4 Documentation for each command includes a brief description of its use, command
syntax, and usage guidelines.
Release Notes, Release 12.4 A description of general release information, including information about
supported platforms, feature sets, platform-specific notes, and Cisco IOS software
defects.
Internetworking Terms and Acronyms Compilation and definitions of the terms and acronyms used in the internetworking
industry.

78-17478-01 xxv
Document Conventions
Table 2 Cisco IOS Release 12.4 Supporting Documents and Resources (continued)
Document Title Description

RFCs RFCs are standards documents maintained by the Internet Engineering Task Force
(IETF). Cisco IOS software documentation references supported RFCs when
applicable. The full text of referenced RFCs may be obtained at the following URL:
http://www.rfc-editor.org/
MIBs MIBs are used for network monitoring. To locate and download MIBs for selected
platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the
following URL:
http://www.cisco.com/go/mibs
Document Conventions
Within Cisco IOS software documentation, the term router is generally used to refer to a variety of Cisco
products (for example, routers, access servers, and switches). Routers, access servers, and other
networking devices that support Cisco IOS software are shown interchangeably within examples. These
products are used only for illustrative purposes; that is, an example that shows one product does not
necessarily indicate that other products are not supported.
The Cisco IOS documentation set uses the following conventions:
Convention Description
^ or Ctrl The ^ and Ctrl symbols represent the Control key. For example, the key combination ^D or Ctrl-D
means hold down the Control key while you press the D key. Keys are indicated in capital letters but
are not case sensitive.
string A string is a nonquoted set of characters shown in italics. For example, when setting an SNMP
community string to public, do not use quotation marks around the string or the string will include the
quotation marks.
Command syntax descriptions use the following conventions:
bold Bold text indicates commands and keywords that you enter literally as shown.
italics Italic text indicates arguments for which you supply values.
[x] Square brackets enclose an optional element (keyword or argument).
| A vertical line indicates a choice within an optional or required set of keywords or arguments.
[x | y] Square brackets enclosing keywords or arguments separated by a vertical line indicate an optional
choice.
{x | y} Braces enclosing keywords or arguments separated by a vertical line indicate a required choice.

xxvi 78-17478-01
Obtaining Documentation
Nested sets of square brackets or braces indicate optional or required choices within optional or required
elements. For example:
[x {y | z}] Braces and a vertical line within square brackets indicate a required choice within an optional element.
Examples use the following conventions:
screen Examples of information displayed on the screen are set in Courier font.
bold screen Examples of text that you must enter are set in Courier bold font.
< > Angle brackets enclose text that is not printed to the screen, such as passwords, and are used in
contexts in which the italic document convention is not available, such as ASCII text.
! An exclamation point at the beginning of a line indicates a comment line. (Exclamation points are also
displayed by the Cisco IOS software for certain processes.)
[ ] Square brackets enclose default responses to system prompts.
The following conventions are used to attract the attention of the reader:
Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Note Means reader take note. Notes contain suggestions or references to material not covered in the
manual.
Timesaver Means the described action saves time. You can save time by performing the action described in the
paragraph.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several
ways to obtain technical assistance and other technical resources. These sections explain how to obtain
technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation and technical support at this URL:
http://www.cisco.com/techsupport

78-17478-01 xxvii
Documentation Feedback
You can access the Cisco website at this URL:

http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Product Documentation DVD

Cisco documentation and additional literature are available in the Product Documentation DVD package,
which may have shipped with your product. The Product Documentation DVD is updated regularly and
may be more current than printed documentation.
The Product Documentation DVD is a comprehensive library of technical product documentation on
portable media. The DVD enables you to access multiple versions of hardware and software installation,
configuration, and command guides for Cisco products and to view technical documentation in HTML.
With the DVD, you have access to the same documentation that is found on the Cisco website without
being connected to the Internet. Certain products also have .pdf versions of the documentation available.
The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com
users (Cisco direct customers) can order a Product Documentation DVD (product number
DOC-DOCDVD=) from Cisco Marketplace at this URL:
http://www.cisco.com/go/marketplace/
Ordering Documentation
Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product
Documentation Store in the Cisco Marketplace at this URL:
Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m.
(0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by
calling 011 408 519-5055. You can also order documentation by e-mail at
tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada,
or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback
form that appears with the technical documents on Cisco.com.
You can send comments about Cisco documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your
document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.

xxviii 78-17478-01
Cisco Product Security Overview
Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
• Report security vulnerabilities in Cisco products.
• Obtain assistance with security incidents that involve Cisco products.
• Register to receive security information from Cisco.
A current list of security advisories and notices for Cisco products is available at this URL:
http://www.cisco.com/go/psirt
If you prefer to see advisories and notices as they are updated in real time, you can access a Product
Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them,
and we strive to correct all vulnerabilities quickly. If you think that you might have identified a
vulnerability in a Cisco product, contact PSIRT:
• Emergencies — security-alert@cisco.com
An emergency is either a condition in which a system is under active attack or a condition for which
a severe and urgent security vulnerability should be reported. All other conditions are considered
nonemergencies.
• Nonemergencies — psirt@cisco.com
In an emergency, you can also reach PSIRT by telephone:
• 1 877 228-7302
• 1 408 525-6532
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive
information that you send to Cisco. PSIRT can work from encrypted information that is compatible with
PGP versions 2.x through 8.x.
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence
with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page
at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.

78-17478-01 xxix
Obtaining Technical Assistance
Obtaining Technical Assistance

Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The
Cisco Technical Support & Documentation website on Cisco.com features extensive online support
resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center
(TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact
your reseller.
Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation website provides online documents and tools for
troubleshooting and resolving technical issues with Cisco products and technologies. The website is
available 24 hours a day, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user
ID and password. If you have a valid service contract but do not have a user ID or password, you can
register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting
a web or phone request for service. You can access the CPI tool from the Cisco Technical Support &
Documentation website by clicking the Tools & Resources link. Choose Cisco Product Identification
Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link
under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree
view; or for certain products, by copying and pasting show command output. Search results show an
illustration of your product with the serial number label location highlighted. Locate the serial number
label on your product and record the information before placing a service call.
Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3
and S4 service requests are those in which your network is minimally impaired or for which you require
product information.) After you describe your situation, the TAC Service Request Tool provides
recommended solutions. If your issue is not resolved using the recommended resources, your service
request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone.
(S1 or S2 service requests are those in which your production network is down or severely degraded.)
Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business
operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

xxx 78-17478-01
Obtaining Additional Publications and Information
For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity
definitions.
Severity 1 (S1)—Your network is “down,” or there is a critical impact to your business operations. You
and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your
business operation are negatively affected by inadequate performance of Cisco products. You and Cisco
will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations
remain functional. You and Cisco will commit resources during normal business hours to restore service
to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or
configuration. There is little or no effect on your business operations.

Information about Cisco products, technologies, and network solutions is available from various online
and printed sources.
• Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo
merchandise. Visit Cisco Marketplace, the company store, at this URL:
• Cisco Press publishes a wide range of general networking, training and certification titles. Both new
and experienced users will benefit from these publications. For current Cisco Press titles and other
information, go to Cisco Press at this URL:
http://www.ciscopress.com
• Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and
networking investments. Each quarter, Packet delivers coverage of the latest industry trends,
technology breakthroughs, and Cisco products and solutions, as well as network deployment and
troubleshooting tips, configuration examples, customer case studies, certification and training
information, and links to scores of in-depth online resources. You can access Packet magazine at
this URL:
http://www.cisco.com/packet
• iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies
learn how they can use technology to increase revenue, streamline their business, and expand
services. The publication identifies the challenges facing these companies and the technologies to
help solve them, using real-world case studies and business strategies to help readers make sound
technology investment decisions. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
or view the digital edition at this URL:
http://ciscoiq.texterity.com/ciscoiq/sample/

78-17478-01 xxxi
• Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering
professionals involved in designing, developing, and operating public and private internets and
intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
• Networking products offered by Cisco Systems, as well as customer support services, can be
obtained at this URL:
http://www.cisco.com/en/US/products/index.html
• Networking Professionals Connection is an interactive website for networking professionals to share
questions, suggestions, and information about networking products and technologies with Cisco
experts and other networking professionals. Join a discussion at this URL:
http://www.cisco.com/discuss/networking
• World-class networking training is available from Cisco. You can view current offerings at
this URL:
http://www.cisco.com/en/US/learning/index.html

xxxii 78-17478-01
Using Cisco IOS Software for Release 12.4
This chapter provides tips for understanding and configuring Cisco IOS software using the
command-line interface (CLI). It contains the following sections:
• Understanding Command Modes, page xxxiii
• Getting Help, page xxxiv
• Using the no and default Forms of Commands, page xxxviii
• Saving Configuration Changes, page xxxviii
• Filtering Output from the show and more Commands, page xxxix
• Finding Additional Feature Support Information, page xxxix
For an overview of Cisco IOS software configuration, see the Cisco IOS Configuration Fundamentals
Configuration Guide.
For information on the conventions used in the Cisco IOS software documentation set, see the “About
Cisco IOS Software Documentation for Release 12.4” chapter.
Understanding Command Modes

You use the CLI to access Cisco IOS software. Because the CLI is divided into many different modes,
the commands available to you at any given time depend on the mode that you are currently in. Entering
a question mark (?) at the CLI prompt allows you to obtain a list of commands available for each
command mode.
When you log in to a Cisco device, the device is initially in user EXEC mode. User EXEC mode contains
only a limited subset of commands. To have access to all commands, you must enter privileged EXEC
mode by entering the enable command and a password (when required). From privileged EXEC mode
you have access to both user EXEC and privileged EXEC commands. Most EXEC commands are used
independently to observe status or to perform a specific function. For example, show commands are used
to display important status information, and clear commands allow you to reset counters or interfaces.
The EXEC commands are not saved when the software reboots.
Configuration modes allow you to make changes to the running configuration. If you later save the
running configuration to the startup configuration, these changed commands are stored when the
software is rebooted. To enter specific configuration modes, you must start at global configuration mode.
From global configuration mode, you can enter interface configuration mode and a variety of other
modes, such as protocol-specific modes.

78-17478-01 xxxiii
Getting Help
ROM monitor mode is a separate mode used when the Cisco IOS software cannot load properly. If a valid
software image is not found when the software boots or if the configuration file is corrupted at startup,
the software might enter ROM monitor mode.
Table 1 describes how to access and exit various common command modes of the Cisco IOS software.
It also shows examples of the prompts displayed for each mode.
Table 1 Accessing and Exiting Command Modes
Command Access Method Prompt Exit Method

Mode
User EXEC Log in. Router> Use the logout command.
Privileged From user EXEC mode, Router# To return to user EXEC mode, use the disable
EXEC use the enable command. command.
Global From privileged EXEC Router(config)# To return to privileged EXEC mode from global
configuration mode, use the configure configuration mode, use the exit or end command.
terminal command.
Interface From global Router(config-if)# To return to global configuration mode, use the exit
configuration configuration mode, command.
specify an interface using To return to privileged EXEC mode, use the end
an interface command. command.
ROM monitor From privileged EXEC > To exit ROM monitor mode, use the continue
mode, use the reload command.
command. Press the
Break key during the
first 60 seconds while the
system is booting.
For more information on command modes, see the “Using the Cisco IOS Command-Line Interface”
chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.
Getting Help
Entering a question mark (?) at the CLI prompt displays a list of commands available for each command
mode. You can also get a list of keywords and arguments associated with any command by using the
context-sensitive help feature.
To get help specific to a command mode, a command, a keyword, or an argument, use one of the
following commands:
Command Purpose
help Provides a brief description of the help system in any command mode.
abbreviated-command-entry? Provides a list of commands that begin with a particular character string. (No space
between command and question mark.)
abbreviated-command-entry<Tab> Completes a partial command name.

xxxiv 78-17478-01
Getting Help
Command Purpose
? Lists all commands available for a particular command mode.
command ? Lists the keywords or arguments that you must enter next on the command line.
(Space between command and question mark.)
Example: How to Find Command Options

This section provides an example of how to display syntax for a command. The syntax can consist of
optional or required keywords and arguments. To display keywords and arguments for a command, enter
a question mark (?) at the configuration prompt or after entering part of a command followed by a space.
The Cisco IOS software displays a list and brief description of available keywords and arguments. For
example, if you were in global configuration mode and wanted to see all the keywords or arguments for
the arap command, you would type arap ?.
The <cr> symbol in command help output stands for “carriage return.” On older keyboards, the carriage
return key is the Return key. On most modern keyboards, the carriage return key is the Enter key. The
<cr> symbol at the end of command help output indicates that you have the option to press Enter to
complete the command and that the arguments and keywords in the list preceding the <cr> symbol are
optional. The <cr> symbol by itself indicates that no more arguments or keywords are available and that
you must press Enter to complete the command.
Table 2 shows examples of how you can use the question mark (?) to assist you in entering commands.
The table steps you through configuring an IP address on a serial interface on a Cisco 7206 router that
is running Cisco IOS Release 12.0(3).
Table 2 How to Find Command Options
Command Comment
Router> enable Enter the enable command and
Password: <password> password to access privileged EXEC
Router#
commands. You are in privileged
EXEC mode when the prompt changes
to Router#.
Router# configure terminal Enter the configure terminal
Enter configuration commands, one per line. End with CNTL/Z. privileged EXEC command to enter
Router(config)#
global configuration mode. You are in
global configuration mode when the
prompt changes to Router(config)#.

78-17478-01 xxxv
Getting Help
Table 2 How to Find Command Options (continued)
Command Comment
Router(config)# interface serial ? Enter interface configuration mode by
<0-6> Serial interface number specifying the serial interface that you
Router(config)# interface serial 4 ?
/
want to configure using the interface
Router(config)# interface serial 4/ ? serial global configuration command.
<0-3> Serial interface number
Enter ? to display what you must enter
Router(config)# interface serial 4/0 ?
<cr> next on the command line. In this
Router(config)# interface serial 4/0 example, you must enter the serial
Router(config-if)# interface slot number and port number,
separated by a forward slash.
When the <cr> symbol is displayed,
you can press Enter to complete the
command.
You are in interface configuration mode
when the prompt changes to
Router(config-if)#.
Router(config-if)# ? Enter ? to display a list of all the
Interface configuration commands: interface configuration commands
.
.
available for the serial interface. This
. example shows only some of the
ip Interface Internet Protocol config commands available interface configuration
keepalive Enable keepalive commands.
lan-name LAN Name command
llc2 LLC2 Interface Subcommands
load-interval Specify interval for load calculation for an
interface
locaddr-priority Assign a priority group
logging Configure logging for interface
loopback Configure internal loopback on an interface
mac-address Manually set interface MAC address
mls mls router sub/interface commands
mpoa MPOA interface configuration commands
mtu Set the interface Maximum Transmission Unit (MTU)
netbios Use a defined NETBIOS access list or enable
name-caching
no Negate a command or set its defaults
nrzi-encoding Enable use of NRZI encoding
ntp Configure NTP
.
.
.
Router(config-if)#

xxxvi 78-17478-01
Getting Help
Command Comment
Router(config-if)# ip ? Enter the command that you want to
Interface IP configuration subcommands: configure for the interface. This
access-group Specify access control for packets
accounting Enable IP accounting on this interface
example uses the ip command.
address Set the IP address of an interface Enter ? to display what you must enter
authentication authentication subcommands
next on the command line. This
bandwidth-percent Set EIGRP bandwidth limit
broadcast-address Set the broadcast address of an interface example shows only some of the
cgmp Enable/disable CGMP available interface IP configuration
directed-broadcast Enable forwarding of directed broadcasts commands.
dvmrp DVMRP interface commands
hello-interval Configures IP-EIGRP hello interval
helper-address Specify a destination address for UDP broadcasts
hold-time Configures IP-EIGRP hold time
.
.
.
Router(config-if)# ip
Router(config-if)# ip address ? Enter the command that you want to
A.B.C.D IP address configure for the interface. This
negotiated IP Address negotiated over PPP
Router(config-if)# ip address
example uses the ip address command.
next on the command line. In this
example, you must enter an IP address
or the negotiated keyword.
A carriage return (<cr>) is not
displayed; therefore, you must enter
additional keywords or arguments to
complete the command.
Router(config-if)# ip address 172.16.0.1 ? Enter the keyword or argument that you
A.B.C.D IP subnet mask want to use. This example uses the
Router(config-if)# ip address 172.16.0.1
172.16.0.1 IP address.
example, you must enter an IP subnet
mask.
A <cr> is not displayed; therefore, you
must enter additional keywords or
arguments to complete the command.

78-17478-01 xxxvii
Using the no and default Forms of Commands
Command Comment
Router(config-if)# ip address 172.16.0.1 255.255.255.0 ? Enter the IP subnet mask. This example
secondary Make this IP address a secondary address uses the 255.255.255.0 IP subnet mask.
<cr>
Router(config-if)# ip address 172.16.0.1 255.255.255.0 Enter ? to display what you must enter
example, you can enter the secondary
keyword, or you can press Enter.
A <cr> is displayed; you can press
Enter to complete the command, or
you can enter another keyword.
Router(config-if)# ip address 172.16.0.1 255.255.255.0 In this example, Enter is pressed to
Router(config-if)# complete the command.
Using the no and default Forms of Commands

Almost every configuration command has a no form. In general, use the no form to disable a function.
Use the command without the no keyword to reenable a disabled function or to enable a function that is
disabled by default. For example, IP routing is enabled by default. To disable IP routing, use the no ip
routing command; to reenable IP routing, use the ip routing command. The Cisco IOS software
command reference publications provide the complete syntax for the configuration commands and
describe what the no form of a command does.
Configuration commands can also have a default form, which returns the command settings to the
default values. Most commands are disabled by default, so in such cases using the default form has the
same result as using the no form of the command. However, some commands are enabled by default and
have variables set to certain default values. In these cases, the default form of the command enables the
command and sets the variables to their default values. The Cisco IOS software command reference
publications describe the effect of the default form of a command if the command functions differently
than the no form.
Saving Configuration Changes

Use the copy system:running-config nvram:startup-config command or the copy running-config
startup-config command to save your configuration changes to the startup configuration so that the
changes will not be lost if the software reloads or a power outage occurs. For example:
Router# copy system:running-config nvram:startup-config
Building configuration...
It might take a minute or two to save the configuration. After the configuration has been saved, the
following output appears:
[OK]
Router#
On most platforms, this task saves the configuration to NVRAM. On the Class A flash file system
platforms, this task saves the configuration to the location specified by the CONFIG_FILE environment
variable. The CONFIG_FILE variable defaults to NVRAM.

xxxviii 78-17478-01
Filtering Output from the show and more Commands
Filtering Output from the show and more Commands

You can search and filter the output of show and more commands. This functionality is useful if you
need to sort through large amounts of output or if you want to exclude output that you need not see.
To use this functionality, enter a show or more command followed by the “pipe” character (|); one of the
keywords begin, include, or exclude; and a regular expression on which you want to search or filter (the
expression is case-sensitive):
command | {begin | include | exclude} regular-expression
The output matches certain lines of information in the configuration file. The following example
illustrates how to use output modifiers with the show interface command when you want the output to
include only lines in which the expression “protocol” appears:
Router# show interface | include protocol
FastEthernet0/0 is up, line protocol is up

Serial4/0 is up, line protocol is up
Serial4/1 is up, line protocol is up
Serial4/2 is administratively down, line protocol is down
Serial4/3 is administratively down, line protocol is down
For more information on the search and filter functionality, see the “Using the Cisco IOS Command-Line
Interface” chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.
Finding Additional Feature Support Information

If you want to use a specific Cisco IOS software feature, you will need to determine in which Cisco IOS
software images that feature is supported. Feature support in Cisco IOS software images depends on
three main factors: the software version (called the “Release”), the hardware model (the “Platform” or
“Series”), and the “Feature Set” (collection of specific features designed for a certain network
environment). Although the Cisco IOS software documentation set documents feature support
information for Release 12.4 as a whole, it does not generally provide specific hardware and feature set
information.
To determine the correct combination of Release (software version), Platform (hardware version), and
Feature Set needed to run a particular feature (or any combination of features), use Feature Navigator.
Use Cisco Feature Navigator to find information about platform support and software image support.
Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images
support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to
http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Software features may also have additional limitations or restrictions. For example, a minimum amount
of system memory may be required. Or there may be known issues for features on certain platforms that
have not yet been resolved (called “Caveats”). For the latest information about these limitations, see the
release notes for the appropriate Cisco IOS software release. Release notes provide detailed installation
instructions, new feature descriptions, system requirements, limitations and restrictions, caveats, and
troubleshooting information for a particular software release.

78-17478-01 xxxix
Finding Additional Feature Support Information

xl 78-17478-01
Part 1: IP Services
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,
Release 12.4. To locate documentation of other commands that appear in this module, use the command
reference master index, or search online.
Contents
• How to Configure IP Services, page 3
• Managing IP Connections, page 3
• Configuring IP Accounting, page 9
• Monitoring and Maintaining the IP Network, page 11
• IP Services Configuration Examples, page 12
How to Configure IP Services

To configure optional IP services, perform any of the optional tasks described in the following sections:
• Managing IP Connections, page 3 (optional)
• Configuring IP Accounting, page 9 (optional)
Managing IP Connections
The IP suite offers a number of services that control and manage IP connections. Internet Control
Message Protocol (ICMP) provides many of these services. ICMP messages are sent by routers or access
servers to hosts or other routers when a problem is discovered with the Internet header. For detailed
information on ICMP, see RFC 792.

78-17478-01 3
To manage various aspects of IP connections, perform the optional tasks described in the following
sections:
• Enabling ICMP Protocol Unreachable Messages, page 4 (optional)
• Enabling ICMP Redirect Messages, page 4 (optional)
• Enabling ICMP Mask Reply Messages, page 5 (optional)
• Understanding Path MTU Discovery, page 5 (optional)
• Setting the MTU Packet Size, page 6 (optional)
• Enabling IP Source Routing, page 6 (optional)
• Configuring a DRP Server Agent, page 7 (optional)
See the “ICMP Services: Example” section at the end of this chapter for examples of ICMP services.
Enabling ICMP Protocol Unreachable Messages

If the Cisco IOS software receives a nonbroadcast packet destined for itself that uses an unknown
protocol, it sends an ICMP protocol unreachable message back to the source. Similarly, if the software
receives a packet that it is unable to deliver to the ultimate destination because it knows of no route to
the destination address, it sends an ICMP host unreachable message to the source. This feature is enabled
by default.
To enable this service if it has been disabled, use the following command in interface configuration
mode:
Command Purpose
Router(config-if)# ip unreachables Enables the sending of ICMP protocol unreachable and host unreachable
messages.
To limit the rate that ICMP destination unreachable messages are generated, use the following command
in global configuration mode:
Command Purpose
Router(config)# ip icmp rate-limit Limits the rate at which ICMP destination unreachable messages are
unreachable [df] milliseconds generated.
Enabling ICMP Redirect Messages

Routes are sometimes less than optimal. For example, it is possible for the router to be forced to resend
a packet through the same interface on which it was received. If the router resends a packet through the
same interface on which it was received, the Cisco IOS software sends an ICMP redirect message to the
originator of the packet telling the originator that the router is on a subnet directly connected to the
receiving device, and that it must forward the packet to another system on the same subnet. The software
sends an ICMP redirect message to the originator of the packet because the originating host presumably
could have sent that packet to the next hop without involving this device at all. The redirect message
instructs the sender to remove the receiving device from the route and substitute a specified device
representing a more direct path. This feature is enabled by default.

4 78-17478-01
To enable the sending of ICMP redirect messages if this feature was disabled, use the following
command in interface configuration mode:
Command Purpose
Router(config-if)# ip redirects Enables the sending of ICMP redirect messages to learn routes.
Enabling ICMP Mask Reply Messages

Occasionally, network devices must know the subnet mask for a particular subnetwork in the
internetwork. To obtain this information, such devices can send ICMP mask request messages. ICMP
mask reply messages are sent in reply from devices that have the requested information. The Cisco IOS
software can respond to ICMP mask request messages if this function is enabled.
To enable the sending of ICMP mask reply messages, use the following command in interface
configuration mode:
Command Purpose
Router(config-if)# ip mask-reply Enables the sending of ICMP mask reply messages.
Understanding Path MTU Discovery

The Cisco IOS software supports the IP Path MTU Discovery mechanism, as defined 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
router is unable to forward a datagram because it requires fragmentation (the packet is larger than the
MTU you set for the interface with the ip mtu interface configuration command), but the “don’t
fragment” (DF) bit is set. The Cisco IOS software sends a message to the sending host, alerting it to the
problem. The host will need to fragment packets for the destination so that they fit the smallest packet
size of all the links along the path. This technique is shown in Figure 1.
Figure 1 IP Path MTU Discovery
MTU = 1500
Packet = 800 bytes
Don't fragment
MTU = 512
"Unreachable" sent
S1014a
Packet dropped
IP Path MTU Discovery is useful when a link in a network goes down, forcing the use of another,
different MTU-sized link (and different routers). As shown in Figure 1, suppose a router is sending IP
packets over a network where the MTU in the first router is set to 1500 bytes, but the second router is
set to 512 bytes. If the “Don’t fragment” bit of the datagram is set, the datagram would be dropped

78-17478-01 5
because the 512-byte router is unable to forward it. All packets larger than 512 bytes are dropped in this
case. The second router returns an ICMP destination unreachable message to the source of the datagram
with its Code field indicating, “Fragmentation needed and DF set.” To support IP Path MTU Discovery,
it would also include the MTU of the next hop network link in the low-order bits of an unused header
field.
IP Path MTU Discovery is also useful when a connection is being established and the sender has no
information at all about the intervening links. It is always advisable to use the largest MTU that the links
will bear; the larger the MTU, the fewer packets the host must send.
Note IP Path MTU Discovery is a process initiated by end hosts. If an end host does not support IP Path
MTU Discovery, the receiving device will have no mechanism available to avoid fragmenting
datagrams generated by the end host.
If a router that is configured with a small MTU on an outbound interface receives packets from a host
that is configured with a large MTU (for example, receiving packets from a Token Ring interface and
forwarding them to an outbound Ethernet interface), the router fragments received packets that are larger
than the MTU of the outbound interface. Fragmenting packets slows the performance of the router. To
keep routers in your network from fragmenting received packets, run IP Path MTU Discovery on all
hosts and routers in your network, and always configure the largest possible MTU for each router
interface type.
To enable IP Path MTU Discovery for connections initiated by the router (when the router is acting as a
host), see the section “Enabling TCP Path MTU Discovery” later in this chapter.
Setting the MTU Packet Size

All interfaces have a default MTU packet size. You can adjust the IP MTU size so that the Cisco IOS
software will fragment any IP packet that exceeds the MTU set for an interface.
Changing the MTU value (with the mtu interface configuration command) can affect the IP MTU value.
If the current IP MTU value is the same as the MTU value and you change the MTU value, the IP MTU
value will be modified automatically to match the new MTU. However, the reverse is not true; changing
the IP MTU value has no effect on the value for the mtu interface configuration command.
Also, all devices on a physical medium must have the same protocol MTU in order to operate.
To set the MTU packet size for a specified interface, use the following command in interface
configuration mode:
Command Purpose
Router(config-if)# ip mtu bytes Sets the IP MTU packet size for an interface.
Enabling IP Source Routing

The Cisco IOS software examines IP header options on every packet. It supports the IP header options
Strict Source Route, Loose Source Route, Record Route, and Time Stamp, which are defined in
RFC 791. If the software finds a packet with one of these options enabled, it performs the appropriate
action. If it finds a packet with an invalid option, it sends an ICMP parameter problem message to the
source of the packet and discards the packet.

6 78-17478-01
IP provides a provision known as source routing that allows the source IP host to specify a route through
the IP network. Source routing is specified as an option in the IP header. If source routing is specified,
the software forwards the packet according to the specified source route. This feature is employed when
you want to force a packet to take a certain route through the network. The default is to perform source
routing.
To enable IP source-route header options if they have been disabled, use the following command in
global configuration mode:
Command Purpose
Router(config)# ip source-route Enables IP source routing.
Configuring a DRP Server Agent

The Director Response Protocol (DRP) is a simple User Datagram Protocol (UDP)-based application
developed by Cisco Systems. It enables the Cisco DistributedDirector product to query routers (DRP
Server Agents) in the field for Border Gateway Protocol (BGP) and Interior Gateway Protocol (IGP)
routing table metrics between distributed servers and clients. DistributedDirector, a separate standalone
product, uses DRP to transparently redirect end-user service requests to the topologically closest
responsive server. DRP enables DistributedDirector to provide dynamic, scalable, and “network
intelligent” Internet traffic load distribution between multiple geographically dispersed servers.
DRP Server Agents are border routers (or peers to border routers) that support the geographically
distributed servers for which DistributedDirector service distribution is desired. Note that, because
DistributedDirector makes decisions based on BGP and IGP information, all DRP Server Agents must
have access to full BGP and IGP routing tables.
Refer to the Cisco DistributedDirector 2501 Installation and Configuration Guide or the Cisco
DistributedDirector 4700-M Installation and Configuration Guide for information on how to configure
DistributedDirector.
To configure and maintain the DRP Server Agent, perform the tasks described in the following sections.
The task in the first section is required; the tasks in the remaining sections are optional.
• Enabling the DRP Server Agent, page 7 (required)
• Limiting the Source of DRP Queries, page 8 (optional)
• Configuring Authentication of DRP Queries and Responses, page 8 (optional)
To monitor and maintain the DRP Server Agent, see the section “Monitoring and Maintaining the DRP
Server Agent” later in this chapter.
For an example of configuring a DRP Server Agent, see the section “DRP Server Agent: Example”
section on page 13 at the end of this chapter.
Enabling the DRP Server Agent

The DRP Server Agent is disabled by default. To enable it, use the following command in global
configuration mode:
Command Purpose
Router(config)# ip drp server Enables the DRP Server Agent.

78-17478-01 7
Limiting the Source of DRP Queries

As a security measure, you can limit the source of valid DRP queries. If a standard IP access list is
applied to the interface, the Server Agent will respond only to DRP queries originating from an IP
address in the list. If no access list is configured, the Server Agent will answer all queries.
If both an access group and a key chain (described in the next section) have been configured, both
security mechanisms must allow access before a request is processed.
To limit the source of valid DRP queries, use the following command in global configuration mode:
Command Purpose
Router(config)# ip drp access-group Controls the sources of valid DRP queries by applying a standard IP
access-list-number access list.
Configuring Authentication of DRP Queries and Responses

Another available security measure is to configure the DRP Server Agent to authenticate DRP queries
and responses. You define a key chain, identify the keys that belong to the key chain, and specify how
long each key is valid. To do so, use the following commands beginning in global configuration mode:
Command Purpose
Step 1 Router(config)# ip drp authentication key-chain Identifies which key chain to use to authenticate all DRP
name-of-chain requests and responses.
Step 2 Router(config)# key chain name-of-chain Identifies a key chain (match the name configured in
Step 1).
Step 3 Router(config-keychain)# key number In key-chain configuration mode, identifies the key number.
Step 4 Router(config-keychain-key)# key-string text In key-chain key configuration mode, identifies the key
string.
Step 5 Router(config-keychain-key)# accept-lifetime (Optional) Specifies the time period during which the key
start-time {infinite | end-time | duration can be received.
seconds}
Step 6 Router(config-keychain-key)# send-lifetime (Optional) Specifies the time period during which the key
start-time {infinite | end-time | duration can be sent.
seconds}
When configuring your key chains and keys, be aware of the following guidelines:
• The key chain configured for the DRP Server Agent in Step 1 must match the key chain in Step 2.
• The key configured in the primary agent in the remote router must match the key configured in the
DRP Server Agent in order for responses to be processed.
• You can configure multiple keys with lifetimes, and the software will rotate through them.
• If authentication is enabled and multiple keys on the key chain happen to be active based on the
send-lifetime values, the software uses only the first key it encounters for authentication.
• Use the show key chain command to display key chain information.

8 78-17478-01
Configuring IP Accounting
Note To configure lifetimes for DRP authentication, you must configure time services for your router. For
information on setting time services, see the Network Time Protocol (NTP) and calendar commands
in the “Performing Basic System Management” chapter of the Cisco IOS Configuration
Fundamentals Configuration Guide.
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 feature
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.
To enable IP accounting, use one of the following commands for each interface in interface configuration
mode:
Command Purpose
Router(config-if)# ip accounting Enables basic IP accounting.
Router(config-if)# ip accounting Enables IP accounting with the ability to identify IP traffic that fails IP
access-violations access lists.

78-17478-01 9
To configure other IP accounting functions, use the following commands in global configuration mode,
as needed:
Command Purpose
Router(config)# ip accounting-threshold Sets the maximum number of accounting entries to be created.
threshold
Router(config)# ip accounting-list Filters accounting information for hosts.
ip-address wildcard
Router(config)# ip accounting-transits Controls the number of transit records that will be stored in the IP
count accounting database.
To display IP access violations for a specific IP accounting database, use the following command in
EXEC mode:
Command Purpose
Router# show ip accounting [checkpoint] Displays IP access violation information.
access-violations
To display IP access violations, include the access-violations keyword in the show ip accounting EXEC
command. If you do not specify the keyword, the command defaults to displaying the number of packets
that have passed access lists and were routed. The access violations output displays the number of the
access list failed by the last packet for the source and destination pair. The number of packets reveals
how aggressive the attack is upon a specific destination.
Use the show ip accounting EXEC command to display the active accounting database, and traffic
coming from a remote site and transiting through a router. To display the checkpointed database, use the
show ip accounting checkpoint EXEC command. The clear ip accounting EXEC command clears the
active database and creates the checkpointed database.
Configuring IP MAC Accounting

The MAC address accounting functionality provides accounting information for IP traffic based on the
source and destination MAC addresses on LAN interfaces. MAC accounting calculates the total packet
and byte counts for a LAN interface that receives or sends IP packets to or from a unique MAC address.
It also records a timestamp for the last packet received or sent. For example, with IP MAC accounting,
you can determine how much traffic is being sent to and/or received from various peers at NAPS/peering
points. IP MAC accounting is supported on Ethernet, Fast Ethernet, and FDDI interfaces and supports
Cisco Express Forwarding (CEF), distributed CEF (dCEF), flow, and optimum switching.
To configure the interface for IP accounting based on the MAC address, perform the following steps
beginning in global configuration:
Command Purpose
Step 1 Router(config)# interface type number Specifies the interface and enters interface configuration
mode.
Step 2 Router(config-if)# ip accounting mac-address Configures IP accounting based on the MAC address of
{input | output} received (input) or transmitted (output) packets

10 78-17478-01
Monitoring and Maintaining the IP Network
To remove IP accounting based on the MAC address from the interface, use the no ip accounting
mac-address command.
Use the EXEC command show interface mac to display MAC accounting information for interfaces
configured for MAC accounting.
Configuring IP Precedence Accounting

The precedence accounting feature provides accounting information for IP traffic based on the
precedence on 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 IP precedence. This feature is supported on
all interfaces and subinterfaces and supports CEF, dCEF, flow, and optimum switching.
To configure the interface for IP accounting based on IP precedence, perform the following steps
beginning in global configuration model:
Command Purpose
Step 1 Router(config)# interface type number Specifies the interface (or subinterface) and enters interface
configuration mode.
Step 2 Router(config-if)# ip accounting precedence Configures IP accounting based on the precedence of
{input | output} received (input) or transmitted (output) packets
To remove IP accounting based on IP precedence from the interface, use the no ip accounting
precedence command.
Use the EXEC command show interface precedence to display precedence accounting information for
interfaces configured for precedence accounting.
Monitoring and Maintaining the IP Network

To monitor and maintain your network, perform any of the optional tasks described in the following
sections:
• Clearing Caches, Tables, and Databases, page 11 (optional)
• Monitoring and Maintaining the DRP Server Agent, page 12 (optional)
• Displaying System and Network Statistics, page 12 (optional)
Clearing Caches, Tables, and Databases

You can remove all contents of a particular cache, table, or database. Clearing a cache, table, or database
can become necessary when the contents of the particular structure have become or are suspected to be
invalid.
To clear the database for IP accounting, use the following command in EXEC mode, as needed:
Command Purpose
Router# clear ip accounting Clears the active IP accounting or checkpointed database when IP accounting
[checkpoint] is enabled.

78-17478-01 11
IP Services Configuration Examples
Monitoring and Maintaining the DRP Server Agent

To monitor and maintain the DRP Server Agent, use the following commands in EXEC mode:
Command Purpose
Router# clear ip drp Clears statistics being collected on DRP requests and responses.
Router# show ip drp Displays information about the DRP Server Agent.
Displaying System and Network Statistics

You can display specific statistics such as the contents of IP routing tables, caches, and databases. The
resulting information can be used to determine resource utilization and to solve network problems.
To display specific statistics such as the contents of IP routing tables, caches, and databases, use the
following commands in privileged EXEC mode, as needed.
Command Purpose
Router# show ip accounting [checkpoint] Displays the active IP accounting or checkpointed database.
Router# show ip redirects Displays the address of the default router and the address of hosts
for which an ICMP redirect message has been received.
Router# show ip sockets Displays IP socket information.
Router# show ip traffic Displays IP protocol statistics.

This section provides the following IP configuration examples:
• ICMP Services: Example, page 12
• DRP Server Agent: Example, page 13
• IP Accounting: Example, page 13
ICMP Services: Example

The following example changes some of the ICMP defaults for the first Ethernet interface 0. Disabling
the sending of redirects could mean that you do not expect your devices on this segment to ever need to
send a redirect message. Disabling the unreachables messages will have a secondary effect—it also will
disable IP Path MTU Discovery, because path discovery works by having the Cisco IOS software send
Unreachables messages. If you have a network segment with a small number of devices and an absolutely
reliable traffic pattern—which could easily happen on a segment with a small number of little-used user
devices—you would be disabling options that your device would be unlikely to use anyway.
interface ethernet 0
no ip unreachables
no ip redirects

12 78-17478-01
DRP Server Agent: Example

The following example enables the DRP Server Agent. Sources of DRP queries are limited by access
list 1, which permits only queries from the host at address 33.45.12.4. Authentication is also configured
for the DRP queries and responses.
ip drp server
access-list 1 permit 10.0.0.0
ip drp access-group 1
ip drp authentication key-chain mktg
key chain mktg
key 1
key-string internal
IP Accounting: Example
The following example enables IP accounting based on the source and destination MAC address and
based on IP precedence for received and transmitted packets:
interface Ethernet0/5
ip accounting mac-address input
ip accounting mac-address output
ip accounting precedence input
ip accounting precedence output

78-17478-01 13

14 78-17478-01
Part 2: IP Access Lists
Configuring IP Access Lists
Packet filtering helps control packet movement through the network. Such control can help limit network
traffic and restrict network use by certain users or devices. To permit or deny packets from crossing
specified interfaces, we provide access lists (ACLs).
You can use access lists in the following ways:
• To control the transmission of packets on an interface
• To control vty access
• To restrict contents of routing updates
This module summarizes how to create IP access lists and how to apply them.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Contents
• Information About Access Lists, page 17
• How to Configure Access Lists, page 18
• Configuration Examples for Access Lists, page 30
Information About Access Lists

To configure access lists, you should understand the following concept:
• How Access Lists Work, page 18

78-17478-01 17
How to Configure Access Lists
How Access Lists Work

An access list is a sequential collection of permit and deny conditions that apply to IP addresses. The
Cisco IOS software tests addresses against the conditions in an access list one by one. The first match
determines whether the software accepts or rejects the address. Because the software stops testing
conditions after the first match, the order of the conditions is critical. If no conditions match, the
software rejects the address.
The two main tasks involved in using access lists are as follows:
1. Create an access list by specifying an access list number or name and access conditions.
2. Apply the access list to interfaces or terminal lines.

This section contains the following procedures. Either the first or second task is required, depending on
whether you identify your access list with a number or a name.
• Creating Standard and Extended Access Lists Using Numbers, page 18 (required)
• Creating Standard and Extended Access Lists Using Names, page 21 (required)
• Specifying IP Extended Access Lists with Fragment Control, page 23 (optional)
• Enabling Turbo Access Control Lists, page 26 (optional)
• Applying Time Ranges to Access Lists, page 27 (optional)
• Including Comments About Entries in Access Lists, page 28 (optional)
• Applying Access Lists, page 28 (required)
• Clearing the Access List Counters, page 30 (optional)
Creating Standard and Extended Access Lists Using Numbers

Cisco IOS software supports the following types of access lists for IP:
• Standard IP access lists that use source addresses for matching operations.
• Extended IP access lists that use source and destination addresses for matching operations, and
optional protocol type information for finer granularity of control.
• Dynamic extended IP access lists that grant access per user to a specific source or destination host
basis through a user authentication process. In essence, you can allow user access through a firewall
dynamically, without compromising security restrictions. Dynamic access lists and lock-and-key
access are described in the “Configuring Traffic Filters” chapter of the Cisco IOS Security
• Reflexive access lists that allow IP packets to be filtered based on session information. Reflexive
access lists contain temporary entries, and are nested within an extended, named IP access list. For
information on reflexive access lists, refer to the “Configuring IP Session Filtering (Reflexive
Access Lists)” chapter in the Cisco IOS Security Configuration Guide and the “Reflexive Access
List Commands” chapter in the Cisco IOS Security Command Reference.

18 78-17478-01
To create a standard access list, use the following commands in global configuration mode:
Command Purpose
Step 1 Router(config)# access-list access-list-number remark Indicates the purpose of the deny or permit
remark statement.1
Step 2 Router(config)# access-list access-list-number {deny | Defines a standard IP access list using a source
permit} source [source-wildcard] [log] address and wildcard.
or
Router(config)# access-list access-list-number {deny | Defines a standard IP access list using an

permit} any [log]
abbreviation for the source and source mask of
0.0.0.0 255.255.255.255.
1. This example configures the remark before the deny or permit statement. The remark can be configured after the deny or permit statement.
The Cisco IOS software can provide logging messages about packets permitted or denied by a standard
IP access list. That is, any packet that matches the access list will cause an informational logging
message about the packet to be sent to the console. The level of messages logged to the console is
controlled by the logging console global configuration command.
The first packet that triggers the access list causes an immediate logging message, and subsequent
packets are collected over 5-minute intervals before they are displayed or logged. The logging message
includes the access list number, whether the packet was permitted or denied, the source IP address of the
packet, and the number of packets from that source permitted or denied in the prior 5-minute interval.
However, you can use the ip access-list log-update command to set the number of packets that, when
match an access list (and are permitted or denied), cause the system to generate a log message. You might
want to do this to receive log messages more frequently than at 5-minute intervals.
Caution If you set the number-of-matches argument to 1, a log message is sent right away, rather than caching
it; every packet that matches an access list causes a log message. A setting of 1 is not recommended
because the volume of log messages could overwhelm the system.
Even if you use the ip access-list log-update command, the 5-minute timer remains in effect, so each
cache is emptied at the end of 5 minutes, regardless of the count of messages in each cache. Regardless
of when the log message is sent, the cache is flushed and the count reset to 0 for that message the same
way it is when a threshold is not specified.
Note The logging facility might drop some logging message packets if there are too many to be handled
or if there is more than one logging message to be handled in 1 second. This behavior prevents the
router from crashing due to too many logging packets. Therefore, the logging facility should not be
used as a billing tool or an accurate source of the number of matches to an access list.
Note If you enable CEF and then create an access list that uses the log keyword, the packets that match the
access list are not CEF switched. They are fast switched. Logging disables CEF.
For an example of a standard IP access list using logs, see the section “Numbered Access List: Example”
at the end of this chapter.

78-17478-01 19
To create an extended access list, use the following commands in global configuration mode:
Command Purpose
Step 1 Router(config)# access-list access-list-number Indicates the purpose of the deny or permit
remark remark statement.1
Step 2 Router(config)# access-list access-list-number {deny Defines an extended IP access list number and the
| permit} protocol source source-wildcard access conditions. Specifies a time range to restrict
destination destination-wildcard [precedence
precedence] [tos tos] [established] [log |
when the permit or deny statement is in effect. Use
log-input] [time-range time-range-name] [fragments] the log keyword to get access list logging messages,
including violations. Use the log-input keyword to
include input interface, source MAC address, or VC
in the logging output.
or
or
Router(config)# access-list access-list-number {deny Defines an extended IP access list using an
| permit} protocol any any [log | log-input] abbreviation for a source and source wildcard of
[time-range time-range-name] [fragments] 0.0.0.0 255.255.255.255, and an abbreviation for a
destination and destination wildcard of 0.0.0.0
255.255.255.255.
or or
Router(config)# access-list access-list-number {deny

Defines an extended IP access list using an
| permit} protocol host source host destination [log
| log-input] [time-range time-range-name][fragments] abbreviation for a source and source wildcard of
source 0.0.0.0, and an abbreviation for a destination
and destination wildcard of destination 0.0.0.0.
or or
Defines a dynamic access list. For information about
Router(config)# access-list access-list-number
[dynamic dynamic-name [timeout minutes]] {deny | lock-and-key access, refer to the “Configuring Traffic
permit} protocol source source-wildcard destination Filters” chapter in the Cisco IOS Security
destination-wildcard [precedence precedence] [tos Configuration Guide.
tos] [established] [log | log-input] [time-range
time-range-name] [fragments]
Note The fragments keyword is described in the “Specifying IP Extended Access Lists with Fragment
Control” section.
After you create an access list, you place any subsequent additions (possibly entered from the terminal)
at the end of the list. In other words, you cannot selectively add or remove access list command lines
from a specific access list.
Note When creating an access list, remember that, by default, the end of the access list contains an implicit
deny statement for everything if it did not find a match before reaching the end.

20 78-17478-01
Note In a standard access list, if you omit the mask from an associated IP host address access list
specification, 0.0.0.0 is assumed to be the mask.
Note Autonomous switching is not used when you have extended access lists.
After creating an access list, you must apply it to a line or interface, as shown in the section “Applying
Access Lists” later in this chapter. See the “Implicit Masks in Access Lists: Example” section at the end
of this chapter for examples of implicit masks.
Creating Standard and Extended Access Lists Using Names

You can identify IP access lists with an alphanumeric string (a name) rather than a number. Named
access lists allow you to configure more IP access lists in a router than if you were to use numbered
access lists. If you identify your access list with a name rather than a number, the mode and command
syntax are slightly different. Currently, only packet and route filters can use a named list.
Consider the following guidelines before configuring named access lists:
• Access lists specified by name are not compatible with Cisco IOS Releases prior to 11.2.
• Not all access lists that accept a number will accept a name. Access lists for packet filters and route
filters on interfaces can use a name.
• A standard access list and an extended access list cannot have the same name.
• Numbered access lists are also available, as described in the previous section, “Creating Standard
and Extended Access Lists Using Numbers.”
To create a standard access list, use the following commands beginning in global configuration mode:
Command Purpose
Step 1 Router(config)# ip access-list standard name Defines a standard IP access list using a name and
enters standard named access list configuration
mode.
Step 2 Router(config-std-nacl)# remark remark Allows you to comment about the following deny or
permit statement in a named access list.1
Step 3 Router(config-std-nacl)# deny {source Specifies one or more conditions allowed or denied,
[source-wildcard] | any}[log] which determines whether the packet is passed or
dropped.
and/or
Router(config-std-nacl)# permit {source
[source-wildcard] | any}[log]
Step 4 Router(config-std-nacl)# exit Exits access-list configuration mode.

78-17478-01 21
To create an extended access list, use the following commands beginning in global configuration mode:
Step 1 Router(config)# ip access-list extended name Defines an extended IP access list using a name and
enters extended named access list configuration
mode.
Step 2 Router(config-ext-nacl)# remark remark Allows you to comment about the following deny or
permit statement in a named access list.1
Step 3 Router(config-ext-nacl)# deny | permit protocol In access-list configuration mode, specifies the
source source-wildcard destination conditions allowed or denied. Specifies a time range
destination-wildcard [precedence precedence] [tos
tos] [established] [log | log-input] [time-range
to restrict when the permit or deny statement is in
time-range-name] [fragments] effect. Use the log keyword to get access list logging
messages, including violations. Use the log-input
keyword to include input interface, source MAC
address, or VC in the logging output.
or or
Router(config-ext-nacl)# deny | permit protocol any Defines an extended IP access list using an
any [log | log-input] [time-range time-range-name] abbreviation for a source and source wildcard of
[fragments]
0.0.0.0 255.255.255.255, and an abbreviation for a
destination and destination wildcard of 0.0.0.0
255.255.255.255.
or or
Router(config-ext-nacl) deny | permit protocol host
source host destination [log | log-input]
Defines an extended IP access list using an
[time-range time-range-name] [fragments] abbreviation for a source and source wildcard of
source 0.0.0.0, and an abbreviation for a destination
and destination wildcard of destination 0.0.0.0.
or or
Router(config-ext-nacl)# dynamic dynamic-name Defines a dynamic access list.
[timeout minutes] {deny | permit} protocol source
source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [established] [log
| log-input] [time-range time-range-name]
[fragments]
Note Autonomous switching is not used when you have extended access lists.
Note The fragments keyword is described in the Specifying IP Extended Access Lists with Fragment
Control section.
After you initially create an access list, you place any subsequent additions (possibly entered from the
terminal) at the end of the list. In other words, you cannot selectively add access list command lines to
a specific access list. However, you can use no permit and no deny commands to remove entries from
a named access list.

22 78-17478-01
Note When making the standard and extended access list, remember that, by default, the end of the access
list contains an implicit deny statement for everything if it did not find a match before reaching the
end. Further, with standard access lists, if you omit the mask from an associated IP host address
access list specification, 0.0.0.0 is assumed to be the mask.
After creating an access list, you must apply it to a line or interface, as shown in section “Applying
Access Lists” later in this chapter.
See the “Named Access List: Example” section at the end of this chapter for an example of a named
access list.
Specifying IP Extended Access Lists with Fragment Control

This section describes the functionality added to IP extended named and numbered access lists. You can
now specify whether the system examines noninitial IP fragments of packets when applying an IP
extended access list.
Prior to this feature, nonfragmented packets and the initial fragment of a packet were processed by IP
extended access lists (if such an access list was applied), but noninitial fragments were permitted by
default. The IP Extended Access Lists with Fragment Control feature now allows more granularity of
control over noninitial packets.
Because noninitial fragments contain only Layer 3 information, access-list entries containing only
Layer 3 information can and now are applied to noninitial fragments. The fragment has all the
information the system needs to filter, so the entry is applied to the fragments.
This feature adds the optional fragments keyword to four IP access list commands [access-list (IP
extended), deny (IP), dynamic, and permit (IP)]. By specifying the fragments keyword in an access
list entry, that particular access list entry applies only to noninitial fragments of packets; the fragment is
either permitted or denied accordingly.

78-17478-01 23
The behavior of access-list entries regarding the presence or absence of the fragments keyword can be
summarized as follows:
If the Access-List Entry has... Then...

...no fragments keyword, and For an access-list entry containing only Layer 3 information:
assuming all of the access-list entry
• The entry is applied to nonfragmented packets, initial
information matches,
fragments and noninitial fragments.
For an access list entry containing Layer 3 and Layer 4
information:
• The entry is applied to nonfragmented packets and initial
fragments.
– If the entry matches and is a permit statement, the
packet or fragment is permitted.
– If the entry matches and is a deny statement, the
packet or fragment is denied.
• The entry is also applied to noninitial fragments in the
following manner. Because noninitial fragments contain
only Layer 3 information, only the Layer 3 portion of an
access-list entry can be applied. If the Layer 3 portion of
the access-list entry matches, and
– If the entry is a permit statement, the noninitial
fragment is permitted.
– If the entry is a deny statement, the next access-list
entry is processed.
Note Note that the deny statements are handled

differently for noninitial fragments versus
nonfragmented or initial fragments.
...the fragments keyword, and The access-list entry is applied only to noninitial fragments.
assuming all of the access-list entry
information matches,
Note The fragments keyword cannot be configured for
an access-list entry that contains any Layer 4
information.
Be aware that you should not simply add the fragments keyword to every access list entry because the
first fragment of the IP packet is considered a nonfragment and is treated independently of the
subsequent fragments. An initial fragment will not match an access list permit or deny entry that
contains the fragments keyword, the packet is compared to the next access list entry, and so on, until it
is either permitted or denied by an access list entry that does not contain the fragments keyword.
Therefore, you may need two access list entries for every deny entry. The first deny entry of the pair
will not include the fragments keyword, and applies to the initial fragment. The second deny entry of
the pair will include the fragments keyword and applies to the subsequent fragments. In the cases where
there are multiple deny access list entries for the same host but with different Layer 4 ports, a single
deny access-list entry with the fragments keyword for that host is all that needs to be added. Thus all
the fragments of a packet are handled in the same manner by the access list.

24 78-17478-01
The fragments keyword can be applied to dynamic access lists also.

Packet fragments of IP datagrams are considered individual packets and each counts individually as a
packet in access list accounting and access list violation counts.
Note The fragments keyword cannot solve all cases involving access lists and IP fragments.
Turbo Access Lists

A turbo access list treats fragments and uses the fragments keyword in the same manner as a nonturbo
access list.
Policy Routing
Fragmentation and the fragment control feature affect policy routing if the policy routing is based on the
match ip address command and the access list had entries that match on Layer 4 through 7 information.
It is possible that noninitial fragments pass the access list and are policy routed, even if the first fragment
was not policy routed or the reverse.
By using the fragments keyword in access list entries as described earlier, a better match between the
action taken for initial and noninitial fragments can be made and it is more likely policy routing will
occur as intended.
Benefits of Fragment Control in an IP Extended Access List

If the fragments keyword is used in additional IP access list entries that deny fragments, the fragment
control feature provides the following benefits:
Additional Security
You are able to block more of the traffic you intended to block, not just the initial fragment of such
packets. The unwanted fragments no longer linger at the receiver until the reassembly timeout is reached
because they are blocked before being sent to the receiver. Blocking a greater portion of unwanted traffic
improves security and reduces the risk from potential hackers.
Reduced Cost
By blocking unwanted noninitial fragments of packets, you are not paying for traffic you intended to
block.
Reduced Storage
By blocking unwanted noninitial fragments of packets from ever reaching the receiver, that destination
does not have to store the fragments until the reassembly timeout period is reached.
Expected Behavior Is Achieved

The noninitial fragments will be handled in the same way as the initial fragment, which is what you
would expect. There are fewer unexpected policy routing results and fewer fragment of packets being
routed when they should not be.
For an example of fragment control in an IP extended access list, see the “IP Extended Access List with
Fragment Control: Example”.

78-17478-01 25
Enabling Turbo Access Control Lists

The Turbo Access Control Lists (Turbo ACL) feature processes access lists more expediently than
conventional access lists. This feature enables Cisco 7200 and 7500 series routers, and Cisco 12000
series Gigabit Switch Routers, to evaluate ACLs for more expedient packet classification and access
checks.
ACLs are normally searched sequentially to find a matching rule, and ACLs are ordered specifically to
take this factor into account. Because of the increasing needs and requirements for security filtering and
packet classification, ACLs can expand to the point that searching the ACL adds a substantial amount of
time and memory when packets are being forwarded. Moreover, the time taken by the router to search
the list is not always consistent, adding a variable latency to the packet forwarding. A high CPU load is
necessary for searching an access list with several entries.
The Turbo ACL feature compiles the ACLs into a set of lookup tables, while maintaining the first match
requirements. Packet headers are used to access these tables in a small, fixed number of lookups,
independently of the existing number of ACL entries. The benefits of this feature include the following:
• For ACLs larger than three entries, the CPU load required to match the packet to the predetermined
packet-matching rule is lessened. The CPU load is fixed, regardless of the size of the access list,
allowing for larger ACLs without incurring any CPU overhead penalties. The larger the access list,
the greater the benefit.
• The time taken to match the packet is fixed, so that latency of the packets is smaller (substantially
in the case of large access lists) and, more importantly, consistent, allowing better network stability
and more accurate transit times.
Note Access lists containing specialized processing characteristics such as evaluate and time-range entries
are excluded from Turbo ACL acceleration.
The Turbo ACL builds a set of lookup tables from the ACLs in the configuration; these tables increase
the internal memory usage, and in the case of large and complex ACLs, tables containing 2 MB to 4 MB
of memory are usually required. Routers enabled with the Turbo ACL feature should allow for this
amount of memory usage. The show access-list compiled EXEC command displays the memory
overhead of the Turbo ACL tables for each access list.
To configure the Turbo ACL feature, perform the tasks described in the following sections. The task in
the first section is required; the task in the remaining section is optional:
• Configuring Turbo ACLs (Required)
• Verifying Turbo ACLs (Optional)
Configuring Turbo ACLs

To enable the Turbo ACL feature, use the following command in global configuration mode:
Command Purpose
Router(config)# access-list compiled Enables the Turbo ACL feature.

26 78-17478-01
Verifying Turbo ACLs

Use the show access-list compiled EXEC command to verify that the Turbo ACL feature has been
successfully configured on your router. This command also displays the memory overhead of the Turbo
ACL tables for each access list. The command output contains the following states:
• Operational—The access list has been compiled by Turbo ACL, and matching to this access list is
performed through the Turbo ACL tables at high speed.
• Unsuitable—The access list is not suitable for compiling, perhaps because it has time-range enabled
entries, evaluate references, or dynamic entries.
• Deleted—No entries are in this access list.
• Building—The access list is being compiled. Depending on the size and complexity of the list, and
the load on the router, the building process may take a few seconds.
• Out of memory—An access list cannot be compiled because the router has exhausted its memory.
The following is sample output from the show access-lists compiled EXEC command:
Router# show access-lists compiled
Compiled ACL statistics:

12 ACLs loaded, 12 compiled tables
ACL State Tables Entries Config Fragment Redundant Memory
1 Operational 1 2 1 0 0 1Kb
First level lookup tables:
Block Use Rows Columns Memory used
0 TOS/Protocol 6/16 12/16 66048
1 IP Source (MS) 10/16 12/16 66048
2 IP Source (LS) 27/32 12/16 132096
3 IP Dest (MS) 3/16 12/16 66048
4 IP Dest (LS) 9/16 12/16 66048
5 TCP/UDP Src Port 1/16 12/16 66048
6 TCP/UDP Dest Port 3/16 12/16 66048
7 TCP Flags/Fragment 3/16 12/16 66048
Applying Time Ranges to Access Lists

You can implement access lists based on the time of day and week using the time-range global
configuration command. To do so, first define the name and times of the day and week of the time range,
then reference the time range by name in an access list to apply restrictions to the access list.
Currently, IP and Internetwork Packet Exchange (IPX) named or numbered extended access lists are the
only functions that can use time ranges. The time range allows the network administrator to define when
the permit or deny statements in the access list are in effect. Prior to this feature, access list statements
were always in effect once they were applied. The time-range keyword is referenced in the named and
numbered extended access list task tables in the previous sections “Creating Standard and Extended
Access Lists Using Numbers” and “Creating Standard and Extended Access Lists Using Names.” The

78-17478-01 27
time-range command is described in the “Performing Basic System Management” chapter of the Cisco
IOS Configuration Fundamentals Configuration Guide. See the “Time Range Applied to an IP Access
List: Example” section at the end of this chapter for a configuration example of IP time ranges.
Possible benefits of using time ranges include the following:
• The network administrator has more control over permitting or denying a user access to resources.
These resources could be an application (identified by an IP address/mask pair and a port number),
policy routing, or an on-demand link (identified as interesting traffic to the dialer).
• Network administrators can set time-based security policy, including the following:
– Perimeter security using the Cisco IOS Firewall feature set or access lists
– Data confidentiality with Cisco Encryption Technology or IP Security Protocol (IPSec)
• Policy-based routing (PBR) and queueing functions are enhanced.
• When provider access rates vary by time of day, it is possible to automatically reroute traffic cost
effectively.
• Service providers can dynamically change a committed access rate (CAR) configuration to support
the quality of service (QoS) service level agreements (SLAs) that are negotiated for certain times of
day.
• Network administrators can control logging messages. Access list entries can log traffic at certain
times of the day, but not constantly. Therefore, administrators can simply deny access without
needing to analyze many logs generated during peak hours.
Including Comments About Entries in Access Lists

You can include comments (remarks) about entries in any named IP access list using the remark
access-list configuration command. The remarks make the access list easier for the network
administrator to understand and scan. Each remark line is limited to 100 characters.
The remark can go before or after a permit or deny statement. You should be consistent about where
you put the remark so it is clear which remark describes which permit or deny statement. For example,
it would be confusing to have some remarks before the associated permit or deny statements and some
remarks after the associated statements. The standard and extended access list task tables in the previous
sections “Creating Standard and Extended Access Lists Using Numbers” and “Creating Standard and
Extended Access Lists Using Names” include the remark command. See the “Commented IP Access
List Entry: Examples” section at the end of this chapter for examples of commented IP access list entries.
Remember to apply the access list to an interface or terminal line after the access list is created. See the
following section “Applying Access Lists” for more information.
Applying Access Lists

After creating an access list, you must reference the access list to make it work. To use an access list,
perform the tasks described in the following sections. The tasks in the first section are required; the tasks
in the remaining sections are optional:
• Controlling Access to a Line or Interface (Required)
• Controlling Policy Routing and the Filtering of Routing Information (Optional)
• Controlling Dialer Functions (Optional)

28 78-17478-01
Controlling Access to a Line or Interface

After you create an access list, you can apply it to one or more interfaces. Access lists can be applied on
either outbound or inbound interfaces. This section describes guidelines on how to accomplish this task
for both terminal lines and network interfaces. Remember the following:
• When controlling access to a line, you must use a number.
• When controlling access to an interface, you can use a name or number.
To restrict access to a vty and the addresses in an access list, use the following command in line
configuration mode. Only numbered access lists can be applied to lines. Set identical restrictions on all
the virtual terminal lines, because a user can attempt to connect to any of them.
Command Purpose
Router(config-line)# access-class access-list-number {in Restricts incoming and outgoing connections between a
| out} particular vty (into a device) and the addresses in an
access list.
To restrict access to an interface, use the following command in interface configuration mode:
Command Purpose
Router(config-if)# ip access-group {access-list-number | Controls access to an interface.
access-list-name} {in | out}
For inbound access lists, after receiving a packet, the Cisco IOS software checks the source address of
the packet against the access list. If the access list permits the address, the software continues to process
the packet. If the access list rejects the address, the software discards the packet and returns an ICMP
host unreachable message.
For outbound access lists, after receiving and routing a packet to a controlled interface, the software
checks the source address of the packet against the access list. If the access list permits the address, the
software sends the packet. If the access list rejects the address, the software discards the packet and
returns an ICMP host unreachable message.
When you apply an access list that has not yet been defined to an interface, the software will act as if the
access list has not been applied to the interface and will accept all packets. Remember this behavior if
you use undefined access lists as a means of security in your network.
Controlling Policy Routing and the Filtering of Routing Information

To use access lists to control policy routing and the filtering of routing information, see the “Configuring
IP Routing Protocol-Independent Features” chapter of this document.
Controlling Dialer Functions

To use access lists to control dialer functions, refer to the “Preparing to Configure DDR” chapter in the
Cisco IOS Dial Technologies Configuration Guide.
generic error(7), offset: 0, data: 00 01 08 00 00 00 00 00 00 FF 00 44 5F F6 00 34

78-17478-01 29
Configuration Examples for Access Lists
Clearing the Access List Counters

The system counts how many packets pass each line of an access list; the counters are displayed by the
show access-lists EXEC command. To clear the counters of an access list, use the following command
in EXEC mode:
Command Purpose
Router# clear access-list counters {access-list-number | Clears the access list counters.
access-list-name}

This section provides the following configuration examples:
• Numbered Access List: Example, page 30
• Turbo Access Control List: Example, page 31
• Implicit Masks in Access Lists: Example, page 31
• Extended Access List: Example, page 32
• Named Access List: Example, page 32
• IP Extended Access List with Fragment Control: Example, page 33
• Time Range Applied to an IP Access List: Example, page 33
• Commented IP Access List Entry: Examples, page 33
Numbered Access List: Example

In the following example, network 36.0.0.0 is a Class A network whose second octet specifies a subnet;
that is, its subnet mask is 255.255.0.0. The third and fourth octets of a network 36.0.0.0 address specify
a particular host. Using access list 2, the Cisco IOS software would accept one address on subnet 48 and
reject all others on that subnet. The last line of the list shows that the software would accept addresses
on all other network 36.0.0.0 subnets.
access-list 2 deny 36.48.0.0 0.0.255.255
access-list 2 permit 36.0.0.0 0.255.255.255
ip access-group 2 in
The following example defines access lists 1 and 2, both of which have logging enabled:
ip address 1.1.1.1 255.0.0.0
ip access-group 2 out
!
access-list 1 permit 5.6.0.0 0.0.255.255 log
access-list 1 deny 7.9.0.0 0.0.255.255 log
!
access-list 2 permit 1.2.3.4 log
access-list 2 deny 1.2.0.0 0.0.255.255 log

30 78-17478-01
If the interface receives 10 packets from 5.6.7.7 and 14 packets from 1.2.23.21, the first log will look
like the following:
list 1 permit 5.6.7.7 1 packet
list 2 deny 1.2.23.21 1 packet
Five minutes later, the console will receive the following log:
list 1 permit 5.6.7.7 9 packets
list 2 deny 1.2.23.21 13 packets
Turbo Access Control List: Example

The following is a Turbo ACL configuration example. The access-list compiled global configuration
command output indicates that Turbo ACL is enabled.
no ip address
no ip directed-broadcast
shutdown
!
no ip classless
ip route 192.168.0.0 255.255.255.0 10.1.1.1
!
access-list compiled
access-list 1 deny any
access-list 2 deny 192.168.0.0 0.0.0.255
access-list 2 permit any
Implicit Masks in Access Lists: Example

IP access lists contain implicit masks. For instance, if you omit the mask from an associated IP host
address access list specification, 0.0.0.0 is assumed to be the mask. Consider the following example
configuration:
access-list 1 deny 0.0.0.0 255.255.255.255
For this example, the following masks are implied in the first two lines:
The last line in the configuration (using the deny keyword) can be left off, because IP access lists
implicitly deny all other access. Leaving off the last line in the configuration is equivalent to finishing
the access list with the following command statement:
access-list 1 deny 0.0.0.0 255.255.255.255
The following access list only allows access for those hosts on the three specified networks. It assumes
that subnetting is not used; the masks apply to the host portions of the network addresses. Any hosts with
a source address that does not match the access list statements will be rejected.
! (Note: all other access implicitly denied)

78-17478-01 31
To specify a large number of individual addresses more easily, you can omit the address mask that is all
0s from the access-list global configuration command. Thus, the following two configuration commands
are identical in effect:
Extended Access List: Example

In the following example, the first line permits any incoming TCP connections with destination ports
greater than 1023. The second line permits incoming TCP connections to the Simple Mail Transfer
Protocol (SMTP) port of host 128.88.1.2. The last line permits incoming ICMP messages for error
feedback.
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 1023
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25
access-list 102 permit icmp 0.0.0.0 255.255.255.255 128.88.0.0 255.255.255.255
For another example of using an extended access list, suppose you have a network connected to the
Internet, and you want any host on an Ethernet to be able to form TCP connections to any host on the
Internet. However, you do not want IP hosts to be able to form TCP connections to hosts on the Ethernet
except to the mail (SMTP) port of a dedicated mail host.
SMTP uses TCP port 25 on one end of the connection and a random port number on the other end. The
same two port numbers are used throughout the life of the connection. Mail packets coming in from the
Internet will have a destination port of 25. Outbound packets will have the port numbers reversed. The
fact that the secure system behind the router always will be accepting mail connections on port 25 is what
makes possible separate control of incoming and outgoing services. The access list can be configured on
either the outbound or inbound interface.
In the following example, the Ethernet network is a Class B network with the address 128.88.0.0, and
the address of the mail host is 128.88.1.2. The established keyword is used only for the TCP protocol
to indicate an established connection. A match occurs if the TCP datagram has the ACK or RST bits set,
which indicate that the packet belongs to an existing connection.
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 established
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25
Named Access List: Example

The following configuration creates a standard access list named Internet_filter and an extended access
list named marketing_group:
ip address 2.0.5.1 255.255.255.0
ip access-group Internet_filter out
ip access-group marketing_group in
...
ip access-list standard Internet_filter
permit 1.2.3.4
deny any
ip access-list extended marketing_group
permit tcp any 171.69.0.0 0.0.255.255 eq telnet
deny tcp any any

32 78-17478-01
permit icmp any any

deny udp any 171.69.0.0 0.0.255.255 lt 1024
deny ip any any log
IP Extended Access List with Fragment Control: Example

The first statement will match and deny only noninitial fragments destined for host 1.1.1.1. The second
statement will match and permit only the remaining nonfragmented and initial fragments that are
destined for host 1.1.1.1 TCP port 80. The third statement will deny all other traffic. In order to block
noninitial fragments for any TCP port, we must block noninitial fragments for all TCP ports, including
port 80 for host 1.1.1.1.
access-list 101 deny ip any host 1.1.1.1 fragments
access-list 101 permit tcp any host 1.1.1.1 eq 80
access-list 101 deny ip any any
Time Range Applied to an IP Access List: Example

The following example denies HTTP traffic on Monday through Friday from 8:00 a.m. to 6:00 p.m. on
IP. The example allows UDP traffic on Saturday and Sunday from noon to 8:00 p.m. only.
time-range no-http
periodic weekdays 8:00 to 18:00
!
time-range udp-yes
periodic weekend 12:00 to 20:00
!
ip access-list extended strict
deny tcp any any eq http time-range no-http
permit udp any any time-range udp-yes
!
ip access-group strict in
Commented IP Access List Entry: Examples

In the following example of a numbered access list, the workstation belonging to Jones is allowed access
and the workstation belonging to Smith is not allowed access:
access-list 1 remark Permit only Jones workstation through
access-list 1 remark Do not allow Smith workstation through
access-list 1 deny 171.69.3.13
In the following example of a numbered access list, the Winter and Smith workstations are not allowed
to browse the web:
access-list 100 remark Do not allow Winter to browse the web
access-list 100 deny host 171.69.3.85 any eq http
access-list 100 remark Do not allow Smith to browse the web
access-list 100 deny host 171.69.3.13 any eq http
In the following example of a named access list, the Jones subnet is not allowed access:
ip access-list standard prevention
remark Do not allow Jones subnet through
deny 171.69.0.0 0.0.255.255

78-17478-01 33
In the following example of a named access list, the Jones subnet is not allowed to use outbound Telnet:
ip access-list extended telnetting
remark Do not allow Jones subnet to telnet out
deny tcp 171.69.0.0 0.0.255.255 any eq telnet

34 78-17478-01
Distributed Time-Based Access Lists
This document describes the Distributed Time-Based Access Lists feature in Cisco IOS
Release 12.2(2)T. It includes the following sections:
• Feature Overview
• Supported Platforms
• Supported Standards, MIBs, and RFCs
• Configuration Tasks
• Monitoring and Maintaining Distributed Time-Based Access Lists
• Configuration Examples
• Command Reference
• Glossary
Feature Overview
Cisco IOS allows implementation of access lists based on the time of day. To do so, you create a time
range that defines specific times of the day and week. The time range is identified by a name and then
referenced by a function, so that those time restrictions are imposed on the function itself.
Currently, IP and IPX named or numbered extended access lists are the only functions that can use time
ranges. The time range allows the network administrator to define when the permit or deny statements
in the access list are in effect.
Before the introduction of the Distributed Time-Based Access Lists feature, time-based access lists were
not supported on line cards for the Cisco 7500 series routers. If time-based access lists were configured,
they behaved as normal access lists. If an interface on a line card was configured with time-based access
lists, the packets switched into the interface were not distributed switched through the line card but
forwarded to the Route Processor for processing.
The Distributed Time-Based Access Lists feature allows packets destined for an interface configured
with time-based access lists to be distributed switched through the line card.
For this functionality to work, the software clock must remain synchronized between the Route
Processor and the line card. This synchronization occurs through an exchange of ipc (interprocess
communications) messages from the Route Processor to the line card. When a time range or a time-range
entry is changed, added, or deleted, an ipc message is sent by the Route Processor to the line card.

78-17478-01 35
Supported Platforms
Benefits
The Distributed Time-Based Access Lists feature gives network administrators more control over
permitting or denying a user access to resources. Customers can now take advantage of the performance
benefits of distributed switching and the flexibility given by time-based access lists.
Related Documents
• Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2
• Cisco IOS Configuration Fundamentals Command Reference, Release 12.2
• Cisco IOS IP Configuration Guide, Release 12.2
• Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services, Release 12.2
Supported Platforms
This feature is supported on VIP-enabled Cisco 7500 series routers.
Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated
information regarding platform support for this feature, access Feature Navigator. Feature Navigator
dynamically updates the list of supported platforms as new platform support is added for the feature.
Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software
images support a specific set of features and which features are supported in a specific Cisco IOS image.
To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your
account information, e-mail the Contact Database Administration group at cdbadmin@cisco.com. If you
want to establish an account on Cisco.com, go to http://www.cisco.com/register and follow the directions
to establish an account.
Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As
of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator
at the following URL:
http://www.cisco.com/go/fn
Supported Standards, MIBs, and RFCs

Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules,
go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

36 78-17478-01
Configuration Tasks
RFCs
No new or modified RFCs are supported by this feature.
Configuration Tasks
See the following sections for configuration tasks for the Distributed Time-Based Access Lists feature.
Each task in the list is identified as either optional or required.
• Defining a Time Range (required)
• Referencing the Time Range (required)
• Verifying Distributed Time-Based Access Lists (optional)
Defining a Time Range
Note The time range relies on the software clock of the routing device. For the time range feature
to work the way you intend, you need a reliable clock source. We recommend that you use
Network Time Protocol (NTP) to synchronize the software clock of the routing device.
To define a time range, use the following commands beginning in global configuration mode.
Command Purpose
Step 1 Router(config)# time-range time-range-name Assigns a name to the time-range to be configured
and enters time range configuration mode.
Step 2 Router(config-time-range)# absolute [start time Specifies when the time range will be in effect. Use
date] [end time date] some combination of these commands. Multiple
periodic statements are allowed; only one absolute
or
statement is allowed.
Router(config-time-range)# periodic days-of-the-week
hh:mm to [days-of-the-week] hh:mm
Repeat these tasks if you have multiple items you want in effect at different times. For example, repeat
the steps to include multiple permit or deny statements in an access list in effect at different times. For
further details on the commands described, see the corresponding chapter in the Cisco IOS
Configuration Fundamentals Command Reference, Release 12.2.
Referencing the Time Range

In order for a time range to be applied, you must reference it by name in a feature that can implement
time ranges. To reference the time range, perform one of the following tasks:
• Create an IP extended access list: refer to the “Configuring IP Services” chapter in the Cisco IOS
IP Configuration Guide, Release 12.2 for instructions and further details.
• Create an IPX Extended Access List: refer to the “Configuring Novell IPX” chapter of the Cisco IOS
Apple Talk and Novell IPX Configuration Guide, Release 12.2 for instructions and further details.

78-17478-01 37
Monitoring and Maintaining Distributed Time-Based Access Lists
Verifying Distributed Time-Based Access Lists

For the distributed time-based access list functionality to work, the software clock must remain
synchronized between the Route Processor and the line card.
To verify that the time clocks remain synchronized and that ipc messages about time range statistics are
being sent by the Route Processor to the line card, use the following command in EXEC mode:
Command Purpose
Router# show time-range ipc Displays the statistics about the time-range ipc messages between the
Route Processor and line card.
Monitoring and Maintaining Distributed Time-Based Access

Lists
To display information about the time-range ipc messages, use the following commands in EXEC mode,
as needed:
Command Purpose
Router# debug time-range ipc Enables debugging output for monitoring the time-range ipc messages
between the Route Processor and the line card.
Router# show time-range ipc Displays the statistics about the time-range ipc messages between the
Route Processor and line card.
Router# clear time-range ipc Clears the time-range ipc message statistics and counters between the
Route Processor and the line card for the time-range subsystem.
Configuration Examples
The Distributed Time-Based Access Lists feature is enabled automatically when time ranges are
configured on access lists. For an example of a time range applied to an access list, refer to the
“Configuring IP Services” chapter of the Cisco IOS IP Configuration Guide, Release 12.2.

38 78-17478-01
Command Reference
Command Reference
The following new commands are pertinent to this feature. To see the command pages for these
commands and other commands used with this feature, go to the Cisco IOS Master Commands List,
Release 12.4, at http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124mindx/
124index.htm.
• clear time-range ipc
• debug time-range ipc
• show time-range ipc

78-17478-01 39
Glossary
Glossary
IPC—interprocess communications. A system that lets threads and processes transfer data and messages
among themselves; used to offer services to and receive services from other programs.
line card—Any I/O card that can be inserted in a modular chassis.
RP—Route Processor. Processor module in the Cisco 7000 series routers that contains the CPU, system
software, and most of the memory components that are used in the router. Sometimes called a
supervisory processor.
VIP—Versatile Interface Processor. Interface card used in Cisco 7000 and Cisco 7500 series routers. The
VIP provides multilayer switching and runs Cisco IOS software.

40 78-17478-01
IP Access List Entry Sequence Numbering
Users can apply sequence numbers to permit or deny statements and also reorder, add, or remove such
statements from a named IP access list. This feature makes revising IP access lists much easier. Prior to
this feature, users could add access list entries to the end of an access list only; therefore needing to add
statements anywhere except the end required reconfiguring the access list entirely.
Feature History for the IP Access List Entry Additions Feature

Release Modification
12.2(14)S This feature was introduced.
12.2(15)T This feature was integrated into Cisco IOS Release 12.2(15)T.
12.3(2T This feature was integrated into Cisco IOS Release 12.3(2)T.
Contents
• Restrictions for IP Access List Entry Sequence Numbering, page 41
• Information About IP Access Lists, page 42
• How to Use Sequence Numbers in an IP Access List, page 45
• Configuration Examples for IP Access List Entry Sequence Numbering, page 48
• Additional References, page 50
• Command Reference, page 51
Restrictions for IP Access List Entry Sequence Numbering

• This feature does not support dynamic, reflexive, or firewall access lists.

78-17478-01 41
Information About IP Access Lists
• This feature does not support old-style numbered access lists, which existed before named access
lists. Keep in mind that you can name an access list with a number, so numbers are allowed when
they are entered in the standard or extended named access list (NACL) configuration mode.

Before you resequence or add entries to an IP access list, you should understand the following concepts:
• Purpose of IP Access Lists, page 42
• How an IP Access List Works, page 42
• IP Access List Entry Sequence Numbering, page 44
Purpose of IP Access Lists

Access lists perform packet filtering to control which packets move through the network and where.
Such control can help limit network traffic and restrict the access of users and devices to the network.
Access lists have many uses, and therefore many commands accept a reference to an access list in their
command syntax. Access lists can be used to do the following:
• Filter incoming packets on an interface.
• Filter outgoing packets on an interface.
• Restrict the contents of routing updates.
• Limit debug output based on an address or protocol.
• Control virtual terminal line access.
• Identify or classify traffic for advanced features, such as congestion avoidance, congestion
management, and priority and custom queuing.
• Trigger dial-on-demand routing (DDR) calls.
How an IP Access List Works

An access list is a sequential list consisting of at least one permit statement and possibly one or more
deny statements that apply to IP addresses and possibly upper-layer IP protocols. The access list has a
name by which it is referenced. Many software commands accept an access list as part of their syntax.
An access list can be configured and named, but it is not in effect until the access list is referenced by a
command that accepts an access list. Multiple commands can reference the same access list. An access
list can control traffic arriving at the router or leaving the router, but not traffic originating at the router.
IP Access List Process and Rules

• The software tests the source or destination address or the protocol of each packet being filtered
against the conditions in the access list, one condition (permit or deny statement) at a time.
• If a packet does not match an access list statement, the packet is then tested against the next
statement in the list.

42 78-17478-01
• If a packet and an access list statement match, the rest of the statements in the list are skipped and
the packet is permitted or denied as specified in the matched statement. The first entry that the packet
matches determines whether the software permits or denies the packet. That is, after the first match,
no subsequent entries are considered.
• If the access list denies the address or protocol, the software discards the packet and returns an ICMP
Host Unreachable message.
• If no conditions match, the software drops the packet. This is because each access list ends with an
unwritten or implicit deny statement. That is, if the packet has not been permitted by the time it was
tested against each statement, it is denied.
• The access list must contain at least one permit statement or else all packets are denied.
• Because the software stops testing conditions after the first match, the order of the conditions is
critical. The same permit or deny statements specified in a different order could result in a packet
being passed under one circumstance and denied in another circumstance.
• If an access list is referenced by name in a command, but the access list does not exist, all packets
pass.
• Only one access list per interface, per protocol, per direction is allowed.
• Inbound access lists process packets arriving at the router. Incoming packets are processed before
being routed to an outbound interface. An inbound access list is efficient because it saves the
overhead of routing lookups if the packet is to be discarded because it is denied by the filtering tests.
If the packet is permitted by the tests, it is then processed for routing. For inbound lists, permit
means continue to process the packet after receiving it on an inbound interface; deny means discard
the packet.
• Outbound access lists process packets before they leave the router. Incoming packets are routed to
the outbound interface and then processed through the outbound access list. For outbound lists,
permit means send it to the output buffer; deny means discard the packet.
Helpful Hints for Creating IP Access Lists

• Create the access list before applying it to an interface. An interface with an empty access list
applied to it permits all traffic.
• Another reason to configure an access list before applying it is because if you applied a nonexistent
access list to an interface and then proceed to configure the access list, the first statement is put into
effect, and the implicit deny statement that follows could cause you immediate access problems.
• Because the software stops testing conditions after it encounters the first match (to either a permit
or deny statement), you will reduce processing time and resources if you put the statements that
packets are most likely to match at the beginning of the access list. Place more frequently occurring
conditions before less frequent conditions.
• Organize your access list so that more specific references in a network or subnet appear before more
general ones.
• In order to make the purpose of individual statements more easily understood at a glance, you can
write a helpful remark before or after any statement.
Source and Destination Addresses

Source address and destination addresses are two of the most typical fields in an IP packet on which to
base an access list. Specify source addresses to control packets from certain networking devices or hosts.
Specify destination addresses to control packets being sent to certain networking devices or hosts.

78-17478-01 43
Wildcard Mask and Implicit Wildcard Mask

Address filtering uses wildcard masking to indicate to the software whether to check or ignore
corresponding IP address bits when comparing the address bits in an access list entry to a packet being
submitted to the access list. By carefully setting wildcard masks, an administrator can select single or
several IP addresses for permit or deny tests.
Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software
treats the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask
because a 1 and 0 mean the opposite of what they mean in a subnet (network) mask.
• A wildcard mask bit 0 means check the corresponding bit value.
• A wildcard mask bit 1 means ignore that corresponding bit value.
If you do not supply a wildcard mask with a source or destination address in an access list statement, the
software assumes a default wildcard mask of 0.0.0.0.
Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard
masks allow noncontiguous bits in the mask.
Transport Layer Information

You can filter packets based on transport layer information, such as whether the packet is a TCP, UDP,
ICMP or IGMP packet.
Benefits
The ability to apply sequence numbers to IP access list entries simplifies access list changes. Prior to the
IP Access List Entry Sequence Numbering feature, there was no way to specify the position of an entry
within an access list. If a user wanted to insert an entry (statement) in the middle of an existing list, all
of the entries after the desired position had to be removed, then the new entry was added, and then all
the removed entries had to be reentered. This method was cumbersome and error prone.
This feature allows users to add sequence numbers to access list entries and resequence them. When a
user adds a new entry, the user chooses the sequence number so that it is in a desired position in the
access list. If necessary, entries currently in the access list can be resequenced to create room to insert
the new entry.
Sequence Numbering Behavior

• For backward compatibility with previous releases, if entries with no sequence numbers are applied,
the first entry is assigned a sequence number of 10, and successive entries are incremented by 10.
The maximum sequence number is 2147483647. If the generated sequence number exceeds this
maximum number, the following message is displayed:
Exceeded maximum sequence number.
• If the user enters an entry without a sequence number, it is assigned a sequence number that is 10
greater than the last sequence number in that access list and is placed at the end of the list.
• If the user enters an entry that matches an already existing entry (except for the sequence number),
then no changes are made.

44 78-17478-01
How to Use Sequence Numbers in an IP Access List
• If the user enters a sequence number that is already present, the following error message is
generated:
Duplicate sequence number.
• If a new access list is entered from global configuration mode, then sequence numbers for that access
list are generated automatically.
• Distributed support is provided so that the sequence numbers of entries in the Route Processor (RP)
and line card (LC) are in synchronization at all times.
• Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the
event that the system is reloaded, the configured sequence numbers revert to the default sequence
starting number and increment. The function is provided for backward compatibility with software
releases that do not support sequence numbering.
• This feature works with named standard and extended IP access lists. Because the name of an access
list can be designated as a number, numbers are acceptable.

This section describes how to use sequence numbers in an IP access list.
• Sequencing Access-List Entries and Revising the Access List, page 45
Sequencing Access-List Entries and Revising the Access List

This task shows how to assign sequence numbers to entries in a named IP access list and how to add or
delete an entry to or from an access list. It is assumed a user wants to revise an access list. The context
of this task is the following:
• A user need not resequence access lists for no reason; resequencing in general is optional. The
resequencing step in this task is shown as required because that is one purpose of this feature and
this task demonstrates the feature.
• Step 5 happens to be a permit statement and Step 6 happens to be a deny statement, but they need
not be in that order.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip access-list resequence access-list-name starting-sequence-number increment
4. ip access-list {standard | extended} access-list-name
5. sequence-number permit source source-wildcard
or
sequence-number permit protocol source source-wildcard destination destination-wildcard

[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
6. sequence-number deny source source-wildcard

78-17478-01 45
or
sequence-number deny protocol source source-wildcard destination destination-wildcard

7. Repeat Step 5 and/or Step 6 as necessary, adding statements by sequence number where you
planned. Use the no sequence-number command to delete an entry.
8. end
9. show ip access-lists access-list-name
DETAILED STEPS
Command or Action Purpose

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 access-list resequence access-list-name Resequences the specified IP access list using the starting
starting-sequence-number increment sequence number and the increment of sequence numbers.
• This example resequences an access list named kmd1.
Example: The starting sequence number is 100 and the increment
Router(config)# ip access-list resequence kmd1 is 15.
100 15
Step 4 ip access-list {standard | extended} Specifies the IP access list by name and enters named access
access-list-name list configuration mode.
• If you specify standard, make sure you subsequently
Example: specify permit and/or deny statements using the
Router(config)# ip access-list standard kmd1 standard access list syntax.
• If you specify extended, make sure you subsequently
specify permit and/or deny statements using the
extended access list syntax.

46 78-17478-01

Step 5 sequence-number permit source source-wildcard Specifies a permit statement in named IP access list mode.
or • This access list happens to use a permit statement first,

but a deny statement could appear first, depending on
sequence-number permit protocol source
source-wildcard destination
the order of statements you need.
destination-wildcard [precedence precedence] • See the permit (IP) command for additional command
[tos tos] [log] [time-range time-range-name]
syntax to permit upper layer protocols (ICMP, IGMP,
[fragments]
TCP, and UDP).
• Use the no sequence-number command to delete an
Example: entry.
Router(config-std-nacl)# 105 permit 10.5.5.5
0.0.0 255 • As the prompt indicates, this access list was a standard
access list. If you had specified extended in Step 4, the
prompt for this step would be
Router(config-ext-nacl) and you would use the
extended permit command syntax.
Step 6 sequence-number deny source source-wildcard (Optional) Specifies a deny statement in named IP access
list mode.
or
• This access list happens to use a permit statement first,
sequence-number deny protocol source
but a deny statement could appear first, depending on
destination-wildcard [precedence precedence] the order of statements you need.
[tos tos] [log] [time-range time-range-name]
• See the deny (IP) command for additional command
[fragments]
syntax to permit upper layer protocols (ICMP, IGMP,
TCP, and UDP).
Example: • Use the no sequence-number command to delete an
Router(config-std-nacl)# 105 deny 10.6.6.7
0.0.0 255
entry.
• As the prompt indicates, this access list was a standard
access list. If you had specified extended in Step 4, the
prompt for this step would be
Router(config-ext-nacl) and you would use the
extended deny command syntax.
Step 7 Repeat Step 5 and/or Step 6 as necessary, adding Allows you to revise the access list.
statements by sequence number where you planned.
Use the no sequence-number command to delete an
entry.

78-17478-01 47
Configuration Examples for IP Access List Entry Sequence Numbering

Step 8 end (Optional) Exits the configuration mode and returns to
privileged EXEC mode.
Example:
Router(config-std-nacl)# end
Step 9 show ip access-lists access-list-name (Optional) Displays the contents of the IP access list.
• Review the output to see that the access list includes the
Example: new entry.
Router# show ip access-lists kmd1
Standard IP access list kmd1

100 permit 10.4.4.0, wildcard bits 0.0.0.255
What to Do Next
If your access list is not already applied to an interface or line or otherwise referenced, apply the access
list. Refer to the “Configuring IP Services” chapter of the Cisco IOS IP Configuration Guide for
information about how to apply an IP access list.
Configuration Examples for IP Access List Entry Sequence

Numbering
This section provides the following examples related to sequence numbering of entries in an IP access
list:
• Resequencing Entries in an Access List: Example, page 48
• Adding Entries with Sequence Numbers: Example, page 49
• Entry without Sequence Number: Example, page 49
Resequencing Entries in an Access List: Example

The following example shows access list resequencing. The starting value is 1, and increment value is 2.
The subsequent entries are ordered based on the increment values that users provide, and the range is
from 1 to 2147483647.
When an entry with no sequence number is entered, by default it has a sequence number of 10 more than
the last entry in the access list.
Router# show access-list 150
Extended IP access list 150

10 permit ip host 10.3.3.3 host 172.16.5.34
20 permit icmp any any
30 permit tcp any host 10.3.3.3
40 permit ip host 10.4.4.4 any
50 Dynamic test permit ip any any

48 78-17478-01
Configuration Examples for IP Access List Entry Sequence Numbering

70 permit ip host 10.3.3.3 any log
80 permit tcp host 10.3.3.3 host 10.1.2.2
100 permit ip any any
Router(config)# ip access-list extended 150

Router(config)# ip access-list resequence 150 1 2
Router(config)# end
Router# show access-list 150
Extended IP access list 150

3 permit icmp any any
5 permit tcp any host 10.3.3.3
9 Dynamic test permit ip any any
13 permit ip host 10.3.3.3 any log
15 permit tcp host 10.3.3.3 host 10.1.2.2
19 permit ip any any
Adding Entries with Sequence Numbers: Example

In the following example, an new entry is added to a specified access list:
Router# show ip access-list
Standard IP access list tryon

Router(config)# ip access-list standard tryon
Router(config-std-nacl)# 15 permit 10.5.5.5 0.0.0.255
Router# show ip access-list
Standard IP access list tryon

Entry without Sequence Number: Example

The following example shows how an entry with no specified sequence number is added to the end of an
access list. When an entry is added without a sequence number, it is automatically given a sequence
number that puts it at the end of the access list. Because the default increment is 10, the entry will have
a sequence number 10 higher than the last entry in the existing access list.
Router(config)# ip access-list standard 1
Router(config-std-nacl)# permit 1.1.1.1 0.0.0.255

78-17478-01 49
Additional References

Router# show access-list

Standard IP access list 1
Router(config)# ip access-list standard 1

Router# show access-list
Standard IP access list 1

The following sections provide references related to IP access lists.
Related Documents
Related Topic Document Title
Configuring IP access lists “Configuring IP Services” chapter in the Cisco IOS IP
IP access list commands “IP Services Commands” chapter in the Cisco IOS IP Command
Reference, Volume 1 of 3: Addressing and Services, Release 12.2
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 To locate and download MIBs for selected platforms, Cisco IOS
feature, and support for existing MIBs has not been releases, and feature sets, use Cisco MIB Locator found at the
modified by this feature. following URL:

50 78-17478-01
Command Reference
RFCs
RFCs Title
No new or modified RFCs are supported by this —
feature, and support for existing RFCs has not been
Technical Assistance
Description Link
Technical Assistance Center (TAC) home page, http://www.cisco.com/public/support/tac/home.shtml
containing 30,000 pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, tools, and lots more.
Registered Cisco.com users can log in from this page to
access even more content.
Command Reference
The following new and modified commands are pertinent to this feature. To see the command pages for
these commands and other commands used with this feature, go to the Cisco IOS Master Commands List,
124index.htm.
New Command
• ip access-list resequence
Revised Commands
• deny (IP)
• permit (IP)

78-17478-01 51
Command Reference

52 78-17478-01
ACL IP Options Selective Drop
The ACL IP Options Selective Drop feature allows Cisco routers to filter packets containing IP options
or to mitigate the effects of IP options on a router or downstream routers by dropping these packets or
ignoring the processing of the IP options.
Feature History for the ACL IP Options Selective Drop Feature

12.0(22)S This feature was introduced.
12.3(4)T This feature was integrated into Cisco IOS Release 12.3(4)T.
12.2(25)S This feature was integrated into Cisco IOS Release 12.2(25)S.
Contents
• Restrictions for ACL IP Options Selective Drop, page 53
• Information About ACL IP Options Selective Drop, page 54
• How to Configure ACL IP Options Selective Drop, page 54
• Configuration Examples for the ACL IP Options Selective Drop Feature, page 55
Restrictions for ACL IP Options Selective Drop

Resource Reservation Protocol (RSVP) (Multiprotocol Label Switching terminal equipment
[MPLS TE]), Internet Group Management Protocol Version 2 (IGMPv2), and other protocols that use IP
options packets may not function in drop or ignore modes.

78-17478-01 53
Information About ACL IP Options Selective Drop
Information About ACL IP Options Selective Drop

Before you configure the ACL IP Options Selective Drop feature, you should understand the concepts
in the following sections:
• How the ACL IP Options Selective Drop Feature Works, page 54
• Benefits of Using the ACL IP Options Selective Drop Feature, page 54
How the ACL IP Options Selective Drop Feature Works

The ACL IP Options Selective Drop feature allows users to filter IP options packets, thereby mitigating
the effects of these packets on a router and downstream routers. This feature allows the users to drop (the
router drops all IP options packets that it receives and prevents options from going deeper into the
network) or ignore (the router treats the packets as if they had no IP options) all IP options packets
destined for the router. For many users, dropping the packets is the best solution. However, in
environments in which some IP options may be legitimate, reducing the load that the packets present on
the routers is sufficient. Therefore, users may prefer to skip options processing on the router and forward
the packet as though it were pure IP.
Benefits of Using the ACL IP Options Selective Drop Feature

• Drop mode filters packets from the network and relieves downstream routers and hosts of the load
from options packets.
• Drop mode minimizes loads to the Route Processor (RP) for options that require RP processing on
distributed systems. Previously, the packets were always routed to or processed by the RP CPU.
Now, the ignore and drop forms keep the packets from impacting the RP.
How to Configure ACL IP Options Selective Drop

This section contains the following configuration information:
• Configuring Your Router and Verifying the ACL IP Options Selective Drop Feature, page 54
Configuring Your Router and Verifying the ACL IP Options Selective Drop
Feature
This section describes how to configure your router and verify the ACL IP Options Selective Drop
feature.
SUMMARY STEPS
1. enable
3. ip options {drop | ignore}
4. exit

54 78-17478-01
Configuration Examples for the ACL IP Options Selective Drop Feature
5. show ip traffic
DETAILED STEPS

Step 1 enable Enables privileged EXEC mode.
• Enter your password if prompted.
Example:
Router> enable
Example:
Step 3 ip options {drop | ignore} Drops or ignores IP options packets that are sent to the
router.
Example:
Router(config)# ip options drop
Step 4 exit Returns to privileged EXEC mode.
Example:
Router(config)# exit
Step 5 show ip traffic Displays statistics about IP traffic.
Example:
Router# show ip traffic
What to Do Next
If you are running Cisco IOS Release 12.3(4)T or a later release, you can also use the ACL Support for
Filtering IP Options feature to filter packets based on whether the packet contains specific IP options.
Configuration Examples for the ACL IP Options Selective Drop

Feature
The following section contains a configuration example for the ACL IP Options Selective Drop feature:
• IP Options Configuration: Example, page 55
IP Options Configuration: Example

The following example shows how to configure the router (and downstream routers) to drop all options
packets that enter the network:
Router(config)# ip options drop

78-17478-01 55
% Warning:RSVP and other protocols that use IP Options packets may not function in drop or
ignore modes.
end
The following sample output will be displayed after 15,000 options packets are sent via the ip options
drop command. Notice the “forced drop” counter incrementing.
Router# show ip traffic
IP statistics:
Rcvd: 15000 total, 0 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 15000 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 couldn't fragment
Bcast: 0 received, 0 sent
Mcast: 0 received, 0 sent
Sent: 0 generated, 0 forwarded
Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 0 unicast RPF, 15000 forced drop
The following sections provide references related to the ACL IP Options Selective Drop feature.
Related Documents
Reference, Volume 1 of 3: Addressing and Services, Release 12.3 T
Using access lists for filtering IP options ACL Support for Filtering IP Options feature for Cisco IOS
Release 12.3(4)T

56 78-17478-01
Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
solutions, technical tips, and tools. Registered
Cisco.com users can log in from this page to access
even more content.
Command Reference
The following modified command is pertinent to this feature. To see the command pages for this
command and other commands used with this feature, go to the Cisco IOS Master Commands List,
124index.htm.
• ip options

78-17478-01 57
Command Reference

58 78-17478-01
ACL Support for Filtering IP Options
The ACL Support for Filtering IP Options feature allows you to use access control lists (ACLs) to filter
IP Options packets, in order to prevent routers from becoming saturated with spurious packets containing
IP Options. The ACLs provide granular control, and can be used in a complementary fashion with the
no ip options command-line interface (CLI) command that is documented in the IP Options Selective
Drop feature in Cisco IOS Release 12.3(4)T.
Feature History for ACL Support for the Filtering IP Options Feature
12.3(4)T This feature was introduced.
Contents
• Restrictions for the ACL Support for Filtering IP Options Feature, page 59
• Information About ACL Support for Filtering IP Options, page 60
• How to Configure the ACL Support for Filtering IP Options Feature, page 61
• ACL Support for Filtering IP Options: Example, page 63
• Where to Go Next, page 63
Restrictions for the ACL Support for Filtering IP Options Feature

Resource Reservation Protocol (RSVP) Multiprotocol Label Switching terminal equipment (MPLS TE),
Internet Group Management Protocol Version 2 (IGMPV2), and other protocols that use IP Options
packets may not function in drop or ignore mode if this feature is configured.

78-17478-01 59
Information About ACL Support for Filtering IP Options
On most Cisco routers, a packet with IP Options is not switched in hardware, but requires control plane
software processing (primarily because there is a need to process the options and rewrite the IP header),
so all IP packets with IP Options will be filtered and switched in software. Also, it must be noted that
Turbo ACLs do not support ACLs with entries that filter using the option keyword and such ACLs will
not get Turbo compiled. This option keyword restriction will not affect any other ACLs on the router. In
general, not using Turbo ACLs in such cases is not considered a performance issue because the
Cisco IOS software allows for faster ACL processing starting from Cisco IOS Release 12.3(2)T.
The ACL Support for Filtering IP Options feature can be used only with named, extended ACLs.
Note To effectively eliminate all packets that contain IP Options, we recommend that the global ip options
drop command be used.
Information About ACL Support for Filtering IP Options

Before you configure the ACL Support for Filtering IP Options feature, you should understand the
following concepts:
• IP Options, page 60
• Benefits of Using the ACL Support for Filtering IP Options Feature, page 61
IP Options
The internet protocol uses four key mechanisms in providing its service: Type of Service, Time to Live,
Options, and Header Checksum.
The Options, commonly referred to as IP Options, provide for control functions that are required in some
situations but unnecessary for the most common communications. IP Options include provisions for time
stamps, security, and special routing.
IP Options may or may not appear in datagrams. They must be implemented by all IP modules (host and
gateways). What is optional is their transmission in any particular datagram, not their implementation.
In some environments the security option may be required in all datagrams.
The option field is variable in length. There may be zero or more options. IP Options can have one of
two formats:
• Format 1: A single octet of option-type.
• Format 2: An option-type octet, an option-length octet, and the actual option-data octets.
The option-length octet counts the option-type octet and the option-length octet and the option-data
octets.
The option-type octet is viewed as having three fields: a 1-bit copied flag, a 2-bit option class, and a 5-bit
option number. These fields form an 8-bit value for the option type field. IP Options are commonly
referred to by their 8-bit value.
For a complete list and description of IP Options, refer to the RFC 791 at the following URL:
http://www.faqs.org/rfcs/rfc791.html.

60 78-17478-01
How to Configure the ACL Support for Filtering IP Options Feature
Benefits of Using the ACL Support for Filtering IP Options Feature

• Filtering of packets that contain IP Options from the network and relieving of downstream routers
and hosts of the load from options packets.
• Load minimization to the Route Processor (RP) for packets with IP Options that require RP
processing on distributed systems. Previously, the packets were always routed to or processed by the
RP CPU. Filtering the packets prevents them from impacting the RP.
How to Configure the ACL Support for Filtering IP Options

Feature
This section contains the following procedures:
• Configuring Access Lists to Filter Packets That Contain IP Options, page 61
Configuring Access Lists to Filter Packets That Contain IP Options

The following task configures access lists to filter packets that contain IP Options and verifies that the
access lists have been configured correctly.
SUMMARY STEPS
1. enable
4. [sequence-number] permit protocol source source-wildcard destination destination-wildcard
[option option-value] [precedence precedence] [tos tos] [log] [time-range time-range-name]
[fragments]
5. [sequence-number] deny protocol source source-wildcard destination destination-wildcard [option
option-value] [precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
6. Repeat Step 4 or Step 5 as necessary, adding statements by option value where you planned. Use the
no sequence-number form of this command to delete an entry.
7. end

78-17478-01 61
How to Configure the ACL Support for Filtering IP Options Feature
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Router(config)# ip access-list extended mylist1 Note The ACL Support for Filtering IP Options feature
works only with named, extended ACLs.
Step 4 [sequence-number] deny protocol source Specifies a deny statement in named IP access list mode.
destination-wildcard [option • This access list happens to use a deny statement first,
option-value][precedence precedence] [tos tos] but a permit statement could appear first, depending on
[log] [time-range time-range-name] [fragments] the order of statements you need.
• Use the option keyword option-value argument to filter
Example: packets that contain a particular IP Option. In this
Router(config-ext-nacl)# deny ip any any option instance any packet that contains the traceroute IP
traceroute Option will be filtered out.
• Use the no sequence-number form of this command to
delete an entry.
Step 5 [sequence-number] permit protocol source (Optional) Specifies a permit statement in named IP access
source-wildcard destination list mode.
destination-wildcard [option option-value]
[precedence precedence] [tos tos] [log] • This access list happens to use a permit statement first,
[time-range time-range-name] [fragments] but a deny statement could appear first, depending on
Example: • Use the option keyword option-value argument to filter
Router(config-ext-nacl)# permit ip any any packets that contain a particular IP Option. In this
option security instance any packet that contains the security IP Option
will be permitted.
• Use the no sequence-number form of this command to
delete an entry.
Step 6 Repeat Step 4 or Step 5 as necessary, adding Allows you to revise the access list.
Use the no sequence-number form of this command to
delete an entry.

62 78-17478-01
ACL Support for Filtering IP Options: Example

Example:
• Review the output to verify that the access list includes
Example: the new entry.
Router# show ip access-lists mylist1
ACL Support for Filtering IP Options: Example

This section contains the following configuration example:
• Configuring the Access List to Filter Packets That Contain IP Options: Example, page 63
Configuring the Access List to Filter Packets That Contain IP Options: Example
The following example shows an extended access list named mylist2 that contains access list entries
(ACEs) that are configured to permit TCP packets only if they contain the IP Options that are specified
in the ACEs:
Router> enable
Router(config)# ip access-list extended mylist2
Router(config-ext-nacl)# 10 permit ip any any option eool
Router(config-ext-nacl)# 20 permit ip any any option record-route
Router(config-ext-nacl)# 30 permit ip any any option zsu
Router(config-ext-nacl)# 40 permit ip any any option mtup
The show access-list command has been entered to show how many packets were matched and therefore
permitted:
Router# show ip access-list mylist2
Extended IP access list test

10 permit ip any any option eool (1 match)
20 permit ip any any option record-route (1 match)
30 permit ip any any option zsu (1 match)
40 permit ip any any option mtup (1 match)
Where to Go Next
You may also want to the enter the no ip options command that is documented in the IP Options
Selective Drop feature in Cisco IOS Release 12.3(4)T.
The following sections provide references related to the ACL Support for Filtering IP Options feature.

78-17478-01 63
Related Documents
Configuration Guide
IP access list commands “IP Addressing and Services Commands” chapter in the Cisco IOS
IP Command Reference, Volume 1 of 4: Addressing and Services,
Release 12.3 T
Configuring the router to drop or ignore packets IP Options Selective Drop feature module for Cisco IOS
containing IP Options Release 12.3(4)T
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 791 Internet Protocol
Description Link
even more content.

64 78-17478-01
Command Reference
Command Reference
The following modified commands are pertinent to this feature. To see the command pages for these
124index.htm.
• deny (IP)
• permit (IP)

78-17478-01 65
Command Reference

66 78-17478-01
ACL TCP Flags Filtering
The ACL TCP Flags Filtering feature provides a flexible mechanism for filtering on TCP flags. Before
Cisco IOS Release 12.3(4)T, an incoming packet was matched as long as any TCP flag in the packet
matched a flag specified in the access control entry (ACE). This behavior allows for a security loophole,
because packets with all flags set could get past the access control list (ACL). The ACL TCP Flags
Filtering feature allows you to select any desired combination of flags on which to filter. The ability to
match on a flag set and on a flag not set gives you a greater degree of control for filtering on TCP flags,
thus enhancing security.
Feature History for the ACL TCP Flags Filtering Feature

Contents
• Restrictions for ACL TCP Flags Filtering, page 67
• Information About the ACL TCP Flags Filtering Feature, page 68
• How to Configure ACL TCP Flags Filtering, page 69
• Configuration Examples for the ACL TCP Flags Filtering Feature, page 70
Restrictions for ACL TCP Flags Filtering

The feature can be used only with named, extended ACLs.

78-17478-01 67
Information About the ACL TCP Flags Filtering Feature
Before Cisco IOS Release 12.3(4)T, the following command-line interface (CLI) format could be used
to configure a TCP flag-checking mechanism:
permit tcp any any rst
The following format that represents the same ACE can be used with Cisco IOS Release 12.3(4)T and
later releases:
permit tcp any any match-any +rst
Both the CLI formats are accepted; however, if the new keywords match-all or match-any are chosen,
they must be followed by the new flags that are prefixed with “+” or “-”. It is advisable to use only the
old format or the new format in a single ACL. You cannot mix and match the old and new CLI formats.
Caution If a router having ACEs with the new syntax format is reloaded with an older version of Cisco IOS
software that does not support the ACL TCP Flags Filtering feature, the ACEs will not be applied,
leading to possible security loopholes.
The ACL TCP Flags Filtering Feature is supported only for Cisco IOS ACLs and Turbo ACLs.
Information About the ACL TCP Flags Filtering Feature

In order to configure the ACL TCP Flags Filtering feature, you should understand the following concept:
• Benefits of Using the ACL TCP Flags Filtering Feature, page 68
Benefits of Using the ACL TCP Flags Filtering Feature

Because TCP packets can be sent as false synchronization packets that can be accepted by a listening
port, it is recommended that administrators of firewall devices set up some filtering rules to drop false
TCP packets.
The ACEs that make up an access list can be configured to detect and drop unauthorized TCP packets
by allowing only the packets that have a very specific group of TCP flags set or not set. The ACL TCP
Flags Filtering feature gives users a greater degree of packet-filtering control in the following ways:
• Users can select any desired combination of TCP flags on which to filter TCP packets.
• Users can configure ACEs in order to allow matching on a flag that is set as well as on a flag that is
not set.

68 78-17478-01
How to Configure ACL TCP Flags Filtering
How to Configure ACL TCP Flags Filtering

This section contains the following procedure:
• Configuring the ACE to Filter TCP Packets and Verifying the Configuration, page 69
Configuring the ACE to Filter TCP Packets and Verifying the Configuration
To configure ACEs to filter TCP packets and verify TCP packet filtering, complete the following steps.
SUMMARY STEPS
1. enable
4. [sequence-number] permit tcp source source-wildcard [operator [port]] destination
destination-wildcard [operator [port]] [established | {match-any | match-all} {+ | -} flag-name]
5. [sequence-number] deny tcp source source-wildcard [operator [port]] destination
destination-wildcard [operator [port]] established | {match-any | match-all} {+ | -} flag-name]
6. Repeat Step 4 or Step 5 as necessary, adding statements by sequence number where you planned.
Use the no sequence-number command to delete an entry.
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Router(config)# ip access-list extended kmd1 Note The ACL TCP Flags Filtering feature works only
with named, extended ACLs.

78-17478-01 69
Configuration Examples for the ACL TCP Flags Filtering Feature

Step 4 [sequence-number] permit tcp source Specifies a permit statement in named IP access list mode.
source-wildcard [operator [port]] destination
destination-wildcard [operator [port]] • This access list happens to use a permit statement first,
[established | {match-any | match-all} {+ | -} but a deny statement could appear first, depending on
flag-name] [precedence precedence] [tos tos] the order of statements you need.
[log] [time-range time-range-name] [fragments]
• Any packet with the RST TCP header flag set will be
matched and allowed to pass the named access list
Example: kmd1 in Step 3.
Router(config-ext-nacl)# permit tcp any any
match-any +rst
Step 5 [sequence-number] deny tcp source (Optional) Specifies a deny statement in named IP access
source-wildcard [operator [port]] destination list mode.
destination-wildcard [operator [port]]
[established | {match-any | match-all} {+ | -} • This access list happens to use a permit statement first,
flag-name] [precedence precedence] [tos tos] but a deny statement could appear first, depending on
[log] [time-range time-range-name] [fragments]
• Any packet that does not have the ACK flag set, and
Example: also does not have the FIN flag set, will not be allowed
Router(config-ext-nacl)# deny tcp any any to pass the named access list kmd1 in Step 3.
match-all -ack -fin
• See the deny (IP) command for additional command
syntax to permit upper-layer protocols (ICMP, IGMP,
TCP, and UDP).
entry.
Example:
Router(config-ext-nacl)# end
• Review the output to confirm that the access list
Example: includes the new entry.
Configuration Examples for the ACL TCP Flags Filtering Feature

• Configuring the ACE to Filter TCP Packets Based on TCP Flags: Example, page 71

70 78-17478-01
Configuring the ACE to Filter TCP Packets Based on TCP Flags: Example
The following ACE has been configured to allow TCP packets only if the TCP flags SYN and ACK are
set and the FIN flag is not set:
Router> enable
Router(config)# ip access-list extended aaa
Router(config-ext-nacl)# permit tcp any any match-all +ack +syn
Router(config-ext-nacl)# permit tcp any any match-any -urg +syn -psh
The show access-list command has been entered to show the following matches based on the configured
ACLs:
Router# show access-list aaa
Extended IP access list aaa

1o permit tcp any any match-all +ack +syn
20 permit tcp any any match-any -psh +syn -urg
The following sections provide references related to the ACL TCP Flags Filtering feature.
Related Documents
Configuration Guide, IPC, Part 1: IP Addressing and Services,
Release 12.3
Standards
Standards Title

78-17478-01 71
Command Reference
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
even more content.
Command Reference
124index.htm.
• deny (IP)
• permit (IP)

72 78-17478-01
ACL—Named ACL Support for Noncontiguous
Ports on an Access Control Entry
The ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry feature allows
you to specify noncontiguous ports on the same access control entry (ACE), which greatly reduces the
number of access list entries required in an access control list (ACL) when several ACEs have the same
source address, destination address, and protocol, but differ only in the ports. If you maintain large
numbers of access list entries that fall under this category, we recommend that you configure this feature.
Feature History for the ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry Feature
Contents
• Restrictions for the ACL—Named ACL Support for Noncontiguous Ports on an Access Control
Entry Feature, page 74
• Information About the ACL—Named ACL Support for Noncontiguous Ports on an Access Control
• How to Configure an Access List Entry with Noncontiguous Ports, page 74
• Configuration Examples for the ACL—Support for Noncontiguous Ports on an Access List Entry
Feature, page 78

78-17478-01 73
ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry
Restrictions for the ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry Feature
Restrictions for the ACL—Named ACL Support for

Noncontiguous Ports on an Access Control Entry Feature
The ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry feature can be
used only with named, extended ACLs.
Information About the ACL—Named ACL Support for

Noncontiguous Ports on an Access Control Entry Feature
In order to configure the ACL—Named ACL Support for Noncontiguous Ports on an Access Control
Entry feature, you should understand the following concept:
• Benefits of Using the ACL—Named ACL Support for Noncontiguous Ports on an Access Control
Benefits of Using the ACL—Named ACL Support for Noncontiguous Ports on an

Access Control Entry Feature
This feature greatly reduces the number of ACEs required in an access control list to handle multiple
entries for the same source address, destination address, and protocol. If you maintain large numbers of
ACEs, we recommend that you use this feature to consolidate existing groups of access list entries
wherever it is possible and also when you create new access list entries. When you configure access list
entries with noncontiguous ports, you will have fewer access list entries to maintain.
How to Configure an Access List Entry with Noncontiguous

Ports
• Configuring an Access Control Entry with Noncontiguous Ports, page 74 (optional)
• Consolidating Access List Entries with Noncontiguous Ports into One Access List Entry, page 76
(optional)
Configuring an Access Control Entry with Noncontiguous Ports

This task configures an access control entry with noncontiguous ports.
SUMMARY STEPS
1. enable

74 78-17478-01
How to Configure an Access List Entry with Noncontiguous Ports
4. [sequence-number] permit tcp source source-wildcard [operator port [port]] destination

5. [sequence-number] deny tcp source source-wildcard [operator port [port]] destination
6. Repeat Step 4 or Step 5 as necessary, adding statements by sequence number where you planned.
Use the no sequence-number command to delete an entry.
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Router(config)# ip access-list extended kmd1 Note The ACL—Named ACL Support for
Noncontiguous Ports on an Access Control Entry
feature works only with named, extended ACLs.
Step 4 [sequence-number] permit tcp source Specifies a permit statement in named IP access list
source-wildcard [operator port [port]] configuration mode.
destination destination-wildcard [operator
[port]] [established | {match-any | match-all} • This access list happens to use a permit statement first,
{+ | -} flag-name] [precedence precedence] [tos but a deny statement could appear first, depending on
tos] [log] [time-range time-range-name]
the order of statements needed.
[fragments]
• You can configure up to ten ports after the eq and neq
operators.
Example:
Router(config-ext-nacl)# permit tcp any eq
telnet ftp any eq 450 679

78-17478-01 75

Step 5 [sequence-number] deny tcp source (Optional) Specifies a deny statement in named access list
source-wildcard [operator port [port]] configuration mode.
destination destination-wildcard [operator
[port]] [established | {match-any | match-all} • This access list happens to use a permit statement first,
{+ | -} flag-name] [precedence precedence] [tos but a deny statement could appear first, depending on
tos] [log] [time-range time-range-name]
the order of statements needed.
[fragments]
• You can configure up to ten ports after the eq and neq
operators.
Example:
Router(config-ext-nacl)# deny tcp any neq 45
565 632
entry.
Step 7 end (Optional) Exits named access list configuration mode and
returns to privileged EXEC mode.
Example:
Step 8 show ip access-lists access-list-name (Optional) Displays the contents of the access list.
• Review the output to verify that the access list displays
Example: the new entries that you created.
Consolidating Access List Entries with Noncontiguous Ports into One Access
List Entry
This task consolidates a group of access list entries with noncontiguous ports into one access list entry.
SUMMARY STEPS
1. enable
[option option-name] [precedence precedence] [tos tos] [log] [time-range time-range-name]
[fragments]
[option option-name] [precedence precedence] [tos tos] [log] [time-range time-range-name]
[fragments]
7. Repeat Step 4 or Step 5 as necessary. Use the no sequence-number command to delete an entry.
8. end

76 78-17478-01
DETAILED STEPS

Example:
Router> enable
• Review the output to see if you can consolidate any
Example: access list entries.
Router# show ip access-lists mylist1
Example:
Example:
Router(config)# ip access-list extended mylist1 Note The ACL—Named ACL Support for
Noncontiguous Ports on an Access Control Entry
feature works only with named, extended ACLs.
Step 5 [sequence-number] permit protocol source (Required) Removes the redundant access list entries that
source-wildcard destination can be consolidated.
destination-wildcard [option option-name]
[precedence precedence] [tos tos] [log] • Repeat this step to remove all applicable access list
[time-range time-range-name] [fragments] entries.
• This access list happens to use only a permit statement
Example: first, but a deny statement could also appear, depending
Router(config-ext-nacl)# no 10 on the order of statements needed.
• In this instance, a group of access list entries that are
numbered 10, 20, 30, and 40 are removed because they
will be consolidated into one permit statement. (This
step should be repeated to remove the access list entries
20, 30, and 40.)
Step 6 [sequence-number] permit protocol source (Required) Specifies a permit statement in named access list
source-wildcard destination configuration mode.
destination-wildcard [option option-name]
[precedence precedence] [tos tos] [log] • This access list happens to use a permit statement first,
[time-range time-range-name] [fragments] but a deny statement could also appear first, depending
on the order of statements needed.
Example: • In this instance, a group of access list entries with
Router(config-ext-nacl)# permit tcp any neq 45 noncontiguous ports was consolidated into one permit
565 632 any eq 23 45 34 43 statement. You can configure up to ten ports after the eq
and neq operators.

78-17478-01 77
Configuration Examples for the ACL—Support for Noncontiguous Ports on an Access List Entry Feature

Step 7 Repeat Step 5 and 6 as necessary, adding permit or Allows you to revise the access list.
deny statements to consolidate access list entries
where possible. Use the no sequence-number
command to delete an entry.
Step 8 end (Optional) Exits named access list configuration mode and
returns to privileged EXEC mode.
Example:
Step 9 show ip access-lists access-list-name (Optional) Displays the contents of the access list.
• Review the output to verify that the redundant access
Example: list entries have been replaced with your new
Router# show ip access-lists mylist1 consolidated entries.
Configuration Examples for the ACL—Support for

Noncontiguous Ports on an Access List Entry Feature
This section contains the following configuration examples:
• Creating an Access list Entry with Noncontiguous Ports: Example, page 78
• Consolidating Some Existing Access List Entries into One Access List Entry with Noncontiguous
Ports: Example, page 78
Creating an Access list Entry with Noncontiguous Ports: Example

The following access list entry can be created because up to ten ports can be entered after the eq and neq
operators:
Router> enable
Router(config)# ip access-list extended aaa
Router(config-ext-nacl)# permit tcp any eq telnet ftp any eq 23 45 34
Enter the show access-lists command to display the newly created access list entry.
Router# show access-lists aaa
Extended IP access list aaa

1o permit tcp any eq telnet ftp any eq 23 45 34
Consolidating Some Existing Access List Entries into One Access List Entry
with Noncontiguous Ports: Example
The show access-lists command is used to display a group of access list entries for the access list named
abc:
Router# show access-lists abc

78 78-17478-01
Extended IP access list abc

10 permit tcp any eq telnet any eq 450
20 permit tcp any eq telnet any eq 679
30 permit tcp any eq ftp any eq 450
40 permit tcp any eq ftp any eq 679
Because the entries are all for the same permit statement and simply show different ports, they can be
consolidated into one new access list entry. The following example shows the removal of the redundant
access list entries and the creation of a new access list entry that consolidates the previously displayed
group of access list entries:
Router(config)# ip access-list extended abc
Router(config-ext-nacl)# no 10
Router(config-ext-nacl)# permit tcp any eq telnet ftp any eq 450 679
When the show access-lists command is reentered, the consolidated access list entry is displayed:
Router# show access-lists abc
Extended IP access list abc

10 permit tcp any eq telnet ftp any eq 450 679
The following sections provide references related to the ACL—Named ACL Support for Noncontiguous
Ports on an Access Control Entry feature.
Related Documents
Standards
Standards Title

78-17478-01 79
Command Reference
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
even more content.
Command Reference
124index.htm.
• deny (IP)
• permit (IP)

80 78-17478-01
Part 3: TCP
Configuring TCP Performance Parameters
The Transmission Control Protocol (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. It is considered a reliable protocol because if
an IP packet is dropped or received out of order, TCP will request the correct packet until it receives it.
Contents
• How to Configure TCP Performance Parameters, page 83
How to Configure TCP Performance Parameters

Perform the following tasks to configure TCP performance parameters:
• Setting the TCP Connection Attempt Time, page 84 (optional)
• Enabling TCP Path MTU Discovery, page 84 (optional)
• Enabling TCP Selective Acknowledgment, page 84 (optional)
• Enabling TCP Time Stamp, page 85 (optional)
• Setting the TCP Maximum Read Size, page 85 (optional)
• Setting the TCP Window Size, page 86 (optional)
• Setting the TCP Outgoing Queue Size, page 86 (optional)

78-17478-01 83
Setting the TCP Connection Attempt Time

You can set the amount of time the Cisco IOS software will wait to attempt to establish a TCP
connection. Because the connection attempt time is a host parameter, it does not pertain to traffic going
through the device, just to traffic originated at the device.
To set the TCP connection attempt time, use the following command in global configuration mode:
Command Purpose
Router(config)# ip tcp synwait-time seconds Sets the amount of time the Cisco IOS software will wait to attempt to
establish a TCP connection.The default is 30 seconds.
Enabling TCP Path MTU Discovery

Path MTU Discovery is a method for maximizing the use of available bandwidth in the network between
the endpoints of a TCP connection, and is described in RFC 1191. By default, this feature is disabled.
Existing connections are not affected when this feature is turned on or off.
To enable Path MTU Discovery, use the following command in global configuration mode:
Command Purpose
Router(config)# ip tcp path-mtu-discovery [age-timer Enables Path MTU Discovery.
{minutes | infinite}]
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.
The ip tcp path-mtu-discovery global configuration command is to enable Path MTU Discovery for
connections initiated by the router when it is acting as a host. For a discussion of how the Cisco IOS
software supports Path MTU Discovery when the device is acting as a router, see the section
“Understanding Path MTU Discovery” section in the “Configuring IP Services” chapter.
The age-timer is a time interval for how often TCP should reestimate the path MTU with a larger
maximum segment size (MSS). The default Path MTU Discovery age-timer is 10 minutes; its maximum
is 30 minutes. You can turn off the age timer by setting it to infinite.
Enabling TCP Selective Acknowledgment

The TCP selective acknowledgment feature improves performance in the event that multiple packets are
lost from one TCP window of data.
Prior to this feature, with the 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 have been
received. In other words, the receiver can acknowledge packets received out of order. The sender can
then resend only the missing data segments (instead of everything since the first missing packet).

84 78-17478-01
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.
Refer to RFC 2018 for more detailed information on TCP selective acknowledgment.
The feature 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. To enable TCP selective acknowledgment,
use the following command in global configuration mode:
Command Purpose
Router(config)# ip tcp selective-ack Enables TCP selective acknowledgment.
Enabling TCP Time Stamp

The TCP time-stamp option provides better 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.
Refer to RFC 1323 for more detailed information on TCP time stamp.
To enable TCP time stamp, use the following command in global configuration mode:
Command Purpose
Router(config)# ip tcp timestamp Enables TCP time stamp.
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. To disable TCP selective
acknowledgment once it is enabled, see the previous “Enabling TCP Selective Acknowledgment”
section.
Setting the TCP Maximum Read Size

By default, for Telnet and rlogin, the maximum number of characters that TCP reads from the input
queue at once is a very large number (the largest possible 32-bit positive number). We do not recommend
that you change this value. However, to change that value, use the following command in global
configuration mode:
Command Purpose
Router(config)# ip tcp chunk-size Sets the TCP maximum read size for Telnet or rlogin.
characters

78-17478-01 85
Setting the TCP Window Size

The default TCP window size is 2144 bytes. We recommend you keep the default value unless you know
your router is sending large packets (greater than 536 bytes). To change the default window size, use the
following command in global configuration mode:
Command Purpose
Router(config)# ip tcp window-size Sets the TCP window size.
bytes
Setting the TCP Outgoing Queue Size

The default TCP outgoing queue size per connection is 5 segments if the connection has a TTY
associated with it (like a Telnet connection). If no TTY connection is associated with it, the default queue
size is 20 segments. To change the 5-segment default value, use the following command in global
configuration mode:
Command Purpose
Router(config)# ip tcp queuemax packets Sets the TCP outgoing queue size.

86 78-17478-01
TCP Window Scaling
Feature History
This document describes the TCP Window Scaling feature and includes the following sections:
• Feature Overview, page 87
• Supported Platforms, page 88
• Supported Standards, MIBs, and RFCs, page 89
• Prerequisites, page 89
• Configuration Tasks, page 89
• Configuration Examples, page 90
• Glossary, page 91
Feature Overview
The TCP Window Scaling feature adds support for the Window Scaling option in RFC 1323. A larger
window size is recommended to improve TCP performance in network paths with large bandwidth,
long-delay characteristics that are called Long Fat Networks (LFNs) . This TCP Window Scaling
enhancement provides that support.
The window scaling extension in Cisco IOS software expands the definition of the TCP window to
32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit window field of the TCP header.
The window size can increase to a scale factor of 14. Typical applications use a scale factor of 3 when
deployed in LFNs.
Benefits
The Cisco IOS window scaling feature complies with RFC 1323, TCP Extensions for High Performance.
The maximum window size has been increased to 1,073,741,823 bytes. The larger scalable window size
will allow TCP to perform better over LFNs.

78-17478-01 87
TCP Window Scaling
Supported Platforms
Related Features and Technologies

• TCP/IP
Related Documents
• Cisco IOS IP Configuration Guide, Release 12.2.
Supported Platforms
• Cisco 800
• Cisco 805
• Cisco 820
• Cisco 1400 series
• Cisco 1600R
• Cisco 3620
• Cisco 3640
• Cisco 3660
• Cisco VG200
• Cisco CVA120 series
• Cisco soho70
• Cisco uBR7200 series
• Cisco uBR920
• Cisco uBR925
Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated
information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature
Navigator dynamically updates the list of supported platforms as new platform support is added for the
feature.
Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS
software images support a specific set of features and which features are supported in a specific
Cisco IOS image. You can search by feature or release. Under the release section, you can compare
releases side by side to display both the features unique to each software release and the features in
common.

88 78-17478-01
TCP Window Scaling
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or
lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check
will verify that your e-mail address is registered with Cisco.com. If the check is successful, account
details with a new random password will be e-mailed to you. Qualified users can establish an account
on Cisco.com by following the directions at http://www.cisco.com/register.
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology
releases occur. For the most current information, go to the Cisco Feature Navigator home page at the
following URL:
http://www.cisco.com/go/fn

Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules,
go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
• RFC 1323, TCP Extensions for High Performance, the Window Scaling option
Prerequisites
Both sides of the link must be configured to support window scaling or the default of 65,535 bytes will
apply as the maximum window size.
Configuration Tasks
See the following sections for configuration tasks for the TCP Window Scaling feature. Each task in the
list is identified as either required or optional.
• Setting the TCP Window Size (required)
• Verifying the Window Scaling Configuration (optional)

78-17478-01 89
TCP Window Scaling
Setting the TCP Window Size

To set the TCP window size and enable window scaling, use the following command in global
configuration mode:
Command Purpose
Router(config)# ip tcp window-size bytes Specifies the scaled TCP window size.
The bytes argument can be set to an integer from 0 to
1,073,741,823. To enable window scaling to support LFNs, the
TCP window size must be more than 65,535. The default
window size is 4128 if window scaling is not configured.
Verifying the Window Scaling Configuration

Enter the show running-config EXEC command to determine if TCP window scaling is enabled. In the
following example output—abbreviated to show only the window size configuration—the TCP window
size is set to a number greater than 65,535, indicating that the TCP Window Scaling feature is enabled:
Router# show running-config
ip tcp window-size 750000
Troubleshooting Tips
Use the debug ip tcp Winscale EXEC command to enable diagnostic output concerning various events
relating to the operation of the TCP Window Scaling feature to be displayed on a console. The debug ip
tcp Winscale command is intended only for troubleshooting purposes because the volume of output
generated by the software when it is used can result in severe performance degradation on the router.
The following configuration example shows a TCP window size of 750,000 bytes being configured:
ip tcp window-size 750000
Command Reference
124index.htm.
• ip tcp window-size

90 78-17478-01
TCP Window Scaling
Glossary
Glossary
LFN—Long Fat Networks. Large bandwidth, long-delay networks where the throughput is high and the
transmission distance is long. Networks with satellite connections are one example of an LFN. Satellite
links always have high propagation delays and typically have high bandwidth.
TCP—Transmission Control protocol. Connection-oriented transport layer protocol that provides
reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.

78-17478-01 91
TCP Window Scaling
Glossary

92 78-17478-01
TCP Congestion Avoidance
The TCP Congestion Avoidance feature enables the monitoring of acknowledgement packets to the TCP
sender when multiple packets are lost in a single window of data. Previously the sender would exit
Fast-Recovery mode, wait for three or more duplicate acknowledgement packets before retransmitting
the next unacknowledged packet, or wait for the retransmission timer to slow start. This could lead to
performance issues.
To monitor the acknowledgement packets, the output of the debug ip tcp transactions command has
been enhanced to show the following conditions:
• TCP entering Fast Recovery mode.
• Duplicate acknowledgements being received during Fast Recovery mode.
• Partial acknowledgements being received.
Feature History for TCP Congestion Avoidance

Contents

78-17478-01 93
TCP Congestion Avoidance
The following sections provide references related to the TCP Congestion Avoidance feature.
Related Documents
Debug commands Cisco IOS Debug Command Reference, Release 12.3 T
MIBs
MIBs MIBs Link
None To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
following URL:
Description Link
even more content.
Command Reference
124index.htm.
• debug ip tcp transactions

94 78-17478-01
TCP Explicit Congestion Notification
The TCP Explicit Congestion Notification (ECN) feature provides a method for an intermediate router
to notify the end hosts of impending network congestion. It also provides enhanced support for TCP
sessions associated with applications that are sensitive to delay or packet loss including Telnet, web
browsing, and transfer of audio and video data. The benefit of this feature is the reduction of delay and
packet loss in data transmissions.
Feature History for TCP Explicit Congestion Notification

Contents
• How to Configure TCP Explicit Congestion Notification, page 96
• Configuration Examples for TCP Explicit Congestion Notification, page 99

78-17478-01 95
How to Configure TCP Explicit Congestion Notification

This section contains the following tasks:
• Enabling Explicit Congestion Notification, page 96 (required)
• Verifying the Configuration of Explicit Congestion Notification, page 97 (optional)
Enabling Explicit Congestion Notification

This task shows you how to enable ECN.
Prerequisites
The remote peer must be ECN enabled because the ECN capability is negotiated during a 3-way
handshake with the remote peer.
SUMMARY STEPS
1. enable
3. ip tcp ecn
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip tcp ecn Enables ECN for TCP.
Example:
Router(config)# ip tcp ecn
Step 4 exit Exits global configuration mode.
Example:
Router(config) exit

96 78-17478-01
Verifying the Configuration of Explicit Congestion Notification

This task shows you how to verify and debug the ECN functionality in the network.
SUMMARY STEPS
1. show running-config
2. show tcp tcb address
3. show tcp brief all
4. debug ip tcp ecn
5. show debugging
DETAILED STEPS
Step 1 show running-config

Use this command to verify that ECN is configured, for example:
Current configuration : 1013 bytes

!
version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
no aaa new-model
ip subnet-zero
!
ip tcp ecn ! ECN is configured.
!
ip cef
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
end
Step 2 show tcp tcb address

Use this command to verify that TCP is ECN enabled on a specific connection (local host), for example:
Router# show tcp tcb 123456A
!Local host
!
Connection state is ESTAB, I/O status: 1, unread input bytes: 0

78-17478-01 97
Connection is ECN Enabled

Local host: 10.1.25.31, Local port: 11002
Foreign host: 10.1.25.34, Foreign port: 23
Step 3 show tcp brief all

Use this command to display concise information about one address, for example:
Router# show tcp brief all
!
TCB Local address Foreign Address (state)
609789C Router.cisco.com.23 cider.cisco.com.3733 ESTAB
Step 4 debug ip tcp ecn

Use this command to turn on the debugging, for example:
Router# debug ip tcp ecn
!
TCP ECN debugging is on
!
Router# telnet 10.1.25.31
Trying 10.1.25.31 ...

!
01:43:19: 10.1.25.35:11000 <---> 10.1.25.31:23 out ECN-setup SYN
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 congestion window changes
01:43:21: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 in non-ECN-setup SYN-ACK
Before a TCP connection can use ECN, a host sends an ECN-setup SYN (synchronization) packet to a
remote end that contains an ECE and CWR bit set in the header. This indicates to the remote end that the
sending TCP is ECN-capable, rather than an indication of congestion. The remote end sends an
ECN-setup SYN-ACK (acknowledgment) packet to the sending host.
In the example above, the “out ECN-setup SYN” text means that a SYN packet with the ECE and CWR
bit set was sent to the remote end. The “in non-ECN-setup SYN-ACK” text means that the remote end
did not favorably acknowledge the ECN request and that therefore the session is ECN capable.
The following debug output shows that ECN capabilities are enabled at both ends. In response to the
ECN-setup SYN, the other end favorably replied with an ECN-setup SYN-ACK message. This
connection is now ECN capable for the rest of the session.
Trying 10.10.10.10 ... Open

Password required, but none set
!
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 out ECN-setup SYN
1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 in ECN-setup SYN-ACK
Step 5 show debugging

Use this command to verify that the hosts are connected, for example:
Router# show debugging
!
TCP:
TCP Packet debugging is on
TCP ECN debugging is on
!
!
Trying 10.1.25.234 ...
!

98 78-17478-01
Configuration Examples for TCP Explicit Congestion Notification
00:02:48: 10.1.25.31:11001 <---> 10.1.25.234:23 out ECN-setup SYN

00:02:48: tcp0: O CLOSED 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
OPTS 4 ECE CWR SYN WIN 4128
00:02:50: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
00:02:54: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
00:03:02: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
00:03:18: 10.1.25.31:11001 <---> 10.1.25.234:23 SYN with ECN disabled
00:03:18: tcp0: O SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
OPTS 4 SYN WIN 4128
00:03:20: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
OPTS 4 SYN WIN 4128
00:03:24: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
OPTS 4 SYN WIN 4128
00:03:32: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018
OPTS 4 SYN WIN 4128
!Connection timed out; remote host not responding
Configuration Examples for TCP Explicit Congestion

Notification
This section contains the following example:
• Running Configuration: Example, page 99
Running Configuration: Example

The following running-configuration example shows that ECN is configured.
Current configuration : 1013 bytes

!
version 12.3
!

78-17478-01 99
hostname Router
!
boot-start-marker
boot-end-marker
!
no aaa new-model
ip subnet-zero
!
ip tcp ecn ! ECN is configured.
!
ip cef
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
ip address 10.1.25.35 255.255.255.0
duplex half
!
no ip address
shutdown
duplex half
!
no ip address
shutdown
duplex half
!
ip address 23.23.23.6 255.255.255.0
shutdown
duplex half
!
end
The following sections provide references related to the TCP Explicit Congestion Notification feature.
Related Documents
IP configuration overview Cisco IOS IP Configuration Guide
IP commands Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and
Services, Release 12.3 T
Configuration fundamentals Cisco IOS Configuration Fundamentals and Network Management
Configuration Guide

100 78-17478-01
Command Reference
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP
Description Link
even more content.
Command Reference
The following new and modified commands are pertinent to this feature. To see the command pages for
these commands and other commands used with this feature, go to the Cisco IOS Master Commands List,
124index.htm.
• debug ip tcp ecn
• ip tcp ecn
• show debugging
• show tcp

78-17478-01 101
Command Reference

102 78-17478-01
Part 4: Server Load Balancing
Configuring Server Load Balancing
This chapter describes how to configure the IOS Server Load Balancing (SLB) feature. For a complete
description of the SLB commands in this chapter, refer to the “Server Load Balancing Commands”
chapter of the Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services. To locate
documentation of other commands that appear in this chapter, use the command reference master index
or search online.
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the “Identifying Supported Platforms”
section in the “Using Cisco IOS Software for Release 12.4” chapter in this book.
The SLB feature is a Cisco IOS-based solution that provides IP server load balancing. Using the
IOS SLB feature, the network administrator defines a virtual server that represents a group of real
servers in a cluster of network servers known as a server farm. In this environment the clients are
configured to connect to the IP address of the virtual server. The virtual server IP address is configured as a
loopback address, or secondary IP address, on each of the real servers. When a client initiates a connection
to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured
load-balancing algorithm.
IOS SLB shares the same software code base as Cisco IOS software and has all the software features sets
of Cisco IOS software. IOS SLB is recommended for customers desiring complete integration of SLB
technology into traditional Cisco switches and routers.
On the Catalyst 6500 switch, IOS SLB takes advantage of hardware acceleration to forward data packets
at very high speed when running in dispatched mode.
IOS SLB assures continuous, high availability of content and applications with proven techniques for
actively managing servers and connections in a distributed environment. By distributing user requests
across a cluster of servers, IOS SLB optimizes responsiveness and system capacity, and dramatically
reduces the cost of providing Internet, database, and application services for large-scale sites as well as
small- and medium-sized sites.
IOS SLB facilitates scalability, availability, and ease of maintenance as follows:
• The addition of new physical (real) servers, and the removal or failure of existing servers, can occur
at any time, transparently, without affecting the availability of the virtual server.
• The slow start capability of IOS SLB allows a new server to increase its load gradually, preventing
failures caused by assigning the server too many new connections too quickly.
• IOS SLB supports fragmented packets and packets with IP options, buffering your servers from
client or network vagaries that are beyond your control.
Administration of server applications is easier. Clients know only about virtual servers; no
administration is required for real server changes.

78-17478-01 105
IOS SLB Functions and Capabilities
Security of the real server is provided because its address is never announced to the external network.
Users are familiar only with the virtual IP address. You can filter unwanted flows based on both IP
address and TCP or UDP port numbers. Though it does not eliminate the need for a firewall, IOS SLB
also can help protect against some denial-of-service attacks.
In a branch office, IOS SLB allows balancing of multiple sites and disaster recovery in the event of
full-site failure, and distributes the work of load balancing.
Figure 2 illustrates a logical view of IOS SLB.
Figure 2 Logical View of IOS SLB
Virtual server
Real Real Real

server server server
Catalyst 4840G
with IOS SLB
29164
Client Client
Client Client

Functions and capabilities supported in IOS SLB are described in the following sections:
• Algorithms for Server Load Balancing
• Port-Bound Servers
• Client-Assigned Load Balancing
• Content Flow Monitor Support
• Sticky Connections
• Maximum Connections
• Delayed Removal of TCP Connection Context
• TCP Session Reassignment
• Automatic Server Failure Detection
• Automatic Unfail
• Slow Start

106 78-17478-01
• SynGuard
• Dynamic Feedback Protocol for IOS SLB
• Alternate IP Addresses
• Transparent Web Cache Balancing
• NAT
• Redundancy Enhancement—Stateless Backup
Algorithms for Server Load Balancing

IOS SLB provides two load-balancing algorithms: weighted round robin and weighted least connections.
You may specify either algorithm as the basis for choosing a real server for each new connection request
that arrives at the virtual server.
Weighted Round Robin

The weighted round robin algorithm specifies that the real server used for a new connection to the virtual
server is chosen from the server farm in a circular fashion. Each real server is assigned a weight, n, that
represents its capacity to handle connections, as compared to the other real servers associated with the
virtual server. That is, new connections are assigned to a given real server n times before the next real
server in the server farm is chosen.
For example, assume a server farm comprises real server ServerA with n = 3, ServerB with n = 1, and
ServerC with n = 2. The first three connections to the virtual server are assigned to ServerA, the fourth
connection to ServerB, and the fifth and sixth connections to ServerC.
Note Assigning a weight of n = 1 to all of the servers in the server farm configures the IOS SLB switch to use
a simple round robin algorithm.
Weighted Least Connections

The weighted least connections algorithm specifies that the next real server chosen from a server farm
for a new connection to the virtual server is the server with the fewest number of active connections.
Each real server is assigned a weight for this algorithm also. When weights are assigned, the server with
the fewest number of connections is based on the number of active connections on each server, and on
the relative capacity of each server. The capacity of a given real server is calculated as the assigned
weight of that server divided by the sum of the assigned weights of all of the real servers associated with
that virtual server, or n1/(n1 + n2 + n3...).
For example, assume a server farm comprises real server ServerA with n = 3, ServerB with n = 1, and
ServerC with n = 2. ServerA would have a calculated capacity of 3/(3 + 1 + 2), or half of all active
connections on the virtual server, ServerB one-sixth of all active connections, and ServerC one-third of
all active connections. At any point in time, the next connection to the virtual server would be assigned
to the real server whose number of active connections is farthest below its calculated capacity.
Note Assigning a weight of n = 1 to all of the servers in the server farm configures the IOS SLB switch to use
a simple least-connection algorithm.

78-17478-01 107
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server.
However, if you configure NAT on the server farm, you can also configure port-bound servers.
Port-bound servers allow one virtual server IP address to represent one set of real servers for one service,
such as HTTP, and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition
are not redirected.
IOS SLB supports both port-bound and nonport-bound servers, but port-bound servers are
recommended.
Client-Assigned Load Balancing

Client-assigned load balancing allows you to limit access to a virtual server by specifying the list of
client IP subnets that are permitted to use that virtual server. With this feature, you can assign a set of
client IP subnets (such as internal subnets) connecting to a virtual IP address to one server farm, and
assign another set of clients (such as external clients) to a different server farm.
Content Flow Monitor Support

IOS SLB supports the Cisco Content Flow Monitor (CFM), a Web-based status monitoring application
within the CiscoWorks2000 product family. You can use CFM to manage Cisco server load-balancing
devices. CFM runs on Windows NT and Solaris workstations, and is accessed using a Web browser.
Sticky Connections
When you use sticky connections, new connections from a client IP address or subnet are assigned to the
same real server as were previous connections from that address or subnet.
IOS SLB creates sticky objects to track client assignments. The sticky objects remain in the IOS SLB
database after the last sticky connection is deleted, for a period defined by a configurable sticky timer. If
the timer is configured on a virtual server, new connections from a client are sent to the same real server
that handled the previous client connection, provided one of the following conditions is true:
• A connection for the same client already exists.
• The amount of time between the end of a previous connection from the client and the start of the
new connection is within the timer duration.
Sticky connections also permit the coupling of services that are handled by more than one virtual server.
This allows connection requests for related services to use the same real server. For example, Web server
(HTTP) typically uses TCP port 80, and HTTP over Secure Socket Layer (HTTPS) uses port 443. If
HTTP virtual servers and HTTPS virtual servers are coupled, connections for ports 80 and 443 from the
same client IP address or subnet are assigned to the same real server.
Maximum Connections
The maximum connections feature allows you to configure a limit on the number of active connections
that a real server can handle.

108 78-17478-01
Delayed Removal of TCP Connection Context

Because of IP packet ordering anomalies, IOS SLB might “see” the termination of a TCP connection (a
finish [FIN] or reset [RST]) followed by other packets for the connection. This problem usually occurs
when there are multiple paths that the TCP connection packets can follow. To correctly redirect the
packets that arrive after the connection is terminated, IOS SLB retains the TCP connection information,
or context, for a specified length of time. The length of time the context is retained after the connection
is terminated is controlled by a configurable delay timer.
TCP Session Reassignment

IOS SLB tracks each TCP SYN sent to a real server by a client attempting to open a new connection. If
several consecutive SYNs are not answered, or if a SYN is replied to with an RST, the TCP session is
reassigned to a new real server. The number of SYN attempts is controlled by a configurable reassign
threshold.
Automatic Server Failure Detection

IOS SLB automatically detects each failed TCP connection attempt to a real server, and increments a
failure counter for that server. (The failure counter is not incremented if a failed TCP connection from
the same client has already been counted.) If the failure counter of a server exceeds a configurable failure
threshold, the server is considered out of service and is removed from the list of active real servers.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections
for a length of time specified by a configurable retry timer. After that timer expires, the server is again
eligible for new virtual server connections and IOS SLB sends the server the next connection for which
it qualifies. If the connection is successful, the failed server is again placed back on the list of active real
servers. If the connection is unsuccessful, the server remains out of service and the retry timer is reset.
Slow Start
In an environment that uses weighted least connections load balancing, a real server that is placed in
service initially has no connections, and could therefore be assigned so many new connections that it
becomes overloaded. To prevent such an overload, the slow start feature controls the number of new
connections that are directed to a real server that has just been placed in service.
SynGuard
The SynGuard feature limits the rate of TCP SYNs handled by a virtual server to prevent a type of
network problem known as a SYN flood denial-of-service attack. A user might send a large number of
SYNs to a server, which could overwhelm or crash the server, denying service to other users. SynGuard
prevents such an attack from bringing down IOS SLB or a real server. SynGuard monitors the number
of SYNs to a virtual server over a specific time interval and does not allow the number to exceed a
configured SYN threshold. If the threshold is reached, any new SYNs are dropped.

78-17478-01 109
Dynamic Feedback Protocol for IOS SLB

The IOS SLB Dynamic Feedback Protocol (DFP) is a mechanism that allows host agents in
load-balanced environments to dynamically report the change in status of the host systems that provide
a virtual service. The status reported is a relative weight that specifies the capacity of a host server to
perform work.
Alternate IP Addresses
IOS SLB enables you to Telnet to the load-balancing device using an alternate IP address. To do so, use
either of the following methods:
• Use any of the interface addresses to Telnet to the load-balancing device.
• Define a secondary IP address to Telnet to the load-balancing device.
This function is similar to that provided by the LocalDirector (LD) Alias command.
Transparent Web Cache Balancing

You can balance transparent Web caches if you know in advance the IP addresses they are serving. In
IOS SLB, configure the IP addresses, or some common subset of them, as virtual servers.
Note A Web cache can start its own connections to real sites if pages are not available in its cache. Those
connections cannot be load balanced back to the same set of caches. IOS SLB addresses this situation
by allowing you to configure “client exclude” statements so that IOS SLB does not load balance
connections initiated by the Web caches.
NAT
Cisco IOS Network Address Translation (NAT), RFC 1631, allows unregistered “private” IP addresses
to connect to the Internet by translating them into globally registered IP addresses. Cisco IOS NAT also
increases network privacy by hiding internal IP addresses from external networks.
IOS SLB can operate in one of two redirection modes:
• Directed mode—The virtual server can be assigned an IP address that is not known to any of the real
servers. IOS SLB translates packets exchanged between a client and real server, translating the
virtual server IP address to a real server address via NAT.
• Dispatched mode—The virtual server address is known to the real servers; you must configure the
virtual server IP address as a loopback address, or secondary IP address, on each real server. IOS SLB
redirects packets to the real servers at the media access control (MAC) layer. Because the virtual
server IP address is not modified in dispatched mode, the real servers must be Layer 2 adjacent to
IOS SLB, or intervening routers might not be able to route to the chosen real server.
The main advantage of dispatched mode is performance. In dispatched mode, the Layer 3 and Layer 4
addresses are not modified, which means IP header checksum adjustment occurs quickly, and checksum
adjustment or recalculation for TCP or UDP is not required. Dispatched mode is also simpler than in
directed mode because packets for applications with IP addresses in the packet need not be examined
and modified.

110 78-17478-01
Restrictions
The main disadvantage of dispatched mode is that the virtual server IP address is not modified, which
means that the real servers must be Layer 2 adjacent with the load balancer or intervening routers may
not be able to route to the chosen real server.
NAT (directed mode) is used to solve these dispatched mode problems.
IOS SLB currently supports only server NAT. By replacing the virtual server IP address with the real
server IP address (and vice versa), servers can be many hops away from the load balancer and intervening
routers can route to them without requiring tunneling. Additionally, loopback and secondary interfaces
need no longer be on the real server.
Note On the Catalyst 6000 family switches and Cisco 7200 series routers, if an IP address is configured as a
real IP address for a NAT virtual server, you cannot balance connection requests from that address to a
different virtual server (whether NAT or dispatch) on the same load balancer.
The network designer must ensure that outbound packets travel through IOS SLB using one of the
following methods:
• Direct wiring (all packets flow through a branch office IOS SLB device)
• Default gateways or policy-based routing
• IOS SLB NAT of client addresses, enabled as an outbound feature on server-side interfaces
A less common form of server NAT is server port translation, which involves replacement of a virtual
server port. Server port translation does not require server IP address translation, but the two translations
can be used together.
Redundancy Enhancement—Stateless Backup

An IOS SLB could represent a point of failure and the servers could lose their connections to the
backbone if power fails, or if a link from a switch to the distribution-layer switch is disconnected.
IOS SLB supports a stateless backup option you can use to reduce that risk. Stateless backup, based on
the Hot Standby Router Protocol (HSRP), provides high network availability by routing IP flows from
hosts on Ethernet networks without relying on the availability of a single Layer 3 switch.
HSRP is configured on Layer 3 switches that run IP over Ethernet. If a Layer 3 switch fails, HSRP
automatically allows another Layer 3 switch to assume the function of the failing switch. HSRP is
therefore particularly useful when you require continuous access to resources in the network.
HSRP is compatible with Internetwork Packet Exchange (IPX) from Novell and with AppleTalk.
Note To avoid any single point of failure in an IOS SLB network, use multiple Layer 2 switches to provide
connectivity between the IOS SLB devices and the servers.
Restrictions
IOS SLB has the following restrictions:
• Operates in a standalone mode and currently does not operate as a MultiNode Load Balancing
(MNLB) Services Manager. The presence of IOS SLB does not preclude the use of the existing
MNLB Forwarding Agent with an external Services Manager in an MNLB environment.

78-17478-01 111
IOS SLB Configuration Task List
• Does not support coordinating server load-balancing statistics among different IOS SLB instances
for backup capability.
• Supports FTP only in dispatched mode.
• Does not support load balancing of flows between clients and real servers that are on the same LAN
VLAN.
• Does not support IOS SLB and Cisco Applications and Services Architecture (CASA) configured
with the same virtual IP address, even if they are for different services.
• Supports Cisco IOS NAT in directed mode with no hardware data packet acceleration. (Hardware
data packet acceleration is performed by the Policy Feature Card (PFC), and in directed mode the
data packets are handled by the Multilayer Switched Feature Card (MSFC), not the PFC.)
Catalyst 6000 family switch restrictions are as follows:
• Requires the MSFC and the PFC.
• Requires that the Multilayer Switching (MLS) flow mode be set to full. For more information about
how to set the MLS flow, refer to the “Configuring IP Multilayer Switching” section in the Catalyst
6000 Family MSFC (12.0) & PFC Configuration Guide, Release 5.4.
• When IOS SLB is operating in dispatched mode, real servers must be Layer 2-adjacent to the
IOS SLB switch (that is, not beyond an additional router), with hardware data packet acceleration
performed by the PFC. All real servers that can be reached by a single IOS SLB device must be on
the same VLAN. The loopback address must be configured in the real servers.
• When IOS SLB is operating in directed mode with server NAT, real servers need not be Layer
2-adjacent to the IOS SLB switch. This allows for more flexible network design, because servers
can be placed several Layer 3 hops away from the IOS SLB switch.
• Requires that all real servers that can be reached by a single IOS SLB device must be on the same
VLAN. The loopback address must be configured in the real servers.
– Supports NativeIOS only and C6sup-is-mz images.
Cisco 7200 series restrictions are as follows:
• In dispatched mode, the servers must be Layer 2-adjacent or tag-switched. In directed mode, the
servers can be one or more hops away.
• Supports Cisco IOS NAT in directed mode with no hardware data packet acceleration. Provides no
hardware acceleration for the IOS SLB function for either dispatched mode or directed mode.
• Supports C7200-is-mz images.

Configuring IOS SLB involves identifying server farms, configuring groups of real servers in server farms,
and configuring the virtual servers that represent the real servers to the clients. To configure the IOS SLB
feature, perform the tasks described in the following sections in the order listed. Some tasks are required;
others are optional.
• Specifying a Server Farm (Required)
• Specifying a Load-Balancing Algorithm (Optional)
• Specifying a Bind ID (Optional)
• Specifying a Real Server (Required)
• Configuring Real Server Attributes (Optional)

112 78-17478-01
• Enabling the Real Server for Service (Required)

• Specifying a Virtual Server (Required)
• Associating a Virtual Server with a Server Farm (Required)
• Configuring Virtual Server Attributes (Required)
• Adjusting Virtual Server Values (Optional)
• Preventing Advertisement of Virtual Server Address (Optional)
• Enabling the Virtual Server for Service (Required)
• Configuring IOS SLB Dynamic Feedback Protocol (Optional)
• Configuring NAT (Optional)
• Implementing IOS SLB Stateless Backup (Optional)
• Verifying IOS SLB (Optional)
• Troubleshooting IOS SLB (Optional)
Specifying a Server Farm

Grouping real servers into server farms is an essential part of IOS SLB. Using server farms enables
IOS SLB to assign new connections to the real servers based on their weighted capacities, and on the
load-balancing algorithms used.
To configure a server farm, use the following command in global configuration mode:
Command Purpose
Router(config)# ip slb serverfarm serverfarm-name Adds a server farm definition to the IOS SLB
configuration and initiates SLB server farm
configuration mode.
Specifying a Load-Balancing Algorithm

To determine which real server to use for each new connection request, the IOS SLB feature uses one of
two load-balancing algorithms: weighted round robin (the default) or weighted least connections. (See
the “Weighted Round Robin” section or the “Weighted Least Connections” section for detailed
descriptions of these algorithms.) To specify the load-balancing algorithm, use the following command
in SLB server farm configuration mode:
Command Purpose
Router(config-slb-sfarm)# predictor [roundrobin | leastconns] Specifies whether the weighted round robin
algorithm or the weighted least connections
algorithm is to be used to determine how a real
server is selected.

78-17478-01 113
Specifying a Bind ID
To configure a bind ID on the server farm for use by DFP, use the following command in SLB server
farm configuration mode:
Command Purpose
Router(config-slb-sfarm)# bindid [bind_id] Specifies a bind ID on the server farm for use by
DFP.
Specifying a Real Server

A server farm comprises a number of real servers. The real servers are the physical devices that provide
the load-balanced services.
To identify a real server in your network, use the following command inSLB server farm configuration
mode:
Command Purpose
Router(config-slb-sfarm)# real ip-address Identifies a real server to the IOS SLB function
and initiates real server configuration mode.
Configuring Real Server Attributes

To configure real server attributes, use the following commands in SLB real server configuration mode:
Command Purpose
Router(config-slb-real)# faildetect numconns number-conns Specifies the number of consecutive connection
[numclients number-clients] failures and, optionally, the number of unique
client connection failures, that constitute failure of
the real server.
Router(config-slb-real)# maxconns maximum-number Specifies the maximum number of active
connections allowed on the real server at one time.
Router(config-slb-real)# reassign threshold Specifies the number of consecutive unanswered
SYNs that initiates assignment of the connection
to a different real server.
Router(config-slb-real)# retry retry-value Specifies the interval (in seconds) to wait between
the detection of a server failure and the next
attempt to connect to the failed server.
Router(config-slb-real)# weight weighting-value Specifies the workload capacity of the real server
relative to other servers in the server farm.

114 78-17478-01
Enabling the Real Server for Service

To place the real server into service, use the following command in SLB real server configuration mode:
Command Purpose
Router(config-slb-real)# inservice Enables the real server for use by IOS SLB.
Specifying a Virtual Server

To specify a virtual server, use the following command in global configuration mode:
Command Purpose
Router(config)# ip slb vserver virtserver-name Identifies a virtual server and enters SLB virtual
server configuration mode.
Associating a Virtual Server with a Server Farm

To associate the virtual server with a server farm, use the following command in SLB virtual server
configuration mode:
Command Purpose
Router(config-slb-vserver)# serverfarm serverfarm-name Associates a real server farm with a virtual server.
Configuring Virtual Server Attributes

To configure virtual server attributes, use the following command in SLB virtual server configuration
mode:
Command Purpose
Router(config-slb-vserver)# virtual ip-address {tcp | udp} Specifies the virtual server IP address, type of
port-number [service service-name] connection, port number, and optional service
coupling.

78-17478-01 115
Adjusting Virtual Server Values

To change the default settings of the virtual server values, use the following commands in SLB virtual
server configuration mode as needed:
Command Purpose
Router(config-slb-vserver)# client ip-address network-mask Specifies which clients are allowed to use the
virtual server.
Router(config-slb-vserver)# delay duration Specifies the amount of time IOS SLB maintains
TCP connection context after a connection has
terminated. The default value is 10 seconds.
Router(config-slb-vserver)# idle duration Specifies the minimum amount of time IOS SLB
maintains connection context in the absence of
packet activity. The default value is 3600 seconds
(1 hour).
Router(config-slb-vserver)# sticky duration [group group-id] Specifies that connections from the same client
use the same real server, as long as the interval
between client connections does not exceed the
specified duration.
Router(config-slb-vserver)# synguard syn-count interval Specifies the rate of TCP SYNs handled by a
virtual server in order to prevent a SYN flood
denial-of -service attack.
Preventing Advertisement of Virtual Server Address

By default, virtual server addresses are advertised. That is, static routes to the Null0 interface are
installed for the virtual server addresses. To advertise these static routes using the routing protocol, you
must configure redistribution of static routes for the routing protocol. To prevent the installation of a
static route, use the following command in SLB virtual server configuration mode:
Command Purpose
Router(config-slb-vserver)# no advertise Omits the virtual server IP address from the
routing protocol updates.
Enabling the Virtual Server for Service

To place the virtual server into service, use the following command in SLB virtual server configuration
mode:
Command Purpose
Router(config-slb-vserver)# inservice Enables the virtual server for use by IOS SLB.

116 78-17478-01
Configuring IOS SLB Dynamic Feedback Protocol

To configure IOS SLB DFP, use the following commands beginning in global configuration mode:
Command Purpose
Step 1 Router(config)# ip slb dfp [password password Configures DFP and, optionally, sets a password
[timeout]] and initiates SLB DFP configuration mode.
Step 2 Router(config-slb-dfp)# agent ip-address port [timeout Configures a DFP agent.
[retry-count [retry-interval]]]
Configuring NAT
To configure IOS SLB NAT mode for a specific server farm, use the following commands beginning in
Command Purpose
Step 1 Router(config)# ip slb serverfarm serverfarm-name Adds a server farm definition to the IOS SLB
configuration and initiates server farm
configuration mode.
Step 2 Router(config-slb-sfarm)# nat server Configures server NAT.
Step 3 Router(config-slb-sfarm)# real ip-address Identifies a real server to the IOS SLB function
and initiates real server configuration mode.
Implementing IOS SLB Stateless Backup

Stateless backup, based on the Hot Standby Router Protocol (HSRP), provides high network availability
by routing IP flows from hosts on Ethernet networks without relying on the availability of any single
Layer 3 switch. Stateless backup is particularly useful for hosts that do not support a router discovery
protocol (such as the Intermediate System-to-Intermediate System [IS-IS] Interdomain Routing Protocol
[IDRP]) and do not have the functionality to shift to a new Layer 3 switch when their selected Layer 3
switch reloads or loses power.
How IOS SLB Stateless Backup Works

A Layer 3 switch running HSRP detects a failure by sending and receiving multicast UDP hello packets.
When the IOS SLB switch running HSRP detects that the designated active Layer 3 switch has failed,
the selected backup Layer 3 switch assumes control of the HSRP group MAC and IP addresses. (You can
also select a new standby Layer 3 switch at that time.) Both the primary and the backup Layer 3 switch
must be on the same subnetwork.
The chosen MAC and IP addresses must be unique and must not conflict with any others on the same
network segment. The MAC address is selected from a pool of Cisco MAC addresses. Configure the last
byte of the MAC address by using the HSRP group number. When HSRP is running, it selects an active
Layer 3 switch and instructs its device layer to listen on an additional (dummy) MAC address.
IOS SLB switching software supports HSRP over 10/100 Ethernet, Gigabit Ethernet, FEC, GEC, and
Bridge Group Virtual Interface (BVI) connections.

78-17478-01 117
HSRP uses a priority scheme to determine which HSRP-configured Layer 3 switch is to be the default
active Layer 3 switch. To configure a Layer 3 switch as active, you assign it a priority higher than that
of all other HSRP-configured Layer 3 switches. The default priority is 100, so if you configure just one
Layer 3 switch to have a higher priority, that switch becomes the default active switch.
HSRP works by the exchange of multicast messages that advertise priority among HSRP-configured
Layer 3 switches. When the active switch fails to send a hello message within a configurable period, the
standby switch with the highest priority becomes the active switch. The transition of packet-forwarding
functions between Layer 3 switches is completely transparent to all hosts accessing the network.
HSRP-configured Layer 3 switches exchange the following types of multicast messages:
• Hello—The hello message conveys the HSRP priority and state information of the switch. By
default, an HSRP switch sends hello messages every 3 seconds.
• Coup—When a standby Layer 3 switch assumes the function of the active switch, it sends a coup
message.
• Resign—The active Layer 3 switch sends a resign message when it is about to shut down or when a
switch that has a higher priority sends a hello message.
At any time, HSRP-configured Layer 3 switches are in one of the following states:
• Active—The switch is performing packet-transfer functions.
• Standby—The switch is prepared to assume packet-transfer functions if the active router fails.
• Speaking and listening—The switch is sending and receiving hello messages.
• Listening—The switch is receiving hello messages.
Configuring IOS SLB Stateless Backup

To configure stateless backup, perform the following tasks. The first task is required; the second task is
optional:
• Configure IOS SLB switches to run HSRP between interfaces on the server side
• Configure multiple IOS SLB switches that share a virtual IP address as long as the client ranges are
exclusive and you use policy routing to forward the flows to the correct IOS SLB switch
To configure stateless backup over VLANs between IOS SLB switches, perform the following steps:
Step 1 Configure the server farms. See the “Specifying a Server Farm” section earlier in this chapter.
Step 2 Configure the real servers. See the “Specifying a Real Server” section earlier in this chapter.
Step 3 Configure the virtual servers. See the “Specifying a Virtual Server”section earlier in this chapter.
Note When you use the inservice (virtual service) command to configure the virtual server as
“in-service” you must use the optional standby interface configuration command and configure
an HSRP group name.
Step 4 Configure the IP routing protocol. See the “IP Routing Protocols” part of the Cisco IOS IP Configuration
Guide.
Step 5 Configure the VLAN between the switches. See the “Virtual LANs” chapter of the Cisco IOS
Switching Services Configuration Guide.
Step 6 Enable HSRP. See the “Enabling HSRP” section earlier in this chapter.

118 78-17478-01
Step 7 Customize group attributes. See the “Customizing Group Attributes” section earlier in this chapter.
Step 8 Verify the IOS SLB HSRP configuration. See the “Verifying the IOS SLB Stateless Backup
Configuration” section earlier in this chapter.
A sample stateless backup configuration is shown in the “IOS SLB Stateless Backup Configuration
Example” section.
Enabling HSRP
To enable HSRP on an IOS SLB interface, enable the protocol, then customize it for the interface. Use
the following command in interface configuration mode:
Command Purpose
Router(config-if)# standby [group-number] ip [ip-address Enables HSRP.
[secondary]]
Customizing Group Attributes

To customize Hot Standby group attributes, use the following commands in interface configuration mode
as needed:
Command Purpose
Router(config-if)# standby [group-number] authentication Selects an authentication string to be carried in all
string HSRP messages.
Router(config-if)# standby [group-number] name group-name Specifies an HSRP group name with which to
associate an IOS SLB interface.
Router(config-if)# standby [group-number] preempt Specifies that if the local router has priority over
the current active router, the local router should
attempt to take its place as the active router.
Router(config-if)# standby [group-number] priority priority Sets the Hot Standby priority used to choose the
active router.
Router(config-if)# standby [group-number] timers hellotime Configures the time between hello packets and the
holdtime hold time before other routers declare the active
router to be down.
Router(config-if)# standby [group-number] track type-number Configures the interface to track other interfaces,
[interface-priority] so that if one of the other interfaces goes down the
Hot Standby priority for the device is lowered.
Verifying the IOS SLB Stateless Backup Configuration

To verify that stateless backup has been configured and is operating correctly, use the following show ip
slb vservers EXEC commands to display information about the IOS SLB virtual server status:
Router# show ip slb vservers
slb vservers prot virtual state conns

-------------------------------------------------------------------

78-17478-01 119
VS1 TCP 10.10.10.12:23 INSERVICE 2

VS2 TCP 10.10.10.18:23 INSERVICE 2
Router# show ip slb vservers detail
VS1, state = INSERVICE, v_index = 10

virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUE
server farm = SERVERGROUP1, delay = 10, idle = 3600
sticky timer = 0, sticky subnet = 255.255.255.255
sticky group id = 0
synguard counter = 0, synguard period = 0
conns = 0, total conns = 0, syns = 0, syn drops = 0
standby group = None
VS2, state = INOFSERVICE, v_index = 11
virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUE
server farm = SERVERGROUP2, delay = 10, idle = 3600
sticky timer = 0, sticky subnet = 255.255.255.255
sticky group id = 0
synguard counter = 0, synguard period = 0
conns = 0, total conns = 0, syns = 0, syn drops = 0
standby group = None
Verifying IOS SLB

The following sections describe how to verify the following different aspects of the IOS SLB feature:
• Verifying IOS SLB Installation
• Verifying Server Failure Detection
Verifying IOS SLB Installation

To verify that the IOS SLB is installed and working properly, perform the following steps:
Step 1 Telnet to the IOS SLB device.

Step 2 Ping from that device to each of the clients and real servers. If it is not precluded by firewalls or network
configuration, ping from the client side to each of the real servers.
Step 3 From the client side, ping the virtual server. Pings are answered by IOS SLB even if no real servers are
in service, so this ensures that the IOS SLB device is reachable.
Step 4 For the selected protocol, start a client connection to the virtual server.
Step 5 If you want sticky connections, perform the following steps:
a. Configure the sticky connections.
b. Start a client connection.
c. Enter the show ip slb reals detail and show ip slb conns EXEC commands.
d. Examine the real server connection counts. The real server whose count increased is the one to
which the client connection is assigned.
e. Enter the show ip slb sticky EXEC command to display the sticky relationships that IOS SLB
stored.
f. End the connection.
g. Ensure that the connection count of the real server decreased.

120 78-17478-01
h. Restart the connection, after waiting no longer than the sticky timeout value.
i. Enter the show ip slb conns EXEC command again.
j. Examine the real server connection counts again, and verify that the sticky connection is assigned
to the same real server as before.
Step 6 Start additional client connections.
Step 7 Enter the show ip slb reals detail EXEC command.
Step 8 Verify that the the connection counts are increasing.
Verifying Server Failure Detection

To verify that server failures are detected correctly, perform the following steps:
Step 1 Use a large client population. If the number of clients is very small, tune the numclients keyword on the
faildetect SLB real server configuration command so that the servers are not displayed as failed.
Step 2 Enter the show ip slb reals detail EXEC command to show the status of the real servers.
Step 3 Examine the status and connection counts of the real servers:
• Servers that failed show a status of failed, testing, or ready_to_test, based on whether IOS SLB is
checking that the server came back up when the command was sent.
• When a real server fails, connections that are assigned but not established (no SYN or ACK is
received) are reassigned to another real server on the first inbound SYN after the reassign threshold
is met. However, any connections that were already established are forwarded to the same real server
because, although it may not be accepting new connections, it may be servicing existing ones.
• For weighted least connections, a real server that has just been placed in service starts slowly so that
it is not overloaded with new connections. (See the “Slow Start” section for more information on
this feature.) Therefore, the connection counts displayed for a new real server show connections
going to other real servers (despite the lower count of the new real server). The connection counts
also show “dummy connections” to the new real server, which IOS SLB uses to artificially inflate
the connection counts for the real server during the slow start period.

78-17478-01 121
Troubleshooting IOS SLB

Table 3 lists questions and answers that can help you troubleshoot IOS SLB.
Table 3 IOS SLB Troubleshooting Guidelines
Question Answer
Why can I connect to real servers directly, but not Make sure that the virtual IP address is configured as a loopback in each
to the virtual server? of the real servers (if you are running in dispatched mode).
Why is IOS SLB not marking my real server as Tune the values for the numclients, numconns, and delay keywords.
failed when I disconnect it from the network?
If you have a very small client population (for example, in a test
environment), the numclients keyword could be causing the problem.
This parameter prevents IOS SLB from mistaking the failure of a small
number of clients for the failure of a real server.
Why is IOS SLB not marking my connections as If you are using dispatched mode, make sure there are no alternate paths
established even though I am transferring data? that allow outbound flows to bypass IOS SLB. Also, make sure that the
clients and real servers are not on the same IP subnet.
Why does IOS SLB show my real server as The inservice and outofservice states indicate whether the network
inservice even though I have taken it down or administrator intends for that real server to be used when it is operational.
physically disconnected it? A real server that was inservice but was removed from the selection list
dynamically by IOS SLB as a result of automatic failure detection, is
marked as failed. Use the show ip slb reals detail EXEC command to
display these real server states.
Beginning with Cisco IOS Release 12.1(1)E, the inservice keyword is
changed to operational, to better reflect actual condition.
Why is IOS SLB not balancing correctly? I am Enter the show mls flow command:
using dispatched mode, the servers are leaving Router# show mls flow
sockets open, and I am seeing RSTs in response
to a number of SYNs. Curiously, sometimes current ip flowmask for unicast: full flow
things work fine. current ipx flowmask for unicast: destination only
The current IP flowmask must be full flow. If it is not, correct the problem
using the mls flow ip full global configuration command:
Enter configuration commands, one per line.
End with CNTL/Z.
Router(config)# mls flow ip full
Router(config)#

122 78-17478-01
Monitoring and Maintaining IOS SLB
Monitoring and Maintaining IOS SLB

To obtain and display run-time information about IOS SLB, use the following commands in EXEC mode
as needed:
Command Purpose
Router# show ip slb conns [vservers virtserver-name] [client Displays all connections handled by IOS SLB, or,
ip-address] [detail] optionally, only those connections associated with
a particular virtual server or client.
Router# show ip slb dfp [agent ip-address port-number] Displays information about DFP and DFP agents,
[detail] [weights] and about the weights assigned to real servers.
Router# show ip slb reals [vservers virtserver-name] [detail] Displays information about the real servers defined
to IOS SLB.
Router# show ip slb serverfarms [name serverfarm-name] Displays information about the server farms
[detail] defined to IOS SLB.
Router# show ip slb stats Displays IOS SLB statistics.
Router# show ip slb sticky [client ip-address] Displays information about the sticky connections
defined to IOS SLB.
Router# show ip slb vservers [name virtserver-name] [detail] Displays information about the virtual servers
defined to IOS SLB.
This section provides the following IOS SLB configuration examples:
• IOS SLB Network Configuration Example
• NAT Configuration Example
• HSRP Configuration Example
• IOS SLB Stateless Backup Configuration Example

78-17478-01 123
IOS SLB Network Configuration Example

This section provides a configuration example based on the network layout shown in Figure 3.
Figure 3 IOS SLB Network Configuration
Restricted Restricted
Web server Web server Web server web server web server
10.1.1.1 10.1.1.2 10.1.1.3 10.1.1.20 10.1.1.21
10.1.1.x
Virtual server
10.0.0.1
10.4.4.x
29163
Client Human
Resources
Client Client
As shown in the following sample code, the example topology has three public Web servers and two
restricted Web servers for privileged clients in subnet 10.4.4.x. The public Web servers are weighted
according to their capacity, with server 10.1.1.2 having the lowest capacity and having a connection limit
imposed on it. The restricted Web servers are configured as members of the same sticky group, so that
HTTP connections and Secure Socket Layer (SSL) connections from the same client use the same real
server.
This configuration is coded as follows:
ip slb serverfarm PUBLIC Unrestricted Web server farm
predictor leastconns Use weighted least connections algorithm
real 10.1.1.1 First real server
weight 16
inservice
real 10.1.1.2 Second real server
weight 4
maxconns 1000 Restrict maximum number of connections
inservice
real 10.1.1.3 Third real server
weight 24
inservice
ip slb serverfarm RESTRICTED Restricted Web server farm

predictor leastconns Use weighted least connections algorithm
real 10.1.1.20 First real server
in-service
real 10.1.1.21 Second real server
in-service

124 78-17478-01
ip slb vservers PUBLIC_HTTP Unrestricted Web virtual server

virtual 10.0.0.1 tcp www Handle HTTP requests
serverfarm PUBLIC Use public Web server farm
inservice
ip slb vservers RESTRICTED_HTTP Restricted HTTP virtual server

virtual 10.0.0.1 tcp www Handle HTTP requests
serverfarm RESTRICTED Use restricted Web server farm
client 10.4.4.0 255.255.255.0 Only allow clients from 10.4.4.x
sticky 60 idle 120 group 1 Couple connections with RESTRICTED_SSL
inservice
ip slb vservers RESTRICTED_SSL Restricted SSL virtual server

virtual 10.0.0.1 tcp https Handle SSL requests
serverfarm RESTRICTED Use restricted Web server farm
client 10.4.4.0 255.255.255.0 Only allow clients from 10.4.4.x
sticky 60 idle 120 group 1 Couple connections with RESTRICTED_HTTP
inservice
NAT Configuration Example

This section provides a configuration example based on the network layout shown in Figure 4.
Figure 4 IOS SLB NAT Topology
Server 1 Server 2 Server 3 Server 4

10.1.1.1 10.2.1.1 10.3.1.1 10.4.1.1
HTTP=80 HTTP=80 HTTP=80 HTTP1 = 8080

HTTP2 = 8081
HTTP3 = 8082
Switch A Switch B Switch C
Clients
33459
The topology in Figure 4 has four Web servers, configured as follows:

• Servers 1, 2, and 3 are running single HTTP server applications listening on port 80.

78-17478-01 125
• Server 4 has multiple HTTP server applications listening on ports 8080, 8081, and 8082.
Servers 1 and 2 are load balanced using Switch A, which is performing server address translation.
Servers 3 and 4 are load balanced using Switches B and C. These two switches are performing server
address translation. These switches also perform server port translation for HTTP packets to and from
Server 4.
The configuration statements for Switch A are as follows:
ip slb serverfarm FARM1
! Translate server addresses
nat server
! Server 1 port 80
real 10.1.1.1
inservice
! Server 2 port 80
real 10.2.1.1
inservice
!
ip slb vservers HTTP1
! Handle HTTP (port 80) requests
virtual 128.1.0.1 tcp www
serverfarm FARM1
inservice
The configuration statements for Switch B are as follows:

nat server
! Server 3 port 80
real 10.3.1.1
inservice
! Server 4 port 8080
real 10.4.1.1 port 8080
inservice
real 10.4.1.1 port 8081
inservice
real 10.4.1.1 port 8082
inservice
!
serverfarm FARM2
inservice
The configuration statements for Switch C are as follows:

nat server
! Server 3 port 80
real 10.3.1.1
inservice
real 10.4.1.1 port 8080
inservice
real 10.4.1.1 port 8081
inservice

126 78-17478-01
real 10.4.1.1 port 8082

inservice
!
serverfarm FARM2
inservice
HSRP Configuration Example

Figure 5 shows the topology of an IP network with two Layer 3 switches configured for HSRP. The
following conditions exist in this network:
• Device A is the active HSRP Layer 3 switch and handles packets to the real servers with IP addresses
3.0.01 through 3.0.020.
• Device B handles packets to real servers with IP addresses 2.0.0.1 through 2.0.0.20.
• All hosts accessing the network use the IP address of the virtual router (in this case, 1.0.0.3).
• The configuration shown uses the Enhanced Interior Gateway Routing Protocol (Enhanced IGRP),
but HSRP can be used with any other routing protocol supported by the Cisco IOS software, such as
Open Shortest Path First (OSPF).
Note Some configurations that use HSRP still require a routing protocol for convergence when a
topology change occurs. The standby Layer 3 switch becomes active, but connectivity does
not occur until convergence occurs.
If the connection between Device A and the client accessing virtual IP 1.0.0.3 fails, fast-converging
routing protocols (such as Enhanced IGRP and OSPF) can respond within seconds, ensuring that
Device B is prepared to transfer packets that would have gone through Device A.

78-17478-01 127
Figure 5 HSRP Example Network Topology
Client
Gigabit Ethernet 41 Gigabit Ethernet 42

1.0.0.1 ISL between 1.0.0.2
devices
Device A active Device B standby

Virtual IP = 1.0.0.3 Virtual IP = 1.0.0.3
Fast Ethernet 1 Fast Ethernet 20 Fast Ethernet 1 Fast Ethernet 20

3.0.0.1 3.0.0.20 2.0.0.1 2.0.0.20
WWW server WWW server WWW server WWW server
Server farm = Public Server farm = Public
33604
HSRP group = Web_Group HSRP group = Web_Group
The configuration for Device A is as follows:

hostname Device A
interface GigabitEthernet 41
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 1 priority 110
standby 1 authentication denmark
standby 1 timers 5 15
standby 1 name Web-Group
interface FastEthernet 1
ip address 3.0.0.1 255.0.0.0
router eigrp 1
network 1.0.0.0
network 3.0.0.0
The configuration for Device B is as follows:

hostname Device B
interface GigabitEthernet 41
ip address 1.0.0.2 255.0.0.0
standby 1 preempt
standby 1 authentication denmark

128 78-17478-01
standby 1 name Web-Group
interface FastEthernet 41
ip address 2.0.0.1 255.0.0.0
router eigrp 1
network 1.0.0.0
network 2.0.0.0
The standby ip interface configuration command enables HSRP and establishes 1.0.0.3 as the IP address
of the virtual router. The configurations of both Layer 3 switches include this command so that both
switches share the same virtual IP address. The number 1 establishes Hot Standby group 1. (If you do
not specify a group number, the default is group 0.) The configuration for at least one of the Layer 3
switches in the Hot Standby group must specify the IP address of the virtual router; specifying the IP
address of the virtual router is optional for other routers in the same Hot Standby group.
The standby preempt interface configuration command allows the Layer 3 switch to become the active
switch when its priority is higher than all other HSRP-configured switches in this Hot Standby group.
The configurations of both switches include this command so that each can be the standby Layer 3 switch
for the other switch. The number 1 indicates that this command applies to Hot Standby group 1. If you
do not use the standby preempt command in the configuration for a Layer 3 switch, that switch cannot
become the active Layer 3 switch.
The standby priority interface configuration command sets the HSRP priority of the Layer 3 switch to
110, which is higher than the default priority of 100. Only the configuration of Device A includes this
command, which makes Device A the default active Layer 3 switch. The number 1 indicates that this
command applies to Hot Standby group 1.
The standby authentication interface configuration command establishes an authentication string
whose value is an unencrypted eight-character string that is incorporated in each HSRP multicast
message. This command is optional. If you choose to use it, each HSRP-configured Layer 3 switch in
the group should use the same string so that each switch can authenticate the source of the HSRP
messages that it receives. The number 1 indicates that this command applies to Hot Standby group 1.
The standby timers interface configuration command sets the interval (in seconds) between hello
messages (called the hello time) to 5 seconds, and sets the interval (in seconds) that a Layer 3 switch
waits before it declares the active Layer 3 switch to be down (called the hold time) to 8 seconds. (The
defaults are 3 and 10 seconds, respectively.) To modify the default values, you must configure each Layer
3 switch to use the same hello time and hold time. The number 1 indicates that this command applies to
Hot Standby group 1.
The standby name interface configuration command associates the IOS SLB interface with an HSRP
group name (in this case, Web-Group), previously specified on an inservice (virtual server) command.
The number 1 indicates that this command applies to Hot Standby group 1.

78-17478-01 129
IOS SLB Stateless Backup Configuration Example

The following commands enable the HSRP standby group 100 IP address, priority, preempt, and timers;
and configures a name and authentication for Device A in Figure 5:
standby 100 ip 172.20.100.10
standby 100 preempt
standby 100 name Web_group1
standby 100 authentication Secret
exit

130 78-17478-01
Part 5: Web Cache Services Using WCCP
Configuring Web Cache Services Using WCCP
The Web Cache Communication Protocol (WCCP) is a Cisco-developed content-routing technology that
allows you to integrate cache engines (such as the Cisco Cache Engine 550) into your network
infrastructure. Cisco IOS Release 12.1 and later releases allow the use of either Version 1 (WCCPv1) or
Version 2 (WCCPv2) of the WCCP. This chapter describes how to configure your router to redirect
traffic to cache engines (web caches), describes how to manage cache engine clusters (cache farms), and
outlines the benefits of using WCCPv2.
For a complete description of the WCCP configuration commands in this chapter, refer to the “WCCP
Commands” chapter in the Release 12.2 Cisco IOS Configuration Fundamentals Command Reference.
To locate documentation of other commands that appear in this chapter, use the command reference
master index or search online.
The tasks in this chapter assume that you have already configured cache engines on your network. For
specific information on hardware and network planning associated with Cisco Cache Engines and
WCCP, see the Product Literature and Documentation links available on the Cisco.com Web Scaling site
at http://www.cisco.com/warp/public/cc/pd/cxsr/ces/index.shtml.
Note Cisco Systems replaced the Cache Engine 500 Series platforms with Content Engine Platforms in July
2001. Cache Engine Products were the Cache Engine 505, 550, 570, and 550-DS3. Content Engine
Products are the Content Engine 507, 560, 590, and 7320.
To identify hardware or software image support for a specific feature, use Feature Navigator on
Cisco.com to search for information about the feature or refer to the software release notes for a specific
release. For more information, see the “Identifying Platform Support for Cisco IOS Software Features”
section in the “About Cisco IOS Software Documentation” chapter.
Understanding WCCP
The Cisco IOS WCCP feature allows utilization of Cisco Cache Engines (or other caches 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 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 cache
engine. The word “transparent” is this case means that the end user does not know that a requested file
(such as a web page) came from the cache engine instead of from the originally specified server.

78-17478-01 133
Understanding WCCP
When a cache engine receives a request, it attempts to service it from its own local cache. If the requested
information is not present, the cache engine issues its own request to the originally targeted server to get
the required information. When the cache engine retrieves the requested information, it 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 cache engines, called a cache engine cluster, to provide content to a router or
multiple routers. Network administrators can easily scale their cache engines to handle heavy traffic
loads through these clustering capabilities. Cisco clustering technology enables each cache member to
work in parallel, resulting in linear scalability. Clustering cache engines greatly improves the scalability,
redundancy, and availability of your caching solution. You can cluster up to 32 cache engines to scale to
your desired capacity.
Understanding WCCPv1 Configuration

With WCCP-Version 1, only a single router services a cluster. In this scenario, this router is the device
that performs all the IP packet redirection. Figure 6 illustrates how this configuration appears.
Figure 6 Cisco Cache Engine Network Configuration Using WCCP-Version 1
Internet
Router
100BASE-T
Cache 1
Clients
Cache 2
Cache 3
S6529
Clients
Content is not duplicated on the cache engines. The benefit of using multiple caches is that you can scale
a caching solution by clustering multiple physical caches to appear as one logical cache.
The following sequence of events details how WCCPv1 configuration works:
1. Each cache engine is configured by the system administrator with the IP address of the control
router. Up to 32 cache engines can connect to a single control router.
2. The cache engines send their IP addresses to the control router using WCCP, indicating their
presence. Routers and cache 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 cache in the cluster, essentially making all the cache 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.

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

Multiple routers can use WCCPv2 to service a cache cluster. This is in contrast to WCCPv1, in which
only one router could redirect content requests to a cluster. Figure 7 illustrates a sample configuration
using multiple routers.
Figure 7 Cisco Cache Engine Network Configuration Using WCCP v2
Internet
Service group
100BASE-T
Cache 1
Clients 100BASE-T
Clients 100BASE-T
Cache 2
Clients 100BASE-T
Clients 100BASE-T
Cache 3
Clients 100BASE-T
23810
Clients
The subset of cache 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 User Datagram Protocol
(UDP) redirection.
Using WCCPv1, the cache engines were configured with the address of the single router. WCCPv2
requires that each cache 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 cache
engine. In this case the address of each router in the group must be explicitly specified for each cache
engine during configuration.
• Multicast—A single multicast address is configured on each cache engine. In the multicast address
method, the cache engine sends a single-address notification that provides coverage for all routers
in the service group. For example, a cache engine could indicate that packets should be sent to a

78-17478-01 135
WCCPv2 Features
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 interface
configuration command for details).
The multicast option is easier to configure because you need only specify a single address on each cache
engine. This option also allows you to add and remove routers from a service group dynamically, without
needing to reconfigure the cache engines with a different list of addresses each time.
The following sequence of events details how WCCPv2 configuration works:
1. Each cache engine is configured with a list of routers.
2. Each cache engine announces its presence and a list of all routers with which it has established
communications. The routers reply with their view (list) of cache engines in the group.
3. Once the view is consistent across all cache engines in the cluster, one cache engine is designated
as the lead and sets the policy that the routers need to deploy in redirecting packets.
The following sections describe how to configure WCCPv2 on routers so they may participate in a
service group.
WCCPv2 Features
WCCPv2 provides the features described in the following sections:
• Support for Services Other than HTTP
• Support for Multiple Routers
• MD5 Security
• Web Cache Packet Return
• Load Distribution
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 introduces 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 keywords (such as “web-cache”).
This information is used to validate that service group members are all using or providing the same
service.
The cache engines in service group specify traffic to be redirected by protocol (TCP or UDP) and port
(source or destination). Each service group has a priority status assigned to it. Packets are matched
against service groups in priority order.

136 78-17478-01
WCCPv2 Features
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.
MD5 Security
WCCPv2 provides optional authentication that enables you to control which routers and cache engines
become part of the service group using passwords and the 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.
Web Cache Packet Return

If a cache engine is unable to provide a requested object it has cached due to error or overload, the cache
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 cache 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 cache cluster). This
provides error handling transparency to clients.
Typical reasons why a cache engine would reject packets and initiate the packet return feature include
the following:
• Instances when the cache engine is overloaded and has no room to service the packets
• Instances when the cache engine is filtering for certain conditions that make caching packets
counterproductive (for example, when IP authentication has been turned on)
Load Distribution
WCCPv2 can be used to adjust the load being offered to individual cache 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 cache to adjust the load on a particular cache and balance the load across
the caches 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 cache engines.
Prior to WCCPv2, information from one hash bucket could only go to one cache engine.
• Load Balancing—Allows the set of hash buckets assigned to a cache engine to be adjusted so that
the load can be shifted from an overwhelmed cache 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 cache engine.
The use of these hashing parameters prevents one cache from being overloaded and reduces the potential
for bottlenecking.

78-17478-01 137
Restrictions for WCCPv2
Restrictions for WCCPv2

The following limitations apply to WCCP v2:
• WCCP works only with IP networks.
• For routers servicing a multicast cluster, the Time To Live (TTL) value must be set at 15 or fewer.
• Because the messages may now be IP multicast, members may receive messages that will not be
relevant or are duplicates. Appropriate filtering needs to be performed.
• Service groups can comprise up to 32 cache engines and 32 routers.
• All cache 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.
Configuring WCCP
The following configuration tasks assume that you have already installed and configured the cache
engines you want to include in your network. You must configure the cache engines in the cluster before
configuring WCCP functionality on your routers. Refer to the Cisco Cache Engine User Guide for cache
engine configuration and setup tasks.
IP must be configured on the router interface connected to the cache engines and on the router interface
connected to the Internet. Note that Cisco Cache Engines require use of a Fast Ethernet interface for a
direct connection. Examples of router configuration tasks follow this section. For complete descriptions
of the command syntax, refer to the Release 12.2 Cisco IOS Configuration Fundamentals Command
Reference.
Perform the tasks found in the following sections to configure WCCP on a router:
• Specifying a Version of WCCP (Optional)
• Configuring a Service Group Using WCCPv2 (Required)
• Excluding Traffic on a Specific Interface from Redirection (Optional)
• Registering a Router to a Multicast Address (Optional)
• Using Access Lists for a WCCP Service Group (Optional)
• Setting a Password for a Router and Cache Engines (Optional)
Specifying a Version of 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.
To change the running version of WCCP from Version 2 to Version 1, or to return to WCCPv2 after an
initial change, use the following command in EXEC mode:
Command Purpose
Router# ip wccp version {1 | 2} Specifies which version of WCCP to configure on a router. WCCPv2 is the
default running version.

138 78-17478-01
Configuring WCCP
WCCPv1 does not use the WCCP commands from earlier Cisco IOS versions. Instead, use the WCCP
commands documented in this chapter. If a function is not allowed in WCCPv1, an error prompt will be
printed to the screen. For example, if WCCPv1 is running on the router and you try to configure a
dynamic service, the following message will be displayed: “WCCP V1 only supports the web-cache
service.” The show ip wccp EXEC command will display the WCCP protocol version number that is
currently running on your router.
Configuring a Service Group Using WCCPv2

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 cache 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 cache engines. A description
of a well-known service is not required beyond a service identification (in this case, the Command Line
Interface (CLI) provides a web-cache keyword in the command syntax).
In addition to the web cache service, there can be up to seven dynamic services running concurrently in
a service group.
Note More than one service can run on a router at the same time, and routers and cache devices can be part of
multiple service groups at the same time.
The dynamic services are defined by the cache engines; the cache 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
web cache to join the group. In a dynamic service, up to eight ports can be specified within a single
protocol.
Cisco Cache Engines, for example, use dynamic service 99 to specify a reverse-proxy service. However,
other cache devices may use this service number for some other service. The following configuration
information deals with enabling general services on Cisco routers. Refer to the cache server
documentation for information on configuring services on cache devices.
To enable a service on a router, use the following commands, beginning in global configuration mode:
Command Purpose
Step 1 Router(config)# ip wccp {web-cache | service-number} Specifies a web-cache or dynamic service to enable
[group-address groupaddress] [redirect-list on the router, specifies the IP multicast address used
access-list] [group-list access-list] [password
password]
by the service group, specifies any access lists to
use, specifies whether to use MD5 authentication,
and enables the WCCP service.
Step 2 Router(config)# interface type number Specifies an interface to configure and enters
interface configuration mode.
Step 3 Router(config-if)# ip wccp {web-cache | service-number} Enables WCCP redirection on the specified
redirect {out | in} interface.
As indicated by the out and in keyword options in the ip wccp service redirect command, redirection
can be specified for outbound interfaces or inbound interfaces. Inbound traffic can be configured to use
Cisco Express Forwarding (CEF), Fast Forwarding, or Process Forwarding.

78-17478-01 139
Configuring WCCP
Configuring WCCP for redirection for inbound traffic on interfaces allows you to avoid the overhead
associated with CEF forwarding for outbound traffic. Setting an output feature on any interface results
in the slower switching path of the feature being taken by all packets arriving at all interfaces. Setting
an input feature on an interface results in only those packets arriving at that interface taking the
configured feature path; packets arriving at other interfaces will use the faster default path. Configuring
WCCP for inbound traffic also allows packets to be classified before the routing table lookup, which
translates into faster redirection of packets.
Specifying a Web Cache Service

Using the specific forms of the above commands, you can configure a web-cache service as follows:
Command Purpose
Step 1 Router(config)# ip wccp web-cache Enables the web cache service on the router.
Step 2 Router(config)# interface type number Targets an interface number for which the web cache
service will run, and enters interface configuration
mode.
Step 3 Router(config-if)# ip wccp web-cache redirect Enables the check on packets to determine if they
{out | in} qualify to be redirected to a web cache, using the
interface specified in Step 2.
Excluding Traffic on a Specific Interface from Redirection

To exclude any interface from redirecting inbound traffic, use the following commands, beginning in
Command Purpose
Step 1 Router(config)# interface type number Specifies an interface to configure, and enters
interface configuration mode.
Step 2 Router(config-if)# ip wccp redirect exclude in Allows inbound packets on this interface to be
excluded from redirection.
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 using the following commands:
Command Purpose
Step 1 Router(config)# ip wccp {web-cache | service-number} Specifies the multicast address for the service
group-address groupaddress group.

140 78-17478-01
Configuring WCCP
Command Purpose
Step 2 Router(config)# interface type number Specifies the interface to be configured for
multicast reception.
Step 3 Router(config-if)# ip wccp {web-cache | service-number} Enables the reception of IP multicast packets
group-listen (content originating from the cache engines) on the
interface specified in Step 2.
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 mode command.
• Enable the interfaces to which the cache engines will connect to receive multicast transmissions
using the ip wccp group-listen interface configuration mode command (note that earlier Cisco IOS
versions required the use of the ip pim interface configuration command).
Using Access Lists for a WCCP Service Group

To configure the router to use an access list to determine which traffic should be directed to which cache
engines, use the following commands, beginning in global configuration mode:
Command Purpose
Step 1 Router(config)# access-list access-list permit ip host Creates an access list that enables or disables traffic
host-address [destination-address | destination-host | redirection to the cache engine.
any]
Step 2 Router(config)# ip wccp web-cache group-list Indicates to the router from which IP addresses of
access-list cache engines to accept packets.
To disable caching for certain clients, use the following commands, beginning in global configuration
mode:
Command Purpose
Step 1 Router(config)# access-list access-list permit ip host Creates an access list that enables or disables traffic
host-address [destination-address | destination-host | redirection to the cache engine.
any]
Step 2 Router(config)# ip wccp web-cache redirect-list Sets the access list used to enable redirection.
access-list
Setting a Password for a Router and Cache Engines

MD5 password security requires that each router and cache engine that wants to join a service group be
configured with the service group password. The password can consist of up to seven characters. Each
cache 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.
To configure an MD5 password for use by the router in WCCP communications, use the following
command in global configuration mode:

78-17478-01 141
Verifying and Monitoring WCCP Configuration Settings
Command Purpose
Router(config)# ip wccp web-cache password password Sets an MD5 password on the router.
Verifying and Monitoring WCCP Configuration Settings

Use the following commands in EXEC mode, as needed to verify and monitor the configuration settings
for WCCP:
Command Purpose
Router# show ip wccp [web-cache | service-number] Displays global information related to WCCP, including
the protocol version currently running, the number of
cache engines in the routers service group, which cache
engine group is allowed to connect to the router, and
which access list is being used.
Router# show ip wccp {web-cache | service-number} detail Queries the router for information on which cache
engines of a specific service group the router has
detected. The information can be displayed for either
the web cache service or the specified dynamic service.
Router# 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.”
Router# show ip wccp {web-cache | service-number} view Displays which devices in a particular service group
have been detected and which cache engines are having
trouble becoming visible to all other routers to which
the current router is connected. The view keyword
indicates a list of addresses of the service group. The
information can be displayed for either the web cache
service or the specified dynamic service. For further
troubleshooting information, use the show ip wccp
{web-cache | service number} service command.
WCCP Configuration Examples

• Changing the Version of WCCP on a Router Example
• Performing a General WCCPv2 Configuration Example
• Running a Web Cache Service Example
• Running a Reverse Proxy Service Example
• Registering a Router to a Multicast Address Example
• Using Access Lists Example
• Setting a Password for a Router and Cache Engines Example
• Verifying WCCP Settings Example

142 78-17478-01
Changing the Version of WCCP on a Router Example

The following example shows the process of changing 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(config)# ip wccp version 1
Router(config)# end
% WCCP version 1 is not enabled
Router# config terminal

Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip wccp web-cache
Router(config)# end
Global WCCP information:
Router information:
Router Identifier: 10.4.9.8
Protocol Version: 1.0
. . .
Performing a General WCCPv2 Configuration Example

The following example shows a general WCCPv2 configuration session:
Router(config)# ip wccp web-cache group-address 224.1.1.100 password alaska1
Router(config)# interface ethernet0
Router(config-if)# ip wccp web-cache redirect out
Running a Web Cache Service Example

The following example shows a web cache service configuration session:
router# configure terminal
router(config)# ip wccp web-cache
router(config)# interface ethernet 0
router(config-if)# ip wccp web-cache redirect out
Router(config-if)# ^Z
Router# copy running-config startup-config
The following example shows a configuration session in which redirection of HTTP traffic arriving on
interface 0/1 is enabled:
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface ethernet 0/1
Router(config-if)# ip wccp web-cache redirect in
Router(config-if)# ^Z
Router# show ip interface ethernet 0/1
.
.
.
WCCP Redirect inbound is enabled
WCCP Redirect exclude is disabled

78-17478-01 143
.
.
.
Running a Reverse Proxy Service Example

The following example assumes you a configuring a service group using Cisco Cache Engines, which
use dynamic service 99 to run a reverse proxy service:
router(config)# ip wccp 99
router(config)# interface ethernet 0
router(config-if)# ip wccp 99 redirect out
Registering a Router to a Multicast Address Example

The following example shows how to register a router to a multicast address of 224.1.1.100:
Router(config)# ip wccp web-cache group-address 224.1.1.100
Router(config)# interface ethernet 0
Router(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 interface ethernet 0:
Router(config)# ip wccp 99 group-address 224.1.1.1

Router(config-if)# ip wccp 99 redirect out
Using Access Lists Example

To achieve better security, you can use a standard access list to notify the router which IP addresses are
valid addresses for a cache engine attempting to register with the current router. The following example
shows a standard access list configuration session where the access list number is 10 for some sample
hosts:
router(config)# access-list 10 permit host 11.1.1.1
router(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 12.1.1.1 will bypass the cache, and
that all other requests will be serviced normally:
Router(config)# ip wccp web-cache redirect-list 120
Router(config)# access-list 120 deny tcp host 10.1.1.1 any
Router(config)# access-list 120 deny tcp any host 12.1.1.1
Router(config)# access-list 120 permit ip any any
The following example configures a router to redirect web-related packets received via interface ethernet
0/1, destined to any host except 209.165.196.51:
Router(config)# access-list 100 deny ip any host 209.165.196.51

Router(config)# access-list 100 permit ip any any

144 78-17478-01
Router(config)# ip wccp web-cache redirect-list 100

Router(config)# interface Ethernet 0/1
Router(config-if)# ip wccp web-cache redirect in
Setting a Password for a Router and Cache Engines Example

The following example shows a WCCPv2 password configuration session where the password is
alaska1:
router(config)# ip wccp web-cache password alaska1
Verifying WCCP Settings Example

To verify your configuration changes, use the more system:running-config EXEC command. The
following example shows that the both the web cache service and dynamic service 99 are enabled on the
router:
router# more system:running-config
Current configuration:
!
version 12.0
service udp-small-servers
service tcp-small-servers
!
hostname router4
!
enable secret 5 $1$nSVy$faliJsVQXVPW.KuCxZNTh1
enable password alabama1
!
ip subnet-zero
ip wccp web-cache
ip wccp 99
ip domain-name cisco.com
ip name-server 10.1.1.1
!
!
!
interface Ethernet0
ip address 10.3.1.2 255.255.255.0
ip wccp web-cache redirect out
ip wccp 99 redirect out
no ip route-cache
no ip mroute-cache
!
interface Ethernet1
ip address 10.4.1.1 255.255.255.0

78-17478-01 145
ip wccp 99 redirect out

no ip route-cache
no ip mroute-cache
!
interface Serial0
no ip address
no ip route-cache
no ip mroute-cache
shutdown
!
interface Serial1
no ip address
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 alaska1
login
!
end

146 78-17478-01
WCCP Bypass Counters
The WCCP Bypass Counters feature allows you to display a count of packets that have been bypassed
by a web cache and returned to the originating router to be forwarded normally.
Feature History for the WCCP Bypass Counters Feature

12.2(25)S This feature was integrated into Cisco IOS 12.2(25)S.
Contents
• Information About WCCP Bypass Counters, page 147
• How to Display WCCP Bypass Counters, page 148
Information About WCCP Bypass Counters

This section contains the following concept that you should understand to use this feature:
• WCCP Bypass Packets, page 147
WCCP Bypass Packets

Web Cache Communication Protocol (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 decides that it cannot deal with 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 encapsulated in generic routing encapsulation (GRE). The router
decapsulates and forwards the packets normally.

78-17478-01 147
How to Display WCCP Bypass Counters
GRE is a Cisco proprietary tunneling protocol that encapsulates packet types from a variety of protocols
inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP
internetwork. By connecting multiprotocol subnetworks in a single-protocol backbone environment, IP
tunneling that uses GRE allows expansion of the network across a single-protocol backbone
environment.
How to Display WCCP Bypass Counters

This section contains the following task:
• Displaying WCCP Bypass Counters, page 148 (required)
Displaying WCCP Bypass Counters

This task shows you how to display the counters for the purposes of troubleshooting.
Note There are no configuration tasks for this feature.
SUMMARY STEPS
1. enable
2. show ip wccp [service-number [detail | view] | web-cache [detail | view]]
DETAILED STEPS
Command Purpose
Step 1 enable Enters privileged EXEC mode.
Example:
Router> enable
Step 2 show ip wccp [service-number [detail | view] Displays information about all web caches in the currently
| web-cache [detail | view]] configured cluster. The argument and keywords are as
follows:
Example: • service-number—(Optional) Dynamic number of the
Router# show ip wccp web-cache detail web-cache service group being controlled by the cache.
Range is from 0 to 99. For web caches that use Cisco
Cache 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.

148 78-17478-01
Problems have been encountered because CPU usage is very high when WCCP is enabled. The counters
enable a determination of the bypass traffic directly on the router and can indicate whether or not this is
the cause. In some situations, 10 percent bypass traffic may be normal; in other situations, it 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 web cache and determine why the web cache is choosing to bypass the traffic. You can
log in to the web-cache console and use CLI to investigate further. The counters allow you to determine
the percent of traffic being bypassed.
This section contains the following output example:
• WCCP Web Cache Configuration: Example, page 149
WCCP Web Cache Configuration: Example

The following sample output is from the show ip wccp web-cache detail command and shows the
bypassed packets for process, fast, and CEF that are switching paths in Cisco IOS.
Router# show ip wccp web-cache detail
WCCP Client information:

Web Client ID: 10.10.10.1
State: Usable
Initial Hash Info: 00000000000000000000000000000000
00000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%)
Packets Redirected: 4320
Connect Time: 00:04:53
Bypassed Packets
Process: 0
Fast: 0
CEF: 250
For more information about the show ip wccp web-cache command, see the Cisco IOS IP Application
Services Command Reference, Release 12.4.

78-17478-01 149
The following sections provide references related to the WCCP Bypass Counters feature.
Related Documents
ACL overview and configuration • “Configuring IP Services” chapter in the Cisco IOS IP
Configuration Guide
• IP Access List Entry Sequence Numbering, Release 12.2(15)T
IP addressing and services • Cisco IOS IP Configuration Guide
• Cisco IOS IP Command Reference, Volume 1 of 4: Addressing
and Services, Release 12.3 T
WCCP overview and configuration “Configuring Web Cache Services Using WCCP” chapter in the
Cisco IOS IP Application Services Configuration Guide, Release
12.4
WCCP commands Cisco IOS IP Application Services Command Reference, Release
12.4.
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title

150 78-17478-01
Command Reference
Description Link
even more content.
Command Reference
124index.htm.
• show ip wccp

78-17478-01 151
Command Reference

152 78-17478-01
WCCP Outbound ACL Check
The WCCP Outbound ACL Check feature enables you to configure an access control list (ACL) check
for redirected traffic to prevent the possibility that cached content could be delivered to an unauthorized
client. This feature is supported by Web Cache Communication Protocol (WCCP) Version 1 and
Version 2.
Feature History for the WCCP Outbound ACL Check Feature

Contents
• Information About WCCP Outbound ACL Check, page 153
• How to Configure WCCP Outbound ACL Check, page 154
• Configuration Examples for WCCP Outbound ACL Check, page 156
Information About WCCP Outbound ACL Check

This section contains the following concepts that you should understand to enable this feature:
• WCCP, page 154
• ACLs, page 154

78-17478-01 153
How to Configure WCCP Outbound ACL Check
WCCP
Web Cache Communication Protocol (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 redirecting router. If there
is an outbound ACL configured on the interface at which redirection takes place, it is possible, under
some circumstances, that hosts whose traffic is redirected will gain access to destinations to which they
would otherwise be blocked.
The WCCP Outbound ACL Check feature ensures that the outbound ACL checking is performed at the
original interface so that the checking is secure and consistent across all platforms and Cisco IOS
switching paths.
ACLs
Access control lists (ACLs) filter network traffic by controlling whether routed packets are forwarded or
blocked at the router interface. Each packet is examined to determine whether it will be forwarded or
dropped, according to the specified criteria within the ACL. ACL criteria can be the source address of
the traffic, the destination address of the traffic, or the upper-layer protocol.
An IP ACL is a sequential collection of permit and deny conditions that apply to an IP address. The
router tests addresses against the conditions in the ACL one at a time. The first match determines
whether the address is accepted or rejected. Because Cisco IOS software stops testing conditions after
the first match, the order of the conditions is critical. If no conditions match, the router rejects the
address, by virtue of an implicit “deny all” clause.
There are many types of IP ACLs that can be configured in Cisco IOS software, such as:
• Standard
• Extended
• Lock and key (dynamic ACLs)
• IP named
• Reflexive
• Time-based and distributed time-based
• Context-based
• Authentication proxy
• Turbo

This section contains the following task:
• Enabling the WCCP Outbound ACL Check, page 155 (required)

154 78-17478-01
Enabling the WCCP Outbound ACL Check

This task shows you how to enable an outbound ACL check for WCCP using a web cache.
Note When all redirection is performed in the hardware, the mode of redirection will change when outbound
ACL checking is enabled. The first packet is switched in software to allow the extra ACL check to be
performed before a shortcut is installed.
SUMMARY STEPS
1. enable
3. ip wccp {web-cache | service-number} [group-address multicast-address] [redirect-list
access-list] [group-list access-list] [password password]
4. ip wccp outbound-acl-check
5. exit
6. show ip wccp [service-number [detail | view] | web-cache [detail | view]]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip wccp {web-cache | service-number} Enables the support for Cisco Cache Engine service group
[group-address multicast-address] or any cache service group and configures a redirect ACL
[redirect-list access-list] [group-list
access-list] [password password]
list or group ACL.
Note The web-cache keyword is for WCCP version 1 and
version 2 and the service-number argument is for
Example:
WCCP version 2 only.
Router(config)# ip wccp web-cache
Step 4 ip wccp outbound-acl-check Enables the ACL outbound check on the originating
interface.
Example:
Router(config)# ip wccp outbound-acl-check

78-17478-01 155
Configuration Examples for WCCP Outbound ACL Check

Step 5 exit Exits global configuration.
Example:
Step 6 show ip wccp [service-number [detail | view] | Displays information about all web caches in the currently
web-cache [detail | view]] configured cluster. The argument and keywords are as
follows:
Example: • service-number—(Optional) Dynamic number of the
Router# show ip wccp 24 detail web-cache service group being controlled by the cache.
Range is from 0 to 99. For web caches that use Cisco
Cache 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.
Configuration Examples for WCCP Outbound ACL Check

• WCCP Outbound ACL Check Configuration: Example, page 156
WCCP Outbound ACL Check Configuration: Example

The following configuration example shows that the access list prevents traffic from network 10.0.0.0
leaving interface f0/0. Because the outbound ACL check is enabled, WCCP does not redirect that traffic.
WCCP checks packets against the ACL before they are redirected.
ip wccp web-cache
ip wccp outbound-acl-check
!
interface f0/0
!
ip wccp web-cache redirect-list redirect-out
access-list 10 deny 10.0.0.0 0.255.255.255
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.

156 78-17478-01
The following sections provide references related to the WCCP Outbound ACL Check feature.
Related Documents
ACL overview and configuration • “Configuring IP Services” chapter in Cisco IOS IP
Configuration Guide
• IP Access List Entry Sequence Numbering, Release 12.2(15)T
IP addressing and services commands and • Cisco IOS IP Configuration Guide
configuration
• Cisco IOS IP Command Reference, Volume 1 of 4: Addressing
and Services, Release 12.3 T
WCCP overview and configuration “Configuring Web Cache Services Using WCCP” chapter in
Cisco IOS Configuration Fundamentals Configuration Guide
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title

78-17478-01 157
Command Reference
Description Link
even more content.
Command Reference
124index.htm.
• ip wccp

158 78-17478-01
WCCP Increased Services
First Published: March 29, 2005

Last Updated: June 19, 2006
Previously, all versions of Web Cache Communication Protocol (WCCP) within Cisco IOS software
supported a maximum number of eight simultaneous service definitions. As content networking
configurations became more complex, this limited number of definitions became an impediment to the
deployment of content networking solutions. The WCCP Increased Services feature increases the
number of services supported by WCCP to a maximum of 256.
Finding Feature Information in This Module

Your Cisco IOS software release may not support all of the features documented in this module. To reach
links to specific feature documentation in this module and to see a list of the releases in which each feature is
supported, use the “Feature Information for WCCP Increased Services” section on page 174.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS
software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An
account on Cisco.com is not required.
Contents
• Information About WCCP Increased Services, page 159
• How to Configure WCCP Increased Services, page 160
• Configuration Examples for WCCP Increased Services, page 161
• Feature Information for WCCP Increased Services, page 174
Information About WCCP Increased Services

To configure the WCCP Increased Services feature, you should understand the following concept:
• WCCP Service Groups, page 160

78-17478-01 159
How to Configure WCCP Increased Services
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 specified on caches and
communicated to routers by using WCCP. The current implementation of WCCP in Cisco IOS software
allows a maximum of eight service groups to be defined. This maximum restricts caching deployments,
so the maximum number of service groups allowed is increased to 256.
How to Configure WCCP Increased Services

This section contains the following procedure:
• Configuring Service Groups, page 160
Configuring Service Groups

Perform this task to specify a check of all services and the number of service groups for WCCP.
SUMMARY STEPS
1. enable
3. ip wccp check services all
4. ip wccp {web-cache | service-number}
5. exit
DETAILED STEPS

Example:
Router> enable
Example:

160 78-17478-01
Configuration Examples for WCCP Increased Services

Step 3 ip wccp check services all Specifies a check of all WCCP services. When traffic
matches a service, it may be prevented from redirection if a
redirect list is configured for that service, and no further
Example:
Router(config)# ip wccp check services all
checks against other services are made and the packet is not
redirected.
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.
Step 4 ip wccp {web-cache | service-number} Specifies the WCCP service number. The web-cache
keyword counts as one service. The service-number
argument has a maximum allowable number of 255. The
Example:
Router(config)# ip wccp 201
dynamic service can be from 0 to 254 and the maximum is
255. The maximum number of services that can be specified
is 256.
Step 5 exit Exits to privileged EXEC mode.
Example:
Configuration Examples for WCCP Increased Services

This section provides the following configuration example:
• WCCP Services Configuration: Example, page 161
WCCP Services Configuration: Example

The following example shows how to configure a check of all WCCP services:
ip wccp check services all
The following example shows how to configure one service number:

ip wccp 15
The following sections provide references related to the WCCP Increased Services feature.

78-17478-01 161
Related Documents
WCCP overview and configuration tasks “Web Cache Services Using WCCP” chapter in the Cisco IOS IP
Application Services Configuration Guide, Release 12.4
WCCP commands: complete command syntax, Cisco IOS IP Application Services Command Reference, Release
command mode, command history, defaults, usage 12.2SR
guidelines, and examples
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
The Cisco Technical Support & Documentation http://www.cisco.com/techsupport
website contains thousands of pages of searchable
technical content, including links to products,
technologies, solutions, technical tips, and tools.

162 78-17478-01
Command Reference
Command Reference
This section documents modified commands only.
• ip wccp
• ip wccp check services all
• show ip wccp

78-17478-01 163
ip wccp
ip wccp
To allocate space and to enable support of the specified Web Cache Communication Protocol (WCCP)
service for participation in a service group, use the ip wccp command in global configuration mode. To
disable the service group and deallocate space, use the no form of this command.
ip wccp {web-cache | service-number | outbound-acl-check} [group-address multicast-address]

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

access-list] [group-list access-list] [password password]
Syntax Description web-cache Web-cache service, WCCP version 1 and version 2.

Note Web cache counts as one service. The maximum number of
services, including those assigned with the service-number
argument are 256.
service-number A dynamic service identifier, which means the service definition is
dictated by the cache. The dynamic service number can be from 0 to 254
and up to 255. There is a maximum allowable number of 256 that includes
the web-cache service specified with the web-cache keyword.
Note If Cisco Cache Engines are being used in your service group, the
reverse-proxy service is indicated by a value of 99.
outbound-acl-check Outbound access control list (ACL) check. You can also use the ip wccp
check acl outbound command.
Note This keyword must be specified alone is not associated with any
one service.
group-address (Optional) Multicast IP address that communicates with the WCCP
multicast-address service group. The multicast-address argument requires a multicast
address, which is used by the router to determine which web cache should
receive redirected messages.
redirect-list access-list (Optional) Access list that controls traffic redirected to this service group.
The access-list argument should consist of a string of no more than 64
characters (name or number) that specifies the access list.
group-list access-list (Optional) Access list that determines which web caches are allowed to
participate in the service group. The access-list argument should consist
of a string of no more than 64 characters (name or number) that specifies
the access list.
password password [0 | (Optional) Message Digest 5 (MD5) authentication for messages received
7] from the service group. Messages that are not accepted by the
authentication are discarded. The password argument can be up to seven
characters in length. The 0 optional keyword means that the password is
not encrypted. The 7 optional keyword indicates that the password is
encrypted.
Defaults WCCP services are not enabled on the router.

164 78-17478-01
ip wccp
Command Modes Global configuration
Command History Release Modification

12.0(3)T This command was introduced.
12.1 This command replaced the ip wccp enable, ip wccp redirect-list, and ip
wccp group-list commands.
12.3(7)T The outbound-acl-check keyword was added.
12.2(25)S This command was integrated into Cisco IOS Release 12.2(25)S.
12.3(14)T The maximum value for service-number argument was increased to 255.
12.2(27)SBC This command was integrated into Cisco IOS Release 12.2(27)SBC.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines WCCP transparent caching bypasses Network Address Translation (NAT) when fast (Cisco Express
Forwarding [CEF]) switching is enabled. To work around this situation, WCCP transparent caching
should be configured in the outgoing direction, fast/CEF switching should be enabled on the Content
Engine interface, and the ip wccp web-cache redirect out command should be specified. Configure
WCCP in the incoming direction on the inside interface by specifying the ip wccp redirect exclude in
command on the router interface facing the cache. This configuration prevents the redirection of any
packets arriving on that interface.
You can also include a redirect list when configuring a service group and the specified redirect list will
deny packets with a network address translation (NAT) (source) IP address and prevent redirection. Refer
to the ip wccp command for configuration of the redirect list and service group.
This command instructs a router to enable or disable the support for the specified service number or the
web-cache service name. A service number can be from 0 to 254. Once the service number or name is
enabled, the router can participate in the establishment of a service group.
When the no ip wccp command is entered, the router terminates participation in the service group,
deallocates space if none of the interfaces still has the service configured, and terminates the WCCP task
if no other services are configured.
The keywords following the web-cache keyword and the service-number argument are optional and may
be specified in any order, but only may be specified once. The following sections outline the specific
usage of each of the optional forms of this command.
ip wccp {web-cache | service-number} group-address multicast-address

A WCCP group address can be configured to set up a multicast address that cooperating routers and web
caches can use to exchange WCCP protocol messages. If such an address is used, IP multicast routing
must be enabled so that the messages that use the configured group (multicast) addresses are received
correctly.
This option instructs the router to use the specified multicast IP address to coalesce the “I See You”
responses for the “Here I Am” messages that it has received on this group address. The response is sent
to the group address as well. The default is for no group address to be configured, in which case all “Here
I Am” messages are responded to with a unicast reply.

78-17478-01 165
ip wccp
ip wccp {web-cache | service-number} redirect-list access-list

This option instructs the router to use an access list to control the traffic that is redirected to the web
caches of the service group specified by the service name given. The access-list argument specifies either
a number from 1 to 99 to represent a standard access list number or a name to represent a named standard
access list. The access list itself specifies which traffic is permitted to be redirected. The default is for
no redirect list to be configured (all traffic is redirected).
WCCP requires that the following protocol and ports not be filtered by any access lists:
• User Datagram Protocol (UDP) (protocol type 17) port 2048. This port is used for control signaling.
Blocking this type of traffic will prevent WCCP from establishing a connection between the router
and web caches.
• Generic routing encapsulation (GRE) (protocol type 47 encapsulated frames). Blocking this type of
traffic will prevent the web caches from ever seeing the packets that are intercepted.
ip wccp {web-cache | service-number} group-list access-list

This option instructs the router to use an access list to control the web caches allowed to participate in
the specified service group. The access-list parameter specifies either a number from 1 to 99 to represent
a standard access list number or a name to represent a named standard access list. The access list itself
specifies which web caches are permitted to participate in the service group. The default is for no group
list to be configured, in which case all web caches may participate in the service group.
Note The ip wccp {web-cache | service-number} group-list command syntax resembles the ip wccp
{web-cache | service-number} group-listen command, but these are entirely different commands. The
ip wccp group-listen command is an interface configuration command used to configure an interface to
listen for multicast notifications from a cache cluster. Refer to the description of the ip wccp
group-listen command in the Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and
Services, Release 12.3T.
ip wccp {web-cache | service-number} password password

This option instructs the router to use MD5 authentication on the messages received from the service
group specified by the service name given. Use this form of the command to set the password on the
router. You must also configure the same password separately on each web cache. The password can be
up to a maximum of seven characters. Messages that do not authenticate when authentication is enabled
on the router are discarded. The default is for no authentication password to be configured and for
authentication to be disabled.
Examples The following example shows how to configure a router to run WCCP reverse-proxy service, using the
multicast address of 10.1.1.1:
ip multicast-routing
ip wccp 99 group-address 10.1.1.1
ip wccp 99 group-listen
The following example shows how to configure a router to redirect web-related packets without a
destination of 10.168.196.51 to the web cache:
access-list 100 deny ip any host 10.168.196.51
access-list 100 permit ip any any
ip wccp web-cache redirect-list 100
ip web-cache redirect out

166 78-17478-01
ip wccp
The following example shows how to configure an access list to prevent traffic from network 10.0.0.0
leaving Fast Ethernet 0/0 interface. Because the outbound ACL check is enabled, WCCP does not
redirect that traffic. WCCP checks packets against the ACL before they are redirected.
ip wccp web-cache
ip wccp outbound-acl-check
interface fastethernet0/0
ip wccp web-cache redirect out
access-list 10 deny 10.0.0.0 0.255.255.255
If the outbound ACL check is disabled, HTTP packets from network 10.0.0.0 would be redirected to a
cache and users with that network address could retrieve web pages when the network administrator
wanted to prevent this from happening.
Related Commands Command Description

ip wccp check services Enables all WCCP services.
all
ip wccp version Specifies which version of WCCP you wish to use on your router.

78-17478-01 167

To enable all Web Cache Communication Protocol (WCCP) services, use the ip wccp check services all
command in global configuration mode. To disable all services, use the no form of this command.
no ip wccp check services all
Syntax Description This command has no arguments or keywords.
Defaults WCCP services are not enabled on the router.
Command Modes Global configuration

12.3(14)T This command was introduced.
Usage Guidelines The ip wccp check services all command specifies a check of all WCCP services. When traffic matches
a service, it may be prevented from redirection if a redirect list is configured for that service, and no
further checks against other services are made and the packet is not redirected.
With the ip wccp check services all command, WCCP can be configured to check the other configured
services for a match and perform redirection for those services if a 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.
Examples The following example shows how to configure all WCCP services:

ip wccp Allocates space and enables support of specified WCCP services for
participation in a service group.
ip wccp version Specifies which version of WCCP you wish to use on your router.

168 78-17478-01
show ip wccp
show ip wccp
To display global statistics related to Web Cache Communication Protocol (WCCP), use the show ip
wccp command in privileged EXEC mode.
show ip wccp [service-number | web-cache] [detail | view]
Syntax Description service-number (Optional) Identification number of the web-cache service group being controlled
by the cache. The number can be from 0 to 256. For web caches using Cisco Cache
Engines, the reverse proxy service is indicated by a value of 99.
web-cache (Optional) Statistics for the web-cache service.
detail (Optional) Information about the router and all web caches.
view (Optional) Other members of a particular service group have or have not been
detected.
Command Modes Privileged EXEC

11.1CA This command was introduced for Cisco 7200 and 7500 platforms.
11.2P Support for this command was added to a variety of Cisco platforms.
12.0(3)T The detail and view keywords were added.
12.3(7)T The output was enhanced to display the bypass counters (process, fast, and
Cisco Express Forwarding) when WCCP is enabled.
12.2(25)S This command was integrated into Cisco IOS Release 12.2(25)S.
12.3(14)T The output was enhanced to display the maximum number of service groups.
12.2(27)SBC This command was integrated into Cisco IOS Release 12.2(27)SBC.
Usage Guidelines Use the clear ip wccp command to reset the counter for the “Packets Redirected” information.
Examples This section contains examples and field descriptions for the following forms of this command:
• show ip wccp web-cache
• show ip wccp service-number view
• show ip wccp service-number detail
• show ip wccp web-cache detail
• show ip wccp web-cache detail (bypass counters displayed)

78-17478-01 169
show ip wccp
show ip wccp web-cache

The following is sample output from the show ip wccp web-cache command:
Router# show ip wccp web-cache
Global WCCP Information:

Service Name: web-cache:
Number of Cache Engines:1
Number of Routers:1
Total Packets Redirected:213
Redirect access-list:no_linux
Total Packets Denied Redirect:88
Total Packets Unassigned:-none-
Group access-list:0
Total Messages Denied to Group:0
Total Authentication failures:0
Table 4 describes the significant fields shown in the display.
Table 4 show ip wccp web-cache Field Descriptions
Field Description
Service Name Indicates which service is detailed.
Number of Cache Engines Number of Cisco cache engines using the router as their home
router.
Number of Routers The number of routers in the service group.
Total Packets Redirected Total number of packets redirected by the router.
Redirect access-list The name or number of the access list that determines which
packets will be redirected.
Total Packets Denied Redirect Total number of packets that were not redirected because they did
not match the access list.
Total Packets Unassigned Number of packets that were not redirected because they were not
assigned to any cache engine. Packets may not be assigned during
initial discovery of cache engines or when a cache is dropped
from a cluster.
Group access-list Indicates which cache engine is allowed to connect to the router.
Total Messages Denied to Group Indicates the number of packets denied by the group-list access
list.
Total Authentication failures The number of instances where a password did not match.
show ip wccp service-number view

The following is sample output from the show ip wccp 1 view command:
Router# show ip wccp 1 view
WCCP Router Informed of:

10.168.88.10
10.168.88.20
WCCP Cache Engines Visible

10.168.88.11
10.168.88.12
WCCP Cache Engines Not Visible:

170 78-17478-01
show ip wccp
-none-
Note The number of maximum service groups that can be configured is 256.
If any web cache is displayed under the WCCP Cache Engines Not Visible field, the router needs to be
reconfigured to map the web cache that is not visible to it.
Table 5 show ip wccp service-number view Field Descriptions
Field Description
WCCP Router Informed of A list of routers detected by the current router.
WCCP Cache Engines Visible A list of cache engines that are visible to the router and other
cache engines in the service group.
WCCP Cache Engines Not Visible A list of cache engines in the service group that are not visible
to the router and other cache engines in the service group.
show ip wccp service-number detail

The following example displays web-cache engine information and WCCP router statistics that include
the type of services:
Router# show ip wccp 91 detail
WCCP Cache-Engine information:

Web Cache ID: 30.1.1.14
State: Usable
Redirection: GRE
Packet Return: GRE
Assignment: HASH
Initial Hash Info: 0000000000000000000000000000000000000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%)
Packets Redirected: 0
Connect Time: 00:01:56
Bypassed Packets
Process: 0
CEF: 0
show ip wccp web-cache detail

The following example displays web-cache engine information and WCCP router statistics for a
particular service group:
WCCP Router information:

IP Address10.168.88.10
Protocol Version:2.0
WCCP Cache-Engine Information

IP Address:10.168.88.11
State:Usable
Initial Hash Info:AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA
Assigned Hash Info:FFFFFFFFFFFFFFFFFFFFFFFFFF

78-17478-01 171
show ip wccp
FFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment:256 (100.00%)
Packets Redirected:21345
Connect Time:00:13:46
Table 6 show ip wccp detail Field Descriptions
Field Description
WCCP Router information The header for the area that contains fields for the IP address and
version of WCCP associated with the router connected to the
cache engine in the service group.
IP Address The IP address of the router connected to the cache engine in the
service group.
Protocol Version The version of WCCP being used by the router in the service
group.
WCCP Cache Engine Information Contains fields for information on cache engines.
IP Address The IP address of the cache engine in the service group.
Protocol Version The version of WCCP being used by the cache engine in the
service group.
State Indicates whether the cache engine is operating properly and can
be contacted by a router and other cache engines in the service
group.
Initial Hash Info The initial state of the hash bucket assignment.
Assigned Hash Info The current state of the hash bucket assignment.
Hash Allotment The percent of buckets assigned to the current cache engine. Both
a value and a percent figure are displayed.
Packets Redirected The number of packets that have been redirected to the cache
engine.
Connect Time The amount of time the cache engine has been connected to the
router.
show ip wccp web-cache detail (Bypass Counters)

The following example displays web-cache engine information and WCCP router statistics that include
the bypass counters:
WCCP Router information:

IP Address:10.168.88.10
WCCP Cache-Engine Information

IP Address:10.168.88.11
State:Usable
Initial Hash Info:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Assigned Hash Info:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment:256 (100.00%)
Packets Redirected:21345
Connect Time:00:13:46

172 78-17478-01
show ip wccp
Bypassed Packets
Process: 0
Fast: 0
CEF: 250
Table 7 show ip wccp web-cache detail Field Descriptions
Field Description
WCCP Router information The header for the area that contains fields for the IP address and
the version of WCCP associated with the router connected to the
cache engine in the service group.
IP Address The IP address of the router connected to the cache engine in the
service group.
Protocol Version The version of WCCP that is being used by the router in the
service group.
WCCP Cache-Engine Information Contains fields for information on cache engines.
IP Address The IP address of the cache engine in the service group.
Protocol Version The version of WCCP that is being used by the cache engine in
the service group.
State Indicates whether the cache engine is operating properly and can
be contacted by a router and other cache engines in the service
group.
Initial Hash Info The initial state of the hash bucket assignment.
Assigned Hash Info The current state of the hash bucket assignment.
Hash Allotment The percent of buckets assigned to the current cache engine. Both
a value and a percent figure are displayed.
Packets Redirected The number of packets that have been redirected to the cache
engine.
Connect Time The amount of time the cache engine has been connected to the
router.
Bypassed Packets The number of packets that have been bypassed. Process, fast, and
Cisco Express Forwarding (CEF) are switching paths within
Cisco IOS software.

clear ip wccp Clears the counter for packets redirected using WCCP.
ip wccp Enables WCCP on a router and specifies the type of services to be used.
show ip interface Lists a summary of the IP information and status of an interface.

78-17478-01 173
Feature Information for WCCP Increased Services
Feature Information for WCCP Increased Services

Table 8 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a
specific command, see the command reference documentation.
Note Table 8 lists only the Cisco IOS software release that introduced support for a given feature in a given
Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
software release train also support that feature.
Table 8 Feature Information for WCCP Increased Services
Feature Name Releases Feature Information

WCCP Increased Services 12.3(14)T The WCCP Increased Services feature increases the number
12.2(33) SRA of services supported by WCCP to a maximum of 256.
In 12.3(14)T, this feature was introduced.
In 12.2(33)SRA, support was added for a Cisco IOS 12.2SR
release.

174 78-17478-01
Part 6: First Hop Redundancy Protocols
FHRP Features Roadmap
This roadmap lists the features documented in the First Hop Redundancy Protocol (FHRP) modules and
maps the features to the modules in which they appear.
Roadmap History
This roadmap was first published on May 2, 2005, and last updated on May 2, 2005.
Feature and Release Support

Table 9 lists FHRP feature support for the following Cisco IOS software release trains:
• Cisco IOS Release 12.2S
• Cisco IOS Releases 12.2T, 12.3, and 12.3T
Only features that were introduced or modified in Cisco IOS Release 12.2(1) or Cisco IOS
Releases 12.2(1) or 12.2(14)S or a later release appear in the table. Not all features may be supported in
your Cisco IOS software release.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform.
Note Table 9 lists only the Cisco IOS software release that introduced support for a given feature in a given
Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
software release train also support that feature.

78-17478-01 177
Table 9 Supported FHRP Features
Release Feature Name Feature Description Where Documented

Cisco IOS Release 12.2S
12.2(14)S Gateway Load Balancing GLBP protects data traffic from a failed router or circuit, Configuring GLBP
Protocol like HSRP and VRRP, while allowing packet load sharing
between a group of redundant routers.
Virtual Router VRRP enables a group of routers to form a single virtual Configuring VRRP
Redundancy Protocol router to provide redundancy. The LAN clients can then
be configured with the virtual router as their default
gateway. The virtual router, representing a group of
routers, is also known as a VRRP group.
12.2(18)S GLBP MD5 MD5 authentication provides greater security than the Configuring GLBP
Authentication alternative plain text authentication scheme.
12.2(25)S HSRP MD5 The HSRP MD5 Authentication feature is an Configuring HSRP
Authentication enhancement to generate an MD5 digest for the HSRP
portion of the multicast HSRP protocol packet. This
feature provides added security and protects against the
threat from HSRP-spoofing software.
HSRP Version 2 HSRP Version 2 feature was introduced to prepare for Configuring HSRP
further enhancements and to expand the capabilities
beyond what is possible with HSRP version 1. HSRP
version 2 has a different packet format than HSRP
version 1.
SSO-Aware HSRP SSO-aware HSRP alters the behavior of HSRP when a Configuring HSRP
router with redundant RPs is configured for SSO. When
an RP is active and the other RP is standby, SSO enables
the standby RP to take over if the active RP fails.
Cisco IOS Releases 12.2T, 12.3, and 12.3T
12.2(13)T Virtual Router VRRP enables a group of routers to form a single virtual Configuring VRRP
Redundancy Protocol router to provide redundancy. The LAN clients can then
be configured with the virtual router as their default
gateway. The virtual router, representing a group of
routers, is also known as a VRRP group.
12.2(15)T Gateway Load Balancing GLBP protects data traffic from a failed router or circuit, Configuring GLBP
Protocol like HSRP and VRRP, while allowing packet load sharing
12.3(2)T GLBP MD5 MD5 authentication provides greater security than the Configuring GLBP
HSRP MD5 MD5 authentication provides greater security than the Configuring HSRP
VRRP Object Tracking VRRP object tracking extends the capabilities of the Configuring VRRP
VRRP to allow tracking of specific objects within the
router that can alter the priority level of a virtual router
for a VRRP group.

178 78-17478-01
Table 9 Supported FHRP Features (continued)
Release Feature Name Feature Description Where Documented

12.3(4)T HSRP Version 2 The HSRP Version 2 feature was introduced to prepare Configuring HSRP
for further enhancements and to expand the capabilities
beyond what is possible with HSRP version 1. HSRP
version 2 has a different packet format than HSRP
version 1.
12.3(11)T VRRP MIB—RFC 2787 This feature enables an enhancement to the MIB for use Configuring VRRP
with SNMP-based network management. The feature
adds support for configuring, monitoring, and controlling
routers that use VRRP.
12.3(14)T FHRP—VRRP The FHRP—VRRP Enhancements feature adds support Configuring VRRP
Enhancements for the following capabilities:
• MD5 Authentication—Added to routers that are
configured for VRRP, similar to HSRP, to provide a
method of authenticating peers using a more simple
method than the method in RFC 2338.
• Bridged Virtual Interface (BVI)—Added the
capability to configure VRRP on BVIs. This
functionality is similar to the existing HSRP support
for BVIs.

78-17478-01 179

180 78-17478-01
Configuring GLBP
Gateway Load Balancing Protocol (GLBP) protects data traffic from a failed router or circuit, like Hot
Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP), while allowing
packet load sharing between a group of redundant routers.
Module History
This module was first published on May 2, 2005, and last updated on September 23, 2005.

Your Cisco IOS software release may not support all features. To find information about feature support
and configuration, use the “Feature Information for GLBP” section on page 203.
Contents
• Prerequisites for GLBP, page 181
• Information About GLBP, page 182
• How to Configure GLBP, page 186
• Configuration Examples for GLBP, page 199
• Feature Information for GLBP, page 203
Prerequisites for GLBP

Before configuring GLBP, ensure that the routers can support multiple MAC addresses on the physical
interfaces. For each GLBP forwarder to be configured, an additional MAC address is used.

78-17478-01 181
Configuring GLBP
Information About GLBP

To configure GLBP, you need to understand the following concepts:
• GLBP Overview, page 182
• GLBP Active Virtual Gateway, page 182
• GLBP Virtual MAC Address Assignment, page 183
• GLBP Virtual Gateway Redundancy, page 184
• GLBP Virtual Forwarder Redundancy, page 184
• GLBP Gateway Priority, page 184
• GLBP Gateway Weighting and Tracking, page 185
• GLBP Benefits, page 185
GLBP Overview
The Gateway Load Balancing Protocol feature provides automatic router backup for IP hosts 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.
GLBP performs a similar function for the user as HSRP and VRRP. HSRP and VRRP allow multiple
routers to participate in a virtual router group configured with a virtual IP address. One member is
elected to be the active router to forward packets sent to the virtual IP address for the group. The other
routers in the group are redundant until the active router fails. These standby routers have unused
bandwidth that the protocol is not using. Although multiple virtual router groups can be configured for
the same set of routers, the hosts must be configured for different default gateways, which results in an
extra administrative burden. The advantage of GLBP is that it additionally provides load balancing over
multiple routers (gateways) using a single virtual IP address and multiple virtual MAC addresses. The
forwarding load is shared among all routers in a GLBP group rather than being handled by a single router
while the other routers stand idle. Each host is configured with the same virtual IP address, and all
routers in the virtual router group participate in forwarding packets. GLBP members communicate
between each other through hello messages sent every 3 seconds to the multicast address 224.0.0.102,
User Datagram Protocol (UDP) port 3222 (source and destination).
GLBP Active Virtual Gateway

Members of a GLBP group elect one gateway to be the active virtual gateway (AVG) for that group.
Other group members provide backup for the AVG in the event that the AVG becomes unavailable. The
function of the AVG is that it assigns a virtual MAC address to each member of the GLBP group. Each
gateway assumes responsibility for forwarding packets sent to the virtual MAC address assigned to it by
the AVG. These gateways are known as active virtual forwarders (AVFs) for their virtual MAC address.
The AVG is also responsible for answering Address Resolution Protocol (ARP) requests for the virtual
IP address. Load sharing is achieved by the AVG replying to the ARP requests with different virtual
MAC addresses.

182 78-17478-01
Configuring GLBP
In Figure 8, Router A is the AVG for a GLBP group, and is responsible for the virtual IP address
10.21.8.10. Router A is also an AVF for the virtual MAC address 0007.b400.0101. Router B is a member
of the same GLBP group and is designated as the AVF for the virtual MAC address 0007.b400.0102.
Client 1 has a default gateway IP address of 10.21.8.10 and a gateway MAC address of 0007.b400.0101.
Client 2 shares the same default gateway IP address but receives the gateway MAC address
0007.b400.0102 because Router B is sharing the traffic load with Router A.
Figure 8 GLBP Topology
WAN Link1 WAN Link2
Router A Router B
AVG 1 AVF 1.2
AVF 1.1
Virtual IP address 10.21.8.10
Virtual MAC 0007.b400.0102
Virtual MAC 0007.b400.0101
AVG = active virtual gateway

AVF = active virtual forwarder
Client 1 Client 2
72264
Default gateway: Virtual IP address 10.21.8.10 Virtual IP address 10.21.8.10
Gateway MAC: Virtual MAC 0007.b400.0101 Virtual MAC 0007.b400.0102
If Router A becomes unavailable, Client 1 will not lose access to the WAN because Router B will assume
responsibility for forwarding packets sent to the virtual MAC address of Router A, and for responding
to packets sent to its own virtual MAC address. Router B will also assume the role of the AVG for the
entire GLBP group. Communication for the GLBP members continues despite the failure of a router in
the GLBP group.
GLBP Virtual MAC Address Assignment

A GLBP group allows up to four virtual MAC addresses per group. The AVG is responsible for assigning
the virtual MAC addresses to each member of the group. Other group members request a virtual MAC
address after they discover the AVG through hello messages. Gateways are assigned the next MAC
address in sequence. A virtual forwarder that is assigned a virtual MAC address by the AVG is known
as a primary virtual forwarder. Other members of the GLBP group learn the virtual MAC addresses from
hello messages. A virtual forwarder that has learned the virtual MAC address is referred to as a
secondary virtual forwarder.

78-17478-01 183
Configuring GLBP
GLBP Virtual Gateway Redundancy

GLBP operates virtual gateway redundancy in the same way as HSRP. One gateway is elected as the
AVG, another gateway is elected as the standby virtual gateway, and the remaining gateways are placed
in a listen state.
If an AVG fails, the standby virtual gateway will assume responsibility for the virtual IP address. A new
standby virtual gateway is then elected from the gateways in the listen state.
GLBP Virtual Forwarder Redundancy

Virtual forwarder redundancy is similar to virtual gateway redundancy with an AVF. If the AVF fails,
one of the secondary virtual forwarders in the listen state assumes responsibility for the virtual MAC
address.
The new AVF is also a primary virtual forwarder for a different forwarder number. GLBP migrates hosts
away from the old forwarder number using two timers that start as soon as the gateway changes to the
active virtual forwarder state. GLBP uses the hello messages to communicate the current state of the
timers.
The redirect time is the interval during which the AVG continues to redirect hosts to the old virtual
forwarder MAC address. When the redirect time expires, the AVG stops using the old virtual forwarder
MAC address in ARP replies, although the virtual forwarder will continue to forward packets that were
sent to the old virtual forwarder MAC address.
The secondary holdtime is the interval during which the virtual forwarder is valid. When the secondary
holdtime expires, the virtual forwarder is removed from all gateways in the GLBP group. The expired
virtual forwarder number becomes eligible for reassignment by the AVG.
GLBP Gateway Priority

GLBP gateway priority determines the role that each GLBP gateway plays and what happens if the AVG
fails.
Priority also determines if a GLBP router functions as a backup virtual gateway and the order of
ascendancy to becoming an AVG if the current AVG fails. You can configure the priority of each backup
virtual gateway with a value of 1 through 255 using the glbp priority command.
In Figure 8, if Router A—the AVG in a LAN topology—fails, an election process takes place to
determine which backup virtual gateway should take over. In this example, Router B is the only other
member in the group so it will automatically become the new AVG. If another router existed in the same
GLBP group with a higher priority, then the router with the higher priority would be elected. If both
routers have the same priority, the backup virtual gateway with the higher IP address would be elected
to become the active virtual gateway.
By default, the GLBP virtual gateway preemptive scheme is disabled. A backup virtual gateway can
become the AVG only if the current AVG fails, regardless of the priorities assigned to the virtual
gateways. You can enable the GLBP virtual gateway preemptive scheme using the glbp preempt
command. Preemption allows a backup virtual gateway to become the AVG, if the backup virtual
gateway is assigned a higher priority than the current AVG.

184 78-17478-01
Configuring GLBP
GLBP Gateway Weighting and Tracking

GLBP uses a weighting scheme to determine the forwarding capacity of each router in the GLBP group.
The weighting assigned to a router in the GLBP group can be used to determine whether it will forward
packets and, if so, the proportion of hosts in the LAN for which it will forward packets. Thresholds can
be set to disable forwarding when the weighting falls below a certain value, and when it rises above
another threshold, forwarding is automatically reenabled.
The GLBP group weighting can be automatically adjusted by tracking the state of an interface within the
router. If a tracked interface goes down, the GLBP group weighting is reduced by a specified value.
Different interfaces can be tracked to decrement the GLBP weighting by varying amounts.
By default, the GLBP virtual forwarder preemptive scheme is enabled with a delay of 30 seconds. A
backup virtual forwarder can become the AVF if the current AVF weighting falls below the low
weighting threshold for 30 seconds. You can disable the GLBP forwarder preemptive scheme using the
no glbp forwarder preempt command or change the delay using the glbp forwarder preempt delay
minimum command.
GLBP Benefits
Load Sharing
You can configure GLBP in such a way that traffic from LAN clients can be shared by multiple routers,
thereby sharing the traffic load more equitably among available routers.
Multiple Virtual Routers

GLBP supports up to 1024 virtual routers (GLBP groups) on each physical interface of a router and up
to four virtual forwarders per group.
Preemption
The redundancy scheme of GLBP enables you to preempt an active virtual gateway with a higher priority
backup virtual gateway that has become available. Forwarder preemption works in a similar way, except
that forwarder preemption uses weighting instead of priority and is enabled by default.
Authentication
You can also use the industry-standard message digest 5 (MD5) algorithm for improved reliability,
security, and protection against GLBP-spoofing software. A router within a GLBP group with a different
authentication string than other routers will be ignored by other group members. You can alternatively
use a simple text password authentication scheme between GLBP group members to detect configuration
errors.

78-17478-01 185
Configuring GLBP
How to Configure GLBP

• Customizing GLBP, page 186 (optional)
• Configuring GLBP Authentication, page 188 (optional)
• Configuring GLBP Weighting Values and Object Tracking, page 194 (optional)
• Enabling and Verifying GLBP, page 196 (required)
• Troubleshooting the Gateway Load Balancing Protocol, page 198 (optional)
Customizing GLBP
This task explains how to customize your GLBP configuration.
Customizing the behavior of GLBP is optional. Be aware that as soon as you enable a GLBP group, that
group is operating. It is possible that if you first enable a GLBP group before customizing GLBP, the
router could take over control of the group and become the AVG before you have finished customizing
the feature. Therefore, if you plan to customize GLBP, it is a good idea to do so before enabling GLBP.
SUMMARY STEPS
1. enable
3. interface type number
4. ip address ip-address mask [secondary]
5. glbp group timers [msec] hellotime [msec] holdtime
6. glbp group timers redirect redirect timeout
7. glbp group load-balancing [host-dependent | round-robin | weighted]
8. glbp group priority level
9. glbp group preempt [delay minimum seconds]
10. glbp group name redundancy-name
11. exit

186 78-17478-01
Configuring GLBP
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number Specifies an interface type and number, and enters interface
configuration mode.
Example:
Router(config)# interface fastethernet 0/0
Step 4 ip address ip-address mask [secondary] Specifies a primary or secondary IP address for an interface.
Example:
255.255.255.0
Step 5 glbp group timers [msec] hellotime [msec] Configures the interval between successive hello packets
holdtime sent by the AVG in a GLBP group.
• The holdtime argument specifies the interval in seconds
Example: before the virtual gateway and virtual forwarder
Router(config-if)# glbp 10 timers 5 18 information in the hello packet is considered invalid.
• The optional msec keyword specifies that the following
argument will be expressed in milliseconds, instead of
the default seconds.
Step 6 glbp group timers redirect redirect timeout Configures the time interval during which the AVG
continues to redirect clients to an AVF.
Example: • The timeout argument specifies the interval in seconds
Router(config-if)# glbp 10 timers redirect 600 before a secondary virtual forwarder becomes invalid.
7200
Step 7 glbp group load-balancing [host-dependent | Specifies the method of load balancing used by the GLBP
round-robin | weighted] AVG.
Example:
Router(config-if)# glbp 10 load-balancing
host-dependent
Step 8 glbp group priority level Sets the priority level of the gateway within a GLBP group.
• The default value is 100.
Example:
Router(config-if)# glbp 10 priority 254

78-17478-01 187
Configuring GLBP

Step 9 glbp group preempt [delay minimum seconds] Configures the router to take over as AVG for a GLBP group
if it has a higher priority than the current AVG.
Example: • This command is disabled by default.
Router(config-if)# glbp 10 preempt delay
minimum 60
• Use the optional delay and minimum keywords and the
seconds argument to specify a minimum delay interval
in seconds before preemption of the AVG takes place.
Step 10 glbp group name redundancy-name Enables IP redundancy by assigning a name to the GLBP
group.
Example: • The GLBP redundancy client must be configured with
Router(config-if)# glbp 10 name abcompany the same GLBP group name so the redundancy client
and the GLBP group can be connected.
Note This command is for future use. The GLBP

redundancy client is not yet available.
Step 11 exit Exits interface configuration mode, and returns the router to
global configuration mode.
Example:
Router(config-if)# exit
Configuring GLBP Authentication

The following sections describe configuration tasks for GLBP authentication. The task you perform
depends on whether you want to use text authentication, a simple MD5 key string, or MD5 key chains
for authentication.
• Configuring GLBP MD5 Authentication Using a Key String, page 189
• Configuring GLBP MD5 Authentication Using a Key Chain, page 190
• Configuring GLBP Text Authentication, page 192
How GLBP MD5 Authentication Works

MD5 authentication provides greater security than the alternative plain text authentication scheme. MD5
authentication allows each GLBP group member to use a secret key to generate a keyed MD5 hash that
is part of the outgoing packet. A keyed hash of an incoming packet is generated and, if the hash within
the incoming packet does not match the generated hash, the packet is ignored.
The key for the MD5 hash can either be given directly in the configuration using a key string or supplied
indirectly through a key chain.
A router will ignore incoming GLBP packets from routers that do not have the same authentication
configuration for a GLBP group. GLBP has three authentication schemes:
• No authentication
• Plain text authentication
• MD5 authentication
GLBP packets will be rejected in any of the following cases:

188 78-17478-01
Configuring GLBP
• The authentication schemes differ on the router and in the incoming packet.
• MD5 digests differ on the router and in the incoming packet.
• Text authentication strings differ on the router and in the incoming packet.
Benefits of GLBP MD5 Authentication

• Protects against spoofing software.
• Uses the industry-standard MD5 algorithm for improved reliability and security.
Configuring GLBP MD5 Authentication Using a Key String

Perform this task to configure GLBP MD5 authentication using a key string.
SUMMARY STEPS
1. enable
5. glbp group-number authentication md5 key-string [0 | 7] key
6. glbp group-number ip [ip-address [secondary]]
7. Repeat Steps 1 through 6 on each router that will communicate.
8. end
9. show glbp
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
Router(config)# interface Ethernet0/1
Step 4 ip address ip-address mask [secondary] Specifies a primary or secondary IP address for an
interface.
Example:
Router(config-if)# ip address 10.0.0.1 255.255.255.0

78-17478-01 189
Configuring GLBP
Command Purpose
Step 5 glbp group-number authentication md5 key-string [0 | 7] Configures an authentication key for GLBP MD5
key authentication.
• The number of characters in the command plus
Example: the key string must not exceed 255 characters.
Router(config-if)# glbp 1 authentication md5
key-string d00b4r987654321a • No prefix to the key argument or specifying 0
means the key is unencrypted.
• Specifying 7 means the key is encrypted. The
key-string authentication key will
automatically be encrypted if the service
password-encryption global configuration
command is enabled.
Step 6 glbp group-number ip [ip-address [secondary]] Enables GLBP on an interface and identifies the
primary IP address of the virtual gateway.
Example:
Router(config-if)# glbp 1 ip 10.0.0.10
Step 7 Repeat Steps 1 through 6 on each router that will communicate. —
Step 8 end Returns to privileged EXEC mode.
Example:
Router(config-if)# end
Step 9 show glbp (Optional) Displays GLBP information.
• Use this command to verify your
Example: configuration. The key string and
Router# show glbp authentication type will be displayed if
configured.
Configuring GLBP MD5 Authentication Using a Key Chain

Perform this task to configure GLBP MD5 authentication using a key chain. Key chains allow a different
key string to be used at different times according to the key chain configuration. GLBP will query the
appropriate key chain to obtain the current live key and key ID for the specified key chain.
SUMMARY STEPS
1. enable
3. key chain name-of-chain
4. key key-id
5. key-string string
6. exit
7. exit

190 78-17478-01
Configuring GLBP
10. glbp group-number authentication md5 key-chain name-of-chain

13. end
14. show glbp
15. show key chain
DETAILED STEPS
Command Purpose
Step 1 enable Enables higher privilege levels, such as privileged
EXEC mode.
Example: • Enter your password if prompted.
Router> enable
Example:
Step 3 key chain name-of-chain Enables authentication for routing protocols and
identifies a group of authentication keys.
Example:
Router(config)# key chain glbp2
Step 4 key key-id Identifies an authentication key on a key chain.
• The key-id must be a number.
Example:
Router(config-keychain)# key 100
Step 5 key-string string Specifies the authentication string for a key.
• The string can be 1 to 80 uppercase or
Example: lowercase alphanumeric characters; the first
Router(config-keychain-key)# key-string xmen382 character cannot be a numeral.
Step 6 exit Returns to keychain configuration mode.
Example:
Router(config-keychain-key)# exit
Step 7 exit Returns to global configuration mode.
Example:
Router(config-keychain)# exit
configuration mode.
Example:

78-17478-01 191
Configuring GLBP
Command Purpose
interface.
Example:
Step 10 glbp group-number authentication md5 key-chain Configures an authentication MD5 key chain for
name-of-chain GLBP MD5 authentication.
• The key chain name must match the name
Example: specified in Step 3.
Router(config-if)# glbp 1 authentication md5 key-chain
glbp2
Example:
Step 12 Repeat Steps 1 through 10 on each router that will —
communicate.
Example:
Example: configuration. The key chain and
Router# show glbp authentication type will be displayed if
configured.
Step 15 show key chain (Optional) Displays authentication key
information.
Example:
Router# show key chain
Configuring GLBP Text Authentication

Perform this task to configure GLBP text authentication. This method of authentication provides
minimal security. Use MD5 authentication if security is required.
SUMMARY STEPS
1. enable
5. glbp group-number authentication text string

192 78-17478-01
Configuring GLBP
8. end
9. show glbp
DETAILED STEPS
Command Purpose
EXEC mode.
Router> enable
Example:
configuration mode.
Example:
interface.
Example:
Step 5 glbp group-number authentication text string Authenticates GLBP packets received from other
routers in the group.
Example: • If you configure authentication, all routers
Router(config-if)# glbp 10 authentication text within the GLBP group must use the same
stringxyz authentication string.
Example:
Example:
Example: configuration.
Router# show glbp

78-17478-01 193
Configuring GLBP
Configuring GLBP Weighting Values and Object Tracking

Perform this task to configure GLBP weighting values and object tracking.
GLBP weighting is used to determine whether a router can act as a virtual forwarder. Initial weighting
values can be set and optional thresholds specified. Interface states can be tracked and a decrement value
set to reduce the weighting value if the interface goes down. When the GLBP router weighting drops
below a specified value, the router will no longer be an active virtual forwarder. When the weighting
rises above a specified value, the router can resume its role as an active virtual forwarder.
SUMMARY STEPS
1. enable
3. track object-number interface type number {line-protocol | ip routing}
4. exit
6. glbp group weighting maximum [lower lower] [upper upper]
7. glbp group weighting track object-number [decrement value]
8. glbp group forwarder preempt [delay minimum seconds]
9. end
10. show track [object-number | brief] [interface [brief] | ip route [brief] | resolution | timers]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track object-number interface type number Configures an interface to be tracked where changes in the
{line-protocol | ip routing} state of the interface affect the weighting of a GLBP
gateway, and enters tracking configuration mode.
Example: • This command configures the interface and
Router(config)# track 2 interface POS 6/0 ip corresponding object number to be used with the glbp
routing
weighting track command.
• The line-protocol keyword tracks whether the interface
is up. The ip routing keywords also check that IP
routing is enabled on the interface, and an IP address is
configured.

194 78-17478-01
Configuring GLBP

Example:
Router(config-track)# exit
Step 5 interface type number Enters interface configuration mode.
Example:
Step 6 glbp group weighting maximum [lower lower] Specifies the initial weighting value, and the upper and
[upper upper] lower thresholds, for a GLBP gateway.
Example:
Router(config-if)# glbp 10 weighting 110 lower
95 upper 105
Step 7 glbp group weighting track object-number Specifies an object to be tracked that affects the weighting
[decrement value] of a GLBP gateway.
• The value argument specifies a reduction in the
Example: weighting of a GLBP gateway when a tracked object
Router(config-if)# glbp 10 weighting track 2 fails.
decrement 5
Step 8 glbp group forwarder preempt [delay minimum Configures the router to take over as AVF for a GLBP group
seconds] if the current AVF for a GLBP group falls below its low
weighting threshold.
Example: • This command is enabled by default with a delay of
Router(config-if)# glbp 10 forwarder preempt 30 seconds.
delay minimum 60
• Use the optional delay and minimum keywords and the
seconds argument to specify a minimum delay interval
in seconds before preemption of the AVF takes place.
Example:
Step 10 show track [object-number | brief] [interface Displays tracking information.
[brief]| ip route [brief] | resolution |
timers]
Example:
Router# show track 2

78-17478-01 195
Configuring GLBP
Enabling and Verifying GLBP

This task explains how to enable GLBP on an interface and verify its configuration and operation. GLBP
is designed to be easy to configure. Each gateway in a GLBP group must be configured with the same
group number, and at least one gateway in the GLBP group must be configured with the virtual IP
address to be used by the group. All other required parameters can be learned.
Prerequisites
If VLANs are in use on an interface, the GLBP group number must be different for each VLAN.
SUMMARY STEPS
1. enable
5. glbp group ip [ip-address [secondary]]
6. exit
7. show glbp [interface-type interface-number] [group] [state] [brief]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number Specifies an interface type and number, and enters interface
configuration mode.
Example:
Example:
255.255.255.0

196 78-17478-01
Configuring GLBP

Step 5 glbp group ip [ip-address [secondary]] Enables GLBP on an interface and identifies the primary IP
address of the virtual gateway.
Example: • After you identify a primary IP address, you can use the
Router(config-if)# glbp 10 ip 10.21.8.10 glbp group ip command again with the secondary
keyword to indicate additional IP addresses supported
by this group.
Step 6 exit Exits interface configuration mode, and returns the router to
global configuration mode.
Example:
Step 7 show glbp [interface-type interface-number] (Optional) Displays information about GLBP groups on a
[group] [state] [brief] router.
• Use the optional brief keyword to display a single line
Example: of information about each virtual gateway or virtual
Router(config)# show glbp 10 forwarder.
• See the display output for this command in the
“Examples” section of this task.
Examples
In the following example, output information is displayed about the status of the GLBP group, named
10, on the router:
Router# show glbp 10
FastEthernet0/0 - Group 10
State is Active
2 state changes, last state change 23:50:33
Virtual IP address is 10.21.8.10
Hello time 5 sec, hold time 18 sec
Next hello sent in 4.300 secs
Redirect time 600 sec, forwarder time-out 7200 sec
Authentication text "stringabc"
Preemption enabled, min delay 60 sec
Active is local
Standby is unknown
Priority 254 (configured)
Weighting 105 (configured 110), thresholds: lower 95, upper 105
Track object 2 state Down decrement 5
Load balancing: host-dependent
There is 1 forwarder (1 active)
Forwarder 1
State is Active
1 state change, last state change 23:50:15
MAC address is 0007.b400.0101 (default)
Owner ID is 0005.0050.6c08
Redirection enabled
Preemption enabled, min delay 60 sec
Active is local, weighting 105

78-17478-01 197
Configuring GLBP
Troubleshooting the Gateway Load Balancing Protocol

The Gateway Load Balancing Protocol feature introduces five privileged EXEC mode commands to
enable diagnostic output concerning various events relating to the operation of GLBP to be displayed on
a console. The debug condition glbp, debug glbp errors, debug glbp events, debug glbp packets, and
debug glbp terse commands are intended only for troubleshooting purposes because the volume of
output generated by the software can result in severe performance degradation on the router. Perform this
task to minimize the impact of using the debug glbp commands.
This procedure will minimize the load on the router created by the debug condition glbp or debug glbp
commands because the console port is no longer generating character-by-character processor interrupts.
If you cannot connect to a console directly, you can run this procedure via a terminal server. If you must
break the Telnet connection, however, you may not be able to reconnect because the router may be unable
to respond due to the processor load of generating the debugging output.
Prerequisites
This task requires a router running GLBP to be attached directly to a console.
SUMMARY STEPS
1. enable
3. no logging console
4. Use Telnet to access a router port and repeat Steps 1 and 2.
5. end
6. terminal monitor
7. debug condition glbp interface-type interface-number group [forwarder]
8. terminal no monitor
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 no logging console Disables all logging to the console terminal.
• To reenable logging to the console, use the
Example: logging console command in global configuration
Router(config)# no logging console
mode.

198 78-17478-01
Configuring GLBP
Configuration Examples for GLBP

Step 4 Use Telnet to access a router port and repeat Enters global configuration mode in a recursive Telnet
Steps 1 and 2. session, which allows the output to be redirected away from
the console port.
Step 5 end Exits to privileged EXEC mode.
Example:
Router(config)# end
Step 6 terminal monitor Enables logging output on the virtual terminal.
Example:
Router# terminal monitor
Step 7 debug condition glbp interface-type Displays debugging messages about GLBP conditions.
interface-number group [forwarder]
• Try to enter only specific debug condition glbp or
debug glbp commands to isolate the output to a certain
Example: subcomponent and minimize the load on the processor.
Router# debug condition glbp fastethernet
0/0 10 1 Use appropriate arguments and keywords to generate
more detailed debug information on specified
subcomponents.
• Enter the specific no debug condition glbp or no debug
glbp command when you are finished.
Step 8 terminal no monitor Disables logging on the virtual terminal.
Example:
Router# terminal no monitor

This section contains the following configuration examples:
• Customizing GLBP Configuration: Example, page 199
• GLBP MD5 Authentication Using Key Strings: Example, page 200
• GLBP MD5 Authentication Using Key Chains: Example, page 200
• GLBP Text Authentication: Example, page 200
• GLBP Weighting: Example, page 200
• Enabling GLBP Configuration: Example, page 201
Customizing GLBP Configuration: Example

In the following example, Router A, shown in Figure 1, is configured with a number of GLBP
commands:
interface fastethernet 0/0
ip address 10.21.8.32 255.255.255.0
glbp 10 timers 5 18
glbp 10 timers redirect 600 7200
glbp 10 load-balancing host-dependent

78-17478-01 199
Configuring GLBP
glbp 10 priority 254

glbp 10 preempt delay minimum 60
GLBP MD5 Authentication Using Key Strings: Example

The following example configures GLBP MD5 authentication using a key string:
!
ip address 10.0.0.1 255.255.255.0
glbp 2 authentication md5 key-string ThisStringIsTheSecretKey
glbp 2 ip 10.0.0.10
GLBP MD5 Authentication Using Key Chains: Example

In the following example, GLBP queries the key chain “AuthenticateGLBP” to obtain the current live
key and key ID for the specified key chain:
key chain AuthenticateGLBP
key 1
key-string ThisIsASecretKey
ip address 10.0.0.1 255.255.255.0
glbp 2 authentication md5 key-chain AuthenticateGLBP
glbp 2 ip 10.0.0.10
GLBP Text Authentication: Example

The following example configures GLBP text authentication using a text string:
ip address 10.21.8.32 255.255.255.0
glbp 10 authentication text stringxyz
glbp 10 ip 10.21.8.10
GLBP Weighting: Example

In the following example, Router A, shown in Figure 1, is configured to track the IP routing state of the
POS interface 5/0 and 6/0, an initial GLBP weighting with upper and lower thresholds is set, and a
weighting decrement value of 10 is set. If POS interface 5/0 and 6/0 goes down, the weighting value of
the router is reduced.
track 1 interface POS 5/0 ip routing
track 2 interface POS 6/0 ip routing
glpb 10 weighting 110 lower 95 upper 105
glbp 10 weighting track 1 decrement 10
glbp 10 weighting track 2 decrement 10
glbp 10 forwarder preempt delay minimum 60

200 78-17478-01
Configuring GLBP
Enabling GLBP Configuration: Example

In the following example, Router A, shown in Figure 1, is configured to enable GLBP, and the virtual IP
address of 10.21.8.10 is specified for GLBP group 10:
ip address 10.21.8.32 255.255.255.0
glbp 10 ip 10.21.8.10
For following sections provide references related to GLBP.
Related Documents
GLBP commands: complete command syntax, Cisco IOS IP Application Services Command Reference,
command mode, command history, defaults, usage Release 12.4
Key chains and key management commands: complete Cisco IOS IP Routing Command Reference, Release 12.4
command syntax, command mode, command history,
defaults, usage guidelines, and examples
Object Tracking “ Configuring Enhanced Object Tracking” configuration module
VRRP “Configuring VRRP” configuration module
HSRP “Configuring HSRP” configuration module
Standards
Standards Title
MIBs
MIBs MIBs Link
No new MIBs are supported by this feature, and To locate and download MIBs for selected platforms, Cisco IOS
support for existing MIBs has not been modified by this releases, and feature sets, use Cisco MIB Locator found at the
feature. following URL:

78-17478-01 201
Configuring GLBP
RFCs
RFCs Title
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.

202 78-17478-01
Configuring GLBP
Glossary
Glossary
AVF—active virtual forwarder. One virtual forwarder within a GLBP group is elected as active virtual
forwarder for a specified virtual MAC address, and is responsible for forwarding packets sent to that
MAC address. Multiple active virtual forwarders can exist for each GLBP group.
AVG—active virtual gateway. One virtual gateway within a GLBP group is elected as the active virtual
gateway, and is responsible for the operation of the protocol.
GLBP gateway—Gateway Load Balancing Protocol gateway. A router or gateway running GLBP. Each
GLBP gateway may participate in one or more GLBP groups.
GLBP group—Gateway Load Balancing Protocol group. One or more GLBP gateways configured with
the same GLBP group number on connected Ethernet interfaces.
vIP—virtual IP address. An IPv4 address. There must be only one virtual IP address for each configured
GLBP group. The virtual IP address must be configured on at least one GLBP group member. Other
GLBP group members can learn the virtual IP address from hello messages.
Note Refer to the Internetworking Terms and Acronyms for terms not included in this glossary.
Feature Information for GLBP

Table 10 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Release 12.2(1) or Cisco IOS
Releases 12.2(14)S or a later release appear in the table.
Not all commands may be available in your Cisco IOS software release. For details on when support for
a specific command was introduced, see the command reference documentation.
For information on a feature in this technology that is not documented here, see the “FHRP Features
Roadmap”.

78-17478-01 203
Configuring GLBP
Feature Information for GLBP
Table 10 Feature Information for GLBP
Feature Name Releases Feature Configuration Information

Gateway Load Balancing Protocol 12.2(14)S GLBP protects data traffic from a failed router or circuit,
12.2(15)T like HSRP and VRRP, while allowing packet load sharing
All sections in this configuration module provide
information about this feature.
GLBP MD5 Authentication 12.2(18)S MD5 authentication provides greater security than the
12.3(2)T alternative plain text authentication scheme. MD5
authentication allows each GLBP group member to use a
secret key to generate a keyed MD5 hash that is part of the
outgoing packet. A keyed hash of an incoming packet is
generated and, if the hash within the incoming packet does
not match the generated hash, the packet is ignored.
The following section provides information about this
feature:
• Configuring GLBP Authentication, page 188
The following commands were modified by this feature:
glbp authentication and show glbp.

204 78-17478-01
Configuring HSRP
The Hot Standby Router Protocol (HSRP) is a first-hop redundancy protocol (FHRP) designed to allow
for transparent fail-over of the first-hop IP router. HSRP provides high network availability by providing
first-hop routing redundancy for IP hosts on Ethernet, Fiber Distributed Data Interface (FDDI),
Bridge-Group Virtual Interface (BVI), LAN Emulation (LANE), or Token Ring networks configured
with a default gateway IP address. HSRP is used in a group of routers for selecting an active router and
a standby router. In a group of router interfaces, the active router is the router of choice for routing
packets; the standby router is the router that takes over when the active router fails or when preset
conditions are met.
Module History
This module was first published on May 2, 2005, and last updated on February 12, 2006.

Not all features may be supported in your Cisco IOS software release. Use the “Feature Information for
HSRP” section on page 252 to find information about feature support and configuration.
Contents
• Restrictions for Configuring HSRP, page 205
• Information About HSRP, page 206
• How to Configure HSRP, page 210
• Configuration Examples for HSRP, page 244
• Feature Information for HSRP, page 252
Restrictions for Configuring HSRP

HSRP is designed for use over multiaccess, multicast, or broadcast capable Ethernet LANs. HSRP is not
intended as a replacement for existing dynamic protocols.
HSRP is configurable on Ethernet, FDDI, BVI, LANE, or Token Ring interfaces. Token Ring interfaces
allow up to three Hot Standby groups each, the group numbers being 0, 1, and 2.

78-17478-01 205
Configuring HSRP
Information About HSRP
The Cisco 2500 series, Cisco 3000 series, Cisco 4000 series, and Cisco 4500 routers that use Lance
Ethernet hardware do not support multiple Hot Standby groups on a single Ethernet interface. The
Cisco 800 series and Cisco 1600 series that use PQUICC Ethernet hardware do not support multiple Hot
Standby groups on a single Ethernet interface. You can configure a workaround solution by using the
standby use-bia interface configuration command, which uses the burned-in address of the interface as
its virtual MAC address, instead of the preassigned MAC address.

To configure HSRP, you should understand the following concepts:
• HSRP Operation, page 206
• HSRP Benefits, page 207
• HSRP Terminology, page 208
• HSRP Groups and Group Attributes, page 208
• HSRP Addressing, page 208
• HSRP Messages and States, page 209
• HSRP and ARP, page 209
• HSRP Object Tracking, page 210
• HSRP Support for MPLS VPNs, page 210
HSRP Operation
Most IP hosts have an IP address of a single router configured as the default gateway. When HSRP is
used, the HSRP virtual IP address is configured as the host’s default gateway instead of the IP address
of the router.
HSRP is useful for hosts that do not support a router discovery protocol (such as ICMP Router Discovery
Protocol [IRDP]) and cannot switch to a new router when their selected router reloads or loses power.
Because existing TCP sessions can survive the failover, this protocol also provides a more transparent
recovery for hosts that dynamically choose a next hop for routing IP traffic.
When HSRP is configured on a network segment, it provides a virtual MAC address and an IP address
that is shared among a group of routers running HSRP. The address of this HSRP group is referred to as
the virtual IP address. One of these devices is selected by the protocol to be the active router. The active
router receives and routes packets destined for the MAC address of the group. For n routers running
HSRP, n + 1 IP and MAC addresses are assigned.
HSRP detects when the designated active router fails, at which point a selected standby router assumes
control of the MAC and IP addresses of the Hot Standby group. A new standby router is also selected at
that time.
HSRP uses a priority mechanism to determine which HSRP configured router is to be the default active
router. To configure a router as the active router, you assign it a priority that is higher than the priority
of all the other HSRP-configured routers. The default priority is 100, so if you configure just one router
to have a higher priority, that router will be the default active router.

206 78-17478-01
Configuring HSRP
Devices that are running HSRP send and receive multicast User Datagram Protocol (UDP)-based hello
messages to detect router failure and to designate active and standby routers. When the active router fails
to send a hello message within a configurable period of time, the standby router with the highest priority
becomes the active router. The transition of packet forwarding functions between routers is completely
transparent to all hosts on the network.
You can configure multiple Hot Standby groups on an interface, thereby making fuller use of redundant
routers and load sharing.
Figure 9 shows a network configured for HSRP. By sharing a virtual MAC address and IP address, two
or more routers can act as a single virtual router. The virtual router does not physically exist but
represents the common default gateway for routers that are configured to provide backup to each other.
You do not need to configure the hosts on the LAN with the IP address of the active router. Instead, you
configure them with the IP address (virtual IP address) of the virtual router as their default gateway. If
the active router fails to send a hello message within the configurable period of time, the standby router
takes over and responds to the virtual addresses and becomes the active router, assuming the active router
duties.
Figure 9 HSRP Topology
Internet or
ISP backbone
Active 172.30.128.1 Virtual 172.30.128.3 Standby 172.30.128.2

router router router
LAN
127024
Host A Host B Host C Host D
HSRP is supported over Inter-Switch Link (ISL) encapsulation. Refer to the “Configuring Routing
Between VLANs with ISL Encapsulation” chapter in the Cisco IOS Switching Services Configuration
Guide, Release 12.2.
HSRP Benefits
Redundancy
HSRP employs a redundancy scheme that is time proven and deployed extensively in large networks.
Fast Failover
HSRP provides transparent fast failover of the first-hop router.

78-17478-01 207
Configuring HSRP
Preemption
Preemption allows a standby router to delay becoming active for a configurable amount of time.
Authentication
HSRP message digest 5 (MD5) algorithm authentication protects against HSRP-spoofing software and
uses the industry-standard MD5 algorithm for improved reliability and security.
HSRP Terminology
active router—The primary router in an HSRP group that is currently forwarding packets for the virtual
router.
standby group—The set of routers participating in HSRP that represent a virtual router.
standby router—The primary backup router.
virtual IP address—The IP address assigned to the virtual router that is used as the default gateway by
the IP hosts on the LAN.
virtual MAC address—For Ethernet and FDDI, the automatically generated MAC address when HSRP
is configured. The standard virtual MAC address used is: 0000.0C07.ACxy, where xy is the group
number in hexadecimal. The functional address is used for Token Ring. The virtual MAC address is
different for HSRP version 2.
HSRP Groups and Group Attributes

By using the command-line interface (CLI), group attributes can be applied to:
• A single HSRP group—performed in interface configuration mode and applies to a group.
• All groups on the interface—performed in interface configuration mode and applies to all groups on
the interface.
• All groups on all interfaces—performed in global configuration mode and applies to all groups on
all interfaces.
HSRP Addressing
HSRP routers communicate between each other by exchanging HSRP hello packets. These packets are
sent to the destination IP multicast address 224.0.0.2 (reserved multicast address used to communicate
to all routers) on UDP port 1985. The active router sources hello packets from its configured IP address
and the HSRP virtual MAC address while the standby router sources hellos from its configured IP
address and the interface MAC address, which may or may not be the Burned-In MAC address (BIA).
Because hosts are configured with their default gateway as the HSRP virtual IP address, hosts must
communicate with the MAC address associated with the HSRP virtual IP address. This MAC address
will be a virtual MAC address composed of 0000.0C07.ACxy, where xy is the HSRP group number in
hexadecimal based on the respective interface. For example, HSRP group one will use the HSRP virtual
MAC address of 0000.0C07.AC01. Hosts on the adjoining LAN segment use the normal Address
Resolution Protocol (ARP) process to resolve the associated MAC addresses.

208 78-17478-01
Configuring HSRP
Token Ring interfaces use functional addresses for the HSRP MAC address. Functional addresses are the
only general multicast mechanism available. There are a limited number of Token Ring functional
addresses available, and many of them are reserved for other functions. The following are the only three
addresses available for use with HSRP:
• c000.0001.0000 (group 0)
• c000.0002.0000 (group 1)
• c000.0004.0000 (group 2)
Thus, only three HSRP groups may be configured on Token Ring interfaces unless the standby use-bia
interface configuration command is configured.
HSRP version 2 uses the new IP multicast address 224.0.0.102 to send hello packets instead of the
multicast address of 224.0.0.2, which is used by version 1. This new multicast address allows Cisco
Group Management Protocol (CGMP) leave processing to be enabled at the same time as HSRP.
HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC
address range 0000.0C9F.F000 to 0000.0C9F.FFFF.
HSRP Messages and States

Routers configured with HSRP exchange three types of multicast messages:
• Hello—The hello message conveys to other HSRP routers the HSRP priority and state information
of the router.
• Coup—When a standby router wants to assume the function of the active router, it sends a coup
message.
• Resign—A router that is the active router sends this message when it is about to shut down or when
a router that has a higher priority sends a hello or coup message.
At any time, a router configured with HSRP is in one of the following states:
• Active—The router is performing packet-transfer functions.
• Standby—The router is prepared to assume packet-transfer functions if the active router fails.
• Speak—The router is sending and receiving hello messages.
• Listen—The router is receiving hello messages.
HSRP and ARP

HSRP also works when the hosts are configured for proxy ARP. When the active HSRP router receives
an ARP request for a host that is not on the local LAN, the router replies with the MAC address of the
virtual router. If the active router becomes unavailable or its connection to the remote LAN goes down,
the router that becomes the active router receives packets addressed to the virtual router and transfers
them accordingly. If the Hot Standby state of the interface is not active, proxy ARP responses are
suppressed.

78-17478-01 209
Configuring HSRP
How to Configure HSRP
HSRP Object Tracking

Object tracking separates the tracking mechanism from HSRP and creates a separate standalone tracking
process that can be used by any other process as well as HSRP. The priority of a device can change
dynamically when it has been configured for object tracking and the object that is being tracked goes
down. Examples of objects that can be tracked are the line protocol state of an interface or the
reachability of an IP route. If the specified object goes down, the HSRP priority is reduced.
A client process, such as HSRP, Virtual Router Redundancy Protocol (VRRP), or Gateway Load
Balancing Protocol (GLBP), can now register its interest in tracking objects and then be notified when
the tracked object changes state.
HSRP Support for MPLS VPNs

HSRP support for a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) interface is
useful when an Ethernet LAN is connected between two provider edge (PE) routers with either of the
following conditions:
• A customer edge (CE) router with a default route to the HSRP virtual IP address
• One or more hosts with the HSRP virtual IP address configured as the default gateway
Each VPN is associated with one or more VPN routing/forwarding (VRF) instances. A VRF consists of
the following elements:
• IP routing table
• Cisco Express Forwarding (CEF) table
• Set of interfaces that use the CEF forwarding table
• Set of rules and routing protocol parameters to control the information in the routing tables
VPN routing information is stored in the IP routing table and the CEF table for each VRF. A separate set
of routing and CEF tables is maintained for each VRF. These tables prevent information from being
forwarded outside a VPN and also prevent packets that are outside a VPN from being forwarded to a
router within the VPN.
HSRP adds ARP entries and IP hash table entries (aliases) using the default routing table instance.
However, a different routing table instance is used when VRF forwarding is configured on an interface,
causing ARP and ICMP echo requests for the HSRP virtual IP address to fail.
HSRP support for MPLS VPNs ensures that the HSRP virtual IP address is added to the correct IP
routing table and not to the default routing table.

• Enabling HSRP, page 211 (required)
• Delaying the Initialization of HSRP on an Interface, page 213 (optional)
• Configuring HSRP Priority and Preemption, page 215 (required)
• Configuring HSRP Object Tracking, page 217 (optional)
• Configuring HSRP Authentication, page 219 (optional)
• Customizing HSRP, page 227 (optional)

210 78-17478-01
Configuring HSRP
• Configuring Multiple HSRP Groups for Load Balancing, page 229 (optional)
• Enabling HSRP Support for ICMP Redirects, page 231 (optional)
• Configuring HSRP Virtual MAC Addresses or BIA MAC Addresses, page 234 (optional)
• Linking IP Redundancy Clients to HSRP Groups, page 236 (optional)
• Changing to HSRP Version 2, page 237 (optional)
• Configuring SSO-Aware HSRP (Cisco IOS Release 12.2(25)S), page 239 (optional)
• Enabling HSRP MIB Traps, page 243 (optional)
Enabling HSRP
Perform this task to enable HSRP.
The standby ip interface configuration command activates HSRP on the configured interface. If an IP
address is specified, that address is used as the virtual IP address for the Hot Standby group. For HSRP
to elect a designated router, you must configure the virtual IP address for at least one of the routers in
the group; it can be learned on the other routers in the group.
Prerequisites
You can configure many attributes in HSRP such as authentication, timers, priority, and preemption. It
is best practice to configure the attributes first before enabling the HSRP group.
This practice avoids authentication error messages and unexpected state changes in other routers that can
occur if the group is enabled first and then there is a long enough delay (one or two hold times) before
the other configuration is entered.
We recommend that you always specify an HSRP IP address.
SUMMARY STEPS
1. enable
4. ip address ip-address mask
5. standby [group-number] ip [ip-address [secondary]]
6. end
7. show standby [all] [brief]
8. show standby type number [group-number | all] [brief]

78-17478-01 211
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 ip address ip-address mask Configures an IP address for an interface.
Example:
255.255.255.0
Step 5 standby [group-number] ip [ip-address Activates HSRP.
[secondary]]
• If you do not configure a group number, it defaults to 0.
The group number range is from 0 to 255 for HSRP
Example: version 1 and from 0 to 4095 for HSRP version 2.
Router(config-if)# standby 1 ip 172.16.6.100
• The ip-address is the virtual IP address of the virtual
router. For HSRP to elect a designated router, you must
configure the virtual IP address for at least one of the
routers in the group; it can be learned on the other
Example:
Step 7 show standby [all] [brief] (Optional) Displays HSRP information.
• This command displays information for each group.
Example: The all option display groups that are learned or that do
Router# show standby not have the standby ip command configured.
Step 8 show standby type number [group-number | all] (Optional) Displays HSRP information about specific
[brief] groups or interfaces.
Example:
Router# show standby ethernet 0

212 78-17478-01
Configuring HSRP
Delaying the Initialization of HSRP on an Interface

Perform this task to delay the initialization of HSRP on an interface.
The standby delay command is used to delay HSRP initialization either after a reload and/or after an
interface comes up. This configuration allows the interface and router time to settle down after the
interface up event and helps prevent HSRP state flapping.
SUMMARY STEPS
1. enable
5. standby delay minimum min-delay reload min-delay
7. end
8. show standby delay [type number]
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 ip address ip-address mask Specifies an IP address for an interface.
Example:
255.255.255.0

78-17478-01 213
Configuring HSRP

Step 5 standby delay minimum min-delay reload (Optional) Configures the delay period before the
reload-delay initialization of HSRP groups.
• The min-delay value is the minimum time (in seconds)
Example: to delay HSRP group initialization after an interface
Router(config-if)# standby delay minimum 20 comes up. This minimum delay period applies to all
reload 25
subsequent interface events.
• The reload-delay value is the time period to delay after
the router has reloaded. This delay period applies only
to the first interface-up event after the router has
reloaded.
[secondary]]
Example:
255.255.255.0
Example:
Step 8 show standby delay [type number] (Optional) Displays HSRP information about delay periods.
Example:
Router# show standby delay

214 78-17478-01
Configuring HSRP
We recommend that you use the standby delay minimum reload command if the standby timers
command is configured in milliseconds or if HSRP is configured on a VLAN interface of a switch.
Configuring HSRP Priority and Preemption

Perform this task to configure HSRP priority and preemption.
HSRP Priority and Preemption

Preemption enables the HSRP router with the highest priority to immediately become the active router.
Priority is determined first by the configured priority value, and then by the IP address. In case of ties,
the primary IP addresses are compared, and the higher IP address has priority. In each case, a higher
value is of greater priority. If you do not use the standby preempt interface configuration command in
the configuration for a router, that router will not become the active router, even if its priority is higher
than all other routers.
A standby router with equal priority but a higher IP address will not preempt the active router.
When a router first comes up, it does not have a complete routing table. You can set a preemption delay
that allows preemption to be delayed for a configurable time period. This delay period allows the router
to populate its routing table before becoming the active router.
How Object Tracking Affects the Priority of an HSRP Router

The priority of a device can change dynamically if it has been configured for object tracking and the
object that is being tracked goes down. The tracking process periodically polls the tracked objects and
notes any change of value. The changes in the tracked object are communicated to HSRP, either
immediately or after a specified delay. The object values are reported as either up or down. Examples of
objects that can be tracked are the line protocol state of an interface or the reachability of an IP route. If
the specified object goes down, the HSRP priority is reduced. The HSRP router with the higher priority
can now become the active router if it has the standby preempt command configured. See the
“Configuring HSRP Object Tracking” section on page 217 for more information on object tracking.
SUMMARY STEPS
1. enable
5. standby [group-number] priority priority
6. standby [group-number] preempt [delay {minimum delay | reload delay | sync delay}]
8. end
9. show standby [all] [brief]
10. show standby type number [group-number | all] [brief]

78-17478-01 215
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
255.255.255.0
Step 5 standby [group-number] priority priority Configures HSRP priority.
• The default priority is 100.
Example:
Router(config-if)# standby 1 priority 110
Step 6 standby [group-number] preempt [delay {minimum Configures HSRP preemption and preemption delay.
delay | reload delay | sync delay}]
• The default delay period is 0 seconds; if the router
wants to preempt, it will do so immediately. By default,
Example: the router that comes up later becomes the standby.
Router(config-if)# standby 1 preempt delay
minimum 380
[secondary]]
Example:
255.255.255.0
Example:

216 78-17478-01
Configuring HSRP

Step 9 show standby [all] [brief] (Optional) Displays HSRP information.
• This command displays information for each group.
Example: The all option display groups that are learned or that do
Router# show standby not have the standby ip command configured.
Step 10 show standby type number [group-number | all] (Optional) Displays HSRP information about specific
[brief] groups or interfaces.
Example:
Router# show standby ethernet 0/1
Configuring HSRP Object Tracking

Perform this task to configure HSRP to track an object and change the HSRP priority based on the state
of the object.
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.
For more information on object tracking, see the “Configuring Enhanced Object Tracking” configuration
module.
SUMMARY STEPS
1. enable
4. exit
6. standby [group-number] track object-number [decrement priority-decrement]
8. end
9. show track [object-number | brief] [interface [brief] | ip route [brief] | resolution | timers]

78-17478-01 217
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track object-number interface type number Configures an interface to be tracked and enters tracking
{line-protocol | ip routing} configuration mode.
Example:
Router(config)# track 100 interface serial2/0
line-protocol
Example:
Router(config-track)# exit
configuration mode.
Example:
Step 6 standby [group-number] track object-number Configures HSRP to track an object and change the Hot
[decrement priority-decrement] Standby priority on the basis of the state of the object.
• By default, the priority of the router is decreased by 10
Example: if a tracked object goes down. Use the decrement
Router(config-if)# standby 1 track 100 priority-decrement keyword and argument combination
decrement 20
to change the default behavior.
• When multiple tracked objects are down and
priority-decrement values have been configured, these
configured priority decrements are cumulative. If
tracked objects are down, but none of them were
configured with priority decrements, the default
decrement is 10 and it is cumulative.
[secondary]]
• The default group number is 0. The group number
range is from 0 to 255 for HSRP version 1 and from 0
Example: to 4095 for HSRP version 2.

218 78-17478-01
Configuring HSRP

Example:
Step 9 show track [object-number | brief] [interface Displays tracking information.
[brief]| ip route [brief]| resolution | timers]
Example:
Router# show track 100 interface
Configuring HSRP Authentication

HSRP ignores unauthenticated HSRP protocol messages. The default authentication type is text
authentication.
The following sections describe configuration tasks for HSRP authentication. The task you perform
for authentication.
• Configuring HSRP MD5 Authentication Using a Key String, page 220
• Configuring HSRP MD5 Authentication Using a Key Chain, page 222
• Troubleshooting HSRP MD5 Authentication, page 224
• Configuring HSRP Text Authentication, page 225
How HSRP MD5 Authentication Works

Before the introduction of HSRP MD5 authentication, HSRP authenticated protocol packets with a
simple plain text string. HSRP MD5 authentication is an enhancement to generate an MD5 digest for the
HSRP portion of the multicast HSRP protocol packet. This functionality provides added security and
protects against the threat from HSRP-spoofing software.
authentication allows each HSRP group member to use a secret key to generate a keyed MD5 hash that
is part of the outgoing packet. A keyed hash of an incoming packet is generated and if the hash within
the incoming packet does not match the generated hash, the packet is ignored.
The key for the MD5 hash can be either given directly in the configuration using a key string or supplied
HSRP has two authentication schemes:
HSRP authentication protects against false HSRP hello packets causing a denial-of-service attack. For
example, Router A has a priority of 120 and is the active router. If a host sends spoof HSRP hello packets
with a priority of 130, then Router A stops being the active router. If Router A has authentication
configured such that the spoof HSRP hello packets are ignored, Router A will remain the active router.
HSRP packets will be rejected in any of the following cases:
• The authentication schemes differ on the router and in the incoming packets.

78-17478-01 219
Configuring HSRP

Benefits of HSRP MD5 Authentication

• Protects against HSRP-spoofing software
• Uses the industry-standard MD5 algorithm for improved reliability and security
Restrictions
Text authentication cannot be combined with MD5 authentication for an HSRP group at any one time.
When MD5 authentication is configured, the text authentication field in HSRP hello messages is set to
all zeroes on transmit and ignored on receipt, provided the receiving router also has MD5 authentication
enabled.
Configuring HSRP MD5 Authentication Using a Key String

Perform this task to configure HSRP MD5 authentication using a key string.
SUMMARY STEPS
1. enable
7. standby [group-number] authentication md5 key-string [0 | 7] key [timeout seconds]
10. end
11. show standby

220 78-17478-01
Configuring HSRP
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
configuration mode.
Example:
interface.
Example:
Example:
Step 6 standby [group-number] preempt [delay {minimum delay | Configures HSRP preemption.
reload delay | sync delay}]
Example:
Router(config-if)# standby 1 preempt
Step 7 standby [group-number] authentication md5 key-string Configures an authentication string for HSRP MD5
[0 | 7] key [timeout seconds] authentication.
• The key argument can be up to 64 characters in
Example: length and it is recommended that at least 16
Router(config-if)# standby 1 authentication md5 characters be used.
key-string d00b4r987654321a timeout 30
• No prefix to the key argument or specifying 0
means the key will be unencrypted.
• Specifying 7 means the key will be encrypted.
The key-string authentication key will
command is enabled.
• The timeout value is the period of time that the
old key string will be accepted to allow
configuration of all routers in a group with a
new key.

78-17478-01 221
Configuring HSRP
Command Purpose
Step 8 standby [group-number] ip [ip-address [secondary]] Activates HSRP.
Example:
Example:
Step 11 show standby (Optional) Displays HSRP information.
Example: configuration. The key string or key chain will
Router# show standby be displayed if configured.
If you are changing a key string in a group of routers, change the active router last to prevent any HSRP
state change. The active router should have its key string changed no later than one holdtime period,
specified by the standby timers interface configuration command, after the non-active routers. This
procedure ensures that the non-active routers do not time out the active router.
Configuring HSRP MD5 Authentication Using a Key Chain

Perform this task to configure HSRP MD5 authentication using a key chain. Key chains allow a different
key string to be used at different times according to the key chain configuration. HSRP will query the
SUMMARY STEPS
1. enable
4. key key-id
6. exit
11. standby [group-number] authentication md5 key-chain key-chain-name

222 78-17478-01
Configuring HSRP
14. end
15. show standby
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Example:
Router(config)# key chain hsrp1
Example:
Router(config-keychain-key)# key-string mno172 character cannot be a number.
Example:
configuration mode.
Example:
interface.
Example:
Example:

78-17478-01 223
Configuring HSRP
Command Purpose
Example:
Step 11 standby [group-number] authentication md5 Configures an authentication MD5 key chain for
key-chain key-chain-name HSRP MD5 authentication.
• The key chain name must match the name
Example: specified in Step 3.
Router(config-if)# standby 1 authentication md5
key-chain hsrp1
Example:
communicate.
Example:
Troubleshooting HSRP MD5 Authentication

Perform this task if HSRP MD5 authentication is not operating correctly.
SUMMARY STEPS
1. enable
2. debug standby errors

224 78-17478-01
Configuring HSRP
DETAILED STEPS
Command Purpose
Example:
Router> enable
Step 2 debug standby errors Displays error messages related to HSRP.
• Error messages will be displayed for each
Example: packet that fails to authenticate, so use this
Router# debug standby errors command with care.
• See the “Examples” section for an example of
the type of error messages displayed when two
routers are not authenticating.
Examples
In the following example, Router A has MD5 text string authentication configured, but Router B has the
default text authentication:
Router# debug standby errors
A:Jun 16 12:14:50.337:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.5, MD5
confgd but no tlv
B:Jun 16 12:16:34.287:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.4, Text auth
failed
In the following example, both Router A and Router B have different MD5 authentication strings:
Router# debug standby errors
A:Jun 16 12:19:26.335:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.5, MD5 auth
failed
B:Jun 16 12:18:46.280:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.4, MD5 auth
failed
Configuring HSRP Text Authentication

Perform this task to configure HSRP text authentication.
SUMMARY STEPS
1. enable
7. standby [group-number] authentication text string

78-17478-01 225
Configuring HSRP

10. end
11. show standby
DETAILED STEPS
Command Purpose
EXEC mode.
Router> enable
Example:
configuration mode.
Example:
interface.
Example:
Example:
Example:
Step 7 standby [group-number] authentication text string Configures an authentication string for HSRP text
authentication.
Example: • The default string is cisco.
Router(config-if)# standby 1 authentication text
sanjose
Example:

226 78-17478-01
Configuring HSRP
Command Purpose
Example:
Customizing HSRP
Perform this task to customize HSRP parameters.
HSRP Timers
Each HSRP router maintains three timers that are used for timing hello messages: an active timer, a
standby timer, and a hello timer. When a timer expires, the router changes to a new HSRP state. Routers
or access servers for which timer values are not configured can learn timer values from the active or
standby router. The timers configured on the active router always override any other timer settings. All
routers in a Hot Standby group should use the same timer values.
For HSRP version 1, nonactive routers learn timer values from the active router, unless millisecond timer
values are being used. If millisecond timer values are being used, all routers must be configured with the
millisecond timer values. This rule applies if either the hello time or the hold time is specified in
milliseconds. This configuration is necessary because the HSRP hello packets advertise the timer values
in seconds. HSRP version 2 does not have this limitation; it advertises the timer values in milliseconds.
HSRP MAC Refresh Interval

When HSRP runs over FDDI, you can change the interval at which a packet is sent to refresh the MAC
cache on learning bridges or switches. HSRP hello packets use the burned-in address (BIA) instead of
the MAC virtual address. Refresh packets keep the MAC cache on switches and learning bridges current.
You can change the refresh interval on FDDI rings to a longer or shorter interval, thereby using
bandwidth more efficiently. You can prevent the sending of any MAC refresh packets if you do not need
them (if you have FDDI but do not have a learning bridge or switch).
SUMMARY STEPS
1. enable
5. standby [group-number] timers [msec] hellotime [msec] holdtime
6. standby mac-refresh seconds

78-17478-01 227
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
255.255.255.0
Step 5 standby [group-number] timers [msec] hellotime Configures the time between hello packets and the time
[msec] holdtime before other routers declare the active Hot Standby router to
be down.
Example: • Normally, the holdtime value is greater than or equal to
Router(config-if)# standby 1 timers 5 15 three times the value of hellotime.
• See the “HSRP Timers” concept in this section for more
information.
Step 6 standby mac-refresh seconds Changes the interval at which packets are sent to refresh the
MAC cache when HSRP is running over FDDI.
Example: • This command applies to HSRP running over FDDI
Router(config-if)# standby mac-refresh 100 only.
[secondary]]
Example:
Some HSRP state flapping can occasionally occur if the holdtime is set to less than 250 milliseconds,
and the processor is busy. It is recommended that holdtime values less than 250 milliseconds be used on
Cisco 7200 platforms or better, and on Fast-Ethernet or FDDI interfaces or better. You can use the
standby delay command to allow the interface to come up completely before HSRP initializes.

228 78-17478-01
Configuring HSRP
Configuring Multiple HSRP Groups for Load Balancing

Perform this task to configure multiple HSRP groups for load balancing.
Multiple HSRP groups enable redundancy and load-sharing within networks and allow redundant routers
to be more fully utilized. While a router is actively forwarding traffic for one HSRP group, it can be in
standby or in the listen state for another group.
If two routers are used, then Router A would be configured as active for group 1 and standby for group 2.
Router B would be standby for group 1 and active for group 2. Fifty percent of the hosts on the LAN
would be configured with the virtual IP address of group 1 and the remaining hosts would be configured
with the virtual IP address of group 2. See the “Multiple HSRP for Load Balancing: Example” section
on page 246 for a diagram and configuration example.
SUMMARY STEPS
1. enable
8. On the same router, repeat Steps 5 through 7 to configure the router attributes for different standby
groups.
9. exit
10. Repeat Steps 3 through 9 to configure HSRP on another router.
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:

78-17478-01 229
Configuring HSRP

Example:
255.255.255.0
Example:
Step 6 standby [group-number] preempt [delay {minimum Configures HSRP preemption.
delay | reload delay | sync delay}]
Example:
[secondary]]
Example:
Step 8 On the same router, repeat Steps 5 through 7 to For example, Router A can be configured as an active router
configure the router attributes for different standby for group 1 and be configured for active or standby router
groups. for another HSRP group with different priority and
preemption values.
Step 9 exit Exits to global configuration mode.
Example:
Step 10 Repeat Steps 3 through 9 on another router. Configures multiple HSRP and enables load balancing on
another router.

230 78-17478-01
Configuring HSRP
Enabling HSRP Support for ICMP Redirects

By default, HSRP filtering of ICMP redirect messages is enabled on routers running HSRP. Perform this
task to reenable this feature on your router if it is disabled.
ICMP is a network layer Internet protocol that provides message packets to report errors and other
information relevant to IP processing. ICMP can send error packets to a host and can send redirect
packets to a host.
When running HSRP, it is important to prevent hosts from discovering the interface (or real) IP addresses
of routers in the HSRP group. If a host is redirected by ICMP to the real IP address of a router, and that
router later fails, then packets from the host will be lost.
ICMP redirect messages are automatically enabled on interfaces configured with HSRP. This
functionality works by filtering outgoing ICMP redirect messages through HSRP, where the next hop IP
address may be changed to an HSRP virtual IP address.
ICMP Redirects to Active HSRP Routers

The next-hop IP address is compared to the list of active HSRP routers on that network; if a match is
found, then the real next-hop IP address is replaced with a corresponding virtual IP address and the
redirect message is allowed to continue.
If no match is found, then the ICMP redirect message is sent only if the router corresponding to the new
next hop IP address is not running HSRP. Redirects to passive HSRP routers are not allowed (a passive
HSRP router is a router running HSRP, but which contains no active HSRP groups on the interface).
For optimal operation, every router in a network that is running HSRP should contain at least one active
HSRP group on an interface to that network. Every HSRP router need not be a member of the same
group. Each HSRP router will snoop on all HSRP packets on the network to maintain a list of active
routers (virtual IP addresses versus real IP addresses).
Consider the network shown in Figure 10, which supports the HSRP ICMP redirection filter.
Figure 10 Network Supporting the HSRP ICMP Redirection Filter
Net B R3 Net C Net D R6 Net E
e1 e1
R1 R2 R4 R5
e0 Active 1 e0 Active 2 Active 3 Active 4

Standby 2 Standby 1 Standby 4 Standby 3
Net A
e0 Listen 1
R7 R8 Default gateway:
virtual IP 1
Host
127025
Net F Net G

78-17478-01 231
Configuring HSRP
If the host wants to send a packet to another host on Net D, then it first sends it to its default gateway,
the virtual IP address of HSRP group 1.
The following is the packet received from the host:
dest MAC = HSRP group 1 virtual MAC
source MAC = Host MAC
dest IP = host-on-netD IP
source IP = Host IP
Router R1 receives this packet and determines that router R4 can provide a better path to Net D, so it
prepares to send a redirect message that will redirect the host to the real IP address of router R4 (because
only real IP addresses are in its routing table).
The following is the initial ICMP redirect message sent by router R1:
dest MAC = Host MAC
source MAC = router R1 MAC
dest IP = Host IP
source IP = router R1 IP
gateway to use = router R4 IP
Before this redirect occurs, the HSRP process of router R1 determines that router R4 is the active HSRP
router for group 3, so it changes the next hop in the redirect message from the real IP address of router
R4 to the virtual IP address of group 3. Furthermore, it determines from the destination MAC address of
the packet that triggered the redirect message that the host used the virtual IP address of group 1 as its
gateway, so it changes the source IP address of the redirect message to the virtual IP address of group 1.
The modified ICMP redirect message showing the two modified fields (*) is as follows:
dest MAC = Host MAC
source MAC = router R1 MAC
dest IP = Host IP
source IP* = HSRP group 1 virtual IP
gateway to use* = HSRP group 3 virtual IP
This second modification is necessary because hosts compare the source IP address of the ICMP redirect
message with their default gateway. If these addresses do not match, the ICMP redirect message is
ignored. The routing table of the host now consists of the default gateway, virtual IP address of group 1,
and a route to Net D through the virtual IP address of group 3.
ICMP Redirects to Passive HSRP Routers

Redirects to passive HSRP routers are not permitted. Redundancy may be lost if hosts learn the real IP
addresses of HSRP routers.
In Figure 10, redirection to router R8 is not allowed because R8 is a passive HSRP router. In this case,
packets from the host to Net D will first go to router R1 and then be forwarded to router R4; that is, they
will traverse the network twice.
A network configuration with passive HSRP routers is considered a misconfiguration. For HSRP ICMP
redirection to operate optimally, every router on the network that is running HSRP should contain at least
one active HSRP group.
ICMP Redirects to Non-HSRP Routers

Redirects to routers not running HSRP on their local interface are permitted. No redundancy is lost if
hosts learn the real IP address of non-HSRP routers.

232 78-17478-01
Configuring HSRP
In Figure 10, redirection to router R7 is allowed because R7 is not running HSRP. In this case, the next
hop IP address is unchanged. The source IP address is changed dependent upon the destination MAC
address of the original packet. You can specify the no standby redirect unknown command to stop
these redirects from being sent.
Passive HSRP Router Advertisements

Passive HSRP routers send out HSRP advertisement messages both periodically and when entering or
leaving the passive state. Thus, all HSRP routers can determine the HSRP group state of any HSRP
router on the network. These advertisements inform other HSRP routers on the network of the HSRP
interface state, as follows:
• Dormant—Interface has no HSRP groups. A single advertisement is sent once when the last group
is removed.
• Passive—Interface has at least one non-active group and no active groups. Advertisements are sent
out periodically.
• Active—Interface has at least one active group. A single advertisement is sent out when the first
group becomes active.
You can adjust the advertisement interval and holddown time using the standby redirect timers
command.
ICMP Redirects Not Sent

If the HSRP router cannot uniquely determine the IP address used by the host when it sends the packet
that caused the redirect, the redirect message will not be sent. The router uses the destination MAC
address in the original packet to make this determination. In certain configurations, such as the use of
the standby use-bia interface configuration command specified on an interface, redirects cannot be sent.
In this case, the HSRP groups use the interface MAC address as their virtual MAC address. The router
now cannot determine if the default gateway of the host is the real IP address or one of the HSRP virtual
IP addresses that are active on the interface.
Using HSRP with ICMP redirects is not possible in the Cisco 800 series, Cisco 1000 series, Cisco 1600
series, Cisco 2500 series, Cisco 3000 series, and Cisco 4500 series routers because the Ethernet
controller can only support one MAC address.
The IP source address of an ICMP packet must match the gateway address used by the host in the packet
that triggered the ICMP packet, otherwise the host will reject the ICMP redirect packet. An HSRP router
uses the destination MAC address to determine the gateway IP address of the host. If the HSRP router
is using the same MAC address for multiple IP addresses then it is not possible to uniquely determine
the gateway IP address of the host and the redirect message is not sent.
The following is sample output from the debug standby events icmp EXEC command if HSRP could
not uniquely determine the gateway used by the host:
10:43:08: SB: ICMP redirect not sent to 20.0.0.4 for dest 30.0.0.2
10:43:08: SB: could not uniquely determine IP address for mac 00d0.bbd3.bc22
SUMMARY STEPS
1. enable
4. standby redirect [timers advertisement holddown] [unknown]

78-17478-01 233
Configuring HSRP
5. end
6. show standby redirect [ip-address] [interface-type interface-number] [active] [passive] [timers]
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 standby redirect [timers advertisement Enables HSRP filtering of ICMP redirect messages.
holddown] [unknown]
• You can also use this command in global configuration
mode, which enables HSRP filtering of ICMP redirect
Example: messages on all interfaces configured for HSRP.
Router(config-if)# standby redirect
Example:
Step 6 show standby redirect [ip-address] (Optional) Displays ICMP redirect information on
[interface-type interface-number] [active] interfaces configured with HSRP.
[passive] [timers]
Example:
Router# show standby redirect
Configuring HSRP Virtual MAC Addresses or BIA MAC Addresses

Perform this task to configure an HSRP virtual MAC address or a burned-in address (BIA) MAC address.
A router automatically generates a virtual MAC address for each HSRP router. However, some network
implementations, such as Advanced Peer-to-Peer Networking (APPN), use the MAC address to identify
the first hop for routing purposes. In this case, it is often necessary to be able to specify the virtual MAC
address by using the standby mac-address command; the virtual IP address is unimportant for these
protocols.
The standby use-bia command was implemented to overcome the limitations of using a functional
address for the HSRP MAC address on Token Ring interfaces. This command allows HSRP groups to
use the BIA MAC address of an interface instead of the HSRP virtual MAC address. When HSRP runs

234 78-17478-01
Configuring HSRP
on a multiple-ring, source-routed bridging environment and the HSRP routers reside on different rings,
configuring the standby use-bia command can prevent confusion about the routing information field
(RFI).
Restrictions
You cannot use the standby use-bia and standby mac-address commands in the same configuration;
they are mutually exclusive.
The standby use-bia command has the following disadvantages:
• When a router becomes active the virtual IP address is moved to a different MAC address. The newly
active router sends a gratuitous ARP response, but not all host implementations handle the
gratuitous ARP correctly.
• Proxy ARP breaks when the standby use-bia command is configured. A standby router cannot
cover for the lost proxy ARP database of the failed router.
SUMMARY STEPS
1. enable
5. standby [group-number] mac-address mac-address
or
standby use-bia [scope interface]
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 ip address ip-address mask [secondary] Configures an IP address for an interface.
Example:
255.255.255.0

78-17478-01 235
Configuring HSRP

Step 5 standby [group-number] mac-address mac-address Specifies a virtual MAC address for HSRP.
or
• This command cannot be used on a Token Ring
standby use-bia [scope interface] interface.
or
Example:
Router(config-if)# standby 1 mac-address
Configures HSRP to use the burned-in address of the
5000.1000.1060 interface as its virtual MAC address.
or • The scope interface keywords specify that the
command is configured just for the subinterface on
Example: which it was entered, instead of the major interface.
Router(config-if)# standby use-bia
[secondary]]
Example:
Linking IP Redundancy Clients to HSRP Groups

Perform this task to link IP redundancy clients to HSRP groups.
HSRP provides stateless redundancy for IP routing. HSRP by itself is limited to maintaining its own
state. Linking an IP redundancy client to an HSRP group provides a mechanism that allows HSRP to
provide a service to client applications so they can implement stateful failover.
IP redundancy clients are other Cisco IOS processes or applications that use HSRP to provide or
withhold a service or resource dependent upon the state of the group.
Prerequisites
Within the client application, you must first specify the same name as configured in the standby name
command.
SUMMARY STEPS
1. enable
5. standby [group-number] name [redundancy-name]

236 78-17478-01
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
255.255.255.0
Step 5 standby [group-number] name [redundancy-name] Configures the name of the standby group.
• HSRP groups have a default name so it is not a
Example: requirement to specify a name.
Router(config-if)# standby 1 name HSRP-1
[secondary]]
Example:
Changing to HSRP Version 2

HSRP version 2 was introduced to prepare for further enhancements and to expand the capabilities
beyond what is possible with HSRP version 1. HSRP version 2 has a different packet format than HSRP
version 1.
HSRP Version 2 Design

HSRP version 2 is designed to address the following issues relative to HSRP version 1:
• Previously, millisecond timer values are not advertised or learned. HSRP version 2 advertises and
learns millisecond timer values. This change ensures stability of the HSRP groups in all cases.
• Group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number
range from 0 to 4095.

78-17478-01 237
Configuring HSRP
• HSRP version 2 provides improved management and troubleshooting. With HSRP version 1, there
is no method to identify from HSRP active hello messages which physical router sent the message
because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet
format includes a 6-byte identifier field that is used to uniquely identify the sender of the message.
Typically, this field is populated with the interface MAC address.
• The multicast address 224.0.0.2 is used to send HSRP hello messages. This address can conflict with
Cisco Group Management Protocol (CGMP) leave processing.
Version 1 is the default version of HSRP.
HSRP version 2 uses the new IP multicast address 224.0.0.102 to send hello packets instead of the
multicast address of 224.0.0.2, which is used by version 1. This new multicast address allows CGMP
leave processing to be enabled at the same time as HSRP.
HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC
address range 0000.0C9F.F000 to 0000.0C9F.FFFF. The increased group number range does not imply
that an interface can, or should, support that many HSRP groups. The expanded group number range was
changed to allow the group number to match the VLAN number on subinterfaces.
When the HSRP version is changed, each group will reinitialize because it now has a new virtual MAC
address.
HSRP version 2 has a different packet format than HSRP version 1. The packet format uses a
type-length-value (TLV) format. HSRP version 2 packets received by an HSRP version 1 router will have
the type field mapped to the version field by HSRP version 1 and subsequently ignored.
The Gateway Load Balancing Protocol (GLBP) also addresses the same issues relative to HSRP version
1 that HSRP version 2 does. See the Configuring GLBP configuration module for more information on
GLBP.
Restrictions
• HSRP version 2 is not available for ATM interfaces running LAN emulation.
• HSRP version 2 will not interoperate with HSRP version 1. An interface cannot operate both version
1 and version 2 because both versions are mutually exclusive. However, the different versions can
be run on different physical interfaces of the same router. You cannot change from version 2 to
version 1 if you have configured groups above the group number range allowed for version 1 (0 to
255).
SUMMARY STEPS
1. enable
5. standby version {1 | 2}
7. end
8. show standby

238 78-17478-01
Configuring HSRP
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Router(config)# interface vlan 400
Step 4 ip address ip-address mask Sets an IP address for an interface.
Example:
255.255.255.0
Step 5 standby version {1 | 2 } Changes the HSRP version.
Example:
Router(config-if)# standby version 2
[secondary]]
• The group number range for HSRP version 2 is
expanded to 0 through 4095. The group number range
Example: for HSRP version 1 is 0 through 255.
Step 7 end Ends the current configuration session and returns to
Example:
• HSRP version 2 information will be displayed if
Example: configured.
Router# show standby
Configuring SSO-Aware HSRP (Cisco IOS Release 12.2(25)S)

This section contains the following tasks:
• Enabling SSO Aware HSRP, page 240 (required)
• Verifying SSO Aware HSRP, page 241 (optional)

78-17478-01 239
Configuring HSRP
SSO-aware HSRP alters the behavior of HSRP when a router with redundant Route Processors (RPs) is
configured for Stateful Switchover (SSO) redundancy mode. When an RP is active and the other RP is
standby, SSO enables the standby RP to take over if the active RP fails.
With this functionality, HSRP SSO information is synchronized to the standby RP, allowing traffic that
is sent using the HSRP virtual IP address to be continuously forwarded during a switchover without a
loss of data or a path change. Additionally, if both RPs fail on the active HSRP router, then the standby
HSRP router takes over as the active HSRP router.
The feature is enabled by default when the redundancy mode of operation is set to SSO.
SSO Dual-Route Processors and Cisco Nonstop Forwarding

SSO functions in networking devices (usually edge devices) that support dual RPs. SSO provides RP
redundancy by establishing one of the RPs as the active processor and the other RP as the standby
processor. SSO also synchronizes critical state information between the RPs so that network state
information is dynamically maintained between RPs.
SSO is generally used with Cisco Nonstop Forwarding (NSF). Cisco NSF enables forwarding of data
packets to continue along known routes while the routing protocol information is being restored
following a switchover. With NSF, users are less likely to experience service outages.
HSRP and SSO Working Together

SSO-aware HSRP enables the Cisco IOS HSRP subsystem software to detect that a standby RP is
installed and the system is configured in SSO redundancy mode. Further, if the active RP fails, no change
occurs to the HSRP group itself and traffic continues to be forwarded through the current active gateway
router.
Prior to this feature, when the primary RP of the active router failed, it would stop participating in the
HSRP group and trigger another router in the group to take over as the active HSRP router.
SSO-aware HSRP is required to preserve the forwarding path for traffic destined to the HSRP virtual IP
address through an RP switchover.
Configuring SSO on the edge router enables the traffic on the Ethernet links to continue during an RP
failover without the Ethernet traffic switching over to an HSRP standby router (and then back, if
preemption is enabled).
Enabling SSO Aware HSRP

The functionality is enabled by default when the redundancy mode is set to SSO. Perform this task to
reenable HSRP to be SSO aware if it has been disabled.
Note You may want to disable SSO-aware HSRP by using the no standby sso command if you have LAN
segments that should switch HSRP traffic to a redundant device while SSO maintains traffic flow for
other connections.
SUMMARY STEPS
1. enable
3. redundancy

240 78-17478-01
Configuring HSRP
4. mode sso
5. exit
6. no standby sso
7. standby sso
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 redundancy Enters redundancy configuration mode.
Example:
Router(config)# redundancy
Step 4 mode sso Enables the redundancy mode of operation to SSO.
• After performing this step, HSRP is SSO aware on
Example: interfaces that are configured for HSRP and the standby
Router(config-red)# mode sso RP is automatically reset.
Step 5 exit Exits redundancy configuration mode.
Example:
Router(config-red)# exit
Step 6 no standby sso Disables HSRP SSO mode for all HSRP groups.
Example:
Router(config)# no standby sso
Step 7 standby sso Enables the SSO-aware HSRP feature if you have disabled
the functionality.
Example:
Router(config)# standby sso
Step 8 end Ends the current configuration session and returns to
Example:
Router(config)# end
Verifying SSO Aware HSRP

To verify or debug HSRP SSO operation, perform the following steps from the active RP console.

78-17478-01 241
Configuring HSRP
SUMMARY STEPS
1. show standby
2. debug standby events ha
DETAILED STEPS
Step 1 show standby

Use the show standby command to display the state of the standby RP, for example:
Router# show standby
Ethernet0/0/1 - Group 1
State is Init (standby RP, peer state is Active)
Active virtual MAC address is unknown
Local virtual MAC address is 000a.f3fd.5001 (bia)
Hello time 1 sec, hold time 3 sec
Authentication text “authword”
Preemption enabled
Active router is unknown
Standby router is unknown
Priority 110 (configured 120)
IP redundancy name is “name1” (cfgd)
Step 2 debug standby events ha

Use the debug standby events ha command to display the active and standby RPs, for example:
Router# debug standby events ha
!Active RP
*Apr 27 04:13:47.755: HSRP: Et0/0/1 Grp 101 RF Encode state Listen into sync buffer
*Apr 27 04:13:47.855: HSRP: CF Sync send ok
*Apr 27 04:13:57.755: HSRP: Et0/0/1 Grp 101 RF Encode state Speak into sync buffer
*Apr 27 04:14:07.755: HSRP: Et0/0/1 Grp 101 RF Encode state Standby into sync buffer
*Apr 27 04:14:07.755: HSRP: Et0/0/1 Grp 101 RF Encode state Active into sync buffer
!Standby RP
*Apr 27 04:11:21.011: HSRP: RF CF client 32, entity 0 got msg len 24

*Apr 27 04:11:21.011: HSRP: Et0/0/1 Grp 101 RF sync state Init -> Listen
*Apr 27 04:11:31.011: HSRP: Et0/0/1 Grp 101 RF sync state Listen -> Speak
*Apr 27 04:11:41.071: HSRP: Et0/0/1 Grp 101 RF sync state Speak -> Standby
*Apr 27 04:11:41.071: HSRP: Et0/0/1 Grp 101 RF sync state Standby -> Active

242 78-17478-01
Configuring HSRP
Enabling HSRP MIB Traps

HSRP MIB supports Simple Network Management Protocol (SNMP) Get operations, to allow network
devices to get reports about HSRP groups in a network from the network management station.
Enabling HSRP MIB trap support is performed through the CLI, and the MIB is used for getting the
reports. A trap notifies the network management station when a router leaves or enters the active or
standby state. When an entry is configured from the CLI, the RowStatus for that group in the MIB
immediately goes to the active state.
The Cisco IOS software supports a read-only version of the MIB, and set operations are not supported.
This functionality supports four MIB tables, as follows:
• cHsrpGrpEntry table defined in CISCO-HSRP-MIB.my
• cHsrpExtIfTrackedEntry, cHsrpExtSecAddrEntry, and cHsrpExtIfEntry defined in
CISCO-HSRP-EXT-MIB.my
The cHsrpGrpEntry table consists of all the group information defined in RFC 2281, Cisco Hot Standby
Router Protocol; the other tables consist of the Cisco extensions to RFC 2281, which are defined in
CISCO-HSRP-EXT-MIB.my.
SUMMARY STEPS
1. enable
3. snmp-server enable traps hsrp
4. snmp-server host host community-string hsrp
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 snmp-server enable traps hsrp Enables the router to send SNMP traps and informs, and
HSRP notifications.
Example:
Router(config)# snmp-server enable traps hsrp
Step 4 snmp-server host host community-string hsrp Specifies the recipient of an SNMP notification operation,
and that HSRP notifications be sent to the host.
Example:
Router# snmp-server host myhost.comp.com public
hsrp

78-17478-01 243
Configuring HSRP
Configuration Examples for HSRP

• HSRP Priority and Preemption: Example, page 244
• HSRP Object Tracking: Example, page 245
• HSRP MD5 Authentication Using Key Strings: Example, page 245
• HSRP MD5 Authentication Using Key Chains: Example, page 245
• HSRP MD5 Authentication Using Key Strings and Key Chains: Example, page 246
• HSRP Text Authentication: Example, page 246
• Multiple HSRP for Load Balancing: Example, page 246
• HSRP Support for ICMP Redirect Messages: Example, page 248
• HSRP Virtual MAC Addresses and BIA MAC Address: Example, page 248
• Linking IP Redundancy Clients to HSRP Groups: Example, page 248
• HSRP Version 2: Example, page 249
• SSO-Aware HSRP (Cisco IOS Release 12.2(25)S): Example, page 249
• HSRP MIB Traps: Example, page 250
HSRP Priority and Preemption: Example

In the following example, Router A is configured to be the active router for group 1 because it has the
higher priority and standby router for group 2. Router B is configured to be the active router for group
2 and standby router for group 1.
Router A Configuration
ip address 10.1.0.21 255.255.0.0
standby 1 preempt
standby 2 preempt
Router B Configuration
ip address 10.1.0.22 255.255.0.0
standby 1 preempt
standby 2 preempt

244 78-17478-01
Configuring HSRP
HSRP Object Tracking: Example

In the following example, the tracking process is configured to track the IP-routing capability of serial
interface 1/0. HSRP on Ethernet interface 0/0 then registers with the tracking process to be informed of
any changes to the IP-routing state of serial interface 1/0. If the IP state on serial interface 1/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 routing on serial interface 1/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.
track 100 interface serial1/0 ip routing
!
ip address 10.1.0.21 255.255.0.0
standby 1 preempt
standby 1 track 100 decrement 10
!
ip address 10.1.0.22 255.255.0.0
standby 1 preempt
HSRP MD5 Authentication Using Key Strings: Example

The following example shows how to configure HSRP MD5 authentication using a key string:
standby 1 preempt
standby 1 authentication md5 key-string 54321098452103ab timeout 30
standby 1 ip 10.21.0.10
HSRP MD5 Authentication Using Key Chains: Example

In the following example, HSRP queries the key chain “hsrp1” to obtain the current live key and key ID
for the specified key chain:
key chain hsrp1
key 1
key-string 54321098452103ab
standby 1 preempt
standby 1 authentication md5 key-chain hsrp1
standby 1 ip 10.21.0.10

78-17478-01 245
Configuring HSRP
HSRP MD5 Authentication Using Key Strings and Key Chains: Example
The key ID for key-string authentication is always zero. If a key chain is configured with a key ID of
zero, then the following configuration will work:
Router 1
key chain hsrp1
key 0
key-string 54321098452103ab
standby 1 authentication md5 key-chain hsrp1
standby 1 ip 10.21.0.10
Router 2
standby 1 authentication md5 key-string 54321098452103ab
standby 1 ip 10.21.0.10
HSRP Text Authentication: Example

The following example shows how to configure HSRP text authentication using a text string:
standby 1 preempt
standby 1 authentication text company2
standby 1 ip 10.21.0.10
Multiple HSRP for Load Balancing: Example

You can use HSRP or multiple HSRP groups when you configure load sharing. In Figure 11, half of the
clients are configured for Router A, and half of the clients are configured for Router B. Together, the
configuration for Routers A and B establish two Hot Standby groups. For group 1, Router A is the default
active router because it has the assigned highest priority, and Router B is the standby router. For group
2, Router B is the default active router because it has the assigned highest priority, and Router A is the
standby router. During normal operation, the two routers share the IP traffic load. When either router
becomes unavailable, the other router becomes active and assumes the packet-transfer functions of the
router that is unavailable. The standby preempt interface configuration command is necessary so that
if a router goes down and then comes back up, preemption occurs and restores load sharing.

246 78-17478-01
Configuring HSRP
Figure 11 HSRP Load Sharing Example
Active router for group 1 Active router for group 2

Standby router for group 2 Standby router for group 1
Router A Router B
E0 10.0.0.1 E0 10.0.0.2
127027
Client 1 Client 2 Client 3 Client 4
The following example shows Router A configured as the active router for group 1 with a priority of 110
and Router B configured as the active router for group 2 with a priority of 110. The default priority level
is 100. Group 1 uses a virtual IP address of 10.0.0.3 and Group 2 uses a virtual IP address of 10.0.0.4.
hostname RouterA
!
ip address 10.0.0.1 255.255.255.0
standby 1 preempt
standby 2 preempt
hostname RouterB
!
ip address 10.0.0.2 255.255.255.0
standby 1 preempt
standby 2 preempt

78-17478-01 247
Configuring HSRP
HSRP Support for ICMP Redirect Messages: Example

The following is a configuration example for two HSRP groups that allow the filtering of ICMP redirect
messages:
Router A Configuration—Active for Group 1 and Standby for Group 2

interface Ethernet1
ip address 10.0.0.10 255.0.0.0
standby redirect
standby 1 preempt delay minimum 20
Router B Configuration—Standby for Group 1 and Active for Group 2

interface Ethernet1
ip address 10.0.0.11 255.0.0.0
standby redirect
HSRP Virtual MAC Addresses and BIA MAC Address: Example

In an APPN network, an end node is typically configured with the MAC address of the adjacent network
node. In the following example, if the end nodes are configured to use 4000.1000.1060, HSRP group 1
is configured to use the same MAC address:
ip address 10.0.0.1
standby 1 mac-address 4000.1000.1060
In the following example, the burned-in address of Token Ring interface 3/0 will be the virtual MAC
address mapped to the virtual IP address:
interface token3/0
standby use-bia
Note You cannot use the standby use-bia command and the standby mac-address command in the same
configuration.
Linking IP Redundancy Clients to HSRP Groups: Example

The following example shows HSRP support for a static NAT configuration. The NAT client application
is linked to HSRP via the correlation between the name specified by the standby name command. Two
routers are acting as HSRP active and standby, and the NAT inside interfaces are HSRP enabled and
configured to belong to the group named “sanjose.”

248 78-17478-01
Configuring HSRP
Active Router Configuration

interface BVI10
ip address 192.168.5.54 255.255.255.255.0
no ip redirects
ip nat inside
standby 10 ip 192.168.5.30
standby 10 preempt
standby 10 name sanjose
standby 10 track Ethernet2/1
!
!
ip nat inside source static 192.168.5.33 10.10.10.5 redundancy sanjose
ip classless
ip route 10.10.10.0 255.255.255.0 Ethernet2/1
no ip http server
Standby Router Configuration

interface BVI10
ip address 192.168.5.56 255.255.255.255.0
no ip redirects
ip nat inside
standby 10 preempt
standby 10 name sanjose
standby 10 ip 192.168.5.30
standby 10 track Ethernet3/1
!
ip nat inside source static 192.168.5.33 3.3.3.5 redundancy sanjose
ip classless
ip route 10.0.32.231 255.255.255 Ethernet3/1
no ip http server
HSRP Version 2: Example

The following example shows how to configure HSRP version 2 on an interface with a group number of
350:
!
interface vlan350
standby version 2
standby 350 preempt
standby 350 ip 172.20.100.10
SSO-Aware HSRP (Cisco IOS Release 12.2(25)S): Example

The following example shows how to set the redundancy mode to SSO. HSRP is automatically
SSO-aware when this mode is enabled.
redundancy
mode sso

78-17478-01 249
Configuring HSRP
If SSO-aware HSRP is disabled using the no standby sso command, you can reenable it as shown in the
following example:
interface Ethernet1
ip address 10.1.1.1 255.255.0.0
standby priority 200
standby preempt
standby sso
HSRP MIB Traps: Example

The following examples show how to configure HSRP on two routers and enable the HSRP MIB trap
support functionality. As in many environments, one router is preferred as the active one. This is realized
by configuring it at a higher priority level and enabling preemption. In the following example, the active
router is referred to as the primary router. The second router is referred to as the backup router:
Router A
interface Ethernet1
ip address 10.1.1.1 255.255.0.0
standby preempt
standby ip 10.1.1.3
snmp-server enable traps hsrp
snmp-server host yourhost.cisco.com public hsrp
Router B
interface Ethernet1
ip address 10.1.1.2 255.255.0.0
standby ip 10.1.1.3
snmp-server enable traps hsrp
snmp-server host myhost.cisco.com public hsrp
The following sections provide references related to HSRP.
Related Documents
HSRP commands: complete command syntax, Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and
command mode, command history, defaults, usage Services, Release 12.4
Key chains and key management commands: complete Cisco IOS IP Command Reference, Volume 2 of 4: Routing
command syntax, command mode, command history, Protocols, Release 12.4
Object tracking “Configuring Enhanced Object Tracking” module
VRRP “Configuring VRRP” module

250 78-17478-01
Configuring HSRP

GLBP “Configuring GLBP” module
Troubleshooting HSRP Understanding and Troubleshooting HSRP Problems in Catalyst
Switch Networks document.
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 1828 IP Authentication Using Keyed MD5
RFC 2281 Cisco Hot Standby Router Protocol
Description Link
even more content.

78-17478-01 251
Configuring HSRP
Glossary
Glossary
active router—The primary router in an HSRP group that is currently forwarding packets for the virtual
router.
active RP—The active RP that controls the system, provides network services, runs the routing
protocols, and presents the system management interface.
HSRP—Hot Standby Router Protocol. Protocol that provides high network availability and transparent
network-topology changes. HSRP creates a router group with a lead router that services all packets sent
to the HSRP address. The lead router is monitored by other routers in the group, and if it fails, one of
these standby HSRP routers inherits the lead position and the HSRP group address.
NSF—Nonstop Forwarding. The ability of a router to continue to forward traffic to a router that may be
recovering from a failure. Also, the ability of a router recovering from a failure to continue to correctly
forward traffic sent to it by a peer.
RF—Redundancy Facility. A structured, functional interface used to notify its clients of active and
standby state progressions and events.
RP—Route Processor. A generic term for the centralized control unit in a chassis. Platforms usually use
a platform-specific term, such as RSP on the Cisco 7500, the PRE on the Cisco 10000, or the
SUP+MSFC on the Cisco 7600.
RPR+—An enhanced Route Processor Redundancy (RPR) in which the standby RP is fully initialized.
SSO—Stateful Switchover. SSO refers to the implementation of Cisco IOS software that allows
applications and features to maintain a defined state between an active and standby RP. When a
switchover occurs, forwarding and sessions are maintained. Along with NSF, SSO makes an RP failure
undetectable to the network.
standby group—The set of routers participating in HSRP that jointly emulate a virtual router.
standby router—The backup router in an HSRP group.
standby RP—The backup RP.
switchover—An event in which system control and routing protocol execution are transferred from the
active RP to the standby RP. Switchover may be a manual operation or may be induced by a hardware or
software fault. Switchover may include transfer of the packet forwarding function in systems that
combine system control and packet forwarding in an indivisible unit.
virtual IP address—The default gateway IP address configured for an HSRP group.
Note Refer to Internetworking Terms and Acronyms for terms not included in this glossary.
Feature Information for HSRP

features that were introduced or modified in Cisco IOS Releases 12.2(1) or 12.2(25)S or later appear in
the table.
specific commands was introduced, see the command reference documents.
If you are looking for information on a feature in this technology that is not documented here, see the
“FHRP Features Roadmap”.

252 78-17478-01
Configuring HSRP
Table 11 Feature Information for HSRP

HSRP MD5 Authentication 12.3(2)T Prior to the introduction of the HSRP MD5 Authentication
12.2(25)S feature, HSRP authenticated protocol packets with a simple
plain text string.The HSRP MD5 Authentication feature is
an enhancement to generate an MD5 digest for the HSRP
portion of the multicast HSRP protocol packet. This feature
provides added security and protects against the threat from
HSRP-spoofing software.
The following sections provide information about this
feature:
• Configuring HSRP Authentication, page 219
The following commands were introduced or modified by
this feature: show standby, standby authentication.
HSRP Version 2 12.3(4)T HSRP Version 2 feature was introduced to prepare for
12.2(25)S further enhancements and to expand the capabilities beyond
what is possible with HSRP version 1. HSRP version 2 has
a different packet format than HSRP version 1.
feature:
• Changing to HSRP Version 2, page 237
this feature: show standby, standby ip, standby version
FHRP - SSO-Aware HSRP 12.2(25)S SSO-aware HSRP alters the behavior of HSRP when a
router with redundant RPs is configured for SSO. When an
RP is active and the other RP is standby, SSO enables the
standby RP to take over if the active RP fails.
feature:
• Configuring SSO-Aware HSRP (Cisco IOS Release
12.2(25)S), page 239
this feature: debug standby events, standby sso

78-17478-01 253
Configuring HSRP

254 78-17478-01
Configuring VRRP
First Published: May 2, 2005

Last Updated: May 8, 2006
The Virtual Router Redundancy Protocol (VRRP) is an election protocol that dynamically assigns
responsibility for one or more virtual routers to the VRRP routers on a LAN, allowing several routers on
a multiaccess link to utilize the same virtual IP address. A VRRP router is configured to run the VRRP
protocol in conjunction with one or more other routers attached to a LAN. In a VRRP configuration, one
router is elected as the virtual router master, with the other routers acting as backups in case the virtual
router master fails.

Your Cisco IOS software release may not support all of the features documented in this module. To reach
links to specific feature documentation in this module and to see a list of the releases in which each feature is
supported, use the “Feature Information for VRRP” section on page 280.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS
software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An
account on Cisco.com is not required.
Contents
• Restrictions for VRRP, page 256
• Information About VRRP, page 256
• How to Configure VRRP, page 260
• Configuration Examples for VRRP, page 275
• Feature Information for VRRP, page 280
• Feature Information for VRRP, page 280

78-17478-01 255
Configuring VRRP
Restrictions for VRRP
Restrictions for VRRP

VRRP is designed for use over multi-access, multicast, or broadcast capable Ethernet LANs. VRRP is
not intended as a replacement for existing dynamic protocols.
VRRP is supported on Ethernet, Fast Ethernet, Bridge Group Virtual Interface (BVI), and Gigabit
Ethernet interfaces, and on Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs).
Because of the forwarding delay that is associated with the initialization of a BVI interface, it is
necessary to set the VRRP advertise timer to a value equal to or greater than the forwarding delay on the
BVI interface. This setting prevents a VRRP router on a recently initialized BVI interface from
unconditionally taking over the master role. Use the bridge forward-time command to set the
forwarding delay on the BVI interface. Use the vrrp timers advertise command to set the VRRP
advertisement timer.
Information About VRRP

Before you configure VRRP, you should understand the following concepts:
• VRRP Operation, page 256
• VRRP Benefits, page 258
• Multiple Virtual Router Support, page 259
• VRRP Router Priority and Preemption, page 259
• VRRP Advertisements, page 260
• VRRP Object Tracking, page 260
VRRP Operation
There are several ways a LAN client can determine which router should be the first hop to a particular
remote destination. The client can use a dynamic process or static configuration. Examples of dynamic
router discovery are as follows:
• Proxy ARP—The client uses Address Resolution Protocol (ARP) to get the destination it wants to
reach, and a router will respond to the ARP request with its own MAC address.
• Routing protocol—The client listens to dynamic routing protocol updates (for example, from
Routing Information Protocol [RIP]) and forms its own routing table.
• IRDP (ICMP Router Discovery Protocol) client—The client runs an Internet Control Message
Protocol (ICMP) router discovery client.
The drawback to dynamic discovery protocols is that they incur some configuration and processing
overhead on the LAN client. Also, in the event of a router failure, the process of switching to another
router can be slow.
An alternative to dynamic discovery protocols is to statically configure a default router on the client.
This approach simplifies client configuration and processing, but creates a single point of failure. If the
default gateway fails, the LAN client is limited to communicating only on the local IP network segment
and is cut off from the rest of the network.
VRRP can solve the static configuration problem. VRRP enables a group of routers to form a single
virtual router. The LAN clients can then be configured with the virtual router as their default gateway.
The virtual router, representing a group of routers, is also known as a VRRP group.

256 78-17478-01
Configuring VRRP
VRRP is supported on Ethernet, Fast Ethernet, BVI, and Gigabit Ethernet interfaces, and on MPLS
VPNs and VLANs.
Figure 12 shows a LAN topology in which VRRP is configured. In this example, Routers A, B, and C
are VRRP routers (routers running VRRP) that comprise a virtual router. The IP address of the virtual
router is the same as that configured for the Ethernet interface of Router A (10.0.0.1).
Figure 12 Basic VRRP Topology
Router A Router B Router C

Virtual router Virtual router Virtual router
master backup backup Virtual
router group
IP address = 10.0.0.1
10.0.0.1 10.0.0.2 10.0.0.3
56623
Client 1 Client 2 Client 3
Because the virtual router uses the IP address of the physical Ethernet interface of Router A, Router A
assumes the role of the virtual router master and is also known as the IP address owner. As the virtual
router master, Router A controls the IP address of the virtual router and is responsible for forwarding
packets sent to this IP address. Clients 1 through 3 are configured with the default gateway IP address
of 10.0.0.1.
Routers B and C function as virtual router backups. If the virtual router master fails, the router
configured with the higher priority will become the virtual router master and provide uninterrupted
service for the LAN hosts. When Router A recovers, it becomes the virtual router master again. For more
detail on the roles that VRRP routers play and what happens if the virtual router master fails, see the
“VRRP Router Priority and Preemption” section later in this document.
Figure 13 shows a LAN topology in which VRRP is configured so that Routers A and B share the traffic
to and from clients 1 through 4 and that Routers A and B act as virtual router backups to each other if
either router fails.

78-17478-01 257
Configuring VRRP
Figure 13 Load Sharing and Redundancy VRRP Topology
Router A Router B
Master for virtual router 1 Backup for virtual router 1
Backup for virtual router 2 Master for virtual router 2
10.0.0.1 10.0.0.2
129284
Client 1 Client 2 Client 3 Client 4
Default gateway = Default gateway = Default gateway = Default gateway =
10.0.0.1 10.0.0.1 10.0.0.2 10.0.0.2
In this topology, two virtual routers are configured. (For more information, see the “Multiple Virtual
Router Support” section later in this document.) For virtual router 1, Router A is the owner of IP address
10.0.0.1 and virtual router master, and Router B is the virtual router backup to Router A. Clients 1 and
2 are configured with the default gateway IP address of 10.0.0.1.
For virtual router 2, Router B is the owner of IP address 10.0.0.2 and virtual router master, and Router A
is the virtual router backup to Router B. Clients 3 and 4 are configured with the default gateway IP
address of 10.0.0.2.
VRRP Benefits
Redundancy
VRRP enables you to configure multiple routers as the default gateway router, which reduces the
possibility of a single point of failure in a network.
Load Sharing
You can configure VRRP in such a way that traffic to and from LAN clients can be shared by multiple
routers, thereby sharing the traffic load more equitably among available routers.
Multiple Virtual Routers

VRRP supports up to 255 virtual routers (VRRP groups) on a router physical interface, subject to the
platform supporting multiple MAC addresses. Multiple virtual router support enables you to implement
redundancy and load sharing in your LAN topology.
Multiple IP Addresses
The virtual router can manage multiple IP addresses, including secondary IP addresses. Therefore, if you
have multiple subnets configured on an Ethernet interface, you can configure VRRP on each subnet.
Preemption
The redundancy scheme of VRRP enables you to preempt a virtual router backup that has taken over for
a failing virtual router master with a higher priority virtual router backup that has become available.

258 78-17478-01
Configuring VRRP
Authentication
VRRP message digest 5 (MD5) algorithm authentication protects against VRRP-spoofing software and
uses the industry-standard MD5 algorithm for improved reliability and security.
Advertisement Protocol
VRRP uses a dedicated Internet Assigned Numbers Authority (IANA) standard multicast address
(224.0.0.18) for VRRP advertisements. This addressing scheme minimizes the number of routers that
must service the multicasts and allows test equipment to accurately identify VRRP packets on a segment.
The IANA assigned VRRP the IP protocol number 112.
VRRP Object Tracking

VRRP object tracking provides a way to ensure the best VRRP router is virtual router master for the
group by altering VRRP priorities to the status of tracked objects such as interface or IP route states.
Multiple Virtual Router Support

You can configure up to 255 virtual routers on a router physical interface. The actual number of virtual
routers that a router interface can support depends on the following factors:
• Router processing capability
• Router memory capability
• Router interface support of multiple MAC addresses
In a topology where multiple virtual routers are configured on a router interface, the interface can act as
a master for one virtual router and as a backup for one or more virtual routers.
VRRP Router Priority and Preemption

An important aspect of the VRRP redundancy scheme is VRRP router priority. Priority determines the
role that each VRRP router plays and what happens if the virtual router master fails.
If a VRRP router owns the IP address of the virtual router and the IP address of the physical interface,
this router will function as a virtual router master.
Priority also determines if a VRRP router functions as a virtual router backup and the order of
ascendancy to becoming a virtual router master if the virtual router master fails. You can configure the
priority of each virtual router backup with a value of 1 through 254 using the vrrp priority command.
For example, if Router A, the virtual router master in a LAN topology, fails, an election process takes
place to determine if virtual router backups B or C should take over. If Routers B and C are configured
with the priorities of 101 and 100, respectively, Router B is elected to become virtual router master
because it has the higher priority. If Routers B and C are both configured with the priority of 100, the
virtual router backup with the higher IP address is elected to become the virtual router master.
By default, a preemptive scheme is enabled whereby a higher priority virtual router backup that becomes
available takes over for the virtual router backup that was elected to become virtual router master. You
can disable this preemptive scheme using the no vrrp preempt command. If preemption is disabled, the
virtual router backup that is elected to become virtual router master remains the master until the original
virtual router master recovers and becomes master again.

78-17478-01 259
Configuring VRRP
How to Configure VRRP
VRRP Advertisements
The virtual router master sends VRRP advertisements to other VRRP routers in the same group. The
advertisements communicate the priority and state of the virtual router master. The VRRP
advertisements are encapsulated in IP packets and sent to the IP Version 4 multicast address assigned to
the VRRP group. The advertisements are sent every second by default; the interval is configurable.
VRRP Object Tracking

Object tracking is an independent process that manages creating, monitoring, and removing tracked
objects such as the state of the line-protocol of an interface. Clients such as the Hot Standby Router
Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), and now VRRP register their interest with
specific tracked objects and act when the state of an object changes.
Each tracked object is identified by a unique number that is specified on the tracking command-line
interface (CLI). Client processes such as VRRP 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.
VRRP object tracking gives VRRP access to all the objects available through the tracking process. The
tracking process provides the ability to track individual objects such as a the state of an interface line
protocol, state of an IP route, or the reachability of a route.
VRRP provides an interface to the tracking process. Each VRRP group can track multiple objects that
may affect the priority of the VRRP router. You specify the object number to be tracked and VRRP will
be notified of any change to the object. VRRP increments (or decrements) the priority of the virtual
router based on the state of the object being tracked.

• Customizing VRRP, page 261 (optional)
• Enabling VRRP, page 263 (required)
• Disabling VRRP on an Interface, page 264 (optional)
• Configuring VRRP Object Tracking, page 265 (optional)
• Configuring VRRP Authentication, page 267 (optional)
• Enabling the Router to Send SNMP VRRP Notifications, page 274 (optional)

260 78-17478-01
Configuring VRRP
Customizing VRRP
Perform this task to customize VRRP.
Customizing the behavior of VRRP is optional. Be aware that as soon as you enable a VRRP group, that
group is operating. It is possible that if you first enable a VRRP group before customizing VRRP, the
router could take over control of the group and become the virtual router master before you have finished
customizing the feature. Therefore, if you plan to customize VRRP, it is a good idea to do so before
enabling VRRP.
How Object Tracking Affects the Priority of a VRRP Router

The priority of a device can change dynamically if it has been configured for object tracking and the
object that is being tracked goes down. The tracking process periodically polls the tracked objects and
notes any change of value. The changes in the tracked object are communicated to VRRP, either
immediately or after a specified delay. The object values are reported as either up or down. Examples of
objects that can be tracked are the line protocol state of an interface or the reachability of an IP route. If
the specified object goes down, the VRRP priority is reduced. The VRRP router with the higher priority
can now become the virtual router master if it has the vrrp preempt command configured. See the
“VRRP Object Tracking” section for more information on object tracking.
SUMMARY STEPS
1. enable
5. vrrp group description text
6. vrrp group priority level
7. vrrp group preempt [delay minimum seconds]
8. vrrp group timers advertise [msec] interval
9. vrrp group timers learn
DETAILED STEPS

Example:
Router> enable
Example:

78-17478-01 261
Configuring VRRP

Example:
Example:
255.255.255.0
Step 5 vrrp group description text Assigns a text description to the VRRP group.
Example:
Router(config-if)# vrrp 10 description
working-group
Step 6 vrrp group priority level Sets the priority level of the router within a VRRP group.
• The default priority is 100.
Example:
Router(config-if)# vrrp 10 priority 110
Step 7 vrrp group preempt [delay minimum seconds] Configures the router to take over as virtual router master
for a VRRP group if it has a higher priority than the current
virtual router master.
Example:
Router(config-if)# vrrp 10 preempt delay • The default delay period is 0 seconds.
minimum 380
• The router that is IP address owner will preempt,
regardless of the setting of this command.
Step 8 vrrp group timers advertise [msec] interval Configures the interval between successive advertisements
by the virtual router master in a VRRP group.
Example: • The unit of the interval is in seconds unless the msec
Router(config-if)# vrrp 10 timers advertise 110 keyword is specified. The default interval value is
1 second.
Note All routers in a VRRP group must use the same
timer values. If the same timer values are not set, the
routers in the VRRP group will not communicate
with each other and any misconfigured router will
change its state to master.
Step 9 vrrp group timers learn Configures the router, when it is acting as virtual router
backup for a VRRP group, to learn the advertisement
interval used by the virtual router master.
Example:
Router(config-if)# vrrp 10 timers learn

262 78-17478-01
Configuring VRRP
Enabling VRRP
Perform this task to enable VRRP.
SUMMARY STEPS
1. enable
5. vrrp group ip ip-address [secondary]
6. end
7. show vrrp [brief | group]
8. show vrrp interface type number [brief]
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
255.255.255.0
Step 5 vrrp group ip ip-address [secondary] Enables VRRP on an interface.
• After you identify a primary IP address, you can use the
Example: vrrp ip command again with the secondary keyword to
Router(config-if)# vrrp 10 ip 172.16.6.1 indicate additional IP addresses supported by this
group.
Note All routers in the VRRP group must be configured
with the same primary address for the virtual router.
If different primary addresses are configured, the
routers in the VRRP group will not communicate
with each other and any misconfigured router will

78-17478-01 263
Configuring VRRP

Example:
Step 7 Router# show vrrp [brief | group] (Optional) Displays a brief or detailed status of one or all
VRRP groups on the router.
Example:
Router# show vrrp 10
Step 8 Router# show vrrp interface type number [brief] (Optional) Displays the VRRP groups and their status on a
specified interface.
Example:
Router# show vrrp interface ethernet 0
Disabling VRRP on an Interface

Disabling VRRP on an interface allows the protocol to be disabled, but the configuration retained. This
ability was added with the introduction of the VRRP MIB, RFC 2787, Definitions of Managed Objects
for the Virtual Router Redundancy Protocol.
You can use a Simple Network Management Protocol (SNMP) management tool to enable or disable
VRRP on an interface. Because of the SNMP management capability, the vrrp shutdown command was
introduced to represent a method via the CLI for VRRP to show the state that had been configured using
SNMP.
When the show running-config command is entered, you can see immediately if the VRRP group has
been configured and set to enabled or disabled. This is the same functionality that is enabled within the
MIB.
The no form of the command enables the same operation that is performed within the MIB. If the vrrp
shutdown command is specified using the SNMP interface, then entering the no vrrp shutdown
command using the Cisco IOS CLI will reenable the VRRP group.
SUMMARY STEPS
1. enable
5. vrrp group shutdown

264 78-17478-01
Configuring VRRP
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
255.255.255.0
Step 5 vrrp group shutdown Disables VRRP on an interface.
• The command is now visible on the router.
Example: Note You can have one VRRP group disabled, while
Router(config-if)# vrrp 10 shutdown
retaining its configuration, and a different VRRP
group enabled.
Configuring VRRP Object Tracking

Perform the following task to configure VRRP object tracking.
Restrictions
If a VRRP group is the IP address owner, its priority is fixed at 255 and cannot be reduced through object
tracking.
SUMMARY STEPS
1. enable
5. vrrp group ip ip-address
6. vrrp group priority level
7. vrrp group track object-number [decrement priority]

78-17478-01 265
Configuring VRRP
8. end
9. show track [object-number]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track object-number interface type number Configures an interface to be tracked where changes in the
{line-protocol | ip routing} state of the interface affect the priority of a VRRP group.
• This command configures the interface and
Example: corresponding object number to be used with the
Router(config)# track 2 interface serial 6 vrrp track command.
line-protocol
• The line-protocol keyword tracks whether the interface
is up. The ip routing keyword also checks that IP
routing is enabled and active on the interface.
• You can also use the track ip route command to track
the reachability of an IP route or a metric type object.
Example:
Router(config)# interface Ethernet 2
Step 5 vrrp group ip ip-address Enables VRRP on an interface and identifies the IP address
of the virtual router.
Example:
Router(config-if)# vrrp 1 ip 10.0.1.20
Step 6 vrrp group priority level Sets the priority level of the router within a VRRP group.
Example:
Step 7 vrrp group track object-number [decrement Configures VRRP to track an object.
priority]
Example:
Router(config-if)# vrrp 1 track 2 decrement 15

266 78-17478-01
Configuring VRRP

Example:
Step 9 show track [object-number] Displays tracking information.
Example:
Configuring VRRP Authentication

VRRP ignores unauthenticated VRRP protocol messages. The default authentication type is text
authentication.
The following sections describe configuration tasks for VRRP authentication. The task you perform
for authentication.
• Configuring VRRP MD5 Authentication Using a Key String, page 268
• Configuring VRRP MD5 Authentication Using a Key Chain, page 269
• Verifying the VRRP MD5 Authentication Configuration, page 271
• Configuring VRRP Text Authentication, page 272
How VRRP MD5 Authentication Works

authentication allows each VRRP group member to use a secret key to generate a keyed MD5 hash of
the packet that is part of the outgoing packet. A keyed hash of an incoming packet is generated and if
the generated hash does not match the hash within the incoming packet, the packet is ignored.
The key for the MD5 hash can either be given directly in the configuration using a key string or supplied
A router will ignore incoming VRRP packets from routers that do not have the same authentication
configuration for a VRRP group. VRRP has three authentication schemes:
• No authentication
VRRP packets will be rejected in any of the following cases:
• The authentication schemes differ on the router and in the incoming packet.

78-17478-01 267
Configuring VRRP
Restrictions
Interoperability with vendors that may have implemented the RFC 2338 method is not enabled.
Text authentication cannot be combined with MD5 authentication for a VRRP group at any one time.
When MD5 authentication is configured, the text authentication field in VRRP hello messages is set to
all zeroes on transmit and ignored on receipt, provided the receiving router also has MD5 authentication
enabled.
Configuring VRRP MD5 Authentication Using a Key String

Perform this task to configure VRRP MD5 authentication using a key string.
SUMMARY STEPS
1. enable
5. vrrp group priority priority
6. vrrp group authentication md5 key-string [0 | 7] key-string [timeout seconds]
7. vrrp group ip [ip-address [secondary]]
9. end
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
configuration mode.
Example:
interface.
Example:

268 78-17478-01
Configuring VRRP
Command Purpose
Step 5 vrrp group priority priority Configures VRRP priority.
Example:
Step 6 vrrp group authentication md5 key-string [0 | 7] Configures an authentication string for VRRP MD5
key-string [timeout seconds] authentication.
• The key argument can be up to 64 characters in
length and it is recommended that at least 16
Example: characters be used.
Router(config-if)# vrrp 1 authentication md5
key-string d00b4r987654321a timeout 30 • No prefix to the key argument or specifying 0
means the key will be unencrypted.
• Specifying 7 means the key will be encrypted.
The key-string authentication key will
command is enabled.
• The timeout value is the period of time that the
old key string will be accepted to allow
configuration of all routers in a group with a
new key.
Note All routers within the VRRP group must be
configured with the same authentication
string. If the same authentication string is
not configured, the routers in the VRRP
group will not communicate with each
other and any misconfigured router will
Step 7 vrrp group ip [ip-address [secondary]] Enables VRRP on an interface and identifies the IP
address of the virtual router.
Example:
Example:
Configuring VRRP MD5 Authentication Using a Key Chain

Perform this task to configure VRRP MD5 authentication using a key chain. Key chains allow a different
key string to be used at different times according to the key chain configuration. VRRP will query the
SUMMARY STEPS
1. enable

78-17478-01 269
Configuring VRRP
4. key key-id
6. exit
9. vrrp group priority priority
10. vrrp group authentication md5 key-chain key-chain
11. vrrp group ip [ip-address [secondary]]
12. Repeat steps 1 through 11 on each router that will communicate.
13. end
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Example:
Router(config)# key chain vrrp1
Example:
Router(config-keychain-key)# key-string mno172 character cannot be a number.
Example:

270 78-17478-01
Configuring VRRP
Command Purpose
configuration mode.
Example:
interface.
Example:
Step 9 vrrp group priority priority Configures VRRP priority.
Example:
Step 10 vrrp group authentication md5 key-chain key-chain Configures an authentication MD5 key chain for
VRRP MD5 authentication.
Example: • The key chain name must match the name
Router(config-if)# vrrp 1 authentication md5 key-chain specified in Step 3.
vrrp1
Step 11 vrrp group ip [ip-address [secondary]] Enables VRRP on an interface and identifies the IP
Example:
communicate.
Example:
Verifying the VRRP MD5 Authentication Configuration

To verify the MD5 authentication configuration, perform the following steps.
SUMMARY STEPS
1. show vrrp
2. debug vrrp authentication

78-17478-01 271
Configuring VRRP
DETAILED STEPS
Step 1 show vrrp

Use this command to verify that the authentication is configured correctly:
Router# show vrrp
Ethernet0/1 - Group 1
State is Master
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 100
Authentication MD5, key-string “f00d4s”, timeout 30 secs
Master Router is 10.21.0.1 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
This output shows that MD5 authentication is configured and the f00d4s key string is used. The timeout
value is set at 30 seconds.
Step 2 debug vrrp authentication
Use this command to verify that both routers have authentication configured, that the MD5 key ID is the
same on each router, and that the MD5 key strings are the same on each router:
Router# debug vrrp authentication
VRRP: Grp 1 Advertisement from 10.24.1.1 has incorrect authentication type 0 expected 254
!MD5 key IDs differ on each router.
VRRP: Grp 1 recalculate MD5 digest: “3n};oHp8_)_7-C”

VRRP: Grp 1 Advertisement from 10.24.1.1 has FAILED MD5 authentication
!The MD5 key strings differ on each router.
VRRP: Grp 1 received MD5 digest:

“_M_^uMiWo^|t?t2m”
VRRP: Grp 1 Advertisement from 10.24.1.1 has FAILED MD5 authentication
!The text authentication strings differ on each router.
VRRP: Grp 1 Advertisement from 172.24.1.1 has FAILED TEXT authentication
Configuring VRRP Text Authentication

Perform this task to configure VRRP text authentication.
SUMMARY STEPS
1. enable

272 78-17478-01
Configuring VRRP

5. vrrp group authentication text text-string
6. vrrp group ip ip-address
8. end
DETAILED STEPS
Command Purpose
EXEC mode.
Router> enable
Example:
configuration mode.
Example:
interface.
Example:
Step 5 vrrp group authentication text text-string Authenticates VRRP packets received from other
Example: • If you configure authentication, all routers
Router(config-if)# vrrp 1 authentication text within the VRRP group must use the same
textstring1 authentication string.
• The default string is cisco.
Step 6 vrrp group ip ip-address Enables VRRP on an interface and identifies the IP
Example:

78-17478-01 273
Configuring VRRP
Command Purpose
Example:
Enabling the Router to Send SNMP VRRP Notifications

The VRRP MIB supports SNMP Get operations, which allow network devices to get reports about VRRP
groups in a network from the network management station.
Enabling VRRP MIB trap support is performed through the CLI, and the MIB is used for getting the
reports. A trap notifies the network management station when a router becomes a Master or backup
router. When an entry is configured from the CLI, the RowStatus for that group in the MIB immediately
goes to the active state.
SUMMARY STEPS
1. enable
3. snmp-server enable traps vrrp
4. snmp-server host host community-string vrrp
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 snmp-server enable traps vrrp Enables the router to send SNMP VRRP notifications (traps
and informs).
Example:
Router(config)# snmp-server enable traps vrrp
Step 4 snmp-server host host community-string vrrp Specifies the recipient of an SNMP notification operation.
Example:
Router(config)# snmp-server host
myhost.comp.com public vrrp

274 78-17478-01
Configuring VRRP
Configuration Examples for VRRP

• Configuring VRRP: Example, page 275
• VRRP Object Tracking: Example, page 276
• VRRP Object Tracking Verification: Example, page 276
• VRRP MD5 Authentication Configuration Using a Key String: Example, page 277
• VRRP MD5 Authentication Configuration Using a Key Chain: Example, page 277
• VRRP Text Authentication: Example, page 277
• Disabling a VRRP Group on an Interface: Example, page 277
• VRRP MIB Trap: Example, page 278
Configuring VRRP: Example

In the following example, Router A and Router B each belong to three VRRP groups.
In the configuration, each group has the following properties:
• Group 1:
– Virtual IP address is 10.1.0.10.
– Router A will become the master for this group with priority 120.
– Advertising interval is 3 seconds.
– Preemption is enabled.
• Group 5:
– Router B will become the master for this group with priority 200.
– Advertising interval is 30 seconds.
– Preemption is enabled.
• Group 100:
– Router A will become the master for this group first because it has a higher IP address
(10.1.0.2).
– Advertising interval is the default 1 second.
– Preemption is disabled.
Router A
interface ethernet 1/0
ip address 10.1.0.2 255.0.0.0
vrrp 1 priority 120
vrrp 1 authentication cisco
vrrp 1 timers advertise 3
vrrp 1 timers learn
vrrp 1 ip 10.1.0.10
vrrp 5 priority 100
vrrp 5 timers learn
vrrp 5 ip 10.1.0.50
vrrp 100 timers learn

78-17478-01 275
Configuring VRRP
no vrrp 100 preempt

vrrp 100 ip 10.1.0.100
no shutdown
Router B
interface ethernet 1/0
ip address 10.1.0.1 255.0.0.0
vrrp 1 priority 100
vrrp 1 authentication cisco
vrrp 1 timers learn
vrrp 1 ip 10.1.0.10
vrrp 5 priority 200
vrrp 5 timers learn
vrrp 5 ip 10.1.0.50
vrrp 100 timers learn
no vrrp 100 preempt
vrrp 100 ip 10.1.0.100
no shutdown
VRRP Object Tracking: Example

In the following example, the tracking process is configured to track the state of the line protocol on
serial interface 0/1. VRRP on Ethernet interface 1/0 then registers with the tracking process to be
informed of any changes to the line protocol state of serial interface 0/1. If the line protocol state on
serial interface 0/1 goes down, then the priority of the VRRP group is reduced by 15.
track 1 interface Serial0/1 line-protocol
!
ip address 10.0.0.2 255.0.0.0
vrrp 1 ip 10.0.0.3
vrrp 1 priority 120
vrrp 1 track 1 decrement 15
VRRP Object Tracking Verification: Example

The following examples verify the configuration shown in the “VRRP Object Tracking: Example”
section:
Router# show vrrp
Ethernet1/0 - Group 1
State is Master
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption is enabled
min delay is 0.000 sec
Priority is 105
Master Router is 10.0.0.2 (local), priority is 105
Master Advertisement interval is 1.000 sec
Master Down interval is 3.531 sec
Router# show track

276 78-17478-01
Configuring VRRP
Track 1
Interface Serial0/1 line-protocol
Line protocol is Down (hw down)
1 change, last change 00:06:53
Tracked by:
VRRP Ethernet1/0 1
VRRP MD5 Authentication Configuration Using a Key String: Example

The following example shows how to configure MD5 authentication using a key string and timeout of
30 seconds:
description ed1-cat5a-7/10
vrrp 1 ip 10.21.0.10
vrrp 1 priority 110
vrrp 1 authentication md5 key-string f00c4s timeout 30
exit
VRRP MD5 Authentication Configuration Using a Key Chain: Example

The following example shows how to configure MD5 authentication using a key chain:
key chain vrrp1
key 1
key-string f00c4s
exit
!
interface ethernet0/1
description ed1-cat5a-7/10
vrrp 1 priority 110
vrrp 1 authentication md5 key-chain vrrp1
vrrp 1 ip 10.21.0.10
In this example, VRRP queries the key chain to obtain the current live key and key ID for the specified
key chain.
VRRP Text Authentication: Example

The following example shows how to configure VRRP text authentication using a text string:
ip address 10.21.8.32 255.255.255.0
vrrp 10 authentication text stringxyz
vrrp 10 ip 10.21.8.10
Disabling a VRRP Group on an Interface: Example

The following example shows how to disable one VRRP group on Ethernet interface 0/1 while retaining
VRRP for group 2 on Ethernet interface 0/2:
ip address 10.24.1.1 255.255.255.0
vrrp 1 ip 10.24.1.254
vrrp 1 shutdown

78-17478-01 277
Configuring VRRP
ip address 10.168.42.1 255.255.255.0
vrrp 2 ip 10.168.42.254
VRRP MIB Trap: Example

The following example shows how to enable the VRRP MIB trap support functionality:
snmp-server enable traps vrrp
snmp-server host 10.1.1.0 community abc vrrp
The following sections provide references related to VRRP.
Related Documents
VRRP commands: complete command syntax, Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and
command mode, command history, defaults, usage Services, Release 12.4
Key chains and key management: complete command Cisco IOS IP Command Reference, Volume 2 of 4: Routing
syntax, command mode, command history, defaults, Protocols, Release 12.4
usage guidelines, and examples
Object tracking “Configuring Enhanced Object Tracking” module
HSRP “Configuring HSRP” module
GLBP “Configuring GLBP” module
Standards
Standards Title

278 78-17478-01
Configuring VRRP
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 2338 Virtual Router Redundancy Protocol
Description Link
The Cisco Technical Support & Documentation http://www.cisco.com/techsupport
website contains thousands of pages of searchable
technical content, including links to products,
technologies, solutions, technical tips, and tools.

78-17478-01 279
Configuring VRRP
Feature Information for VRRP

features that were introduced or modified in Cisco IOS Release 12.2(1) or Cisco IOS Release 12.2(14)S
or a later release appear in the table.
a specific command was introduced, see the command reference documentation.
If you are looking for information on a feature in this technology that is not documented here, see the
“FHRP Features Roadmap”.
Table 12 Feature Information for VRRP

Virtual Router Redundancy Protocol 12.2(13)T VRRP enables a group of routers to form a single virtual
12.2(14)S router to provide redundancy. The LAN clients can then be
configured with the virtual router as their default gateway.
The virtual router, representing a group of routers, is also
known as a VRRP group.
All sections provide information about this feature.
The following commands were introduced by this feature:
debug vrrp all, debug vrrp error, debug vrrp events,
debug vrrp packets, debug vrrp state, show vrrp, show
vrrp interface, vrrp authentication, vrrp description,
vrrp ip, vrrp preempt, vrrp priority, vrrp timers
advertise, vrrp timers learn.
VRRP Object Tracking 12.3(2)T The VRRP Object Tracking feature extends the capabilities
12.2(25)S of the VRRP to allow tracking of specific objects within the
router that can alter the priority level of a virtual router for
a VRRP group.
feature:
• VRRP Object Tracking, page 260
• Configuring VRRP Object Tracking, page 265
The following command was introduced by this feature:
vrrp track.
The following command was modified by this feature:
show track.

280 78-17478-01
Configuring VRRP
Table 12 Feature Information for VRRP (continued)

VRRP MIB—RFC 2787 12.3(11)T The VRRP MIB—RFC 2787 feature enables an
enhancement to the MIB for use with SNMP-based network
management. The feature adds support for configuring,
monitoring, and controlling routers that use VRRP.
feature:
• Disabling VRRP on an Interface, page 264
• Enabling the Router to Send SNMP VRRP
Notifications, page 274
vrrp shutdown.
snmp-server enable traps and snmp-server host.
FHRP—VRRP Enhancements 12.3(14)T The FHRP—VRRP Enhancements feature adds support for
the following capabilities:
• MD5 Authentication—Added to routers that are
configured for VRRP, similar to HSRP, to provide a
method of authenticating peers using a more simple
method than the method in RFC 2338.
• Bridged Virtual Interface (BVI)—Added the capability
to configure VRRP on BVIs. This functionality is
similar to the existing HSRP support for BVIs.
feature:
• Restrictions for VRRP, page 256
• Configuring VRRP Authentication, page 267
debug vrrp authentication.
vrrp authentication and show vrrp.

78-17478-01 281
Configuring VRRP
Glossary
Glossary
virtual router—One or more VRRP routers that form a group. The virtual router acts as the default
gateway router for LAN clients. Also known as a VRRP group.
virtual router backup—One or more VRRP routers that are available to assume the role of forwarding
packets if the virtual router master fails.
virtual router master—The VRRP router that is currently responsible for forwarding packets sent to
the IP addresses of the virtual router. Usually the virtual router master also functions as the IP address
owner.
virtual IP address owner—The VRRP router that owns the IP address of the virtual router. The owner
is the router that has the virtual router address as its physical interface address.
VRRP router—A router that is running VRRP.
Note See Internetworking Terms and Acronyms for terms not included in this glossary.

282 78-17478-01
Part 7: Enhanced Object Tracking
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 as well as 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 now register its interest in tracking objects and then be notified when
the tracked object changes state.
Module History
This module was first published on May 2, 2005, and last updated on May 2, 2005.

Your Cisco IOS software release may not support all features. To find information about feature support and
configuration, use the “Feature Information for Enhanced Object Tracking” section on page 310.
Contents
• Information About Enhanced Object Tracking, page 285
• How to Configure Enhanced Object Tracking, page 286
• Configuration Examples for Enhanced Object Tracking, page 303
• Feature Information for Enhanced Object Tracking, page 310
Information About Enhanced Object Tracking

Before you configure the Enhanced Object Tracking feature, you should understand the following
concepts:
• Feature Design of Enhanced Object Tracking, page 286

78-17478-01 285
How to Configure Enhanced Object Tracking
• Benefits of Enhanced Object Tracking, page 286
Feature Design of Enhanced Object Tracking

Enhanced Object Tracking 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 command-line
interface (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 also 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 or not the threshold has been met.
• Boolean “and” function—When a tracked list has been assigned a Boolean “and” function, it means
that 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, it means
that at least one object defined within a subset must be in an up state so that the tracked object can
become up.
Benefits of Enhanced Object Tracking

• Increases the availability and speed of recovery of a network.
• Decreases network outages and their duration.
• Provides a scalable solution that allows other client processes such as VRRP and GLBP the ability
to track objects individually or as a list of objects. Prior to the introduction of this functionality, the
tracking process was embedded within HSRP.

The following sections describe configuration tasks for enhanced object tracking:
• Tracking the Line-Protocol State of an Interface, page 287 (optional)
• Tracking the IP-Routing State of an Interface, page 288 (optional)
• Tracking IP-Route Reachability, page 290 (optional)
• Tracking the Threshold of IP-Route Metrics, page 292 (optional)
• Tracking IP SLAs Operations, page 294 (optional)
• Configuring a Tracked List and Boolean Expression, page 298 (optional)
• Configuring a Tracked List and Threshold Weight, page 299 (optional)

286 78-17478-01
• Configuring a Tracked List and Threshold Percentage, page 301 (optional)

• Configuring the Track List Defaults, page 302 (optional)
Tracking the Line-Protocol State of an Interface

Perform this task to track the line-protocol state of an interface.
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.
See the “Tracking the IP-Routing State of an Interface” section for more information.
SUMMARY STEPS
1. enable
3. track timer interface seconds
4. track object-number interface type number line-protocol
5. delay {up seconds [down seconds] | [up seconds] down seconds}
6. end
7. show track object-number
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track timer interface seconds (Optional) Specifies the interval in which the tracking
process polls the tracked object.
Example: • The default interval that the tracking process polls
Router(config)# track timer interface 5 interface objects is 1 second.
Step 4 track object-number interface type number Tracks the line-protocol state of an interface and enters
line-protocol tracking configuration mode.
Example:
Router(config)# track 3 interface ethernet 0/1
line-protocol

78-17478-01 287

Step 5 delay {up seconds [down seconds] | [up seconds] (Optional) Specifies a period of time (in seconds) to delay
down seconds} communicating state changes of a tracked object.
Example:
Router(config-track)# delay up 30
Example:
Router(config-track)# end
Step 7 show track object-number (Optional) Displays tracking information.
• Use this command to verify the configuration. See the
Example: display output in the “Examples” section.
Examples
The following example shows the state of the line protocol on an interface when it is tracked:
Track 3
Interface Ethernet0/1 line-protocol
Line protocol is Up
Tracked by:
HSRP Ethernet0/3 1
Tracking the IP-Routing State of an Interface

Perform this task to track the IP-routing state of an interface. 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 the Dynamic
Host Configuration Protocol (DHCP) or IP Control Protocol (IPCP) negotiation.
Interface IP routing will go down when one of the following criteria exist:
• 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 Point-to-Point Protocol (PPP), the line protocol could be
up (link control protocol [LCP] negotiated successfully), but IP could be down (IPCP negotiation failed).

288 78-17478-01
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
SUMMARY STEPS
1. enable
3. track timer interface seconds
4. track object-number interface type number ip routing
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track timer interface seconds (Optional) Specifies the interval in which the tracking
Router(config)# track timer interface 5 interface objects is 1 second.
Step 4 track object-number interface type number ip Tracks the IP-routing state of an interface and enters
routing tracking configuration mode.
• IP-route tracking tracks an IP route in the routing table
Example: and the ability of an interface to route IP packets.
Router(config)# track 1 interface ethernet 0/1
ip routing
Example:

78-17478-01 289

Example:
Step 7 show track object-number Displays tracking information.
Examples
The following example shows the state of IP routing on an interface when it is tracked:
Track 1
Interface Ethernet0/1 ip routing
IP routing is Up
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
3. track timer ip route seconds
4. track object-number ip route ip-address/prefix-length reachability
6. ip vrf vrf-name
7. end

290 78-17478-01
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track timer ip route seconds (Optional) Specifies the interval in which the tracking
Router(config)# track timer ip route 20 IP-route objects is 15 seconds.
Step 4 track object-number ip route Tracks the reachability of an IP route and enters tracking
ip-address/prefix-length reachability configuration mode.
Example:
Router(config)# track 4 ip route 10.16.0.0/16
reachability
Example:
Step 6 ip vrf vrf-name (Optional) Configures a VPN routing and forwarding
(VRF) table.
Example:
Router(config-track)# ip vrf VRF2
Example:
Examples
The following example shows the state of the reachability of an IP route when it is tracked:
Track 4
IP route 10.16.0.0 255.255.0.0 reachability
Reachability is Up (RIP)

78-17478-01 291
First-hop interface is Ethernet0/1

Tracked by:
HSRP Ethernet0/3 1
Tracking the Threshold of IP-Route Metrics

Perform this task to track the threshold of IP route metrics.
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, route
metric values are normalized 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.
Table 13 shows the default values used for the conversion. You can use the track resolution command
to change the metric resolution default values.
Table 13 Metric Conversion
Route Type1 Metric Resolution

Static 10
Enhanced Interior Gateway 2560
Routing Protocol (EIGRP)
Open Shortest Path First 1
(OSPF)
Intermediate 10
System-to-Intermediate
System (IS-IS)
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 go above the maximum limit with a 2-Mbps 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.

292 78-17478-01
SUMMARY STEPS
1. enable
3. track timer ip route seconds
4. track resolution ip route {eigrp resolution-value | isis resolution-value | ospf resolution-value |
static resolution-value}
5. track object-number ip route ip-address/prefix-length metric threshold
7. ip vrf vrf-name
8. threshold metric {up number down number | up number | down number}
9. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track timer ip route seconds (Optional) Specifies the interval in which the tracking
Router(config)# track timer ip route 20 IP-route objects is 15 seconds.
Step 4 track resolution ip route {eigrp (Optional) Specifies resolution parameters for a tracked
resolution-value | isis resolution-value | ospf object.
resolution-value | static resolution-value}
• Use this command to change the default metric
resolution values.
Example:
Router(config)# track resolution ip route eigrp
300
Step 5 track object-number ip route ip-address/ Tracks the scaled metric value of an IP route to determine if
prefix-length metric threshold it is above or below a threshold.
• The default down value is 255, which equates to an
Example: inaccessible route.
Router(config)# track 6 ip route 10.16.0.0/16
metric threshold • The default up value is 254.

78-17478-01 293

Example:
Step 7 ip vrf vrf-name (Optional) Configures a VRF table.
Example:
Router(config-track)# ip vrf VRF1
Step 8 threshold metric {up number down number | up (Optional) Sets a metric threshold other than the default
number | down number} value.
Example:
Router(config-track)# threshold metric up 254
down 255
Example:
Examples
The following example shows the metric threshold of an IP route when it is tracked:
Track 6
IP route 10.16.0.0 255.255.0.0 metric threshold
Metric threshold is Up (RIP/6/102)
Metric threshold down 255 up 254
First-hop interface is Ethernet0/1
Tracked by:
HSRP Ethernet0/3 1
Tracking IP SLAs Operations

Perform the following tasks to track Cisco IOS IP Service Level Agreements (SLAs) operations:
• Tracking the State of an IP SLAs Operation, page 295
• Tracking the Reachability of an IP SLAs IP Host, page 296
Object tracking of IP SLAs operations allows tracking clients to track the output from IP SLAs objects
and use the provided information to trigger an action.

294 78-17478-01
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 relates to the acceptance of the OverThreshold return code. Table 14 shows the state and
reachability aspects of IP SLAs operations that can be tracked.
Table 14 Comparison of State and Reachability Operations
Tracking Return Code Track State

State OK Up
(all other return codes) Down
Reachability OK or OverThreshold Up
(all other return codes) Down
Tracking the State of an IP SLAs Operation

Perform this task to track the state of an IP SLAs operation.
SUMMARY STEPS
1. enable
3. track object-number rtr operation-number state
5. end

78-17478-01 295
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track object-number rtr operation-number state Tracks the state of an IP SLAs object and enters tracking
configuration mode.
Example:
Router(config)# track 2 rtr 4 state
Example:
Router(config-track)# delay up 60 down 30
Example:
Example: display output in the “Examples” section of this task.
Examples
The following example shows the state of the IP SLAs tracking:
Track 2
Response Time Reporter 1 state
State is Down
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

Perform this task to track the reachability of an IP host.

296 78-17478-01
SUMMARY STEPS
1. enable
3. track object-number rtr operation-number reachability
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track object-number rtr operation-number Tracks the reachability of an IP SLAs IP host and enters
reachability tracking configuration mode.
Example:
Router(config)# track 3 rtr 4 reachability
Example:
Router(config-track)# delay up 30 down 10
Example:
Example: display output in the “Examples” section of this task.
Examples
The following example shows whether the route is reachable:
Track 3
Response Time Reporter 1 reachability
Reachability is Up

78-17478-01 297

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 tracking two interfaces using
the “and” operator, up means that both interfaces are up, and down means that either interface is down.
You may also configure a tracked list state to be measured using a weight or percentage threshold. See
“Configuring a Tracked List and Threshold Weight” section on page 299 and “Configuring a Tracked
List and Threshold Percentage” section on page 301.
Note The “not” operator is specified for one or more objects and negates the state of the object.
Prerequisites
An object must exist before it can be added to a tracked list.
SUMMARY STEPS
1. enable
3. track track-number list boolean {and | or}
4. object object-number [not]
6. end
DETAILED STEPS

Example:
Router> enable
Example:

298 78-17478-01

Step 3 track track-number list boolean {and | or} Configures a tracked list object and enters tracking
configuration mode. The keywords are as follows:
Example: • boolean—Specifies that the state of the tracked list is
Router(config-track)# track 100 list boolean based on a Boolean calculation. The keywords are as
and follows:
– and—Specifies that the list is up if all objects are
up, or down if one or more objects are down. For
example when tracking two interfaces, up means
that both interfaces are up, and down means that
either interface is down.
– or—Specifies that the list is up if at least one object
is up. For example, when tracking two interfaces,
up means that either interface is up, and down
means that both interfaces are down.
Step 4 object object-number [not] Specifies the object to be tracked. The object-number
argument has a valid range from 1 to 500. There is no
default. The optional not keyword negates the state of the
Example:
Router(config-track)# object 3 not
object.
Note The example means that when object 3 is up, the
tracked list detects object 3 as down.
Step 5 delay {up seconds [down seconds] | [up seconds] (Optional) Specifies a tracking delay in seconds between up
down seconds} and down states.
Example:
Example:
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 its objects. A tracked list contains one or more objects. Using a
threshold weight, the state of each object is determined 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 on page 298 and the
“Configuring a Tracked List and Threshold Percentage” section on page 301.
Prerequisites

78-17478-01 299
Restrictions
You cannot use the Boolean “not” operator in a weight or percentage threshold list.
SUMMARY STEPS
1. enable
3. track track-number list threshold weight
4. object object-number [weight weight-value]
5. threshold weight {up number down number | up number | down number}
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track track-number list threshold weight Configures a tracked list object and enters tracking
Example: • threshold—Specifies that the state of the tracked list is
Router(config-track)# track 100 list threshold based on a threshold.
weight
• weight—Specifies that the threshold is based on a
specified weight.
Step 4 object object-number [weight weight-number] Specifies the object to be tracked. The object-number
default. The optional weight keyword specifies a threshold
Example:
Router(config-track)# object 3 weight 30
weight for each object.
Step 5 threshold weight {up number down number | up Specifies the threshold weight. The keywords and
number | down number} arguments are as follows:
• up number—Valid range is from 1 to 255.
Example:
Router(config-track)# threshold weight up 30
• 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.

300 78-17478-01

Example:
Example:
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. Using the threshold percentage, the state of the list is determined 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 “Configuring a Tracked List and Boolean Expression” section on page 298 and
“Configuring a Tracked List and Threshold Weight” section on page 299.
Prerequisites
Restrictions
You cannot use the Boolean “not” operator in a weight or percentage threshold list.
SUMMARY STEPS
1. enable
3. track track-number list threshold percentage
4. object object-number
5. threshold percentage {up number down number | up number | down number}
7. end

78-17478-01 301
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track track-number list threshold percentage Configures a tracked list object and enters tracking
Example: • threshold—Specifies that the state of the tracked list is
Router(config-track)# track 100 list threshold based on a threshold.
percentage
• percentage—Specifies that the threshold is based on a
percentage.
Step 4 object object-number Specifies the object to be tracked. The object-number
default.
Example:
Router(config-track)# object 3
Step 5 threshold percentage {up number down number | up Specifies the threshold percentage. The keywords and
number | down number} arguments are as follows:
• up number—Valid range is from 1 to 100.
Example:
Router(config-track)# threshold percentage up
• down number—Range depends upon what you have
30 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:
Example:
Configuring the 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.

302 78-17478-01
Configuration Examples for Enhanced Object Tracking
SUMMARY STEPS
1. enable
3. track track-number
4. default {delay | object object-number | threshold percentage}
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 track track-number Enters tracking configuration mode.
Example:
Router(config)# track 3
Step 4 default {delay | object object-number | Specifies a default delay value for a tracked list, a default
threshold percentage} object, and default threshold parameters for a tracked list.
The keywords and arguments are as follows:
Example: • delay—Reverts to the default delay.
Router(config-track)# default delay
• object object-number—Specifies a default object for
the track list. The valid range is from 1 to 500.
• threshold percentage—Specifies a default threshold
percentage.
Example:

• Interface Line Protocol: Example, page 304
• Interface IP Routing: Example, page 304
• IP-Route Reachability: Example, page 305
• IP-Route Threshold Metric: Example, page 306

78-17478-01 303
• IP SLAs IP Host Tracking: Example, page 306

• Boolean Expression for a Tracked List: Example, page 306
• Threshold Weight for a Tracked List: Example, page 307
• Threshold Percentage for a Tracked List: Example, page 308
Interface Line Protocol: Example

The following example is very similar to the IP-routing example. Instead, the tracking process is
configured to track the line-protocol state of serial interface 1/0. HSRP on Ethernet interface 0/0 then
registers with the tracking process to be informed of any changes to the line-protocol state of serial
interface 1/0. If the line protocol on serial interface 1/0 goes down, the priority of the HSRP group is
reduced by 10.
track 100 interface serial1/0 line-protocol
!
ip address 10.1.0.21 255.255.0.0
standby 1 preempt
!
ip address 10.1.0.22 255.255.0.0
standby 1 preempt
Interface IP Routing: Example

In the following example, the tracking process is configured to track the IP-routing capability of serial
interface 1/0. HSRP on Ethernet interface 0/0 then registers with the tracking process to be informed of
any changes to the IP-routing state of serial interface 1/0. If the IP-routing state on serial interface 1/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 serial interface 1/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 Figure 14 for a sample topology.

304 78-17478-01
Figure 14 Topology for IP-Routing Support
s1/0 s1/0
88323
Router A Router B
e0/0 e0/0
10.1.0.0
!
ip address 10.1.0.21 255.255.0.0
standby 1 preempt
!
ip address 10.1.0.22 255.255.0.0
standby 1 preempt
IP-Route Reachability: Example

In the following example, the tracking process is configured to track the reachability of IP route
10.2.2.0/24:
track 100 ip route 10.2.2.0/24 reachability
!
ip address 10.1.1.21 255.255.255.0
standby 1 preempt
track 100 ip route 10.2.2.0/24 reachability
!
ip address 10.1.1.22 255.255.255.0
standby 1 preempt

78-17478-01 305
IP-Route Threshold Metric: Example

In the following example, the tracking process is configured to track the threshold metric of IP route
10.2.2.0/24:
track 100 ip route 10.2.2.0/24 metric threshold
!
ip address 10.1.1.21 255.255.255.0
standby 1 preempt
track 100 ip route 10.2.2.0/24 metric threshold
!
ip address 10.1.1.22 255.255.255.0
standby 1 preempt
IP SLAs IP Host Tracking: Example

The following example shows how to configure IP host tracking for IP SLAs operation 1:
ip sla monitor 1
type echo protocol ipIcmpEcho 10.51.12.4
timeout 1000
frequency 3
threshold 2
request-data-size 1400
ip sla monitor schedule 1 start-time now life forever
!
track 2 rtr 1 state
track 3 rtr 1 reachability
!
ip address 10.21.0.4 255.255.0.0
no shutdown
standby 3 ip 10.21.0.10d
standby 3 preempt
Boolean Expression for a Tracked List: Example

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

306 78-17478-01
track 100 list boolean and

object 1
object 2
In the following example, a track list object is configured to track two serial interfaces when either serial
interface is up and when both serial interfaces are down:
track 101 list boolean or

object 1
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):
track 4 list boolean and
object 1
object 2 not
Threshold Weight for a Tracked List: Example

In the following example, three serial 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:
track 100 list threshold weight

object 1 weight 20
object 2 weight 20
object 3 weight 20
threshold weight down 0 up 40
The above example means that the track-list object goes down only when all three serial interfaces go
down, and only comes up again when at least two serial interfaces are up (since 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.
track 4 list threshold weight
object 1 weight 15
object 2 weight 20
object 3 weight 30
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.

78-17478-01 307
Threshold Percentage for a Tracked List: Example

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

object 1
object 2
object 3
object 4
threshold percentage up 75
For following sections provide references related to Enhanced Object Tracking.
Related Documents
HSRP concepts and configuration tasks “Configuring HSRP” module
GLBP concepts and configuration tasks “Configuring GLBP” module
VRRP concepts and configuration tasks “Configuring VRRP” module
GLBP, HSRP, and VRRP commands: complete Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and
command syntax, command mode, command history, Services, Release 12.4
Standards
Standards Title
MIBs
MIBs MIBs Link

308 78-17478-01
RFCs
RFCs Title
Description Link
even more content.

78-17478-01 309
Glossary
Glossary
DHCP—Dynamic Host Configuration Protocol. DHCP is a protocol that delivers IP addresses and
configuration information to network clients.
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.
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.
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, which 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.
Note Refer to Internetworking Terms and Acronyms for terms not included in this glossary.
Feature Information for Enhanced Object Tracking

features that were introduced or modified in Cisco IOS Releases 12.2(1) or 12.0(3)S or later appear in
the table.
specific commands was introduced, see the command reference documents.

310 78-17478-01
Table 15 Feature Information for Enhanced Object Tracking

Enhanced Object Tracking 12.2(15)T The Enhanced Object Tracking feature separates the
12.2(25)S 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.
feature:
• Tracking the Line-Protocol State of an Interface,
page 287
• Tracking the IP-Routing State of an Interface, page 288
• Tracking IP-Route Reachability, page 290
• Tracking the Threshold of IP-Route Metrics, page 292
this feature: debug track, delay tracking, ip vrf, show
track, standby track, threshold metric, track interface,
track ip route, and track timer.
FHRP - Enhanced Object Tracking of IP SLAs 12.3(4)T This feature enables first-hop redundancy protocols
Operations 12.2(25)S (FHRPs) and other enhanced object tracking clients to track
the output from the IP SLAs objects and use the provided
information to trigger an action.
The following section provides information about this
feature:
• Tracking IP SLAs Operations, page 294
track rtr.
FHRP - Object Tracking List 12.3(8)T 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.
feature:
• Configuring a Tracked List and Boolean Expression,
page 298
• Configuring a Tracked List and Threshold Weight,
page 299
• Configuring a Tracked List and Threshold Percentage,
page 301
• Configuring the Track List Defaults, page 302
this feature: show track, threshold percentage, threshold
weight, track list, track resolution.

78-17478-01 311

312 78-17478-01

Cisco IOS IP Application Services Configuration Guide, Release 12.4

Uploaded by

Copyright:

Available Formats

You might also like

Cisco IOS IP Application Services Configuration Guide, Release 12.4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IOS IP Application Services Configuration Guide, Release 12.4

Uploaded by

Copyright:

Available Formats

Cisco IOS IP Application Services

Customer Order Number: DOC-7817478=

Cisco IOS IP Application Services Configuration Guide

About Cisco IOS Software Documentation for Release 12.4 xix

Documentation Objectives xix

Documentation Organization for Cisco IOS Release 12.4 xx

Document Conventions xxvi

Obtaining Documentation xxvii

Cisco Product Security Overview xxix

Obtaining Technical Assistance xxx

Using Cisco IOS Software for Release 12.4 xxxiii

Understanding Command Modes xxxiii

Getting Help xxxiv

Using the no and default Forms of Commands xxxviii

Saving Configuration Changes xxxviii

Filtering Output from the show and more Commands xxxix

Finding Additional Feature Support Information xxxix

How to Configure IP Services 3

Cisco IOS IP Application Services Configuration Guide

Enabling ICMP Redirect Messages 4

PART 2: IP ACCESS LISTS

Configuring IP Access Lists 17

Information About Access Lists 17

Cisco IOS IP Application Services Configuration Guide

Controlling Policy Routing and the Filtering of Routing Information 29

Distributed Time-Based Access Lists 35

Supported Standards, MIBs, and RFCs 36

Monitoring and Maintaining Distributed Time-Based Access Lists 38

IP Access List Entry Sequence Numbering 41

Restrictions for IP Access List Entry Sequence Numbering 41

Information About IP Access Lists 42

Cisco IOS IP Application Services Configuration Guide

IP Access List Entry Sequence Numbering 44

ACL IP Options Selective Drop 53

Restrictions for ACL IP Options Selective Drop 53

Information About ACL IP Options Selective Drop 54

How to Configure ACL IP Options Selective Drop 54

ACL Support for Filtering IP Options 59

Cisco IOS IP Application Services Configuration Guide

Restrictions for the ACL Support for Filtering IP Options Feature 59

Information About ACL Support for Filtering IP Options 60

How to Configure the ACL Support for Filtering IP Options Feature 61

ACL TCP Flags Filtering 67

Restrictions for ACL TCP Flags Filtering 67

Information About the ACL TCP Flags Filtering Feature 68

ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry 73

Cisco IOS IP Application Services Configuration Guide

Configuring TCP Performance Parameters 83

How to Configure TCP Performance Parameters 83

TCP Window Scaling 87

Supported Standards, MIBs, and RFCs 89

Cisco IOS IP Application Services Configuration Guide

TCP Congestion Avoidance 93

TCP Explicit Congestion Notification 95

How to Configure TCP Explicit Congestion Notification 96

Configuration Examples for TCP Explicit Congestion Notification 99

PART 4: SERVER LOAD BALANCING

Configuring Server Load Balancing 105