From: Mathew (mathewfer@gmail.com)
Date: Thu Dec 07 2006 - 09:42:28 ART
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
>
>
-- ThanksMathew
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:37 ART