Thursday, 25 December 2014

Anycast RP

Anycast RP




IP multicast is deployed as an integral component in mission-critical networked applications throughout the world. These applications must be robust, hardened, and scalable to deliver the reliability that users demand.
Using Anycast RP is an implementation strategy that provides load sharing and redundancy in Protocol Independent Multicast sparse mode (PIM-SM) networks. Anycast RP allows two or more rendezvous points (RPs) to share the load for source registration and the ability to act as hot backup routers for each other. Multicast Source Discovery Protocol (MSDP) is the key protocol that makes Anycast RP possible.
The scope of this document is to explain the basic concept of MSDP and the theory behind Anycast RP. It also provides an example of how to deploy Anycast RP.
This document has the following sections:

Multicast Source Discovery Protocol Overview

In the PIM sparse mode model, multicast sources and receivers must register with their local rendezvous point (RP). Actually, the router closest to a source or a receiver registers with the RP, but the key point to note is that the RP "knows" about all the sources and receivers for any particular group. RPs in other domains have no way of knowing about sources located in other domains. MSDP is an elegant way to solve this problem.
MSDP is a mechanism that allows RPs to share information about active sources. RPs know about the receivers in their local domain. When RPs in remote domains hear about the active sources, they can pass on that information to their local receivers. Multicast data can then be forwarded between the domains. A useful feature of MSDP is that it allows each domain to maintain an independent RP that does not rely on other domains, but it does enable RPs to forward traffic between domains. PIM-SM is used to forward the traffic between the multicast domains.
The RP in each domain establishes an MSDP peering session using a TCP connection with the RPs in other domains or with border routers leading to the other domains. When the RP learns about a new multicast source within its own domain (through the normal PIM register mechanism), the RP encapsulates the first data packet in a Source-Active (SA) message and sends the SA to all MSDP peers. Each receiving peer uses a modified Reverse Path Forwarding (RPF) check to forward the SA, until the SA reaches every MSDP router in the interconnected networks—theoretically the entire multicast internet. If the receiving MSDP peer is an RP, and the RP has a (*, G) entry for the group in the SA (there is an interested receiver), the RP creates (S, G) state for the source and joins to the shortest path tree for the source. The encapsulated data is decapsulated and forwarded down the shared tree of that RP. When the last hop router (the router closest to the receiver) receives the multicast packet, it may join the shortest path tree to the source. The MSDP speaker periodically sends SAs that include all sources within the domain of the RP. Figure 1 shows how data would flow between a source in domain A to a receiver in domain E.
MSDP was developed for peering between Internet service providers (ISPs). ISPs did not want to rely on an RP maintained by a competing ISP to provide service to their customers. MSDP allows each ISP to have its own local RP and still forward and receive multicast traffic to the Internet.
Figure 1 MSDP Example: MSDP Shares Source Information Between RPs in Each Domain

Anycast RP Overview

Anycast RP is a useful application of MSDP. Originally developed for interdomain multicast applications, MSDP used for Anycast RP is an intradomain feature that provides redundancy and load-sharing capabilities. Enterprise customers typically use Anycast RP for configuring a Protocol Independent Multicast sparse mode (PIM-SM) network to meet fault tolerance requirements within a single multicast domain.
In Anycast RP, two or more RPs are configured with the same IP address on loopback interfaces. The Anycast RP loopback address should be configured with a 32-bit mask, making it a host address. All the downstream routers should be configured to "know" that the Anycast RP loopback address is the IP address of their local RP. IP routing automatically will select the topologically closest RP for each source and receiver. Assuming that the sources are evenly spaced around the network, an equal number of sources will register with each RP. That is, the process of registering the sources will be shared equally by all the RPs in the network.
Because a source may register with one RP and receivers may join to a different RP, a method is needed for the RPs to exchange information about active sources. This information exchange is done with MSDP.
In Anycast RP, all the RPs are configured to be MSDP peers of each other. When a source registers with one RP, an SA message will be sent to the other RPs informing them that there is an active source for a particular multicast group. The result is that each RP will know about the active sources in the area of the other RPs. If any of the RPs were to fail, IP routing would converge and one of the RPs would become the active RP in more than one area. New sources would register with the backup RP. Receivers would join toward the new RP and connectivity would be maintained.
Note that the RP is normally needed only to start new sessions with sources and receivers. The RP facilitates the shared tree so that sources and receivers can directly establish a multicast data flow. If a multicast data flow is already directly established between a source and the receiver, then an RP failure will not affect that session. Anycast RP ensures that new sessions with sources and receivers can begin at any time.

Anycast RP Example

The main purpose of an Anycast RP implementation is that the downstream multicast routers will "see" just one address for an RP. The example given in Figure 2 shows how the loopback 0 interface of the RPs (RP1 and RP2) is configured with the same 10.0.0.1 IP address. If this 10.0.0.1 address is configured on all RPs as the address for the loopback 0 interface and then configured as the RP address, IP routing will converge on the closest RP. This address must be a host route—note the 255.255.255.255 subnet mask.
The downstream routers must be informed about the 10.0.0.1 RP address. In Figure 2, the routers are configured statically with the ip pim rp-address 10.0.0.1 global configuration command. This configuration could also be accomplished using the Auto-RP or bootstrap router (BSR) features.
The RPs in Figure 2 must also share source information using MSDP. In this example, the loopback 1 interface of the RPs (RP1 and RP2) is configured for MSDP peering. The MSDP peering address must be different than the Anycast RP address.
Figure 2 Anycast RP Configuration
Many routing protocols choose the highest IP address on loopback interfaces for the Router ID. A problem may arise if the router selects the Anycast RP address for the Router ID. We recommend that you avoid this problem by manually setting the Router ID on the RPs to the same address as the MSDP peering address (for example, the loopback 1 address in Figure 2). In Open Shortest Path First (OSPF), the Router ID is configured using the router-id router configuration command. In Border Gateway Protocol (BGP), the Router ID is configured using the bgp router-id router configuration command. In many BGP topologies, the MSDP peering address and the BGP peering address must be the same in order to pass the RPF check. The BGP peering address can be set using the neighbor update-source router configuration command.
The Anycast RP example in the previous paragraphs used IP addresses from RFC 1918. These IP addresses are normally blocked at interdomain borders and therefore are not accessible to other ISPs. You must use valid IP addresses if you want the RPs to be reachable from other domains.

Related Documents

•IP Multicast Technology Overview, Cisco white paper
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm
•Interdomain Multicast Solutions Using MSDP, Cisco integration solutions document
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_p1/mcstmsdp/index.htm
•Configuring a Rendezvous Point, Cisco white paper
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/rps.htm
•"Configuring Multicast Source Discovery Protocol," Cisco IOS IP Configuration Guide, Release 12.2
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmsdp.htm
•"Multicast Source Discovery Protocol Commands," Cisco IOS IP Command Reference, Volume 3 of 3: Multicast, Release 12.2

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprmc_r/1rfmsdp.htm

Saturday, 20 December 2014

Multicast

Multicast

Multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of corporate recipients and homes. Applications that take advantage of multicast technologies include video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news.

Multicast Group Concept


Multicast is based on the concept of a group. A multicast group is an arbitrary group of receivers that expresses an interest in receiving a particular data stream. This group has no physical or geographical boundaries—the hosts can be located anywhere on the Internet or any private internetwork. Hosts that are interested in receiving data flowing to a particular group must join the group using IGMP (IGMP is discussed in the "Internet Group Management Protocol (IGMP)" section later in this document). Hosts must be a member of the group to receive the data stream.

IP Multicast Addresses


IP multicast addresses specify a "set" of IP hosts that have joined a group and are interested in receiving multicast traffic designated for that particular group. IPv4 multicast address conventions are described in the following sections.

IP Class D Addresses


The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. IANA has assigned the IPv4 Class D address space to be used for IP multicast. Therefore, all IP multicast group addresses fall in the range from 224.0.0.0 through 239.255.255.255.

Note The Class D address range is used only for the group address or destination address of IP multicast traffic. The source address for multicast datagrams is always the unicast source address.


Table 1 gives a summary of the multicast address ranges discussed in this document.

Table 1 Multicast Address Range Assignments

Description

Range

Reserved Link Local Addresses

224.0.0.0/24

Globally Scoped Addresses

224.0.1.0 to 238.255.255.255

Source Specific Multicast

232.0.0.0/8

GLOP Addresses

233.0.0.0/8

Limited Scope Addresses

239.0.0.0/8

Reserved Link Local Addresses


The IANA has reserved addresses in the range 224.0.0.0/24 to be used by network protocols on a local network segment. Packets with these addresses should never be forwarded by a router. Packets with link local destination addresses are typically sent with a time-to-live (TTL) value of 1 and are not forwarded by a router.

Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, Open Shortest Path First (OSPF) uses the IP addresses 224.0.0.5 and 224.0.0.6 to exchange link-state information. Table 2 lists some well-known link local IP addresses.

Table 2 Examples of Link Local Addresses

IP Address

Usage

224.0.0.1

All systems on this subnet

224.0.0.2

All routers on this subnet

224.0.0.5

OSPF routers

224.0.0.6

OSPF designated routers

224.0.0.12

Dynamic Host Configuration Protocol (DHCP) server/relay agent

Globally Scoped Addresses


Addresses in the range from 224.0.1.0 through 238.255.255.255 are called globally scoped addresses. These addresses are used to multicast data between organizations and across the Internet.

Some of these addresses have been reserved for use by multicast applications through IANA. For example, IP address 224.0.1.1 has been reserved for Network Time Protocol (NTP).

IP addresses reserved for IP multicast are defined in RFC 1112, Host Extensions for IP Multicasting. More information about reserved IP multicast addresses can be found at the following location:
http://www.iana.org/assignments/multicast-addresses.


Note You can find all RFCs and Internet Engineering Task Force (IETF) drafts on the IETF website (http://www.ietf.org).


Source Specific Multicast Addresses


Addresses in the 232.0.0.0/8 range are reserved for Source Specific Multicast (SSM). SSM is an extension of the PIM protocol that allows for an efficient data delivery mechanism in one-to-many communications. SSM is described in the "Source Specific Multicast (SSM)" section later in this document.

GLOP Addresses


RFC 2770, GLOP Addressing in 233/8, proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. This practice is called GLOP addressing. The AS number of the domain is embedded into the second and third octets of the 233.0.0.0/8 address range. For example, the AS 62010 is written in hexadecimal format as F23A. Separating the two octets F2 and 3A results in 242 and 58 in decimal format. These values result in a subnet of 233.242.58.0/24 that would be globally reserved for AS 62010 to use.

Limited Scope Addresses


Addresses in the 239.0.0.0/8 range are called limited scope addresses or administratively scoped addresses. These addresses are described in RFC 2365, Administratively Scoped IP Multicast, to be constrained to a local group or organization. Companies, universities, or other organizations can use limited scope addresses to have local multicast applications that will not be forwarded outside their domain. Routers typically are configured with filters to prevent multicast traffic in this address range from flowing outside of an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so that local multicast boundaries can be defined. This subdivision is called address scoping and allows for address reuse between these smaller domains.

Layer 2 Multicast Addresses


Historically, network interface cards (NICs) on a LAN segment could receive only packets destined for their burned-in MAC address or the broadcast MAC address. In IP multicast, several hosts need to be able to receive a single data stream with a common destination MAC address. Some means had to be devised so that multiple hosts could receive the same packet and still be able to differentiate between several multicast groups.

One method to accomplish this is to map IP multicast Class D addresses directly to a MAC address. Today, using this method, NICs can receive packets destined to many different MAC addresses—their own unicast, broadcast, and a range of multicast addresses.

The IEEE LAN specifications made provisions for the transmission of broadcast and multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast or multicast frame. Figure 2 shows the location of the broadcast or multicast bit in an Ethernet frame. 

Figure 2 IEEE 802.3 MAC Address Format


This bit indicates that the frame is destined for a group of hosts or all hosts on the network (in the case of the broadcast address, 0xFFFF.FFFF.FFFF).

IP multicast makes use of this capability to send IP packets to a group of hosts on a LAN segment.

 

Tuesday, 2 December 2014

DMVNP

Introduction:

This document gives a brief information about DMVPN with a configuration example where you can see DMVPN without IPSEC and with IPSEC.

What is DMVPN?

DMVPN stands for Dynamic Multipoint VPN and it is an effective solution for dynamic secure overlay networks. In short, DMVPN is combination of the following technologies:

  • Multipoint GRE (mGRE)
  • Next-Hop Resolution Protocol (NHRP)
  • Dynamic IPsec encryption
 
Dynamic Multipoint VPN (DMVPN) is Cisco’s answer to the increasing demands of enterprise companies to be able to connect branch offices with head offices and between each other while keeping costs low, minimizing configuration complexity and increasing flexibility.

With DMVPN, one central router, usually placed at the head office, undertakes the role of the Hub while all other branch routers are Spokes that connect to the Hub router so the branch offices can access the company’s resources. DMVPN consists of two mainly deployment designs:
  • DMVPN Hub & Spoke, used to perform headquarters-to-branch interconnections
  • DMVPN Spoke-to-Spoke, used to perform branch-to-branch interconnections
In both cases, the Hub router is assigned a static public IP Address while the branch routers (spokes) can be assigned static or dynamic public IP addresses.

Example:

Physical Connectivity:

DMVPN Operation - How DMVPN Operates

Before diving into the configuration of our routers, we’ll briefly explain how the DMVPN is expected to work. This will help in understanding how DMVPN operates in a network:
  • Each spoke has a permanent IPSec tunnel to the hub but not to the other spokes within the network.
  • Each spoke registers as a client of the NHRP server. The Hub router undertakes the role of the NHRP server.
  • When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.
  • After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPSec tunnel to the target spoke.
  • The spoke-to-spoke tunnel is built over the multipoint GRE (mGRE) interface.
  • The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.
  • All data traversing the GRE tunnel is encrypted using IPSecurity (optional)


 configuration:

ROUTER 4 ISP

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 speed auto
 full-duplex
!
interface FastEthernet0/1
 ip address 192.168.2.1 255.255.255.0
 speed auto
 full-duplex
!
interface FastEthernet1/0
 ip address 192.168.3.1 255.255.255.0
 speed auto
 full-duplex


ROUTER 1 (Hub)

interface Loopback0
 ip address 192.168.0.1 255.255.255.0
 !
!
interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source 192.168.1.100
 tunnel mode gre multipoint
 !
!
interface FastEthernet0/0
 ip address 192.168.1.100 255.255.255.0
 duplex full
 speed auto
 !
!
ip route 192.168.2.0 255.255.255.0 192.168.1.1
ip route 192.168.3.0 255.255.255.0 192.168.1.1
!

ROUTER 2


!
interface Loopback0
 ip address 172.16.2.1 255.255.255.0
 !
!
interface Tunnel0
 ip address 10.1.1.2 255.255.255.0
 no ip redirects
 ip nhrp map 10.1.1.1 192.168.1.100
 ip nhrp map multicast 192.168.1.100
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source 192.168.2.2
 tunnel mode gre multipoint
 !
!
interface FastEthernet0/0
 ip address 192.168.2.2 255.255.255.0
 duplex full
 speed auto
 !

!
ip route 192.168.1.100 255.255.255.255 192.168.2.1
!

!


-==ROUTER 3
!
interface Loopback0
 ip address 172.16.3.1 255.255.255.0
 !
!
interface Tunnel0
 ip address 10.1.1.3 255.255.255.0
 no ip redirects
 ip nhrp map multicast 192.168.1.100
 ip nhrp map 10.1.1.1 192.168.1.100
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 tunnel source 192.168.3.3
 tunnel mode gre multipoint
 !
!
interface FastEthernet0/0
 ip address 192.168.3.3 255.255.255.0
 duplex full
 speed auto
 !
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
 !
!
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip route 192.168.1.100 255.255.255.255 192.168.3.1
!
!

-==== Until here we have the DMVPN without IPSEC-===

IPSEC:

Next you will need to add IPSEC, this will ensure that traffic is not sent in clear text. This configuration will be added to each router except router 4.

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key firewall address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
!
then 

(config-t) #
(config-if)#tunnel protection ipsec profile protect-gre

-=========
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Verification

R1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1     192.168.2.2        10.1.1.2    UP 00:00:00     D
     1     192.168.3.3        10.1.1.3    UP 00:00:01     D



R1#sh crypto session
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.2.2 port 500
  IKE SA: local 192.168.1.100/500 remote 192.168.2.2/500 Active
  IKE SA: local 192.168.1.100/500 remote 192.168.2.2/500 Inactive
  IPSEC FLOW: permit 47 host 192.168.1.100 host 192.168.2.2
        Active SAs: 2, origin: crypto map

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.3.3 port 500
  IKE SA: local 192.168.1.100/500 remote 192.168.3.3/500 Active
  IKE SA: local 192.168.1.100/500 remote 192.168.3.3/500 Inactive
  IPSEC FLOW: permit 47 host 192.168.1.100 host 192.168.3.3
        Active SAs: 2, origin: crypto map

!!!!!!!!!!!!!!!!!!!!!!!!!!!!! R2

R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1   192.168.1.100        10.1.1.1    UP 00:08:19     SR2 


R2#sh crypto session
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.1.100 port 500
  IKE SA: local 192.168.2.2/500 remote 192.168.1.100/500 Active
  IPSEC FLOW: permit 47 host 192.168.2.2 host 192.168.1.100
        Active SAs: 2, origin: crypto map

!!!!!!!!!!!!!!R3

R3#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1   192.168.1.100        10.1.1.1    UP 00:08:59     S


R3#sh crypto session
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.1.100 port 500
  IKE SA: local 192.168.3.3/500 remote 192.168.1.100/500 Active
  IPSEC FLOW: permit 47 host 192.168.3.3 host 192.168.1.100
        Active SAs: 2, origin: crypto map

Wednesday, 27 August 2014

icmp unrechable and redirect

Information About ICMP Unreachable Destination Counters

To configure the ICMP Unreachable Counters feature, you should understand the following concepts:

ICMP Overview

Originally created for the TCP/IP suite in RFC 792, the Internet Control Message Protocol (ICMP) was designed to report a small set of error conditions. ICMP also can report a wide variety of error conditions, provide feedback and testing capabilities. It is a valuable support tool because each message uses a common format and is sent and received by using the same protocol rules.
ICMP enables IP to perform addressing, datagram packaging, and routing by allowing encapsulated messages to be sent and received between IP devices. These messages are encapsulated in IP datagrams just like any other IP message. When the message is generated, the original IP header is encapsulated in the ICMP message and these two pieces are encapsulated within a new IP header to be returned as an error report to the sending device.
ICMP messages are sent in several situations: for example, when a datagram cannot reach its destination, when the gateway does not have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a shorter route. To avoid the infinite regress of messages about messages, no ICMP messages are sent about ICMP messages.
ICMP does not make IP reliable or ensure the delivery of datagrams or the return of a control message. Some datagrams may be dropped without any report of their loss. The higher-level protocols that use IP must implement their own reliability procedures if reliable communication is required.
For information about IPv6 and ICMP, refer to Cisco IOS IPv6 Configuration Guide, Release 12.4 and Cisco IOS IPv6 Command Reference, Release 12.4.

Type 3 Destination Unreachable Error Messages

Type 3 error messages are sent when a message cannot be delivered completely to the application at a destination host. Six codes contained in the ICMP header describe the unreachable condition as follows:
•0—Network unreachable
•1—Host unreachable
•2—Protocol unreachable
•3—Port unreachable
•4—Fragmentation needed and Don't Fragment (DF) bit set
•5—Source route failed
Cisco IOS software can suppress the generation of ICMP unreachable destination error messages, which is called rate-limiting. The default is no unreachable messages more often than once every half second. Separate intervals can be configured for code 4 and all other unreachable destination error messages. However, there is no method of displaying how many ICMP messages have not been sent.
The ICMP Unreachable Destination Counters feature provides a method to count and display the unsent Type 3 messages. This feature also provides console logging with error messages when there are periods of excessive rate limiting that would indicate a Denial of Service (DoS) attack against the router.

Denial of Service Attack

A DoS attack occurs when a stream of ICMP echo requests (pings) are broadcast to a destination subnet. The source addresses of these requests are falsified to be the source address of the target. For each request sent by the attacker, many hosts on the subnet will respond flooding the target and wasting bandwidth. The most common DoS attack is called a "smurf" attack, named after an executable program and is in the category of network-level attacks against hosts. DoS attacks can be easily detected when error-message logging of the ICMP Unreachable Destination Counters feature is enabled.

How to Configure ICMP Unreachable Destination Counters

This section contains the following procedures:

Clearing the ICMP Unreachable Destination Packet Statistics

Perform this task to clear all of the unreachable destination packet statistics. This task is beneficial to begin a new log after the thresholds have been set.

SUMMARY STEPS

1. enable
2. clear ip icmp rate-limit [interface-type interface-number]
3. end

DETAILED STEPS


 
Command or Action
Purpose
Step 1 
enable
Example:
Router> enable
Enables privileged EXEC mode.
•Enter your password if prompted.
Step 2 
clear ip icmp rate-limit [interface-type interface-number]
Example:
Router# clear ip icmp rate-limit ethernet 2/3
Clears all current ICMP unreachable statistics for all configured interfaces. The optional interface-type and interface-number arguments clear the statistics for only one interface.
Note Refer to the interface command in the Cisco IOS Interface and Hardware Component Command Reference, Release 12.4 for valid interface types.
Step 3 
end
Example:
Router# end
Exits to user EXEC mode.

Configuring ICMP Unreachable Destination Counters and Logging Intervals

Perform this task to specify an interval number for unreachable destination messages and a packet counter (threshold) and interval to trigger a logging message to a console. Counting begins as soon as this command is configured.

SUMMARY STEPS

1. enable
2. configure terminal
3. ip icmp rate-limit unreachable [df] [ms] [log [packets] [interval-ms]]
4. exit

DETAILED STEPS


 
Command or Action
Purpose
Step 1 
enable
Example:
Router> enable
Enables privileged EXEC mode.
•Enter your password if prompted.
Step 2 
configure terminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3 
ip icmp rate-limit unreachable [df] [ms] [log [packets] [interval-ms]]
Example:
Router(config)# ip icmp rate-limit unreachable df log 1100 12000
Specifies the rate limitation of ICMP unreachable destination messages and the error message log threshold for generating a message. The default is no unreachable messages are sent more often than once every half second.
The arguments and keywords are as follows:
•df—(Optional) When Don't Fragment (DF) bit is set in the ICMP header, a datagram cannot be fragmented. If the df keyword is not specified, all other types of destination unreachable messages are sent.
•ms—(Optional) Interval at which unreachable messages are generated. The valid range is from 1 ms to 4294967295 ms.
•log—(Optional) List of error messages. The arguments are as follows:
–packets—(Optional) Number of packets that determine a threshold for generating a log. The default is 1000 packets.
–interval-ms—(Optional) Time limit for an interval for which a logging message is triggered. The default is 60000 ms, which is 1 minute.
Note Counting begins as soon as this command is configured.
Step 4 
exit
Example:
Router(config)# exit
Exits to privileged EXEC mode.

Displaying the ICMP Unreachable Destination Packets

Perform this optional task to display all of the unreachable destination packet statistics, which include dropped packets. Counting begins as soon as ip icmp rate-limit unreachable command is configured.

SUMMARY STEPS

1. enable
2. show ip icmp rate-limit [interface-type interface-number]
3. end

DETAILED STEPS


 
Command or Action
Purpose
Step 1 
enable
Example:
Router> enable
Enables privileged EXEC mode.
•Enter your password if prompted.
Step 2 
show ip icmp rate-limit [interface-type interface-number]
Example:
Router# show ip icmp rate-limit ethernet 2/3
Displays all current ICMP unreachable statistics for all configured interfaces. The optional interface-type and interface-number arguments displays the statistics for only one interface.
Note Refer to the interface command in the Cisco IOS Interface and Hardware Component Command Reference, Release 12.4 for valid interface types.
Step 3 
end
Example:
Router# end
Exits to user EXEC mode.

Examples

The following output using the show ip icmp rate-limit command displays the unreachable destinations by interface:
Router# show ip icmp rate-limit 

                           DF bit unreachables       All other unreachables
Interval (millisecond)     500                       500

Interface                  # DF bit unreachables     # All other unreachables 
---------                  ---------------------     ------------------------ 
Ethernet0/0                0                         0                        
Ethernet0/2                0                         0                        
Serial3/0/3                0                         19 

The greatest number of unreachables is on serial interface 3/0/3.

Configuration Examples for ICMP Unreachable Packet Counters

This section provides the following configuration example:

ICMP Rate-Limit Unreachable Log Configuration: Example

In the following example, console logging begins with a packet threshold of 1200 and every 120,000 ms:
ip icmp rate-limit unreachable log 1200 120000

Additional References

The following sections provide references related to ICMP Unreachable Destination Counters feature.

Related Documents


Related Topic
Document Title
IP application services configuration tasks
Cisco IOS IP Addressing and Services Configuration Guide, Release 12.3
IP application services commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Application Services Command Reference, Release 12.4T
Interface and hardware component commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS Interface and Hardware Component Command Reference, Release 12.4T

Standards


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

MIBs


MIBs
MIBs Link
No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

RFCs


RFCs
Title
RFC 792
Internet Control Message Protocol

Technical Assistance


Description
Link
Technical Assistance Center (TAC) home page, containing 30,000 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.

Command Reference

This section documents new and modified commands only.
New Commands
Modified Commands

clear ip icmp rate-limit

To clear all Internet Control Message Protocol (ICMP) unreachable rate-limiting statistics or all statistics for a specified interface, use the clear ip icmp rate-limit command in privileged EXEC mode.
clear ip icmp rate-limit [interface-type interface-number]

Syntax Description


interface-type
(Optional) Type of interface to be configured. Refer to the interface command in the Cisco IOS Interface and Hardware Component Command Reference, Release 12.4 for a list of valid interface types.
interface-number
(Optional) Port, connector, or interface card number. On Cisco 4700 series routers, specifies the network interface module (NIM) or network processor module (NPM) number. The numbers are assigned at the factory at the time of installation or when added to a system, and can be displayed with the show interfaces command.

Defaults

All unreachable statistics for all devices are cleared.

Command Modes

Privileged EXEC

Command History


Release
Modification
12.4(2)T
This command was introduced.

Examples

The following example shows how to clear all unreachable statistics on all interfaces:
Router# clear icmp rate-limit

Related Commands


Command
Description
ip icmp rate-limit unreachable
Limits the rate at which ICMP unreachable messages are generated for a destination.
show ip icmp rate-limit
Displays all ICMP unreachable rate-limiting statistics or all statistics for a specified interface.

ip icmp rate-limit unreachable

To limit the rate at which Internet Control Message Protocol (ICMP) unreachable messages are generated for a destination, use the ip icmp rate-limit unreachable command in global configuration mode. To use the default, use the no form of this command.
ip icmp rate-limit unreachable [df] [ms] [log [packets] [interval-ms]]
no ip icmp rate-limit unreachable [df] [ms] [log [packets] [interval-ms]]

Syntax Description


df
(Optional) Don't Fragment (DF) bit is set. The optional ms argument is a time limit in milliseconds (ms) in which one unreachable message is generated. If the df keyword is specified, its ms argument remains independent from those of general destination unreachable messages.
The valid range is from 1 ms to 4294967295 ms.
Note Counting begins as soon as this command is configured.
log
(Optional) Logging of generated messages that show packets that could not reach a destination at a specified threshold. The optional packets argument specifies a packet threshold. When it is reached, a log message is generated on the console. The default is 1000 packets. The optional interval-ms argument is a time limit for the interval for which a logging message is triggered. The default is 60000 ms, which is 1 minute.

Defaults

The default value is one ICMP destination unreachable message per 500 ms.

Command Modes

Global configuration

Command History


Release
Modification
12.0
This command was introduced.
12.4(2)T
The packets and the interval-ms arguments and log keyword were introduced.

Usage Guidelines

Counting of packets begins when the command is configured and a packet threshold is specified.
The no ip icmp rate-limit unreachable command turns off the previously configured rate limit. To reset the rate limit to its default value, use the ip icmp rate-limit unreachable command default.
Cisco IOS software maintains two timers: one for general destination unreachable messages and one for DF destination unreachable messages. Both share the same time limits and defaults. If the df option is not configured, the ip icmp rate-limit unreachable command sets the time values in ms for DF destination unreachable messages.

Examples

The following example sets the rate of the ICMP destination unreachable message to one message every 10 ms:
ip icmp rate-limit unreachable 10

The following example turns off the previously configured rate limit:
no ip icmp rate-limit unreachable

The following example sets the rate limit back to the default:
no ip icmp rate-limit unreachable

The following example sets a logging packet threshold and time interval:
ip icmp rate-limit unreachable log 1200 120000

Related Commands


Command
Description
clear ip icmp rate-limit
Clears all ICMP unreachable destination messages or all statistics for a specified interface.
show ip icmp rate-limit
Displays all ICMP unreachable destination messages or all statistics for a specified interface.


show ip icmp rate-limit

To display all Internet Control Message Protocol (ICMP) unreachable destination messages or unreachable destination messages for a specified interface including the number of dropped packets, use the show ip icmp rate-limit command in privileged EXEC mode.
show ip icmp rate-limit [interface-type interface-number]

Syntax Description


interface-type
(Optional) Interface type. Type of interface to be configured.
Note Refer to the interface command in the Cisco IOS Interface and Hardware Component Command Reference, Release 12.4 for a list of interface types.
interface-number
(Optional) Port, connector, or interface card number. On Cisco 4700 series routers, specifies the network interface module (NIM) or network processor module (NPM) number. The numbers are assigned at the factory at the time of installation or when added to a system, and can be displayed with the show interfaces command.

Defaults

All unreachable statistics for all devices are displayed.

Command Modes

Privileged EXEC

Command History


Release
Modification
12.4(2)T
This command was introduced.

Examples

The following is sample output when the show ip icmp rate-limit command is entered and unreachable messages are generated:
Router# show ip icmp rate-limit

                           DF bit unreachables        All other unreachables
Interval (millisecond)     500                        500

Interface                  # DF bit unreachables     # All other unreachables 
---------                  ---------------------     ------------------------ 
Ethernet0/0                0                         0                        
Ethernet0/2                0                         0                        
Serial3/0/3                0                         19

The greatest number of unreachables on Serial3/0/3 is 19.
The following is sample output when the show ip icmp rate-limit command is entered and the rate-limit interval has been set at 500. The packet threshold has been set at 1 by using the ip icmp rate-limit unreachable command, so the logging will display on the console when the threshold is exceeded. The total suppressed packets since last log message is displayed.
Router# show ip icmp rate-limit

00:04:18: %IP-3-ICMPRATELIMIT: 2 unreachables rate-limited within 60000 milliseconds on 
Serial3/0/3. 17 log messages suppressed since last log message displayed on Serial3/0/3

Table 1 describes the significant fields shown in the display.
Table 1 show ip icmp rate-limit Field Descriptions 
Field
Description
ICMPRATELIMIT
ICMP packets that are rate limited.
suppressed
Packets that have been suppressed because the destination is unreachable.

-================================


How ICMP Redirect Messages Work

ICMP redirect messages are used by routers to notify the hosts on the data link that a better route is available for a particular destination.
For example, the two routers R1 and R2 are connected to the same Ethernet segment as Host H. The default gateway for Host H is configured to use router R1. Host H sends a packet to router R1 to reach the destination on Remote Branch office Host 10.1.1.1. Router R1, after it consults its routing table, finds that the next-hop to reach Host 10.1.1.1 is router R2. Now router R1 must forward the packet out the same Ethernet interface on which it was received. Router R1 forwards the packet to router R2 and also sends an ICMP redirect message to Host H. This informs the host that the best route to reach Host 10.1.1.1 is by way of router R2. Host H then forwards all the subsequent packets destined for Host 10.1.1.1 to router R2.
43_01.gif
This debug message shows router R1, as in the network diagram, sending an ICMP redirect message to Host H (172.16.1.1).
R1#
debug ip icmp


ICMP packet debugging is on

*Mar 18 06:28:54: ICMP:redirect sent to 172.16.1.1 for dest 10.1.1.1, use gw 172.16.1.200

R1# 
Router R1 (172.16.1.100) sends a redirect to Host H (172.16.1.1) to use router R2 (172.16.1.200) as the gateway to reach the destination 10.1.1.1.

When Are ICMP Redirects Sent?

Cisco routers send ICMP redirects when all of these conditions are met:
  • The interface on which the packet comes into the router is the same interface on which the packet gets routed out.
  • The subnet or network of the source IP address is on the same subnet or network of the next-hop IP address of the routed packet.
  • The datagram is not source-routed.
  • The kernel is configured to send redirects. (By default, Cisco routers send ICMP redirects. The interface subcommand no ip redirects can be used to disable ICMP redirects.)
Note: ICMP redirects are disabled by default if Hot Standby Router Protocol (HSRP) is configured on the interface. In Cisco IOS Software Release 12.1(3)T and later, ICMP Redirect is allowed to be enabled on interfaces configured with HSRP. For more information, refer to HSRP Support for ICMP Redirects section of Hot Standby Router Protocol Features and Functionality.
For example, if a router has two IP addresses on one of its interfaces:
  interface ethernet 0

  ip address 171.68.179.1 255.255.255.0

  ip address 171.68.254.1 255.255.255.0 secondary
If the router receives a packet that is sourced from a host in the subnet 171.68.179.0 and destined to a host in the subnet 171.68.254.0, the router does not send an ICMP redirect because only the first condition is met, not the second.
The original packet for which the router sends a redirect still gets routed to the correct destination.

Related Commands


Command
Description
clear icmp rate-limit
Clears all ICMP unreachable destination messages or all messages for a specified interface.
ip icmp rate-limit unreachable
Limits the rate at which ICMP unreachable messages are generated for a destination.