From: Andrew Bruce Caslow (abcaslow@netmasterclass.net)
Date: Wed Nov 29 2006 - 11:14:50 ART
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
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:49 ART