Table Of Contents
Enabling ICMP Protocol Unreachable Messages
Enabling ICMP Redirect Messages
Enabling ICMP Mask Reply Messages
Understanding Path MTU Discovery
Configuring Simplex Ethernet Interfaces
Configuring a DRP Server Agent
Limiting the Source of DRP Queries
Configuring Authentication of DRP Queries and Responses
Creating Standard and Extended Access Lists Using Numbers
Creating Standard and Extended Access Lists Using Names
Specifying IP Extended Access Lists with Fragment Control
Policy Routing and Fragment Control
Applying Time Ranges to Access Lists
Including Comments About Entries in Access Lists
Controlling Access to a Line or Interface
Controlling Policy Routing and the Filtering of Routing Information
Configuring HSRP Group Attributes
Changing the HSRP MAC Refresh Interval
Configuring IP Precedence Accounting
Configuring TCP Performance Parameters
Compressing TCP Packet Headers
Expressing TCP Header Compression
Changing the Number of TCP Header Compression Connections
Setting the TCP Connection Attempt Time
Enabling TCP Path MTU Discovery
Enabling TCP Selective Acknowledgment
Setting the TCP Maximum Read Size
Setting the TCP Outgoing Queue Size
Configuring the MultiNode Load Balancing Forwarding Agent
MultiNode Load Balancing Forwarding Agent Configuration Task List
Enabling Cisco Express Forwarding
Configuring the Router as a Forwarding Agent
Monitoring and Maintaining the IP Network
Clearing Caches, Tables, and Databases
Monitoring and Maintaining the DRP Server Agent
Clearing the Access List Counters
Displaying System and Network Statistics
Monitoring the MNLB Forwarding Agent
IP Services Configuration Examples
Simplex Ethernet Interfaces Example
Implicit Masks in Access Lists Examples
IP Extended Access List with Fragment Control Example
Time Range Applied to an IP Access List Example
Commented IP Access List Entry Examples
HSRP MAC Refresh Interval Examples
No Switch or Learning Bridge Present Example
Switch or Learning Bridge Present Example
MNLB Forwarding Agent Examples
Configuring IP Services
Release 12.1
June 29, 2000This chapter describes how to configure optional IP services. For a complete description of the IP services commands in this chapter, refer to the "IP Services Commands" chapter of the Cisco IOS IP and IP Routing Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
IP Services Task List
To configure optional IP services, perform any of the tasks in the following sections:
•
Configuring TCP Performance Parameters
•
•
Remember that not all the tasks in these sections are required. The tasks you must perform will depend on your network and your needs.
At the end of this chapter, the examples in the "IP Services Configuration Examples" section illustrate how you might configure your network using IP.
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.
To manage various aspects of IP connections, perform the appropriate tasks in the following sections:
•
•
•
•
•
•
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:
ip unreachables
Enable 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:
Router(config)# ip icmp rate-limit unreachable [df] milliseconds
Limits the rate that ICMP destination unreachable messages are 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 packet's originator 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. However, when Hot Standby Router Protocol (HSRP) is configured on an interface, ICMP Redirect messages are disabled by default for the interface.
To enable the sending of ICMP Redirect messages if this feature was disabled, use the following command in interface configuration mode:
Enabling ICMP Mask Reply Messages
Occasionally, network devices must know the subnet mask for a particular subnetwork in the internetwork. To achieve this information, such devices can send ICMP Mask Request messages. These messages are responded to by ICMP Mask Reply messages 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:
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 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 15.
Figure 15 IP Path MTU Discovery
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 15, 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 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 first 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
If a router that is configured with a small MTU on an outbound interface receives packets from 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 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 if an IP packet exceeds the MTU set for an interface, the Cisco IOS software will fragment it.
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:
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.
IP provides a provision that allows the source IP host to specify a route through the IP network. This provision is known as source routing. 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:
Configuring Simplex Ethernet Interfaces
You can configure simplex Ethernet interfaces. This feature is useful for setting up dynamic IP routing over a simplex circuit (a circuit that receives only or sends only). When a route is learned on a receive-only interface, the interface designated as the source of the route is converted to the interface you specify. When packets are routed out this specified interface, they are sent to the IP address of the source of the routing update. To reach this IP address on a transmit-only Ethernet link, a static Address Resolution Protocol (ARP) entry mapping this IP address to the hardware address of the other end of the link is required.
To assign a transmit interface to a receive-only interface, use the following command in interface configuration mode:
transmit-interface type number
Assign a transmit interface to a receive-only interface.
See the "Simplex Ethernet Interfaces Example" section at the end of this chapter for an example of configuring a simplex Ethernet interface.
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 Cisco's 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.
Perform the tasks in the following sections to configure and maintain the DRP Server Agent. The first task is required; the remaining tasks are 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" 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:
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:
ip drp access-group access-list-number
Control the sources of valid DRP queries by applying a standard IP 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:
When configuring your key chains and keys, be aware of the following:
•
•
•
•
•
Filtering IP Packets
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.
You can use access lists in the following ways:
•
•
•
This section summarizes how to create IP access lists and how to apply them.
See the "IP Services Configuration Examples" section at the end of this chapter for examples of configuring IP access lists.
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.
2.
These and other tasks are described in this section and are labeled as required or optional. Either the first or second task is required, depending on whether you identify your access list with a number or a name. The last task is also required in order to use the access list.
•
•
•
•
•
•
Creating Standard and Extended Access Lists Using Numbers
Caution
The software supports the following styles of access lists for IP:
•
•
•
•
To create a standard access list, use the following commands in global configuration mode:
Step 1
access-list access-list-number remark remark
Indicates the purpose of the deny or permit statement.1
Step 2
access-list access-list-number {deny | permit} source [source-wildcard] [log]
or
access-list access-list-number {deny | permit} any [log]
Defines a standard IP access list using a source address and wildcard.
Defines a standard IP access list using an 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 command. This capability was previously only available in extended IP access lists.
The first packet that triggers the access list causes a logging message right away, 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
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
Note
For an example of a standard IP access list using logs, see the section "Numbered Access List Examples" at the end of this chapter.
To create an extended access list, use the following commands in global configuration mode:
Step 1
access-list access-list-number remark remark
Indicates the purpose of the deny or permit statement.1
Step 2
access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] [time-range time-range-name] [fragments]
or
access-list access-list-number {deny | permit} protocol any any [log] [time-range time-range-name] [fragments]
or
access-list access-list-number {deny | permit} protocol host source host destination [log] [time-range time-range-name] [fragments]
or
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] [time-range time-range-name] [fragments]
Defines an extended IP access list number and the access conditions. Use the log keyword to get access list logging messages, including violations. Specifies a time range to restrict when the permit or deny statement is in effect.
or
Defines an extended IP access list using an abbreviation for a source and source wildcard of 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
Defines an extended IP access list using an 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
Defines a dynamic access list. For information about lock-and-key access, refer to the "Configuring Traffic Filters" chapter in the Cisco IOS Security Configuration Guide.
1 This example configures the remark before the deny or permit statement. The remark can be configured after the deny or permit statement.
After an access list is created initially, any subsequent additions (possibly entered from the terminal) are placed 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
Note
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 Examples" section at the end of this chapter for examples of implicit masks.
Creating Standard and Extended Access Lists Using Names
Caution
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 before configuring named access lists:
•
•
•
•
To create a standard access list, use the following commands beginning in global configuration mode:
Step 1
ip access-list standard name
Defines a standard IP access list using a name and enters standard named access list configuration mode.
Step 2
remark remark
Allows you to comment about the following deny or permit statement in a named access list.1
Step 3
deny {source [source-wildcard] | any}[log]
or
permit {source [source-wildcard] | any}[log]
Specifies one or more conditions allowed or denied, which determines whether the packet is passed or dropped.
Step 4
exit
Exits access-list configuration mode.
.1 This example configures the remark before the deny or permit statement. The remark can be configured after the deny or permit statement.
To create an extended access list, use the following commands beginning in global configuration mode:
Step 1
ip access-list extended name
Defines an extended IP access list using a name.
Step 2
remark remark
Allows you to comment about the following deny or permit statement in a named access list.1
Step 3
deny | permit protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] [time-range time-range-name] [fragments]
or
deny | permit protocol any any [log] [time-range time-range-name] [fragments]
or
deny | permit protocol host source host destination [log] [time-range time-range-name] [fragments]
or
dynamic dynamic-name [timeout minutes] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] [time-range time-range-name] [fragments]
In access-list configuration mode, specifies the conditions allowed or denied. Use the log keyword to get access list logging messages, including violations. Specifies a time range to restrict when the permit or deny statement is in effect.
or
Defines an extended IP access list using an abbreviation for a source and source wildcard of 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
Defines an extended IP access list using an 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
Defines a dynamic access list. For information about lock-and-key access, refer to the "Configuring Traffic Filters" chapter in the Cisco IOS Security Configuration Guide.
.1 This example configures the remark before the deny or permit statement. The remark can be configured after the deny or permit statement.
Note
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.
Note
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 document 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 several IP access list commands. 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.
The behavior of access-list entries regarding the presence or absence of the fragments keyword can be summarized as follows:
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.
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
For an example of fragment control in an IP extended access list, see the IP Extended Access List with Fragment Control Example.
Policy Routing and Fragment Control
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
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.
Applying Time Ranges to Access Lists
It is now possible to implement access lists based on the time of day and week using the time-range 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 and argument are 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 time-range command is configured 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 examples of IP time ranges.
There are many possible benefits of using time ranges, such as the following:
•
•
–
–
•
•
•
•
Including Comments About Entries in Access Lists
It is now possible to include comments (remarks) about entries in any IP access list using the remark 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. The several ways to use an access list are described in the following sections:
•
•
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. The following two tables show how to accomplish this task for both terminal lines and network interfaces. Remember the following:
•
•
To restrict access to a virtual terminal line 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.
access-class access-list-number {in | out}
Restrict incoming and outgoing connections between a particular virtual terminal line (into a device) and the addresses in an access list.
To restrict access to an interface, use the following command in interface configuration mode:
ip access-group {access-list-number | name} {in | out}
Control access to an interface.
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 guide.
Controlling Dialer Functions
To use access lists to control dialer functions, refer to the Cisco IOS Dial Services Configuration Guide: Terminal Services and Cisco IOS Dial Services Configuration Guide: Network Services publications.
Configuring HSRP
HSRP provides high network availability because it routes IP traffic from hosts on Ethernet, FDDI, or Token Ring networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an active router and a standby router. (An active router is the router of choice for routing packets; a standby router is a router that takes over the routing duties when an active router fails, or when preset conditions are met.)
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 the HSRP is configured on a network segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among routers in a group of routers that is running HSRP. One of these devices is selected by the protocol to be the active router. The active router receives and routes packets destined for the group's MAC address. For n routers running HSRP, there are n + 1 IP and MAC addresses assigned.
HSRP detects when the designated active router fails, at which point a selected standby router assumes control of the Hot Standby group's MAC and IP addresses. A new standby router is also selected at that time.
Devices that are running HSRP send and receive multicast UDP-based hello packets to detect router failure and to designate active and standby routers.
When HSRP is configured on an interface, ICMP Redirect messages are disabled by default for the interface.
You can configure multiple Hot Standby groups on an interface, thereby making fuller use of the redundant routers. To do so, specify a group number for each Hot Standby command you configure for the interface.
Note
Note
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.
Use the commands in the following sections to configure HSRP:
•
•
•
For more information about HSRP and how to configure it on a Cisco router, see the chapter "Using HSRP for Fault-Tolerant IP Routing" in the Cisco CCIE Fundamentals: Case Studies publication.
Enabling HSRP
To enable the HSRP on an interface, use the following command in interface configuration mode:
Configuring HSRP Group Attributes
To configure other Hot Standby group attributes that affect how the local router participates in HSRP, use one or more of the following commands in interface configuration mode:
Changing the 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 don't need them (if you have FDDI but do not have a learning bridge or switch). When changing the HSRP MAC refresh interval, be aware of the following items:
•
•
By default, a packet is sent every 10 seconds to refresh the MAC cache on learning bridges or switches. To change the interval, use the following command in interface configuration mode:
For examples of this feature, see the section "HSRP MAC Refresh Interval Examples" at the end of this chapter.
Enabling HSRP MIB Traps
With Cisco IOS Release 12.0(3)T, the software supports the HSRP Management MIB feature. HSRB 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 done from the command-line interface (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 feature supports four MIB tables:
•
•
For descriptions of supported MIBs and how to use MIBs, see Cisco's MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
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.
To enable HSRP MIB trap support, use the following commands in global configuration mode:
