From: Andrew Bruce Caslow (abcaslow@netmasterclass.net)
Date: Fri Dec 08 2006 - 02:53:38 ART
Hi Mathew,
The command you ask about - "ip icmp rate-limit unreachable" - is a global
configuration command used to limit the rate at which a router responds to
ICMP Type 3 echo requests. It is a useful command if the router itself is
generating ICMP Type 3 echo request messages. In the smurf attack scenario I
mentioned to you, the routers were either forwarding the ICMP ECHO-REPLY
messages generated by end stations or receiving the ECHO-REPLY messages. The
router attached to the amplifying network forwards the ICMP ECHO-REPLY
messages. The router attached to the edge of the internetwork where the
ultimate victim interface is attached will receive the ICMP ECHO-REPLY
messages. In fact, the Internet attached router interface is many times the
victim of a smurf attack.
For those that missed this SMURF/ICMP flood discussion, go to:
http://netmasterclass.com/site/articles/A%20Brief%20Description%20of%20an%20
ICMP%20Flood%20Attack.pdf
Note: Matt pointed out to me that part of this PDF references a 140.10
prefix and another part references a 172.16 prefix. For consistency's sake,
refer to all prefixes with the 172.16 prefix. I will edit the PDF tomorrow.
Again to restate what I said earlier, this new command you are studying -
the "ip icmp rate-limit unreachable" is a global configuration command used
to limit that rate at which a router "generates" ICMP Type 3 echo requests.
Let's attempt to perform a "proof by debug" to prove my assertion. Let's
take two routers attached to a common subnet with the following basic
config:
R1:
interface FastEthernet0/0
ip address 144.44.16.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 144.44.16.6
R2#
interface FastEthernet0/0
ip address 144.44.16.6 255.255.255.0
!
ip icmp rate-limit unreachable 2000 <= This value is in millisec.
With these simple configurations, I generate the following ping to the
next-hop router with a destination address that is not in the next-hop
router's routing table. This will cause it to generate an ICMP Type 3
"unreachable" message. These messages are reflected by the letter "U" in IOS
PING output. See below. In this first output, I generate a "one U followed
by two dots" pattern:
R1#ping 200.1.1.1 rep 1000 ti 1
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 200.1.1.1, timeout is 1 seconds:
U..U..U..U..U..
Success rate is 0 percent (0/15)
Now, I increase the icmp rate-limit unreachable setting to 4 sec. (4000 ms):
ip icmp rate-limit unreachable 4000 <= This value is in millisec.
In this second output, I generate "a one U followed by four dots" pattern:
R1#ping 200.1.1.1 rep 1000 ti 1
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 200.1.1.1, timeout is 1 seconds:
U....U....U....U..
Success rate is 0 percent (0/18)
The behavior of this command can be further demonstrated by enabling "Debug
ip icmp" and examining the timestamps of the debug messages. Let's take a
look:
First:
ip icmp rate-limit unreachable 2000 <= This value is in millisec.
*Dec 7 10:26:37: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6.U.
*Dec 7 10:26:39: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6.U.
*Dec 7 10:26:41: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6.U.
*Dec 7 10:26:43: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6.U.
*Dec 7 10:26:45: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6.U.
Notice all of the timestamps above are two seconds apart.
Next:
ip icmp rate-limit unreachable 4000 <= This value is in millisec.
*Dec 7 10:25:54: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6...U.
*Dec 7 10:25:58: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6...U.
*Dec 7 10:26:02: ICMP: dst (144.44.16.1) host unreachable rcv from
144.44.16.6...U.
Notice all of the timestamps above are four seconds apart.
Quod erat demonstrandum (Q.E.D) Proof by Debug! : )
Try re-constructing this little test yourself. It will have two benefits -
(1) you will gain a better understanding of this command and (2) you will
become more comfortable with this "proof by debug" analysis method and
learning technique. In the best of all possible worlds, you will establish
the goal of making any explanation you obtain about the operation of any
internetworking technology come alive with the Cisco IOS! It's lots of fun
to do this. I feel like I really understand something if I can see it
operate, or if I can explicitly make it come to life. With Dynamips, it is
so easy to perform these little mini-scenarios and make internetworking
technology come alive right before your eyes.
HTH,
-Bruce Caslow CCIE #3139
NetMasterClass, LLC
www.netmasterclass.net
A Cisco Learning Partner
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Mathew
> Sent: Thursday, December 07, 2006 7:42 AM
> To: Andrew Bruce Caslow
> Cc: Cisco certification
> Subject: Re: "ip directed-broadcast" how does it works?
>
> Hi Andrew,
>
> Just one more question;
>
> How does the command "ip icmp rate-limit unreachable" come into effect
> when we try to reduce the effects of ICMP floding?
>
> Thanks in advance for your reply.
>
> mathew
>
> On 12/7/06, Andrew Bruce Caslow <abcaslow@netmasterclass.net> wrote:
> > Hi Mathew,
> >
> > Here are two links to check out regarding DOS attacks in general and UDP
> > flooding in particular:
> >
> > http://www.ciscopress.com/articles/article.asp?p=345618&rl=1
> >
> > http://www.cisco.com/warp/public/707/22.html
> >
> > While neither one of these links is precisely on point on the subject of
> UDP
> > flooding, they will get you started.
> >
> > HTH,
> >
> > -Bruce Caslow CCIE #3139
> > NetMasterClass, LLC
> > www.netmasterclass.net
> > A Cisco Learning Partner
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > > Mathew
> > > Sent: Wednesday, December 06, 2006 6:37 AM
> > > To: Andrew Bruce Caslow
> > > Cc: ccielab@groupstudy.com
> > > Subject: Re: "ip directed-broadcast" how does it works?
> > >
> > > Hi Andrew,
> > >
> > > Thank you for the detailed reply and the EXCELENT explanation. I have
> > > understood this very well.
> > >
> > > By the way, do you know any links that talk about UDP flooding and how
> > > to reduce that effects?. As I think we can use CBAC & police to reduce
> > > it but I am wondering whether there are any other ways to do that.
> > >
> > > Your reply on this is much appreciated.
> > >
> > > mathew
> > >
> > > On 11/30/06, Andrew Bruce Caslow <abcaslow@netmasterclass.net> wrote:
> > > > Hi Mathew,
> > > >
> > > > Let me help you get started with learning how the "ip directed-
> > > broadcast"
> > > > command works. I will also show you some of the research techniques
> I
> > > would
> > > > use. And in doing so, we will see that we can find some useful
> > > information,
> > > > but much of it is oftentimes incomplete, misleading and sometimes
> > > downright
> > > > inaccurate. I feel your pain! : )
> > > >
> > > > Let's begin:
> > > >
> > > > First, I would go to Google and type: "ip directed-broadcast Cisco"
> > > >
> > > > This will give me a list of sites that probably discuss the "ip
> > > > directed-broadcast" command. Actually, the first two sites here give
> me
> > > some
> > > > good information:
> > > >
> > > >
> http://www.oreillynet.com/pub/a/network/excerpt/CISCO_Chap1/index2.html
> > > >
> > > > http://www.informit.com/articles/article.asp?p=102180&seqNum=5&rl=1
> > > >
> > > > Once I access either of these sites, I use the CTRL+F search feature
> of
> > > my
> > > > browser and I search once again for "ip directed-broadcast"
> > > >
> > > > At the Informit site I found this description of "ip directed-
> > > broadcast":
> > > >
> > > > "The IP-directed broadcast is another service that is commonly used
> in
> > > Smurf
> > > > attacks. Smurf attacks send ICMP echo requests from a spoofed source
> > > address
> > > > to a directed broadcast that cause all hosts to respond to the ping
> echo
> > > > request, creating a lot of traffic on the network. By default on IOS
> > > version
> > > > 12.0 and higher, ip directed broadcast is disabled, and if you are
> > > running
> > > > any version lower than 12.0, it is imperative that you disable IP
> > > directed
> > > > broadcasts on the router by issuing the following command in
> interface
> > > > configuration mode:
> > > >
> > > > Central(config-if)#no ip directed-broadcast"
> > > >
> > > > While this information is a good start, it leaves me with a feeling
> of
> > > > incompleteness and vagueness. It gives me part of the answer I was
> > > looking
> > > > for, but not the complete answer.
> > > >
> > > > Now, I suggest we take a step back. Why don't we figure out what
> exactly
> > > an
> > > > "ip directed-broadcast" is. I think this is defined in some RFC.
> > > Therefore,
> > > > I go back to google and I begin searching for "directed-broadcast
> and
> > > RFC"
> > > > and I get a tangled collection of results. (Once again, I feel the
> pain
> > > of
> > > > all CCIE candidates searching for a clear answer!) I search through
> some
> > > > RFC's and I come up with two that are of use:
> > > >
> > > > RFC 2644 - Changing the Default for Directed Broadcasts in Routers
> > > >
> > > > This RFC seems to be focued on the topic I am doing research on. It
> is
> > > also
> > > > only 2 pages long! Excluding all of the legal mumbo jumbo, it is
> really
> > > just
> > > > 1 page long. I suggest you read this 1 page RFC!
> > > >
> > > > Also, RFC 1812 the famous "Requirements for IP Version 4 Routers"
> > > Section of
> > > > 5.3.5.2 of RFC 1812 is titled "Directed Broadcasts" (p 93). Here it
> > > states:
> > > >
> > > > ***BEGIN RFC QUOTE
> > > >
> > > > 5.3.5.2 Directed Broadcasts
> > > >
> > > > A router MUST classify as network-prefix-directed broadcasts all
> > > > valid, directed broadcasts destined for a remote network or an
> > > > attached nonsubnetted network. Note that in view of CIDR, such
> > > > appear to be host addresses within the network prefix; we
> preclude
> > > > inspection of the host part of such network prefixes. Given a
> route
> > > > and no overriding policy, then, a router MUST forward network-
> > > > prefix-directed broadcasts. Network-Prefix-Directed broadcasts
> MAY
> > > be
> > > > sent.
> > > >
> > > > A router MAY have an option to disable receiving network-prefix-
> > > > directed broadcasts on an interface and MUST have an option to
> > > > disable forwarding network-prefix-directed broadcasts. These
> options
> > > > MUST default to permit receiving and forwarding network-prefix-
> > > > directed broadcasts.
> > > >
> > > > DISCUSSION
> > > > There has been some debate about forwarding or not forwarding
> > > > directed broadcasts. In this memo we have made the forwarding
> > > > decision depend on the router's knowledge of the destination
> > > > network prefix. Routers cannot determine that a message is
> > > > unicast or directed broadcast apart from this knowledge. The
> > > > decision to forward or not forward the message is by
> definition
> > > > only possible in the last hop router."
> > > >
> > > > ***END RFC QUOTE
> > > >
> > > > Sorry for the poor formatting of the passage above . It was a direct
> cut
> > > and
> > > > past from RFC 1812. RFC 1812 is a very important RFC for any network
> > > > professional. It is about 175 pages long. At NMC, we think it is
> such an
> > > > important RFC that we have PDF'd the RFC, highlighted key sections
> in
> > > the
> > > > RFC and have added some annotated comments. You can get this
> annotated
> > > > version of RFC 1812 from our web-site at:
> > > >
> > > > http://netmasterclass.com/site/articles/RFC-1812-annotated.pdf
> > > >
> > > > I suggest you down load this PDF and frequently refer to it. It
> covers
> > > lots
> > > > of essential operations of internetworking in general and routing in
> > > > particular.
> > > >
> > > > Also, here is a very useful reference on ip directed-broadcasts. It
> is
> > > from
> > > > a paper called "How to Defeat DDoS Attack".
> > > >
> > > > http://anml.iu.edu/ddos/defeat.html
> > > >
> > > >
> > > > Now, all of this information is good and useful. I think I have a
> better
> > > > understanding of what a "directed broadcast" is and "why I should
> > > prevent
> > > > forwarding them". However, I still don't have a complete and clear
> > > picture
> > > > of what one is. The best way to obtain this answer is to go to a
> rack of
> > > > routers and make all of this theory "come alive". Let's do this:
> > > >
> > > > First I activate a simple Dynamips topology of 4 routers arranged in
> the
> > > > following way:
> > > >
> > > >
> > > > R1 ==== ETHERNET ==== R2 ==== SERIAL ==== R3 ==== ETHERNET ==== R4
> > > >
> > > > The source of my directed broadcast will be R1 and the target of my
> IP
> > > > directed broadcast will be the Ethernet on the far right hand side
> of
> > > the
> > > > diagram above, the Ethernet between R3 and R4. This will is the
> > > > 172.16.34.0/24 network. R3 is assigned the address of 172.16.34.3
> and
> > > R4,
> > > > 172.16.34.4.
> > > >
> > > > On R1, I enable "debug ip packet" and then I perform the following
> PING:
> > > >
> > > > R1#ping 172.16.34.255 repeat 1
> > > >
> > > > Type escape sequence to abort.
> > > > Sending 1, 100-byte ICMP Echos to 172.16.34.255, timeout is 2
> seconds:
> > > > !
> > > > Success rate is 100 percent (1/1), round-trip min/avg/max =
> 360/360/360
> > > ms
> > > > R1#
> > > > IP: tableid=0, s=172.16.12.1 (local), d=172.16.34.255
> > > (FastEthernet0/0.12),
> > > > routed via FIB
> > > > IP: s=172.16.12.1 (local), d=172.16.34.255 (FastEthernet0/0.12), len
> > > 100,
> > > > sending
> > > >
> > > > Hey, I see that I have generated a PING using an IP directed-
> broadcast
> > > > address (in accordance to RFC 1812). It has the 24-bit unicast
> prefix of
> > > > 172.l6.34.X and an 8-bit broadcast host suffix of "x.x.x.255".
> Proof by
> > > > debug! Now, instead of just reading about an ip directed-broadcast,
> I
> > > > actually see one. In fact, I actually created one. Now, I feel like
> I am
> > > > learning something.
> > > >
> > > > Now, let me see what type of response I am getting from this
> > > > directed-broadcast that I have created:
> > > >
> > > > Then, once again on R1, I enable "debug ip icmp" and then I perform
> the
> > > > following PING:
> > > >
> > > > R1#ping 172.16.34.255 repeat 2
> > > >
> > > > Type escape sequence to abort.
> > > > Sending 2, 100-byte ICMP Echos to 172.16.34.255, timeout is 2
> seconds:
> > > > !!
> > > > Success rate is 100 percent (2/2), round-trip min/avg/max =
> 12/142/272
> > > ms
> > > > R1#
> > > > ICMP: echo reply rcvd, src 172.16.23.3, dst 172.16.12.1
> > > > ICMP: echo reply rcvd, src 172.16.34.4, dst 172.16.12.1
> > > > ICMP: echo reply rcvd, src 172.16.23.3, dst 172.16.12.1
> > > > ICMP: echo reply rcvd, src 172.16.34.4, dst 172.16.12.1
> > > >
> > > > I see that I get unicast replies from all end stations on this
> > > > 172.16.34.0/24 subnet. In my Dynamips configuration, there are only
> two
> > > > devices and they both respond.
> > > >
> > > > Now, let me repeat my ping and check out what I receive on router
> R4.
> > > >
> > > > On R4, I enable "debug ip packet detail" as well as "debug ip icmp"
> and
> > > then
> > > > I perform the previous PING on R1. This is what I see on R4:
> > > >
> > > > IP: s=172.16.12.1 (FastEthernet0/0.34), d=255.255.255.255, len 100,
> rcvd
> > > 2
> > > > ICMP type=8, code=0
> > > > ICMP: echo reply sent, src 172.16.34.4, dst 172.16.12.1
> > > >
> > > > I see the ICMP echo request coming in from R1 and received by R4 and
> > > then I
> > > > see the ICMP echo reply generated by R4. It is interesting to note,
> that
> > > the
> > > > original IP directed-broadcast of 172.16.34.255 has been converted
> to
> > > the
> > > > local broadcast of 255.255.255.255.
> > > >
> > > > I think I now have a better understanding of how an IP directed-
> > > broadcast
> > > > works. Now, let me attempt to learn how the Cisco IOS command "ip
> > > > directed-broadcast" works. Let's make some theory "come alive" using
> the
> > > > Cisco IOS.
> > > >
> > > > As mentioned in the Informit article above, " By default on IOS
> version
> > > 12.0
> > > > and higher, ip directed broadcast is disabled". I can prove this in
> two
> > > ways
> > > > with two IOS show commands:
> > > >
> > > > R3#sh ip inte fa0/0.34 | i Directed
> > > > Directed broadcast forwarding is disabled
> > > >
> > > > R3#sh run inte fa0/0.34
> > > > !
> > > > interface FastEthernet0/0.34
> > > > encapsulation dot1Q 34
> > > > ip address 172.16.34.3 255.255.255.0
> > > > end
> > > >
> > > > First, the "show ip interface" display listed " Directed broadcast
> > > > forwarding is disabled"
> > > >
> > > > Second, the "ip directed-broadcast" command does not show up in the
> > > running
> > > > configuration. As a general rule, default settings do not appear in
> > > Cisco
> > > > running configurations. There are some exceptions, but this is the
> > > general
> > > > rule.
> > > >
> > > > Now, with this default configuration in place, I begin the directed
> > > > broadcast ping from R1 and I enable "debug ip icmp" on R4. Debug ip
> > > packet
> > > > is too verbose. This time I run the ping for 1000 ICMP echos.
> > > >
> > > > I will focus my use of the "ip directed-broadcast" command on Router
> R3.
> > > > This is the router in the path that will deliver the directed
> broadcast
> > > to
> > > > all of the attached interfaces on the 172.16.34.0/24 subnet. The
> actual
> > > > interface on R3 that is attached to the 172.16.34.0 subnet is the
> > > fa0/0.34
> > > > interface in my Dynamips configuration.
> > > >
> > > > With the "ip directed-broadcast" forwarding disabled on the fa0/0.34
> > > > interface of R3 (remember this is the default setting), you see no
> ICMP
> > > ECHO
> > > > responses beginning generated on router R4.
> > > >
> > > > However, as soon as you enter the following command on the fa0/0.34
> > > > interface on R3, R4 begins to generate ICMP ECHO REPLY messages
> directed
> > > to
> > > > R1.
> > > >
> > > > R3(config-subif)#ip directed-broadcast
> > > >
> > > > Here is the output you will see on R4:
> > > >
> > > > R4#
> > > > ICMP: echo reply sent, src 172.16.34.4, dst 172.16.12.1
> > > > ICMP: echo reply sent, src 172.16.34.4, dst 172.16.12.1
> > > > ICMP: echo reply sent, src 172.16.34.4, dst 172.16.12.1
> > > >
> > > > Now, go back to R3 and disable the "ip directed-broadcast" feature
> and
> > > then
> > > > re-enable it. Then check the debug output on R4, you will that you
> are
> > > > stopping and starting that debug output just as if you were turning
> on
> > > and
> > > > off a light switch. You are in control!!! See below:
> > > >
> > > > R3(config-subif)#no ip directed-broadcast
> > > >
> > > > R3(config-subif)#ip directed-broadcast
> > > >
> > > > R3(config-subif)#no ip directed-broadcast
> > > >
> > > > So, now you should have been able to improve your understanding of
> the
> > > "ip
> > > > directed-broadcast" command by using the IOS. At NMC, we call this
> > > "proof by
> > > > debug"; "proof by show command".
> > > >
> > > > I haven't covered everything with this subject, but it is a start.
> My
> > > > apologies for the length response, but I what I want to emphasize
> here
> > > is
> > > > not just the answer, but the analysis method to get to an answer.
> > > Ideally,
> > > > you must get to a level of understanding of these CCIE related
> > > technologies
> > > > that will involve proofs by "show command" and debug or Ethereal
> trace.
> > > At
> > > > least that is what we try to do in our NMC presentations - both
> > > classroom
> > > > and on-line/self-paced.
> > > >
> > > > Well, I've got to get back to developing the NMC IPv6 Class on
> Demand
> > > > module. Anthony Sequiera is ready to record more of the Video on
> Demand
> > > > components for this module. By the way, we will be using the same
> > > > methodology used in this e-mail in these Video on Demand modules.
> They
> > > will
> > > > also be re-enforced with on-line quizzes and technology focused
> mini-
> > > labs.
> > > >
> > > > Please let me know if you thing this methodology is helpful. Over
> the
> > > years,
> > > > almost all of our students have found it useful.
> > > >
> > > > I am going to close by stating the obvious. In your CCIE preparation
> > > > studies, please just do not pursue an answer to a question. Also,
> pursue
> > > a
> > > > clear understanding of that answer. With the Cisco IOS, and now with
> > > tools
> > > > like Dynamips, it is so much easier to make internetworking
> technology
> > > "come
> > > > alive" through the IOS.
> > > >
> > > > HTH,
> > > >
> > > > -Bruce Caslow CCIE #3139
> > > > NetMasterClass, LLC
> > > > www.netmasterclass.net
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> > > Of
> > > > > mathew Fer
> > > > > Sent: Wednesday, November 29, 2006 2:08 AM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: "ip directed-broadcast" how does it works?
> > > > >
> > > > > Hi GS,
> > > > >
> > > > > Can someone explain how this command "ip directed-broadcast" works
> &
> > > in
> > > > > which situation we enable or disable it?
> > > > >
> > > > > thanks for the reply.
> > > > >
> > > > > mathew
> > > > >
> > > > >
> > >
> _______________________________________________________________________
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> _______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > >
> > >
> > > --
> > > Thanks
> > >
> > > Mathew
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
>
>
> --
> Thanks
>
> Mathew
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:37 ART