From: Mathew (mathewfer@gmail.com)
Date: Wed Dec 06 2006 - 08:36:43 ART
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
>
-- ThanksMathew
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:36 ART