From: robbie (robbie@packetized.org)
Date: Fri Jul 02 2004 - 18:07:13 GMT-3
This is normal behavior, as old Solaris (well, sunos 2.4/2.5 etc) boxen
would use the Network number as the broadcast address, if memory serves
correctly. Also, RFC919 states...
If the use of "all ones" in a field of an IP address means
"broadcast", using "all zeros" could be viewed as meaning
"unspecified". There is probably no reason for such addresses to
appear anywhere but as the source address of an ICMP Information
Request datagram. However, as a notational convention, we refer to
networks (as opposed to hosts) by using addresses with zero fields.
For example, 36.0.0.0 means "network number 36" while 36.255.255.255
means "all hosts on network number 36".
I would say that the portion relevant to this discussion is the portion
noting that "all zeros" is "unspecified", in which case the router might
decide to respond on it's own, much as Sun boxen would once (and I think
still might) do.
robbie.
john matijevic wrote:
> Hello All,
> I apologize, I believe this is also normal behavior. I just reproduced
> again with 2 routers. The first time I reproduced I did with one router
> I just added a loopback then pinged the network 172.24.10.4, and did not
> receive a response. When I added a second router, I pinged 172.24.10.4
> and received response from the other router.
> r3#ping 172.24.10.4
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 172.24.10.4, timeout is 2 seconds:
>
> Reply to request 0 from 172.24.10.6, 8 ms
> Reply to request 1 from 172.24.10.6, 4 ms
> Reply to request 2 from 172.24.10.6, 4 ms
> Reply to request 3 from 172.24.10.6, 4 ms
> Reply to request 4 from 172.24.10.6, 4 ms
>
> So the conclusion can be made by what Kenneth said and RFC and Cisco
> doc, is when you ping a network boundary. For example 172.24.10.4 it
> will convert to broadcast than all hosts on that broadcast will respond.
> As can be seen with debug ip packet:
> 5d00h: IP: s=172.24.10.5 (local), d=255.255.255.255
> (FastEthernet0/0.13), len 10
> 0, sending broad/multicast
> 5d00h: ICMP type=8, code=0
>
>
> John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> Network Consultant
> Hablo Espanol
> 305-321-6232
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Kenneth Wygand
> Sent: Friday, July 02, 2004 2:01 PM
> To: Guilherme Correia; robbie@packetized.org; ccielab@groupstudy.com
> Subject: RE: Ping the subnet address - FINAL
>
> Guilherme,
>
> This is normal, as per RFC1812:
>
> <SNIP>
> As was described in Section [4.2.3.1], a router may encounter certain
> non-standard IP broadcast addresses:
> ...
> o { <Network-prefix>, 0 } is an obsolete form of a network-prefix-
> directed broadcast address.
>
> As was described in that section, packets addressed to any of these
> addresses SHOULD be silently discarded, but if they are not, they
> MUST be treated according to the same rules that apply to packets
> addressed to the non-obsolete forms of the broadcast addresses
> described above. These rules are described in the next few sections.
> </SNIP>
>
> So the '0' in the node address is a legacy version of a broadcast, so
> that's how Cisco routers treat this.
>
> Ken
>
>
> ________________________________
>
> From: Guilherme Correia [mailto:razzolini80@hotmail.com]
> Sent: Fri 7/2/2004 1:33 PM
> To: Kenneth Wygand; robbie@packetized.org; ccielab@groupstudy.com
> Subject: RE: Ping the subnet address - FINAL
>
>
>
> I am running 12.3 on both routers..
>
> Thanks all for your help; as per the results I also believe now that
> this is
> a normal, but different from previous behaviour, AFAIK.
>
> Thanks
>
>
>
> From: "Kenneth Wygand" <KWygand@customonline.com>
> Reply-To: "Kenneth Wygand" <KWygand@customonline.com>
> To: "robbie" <robbie@packetized.org>, <ccielab@groupstudy.com>
> Subject: RE: Ping the subnet address
> Date: Fri, 2 Jul 2004 13:14:24 -0400
>
> Robbie, John, Guilherme,
>
> I receive the same thing on my routers (12.2(19)).
>
> It's not an IP directed broadcast issue because it's not a broadcast
> until
> the final hop (remote side relative to where the ping was sourced from).
> When it gets there, it is treated as a broadcast packet. If IP directed
> broadcasts were enabled, it would simply expload the directed network
> broadcast to an all-1's broadcast onto the interface attached to the
> respective network. However, even without ip directed broadcasts
> enabled,
> the remote router will still locally respond to the ping, it just won't
> expload it onto the associated network.
>
> I'm receiving the same results as Guilherme. I believe this is proper
> operation based on the design of Cisco routers to forward network
> broadcasts
> along the unicast path until the final hop, where it is then treated as
> (converted to) a directed broadcast.
>
> HTH,
> Ken
>
> ________________________________
>
> From: nobody@groupstudy.com on behalf of robbie
> Sent: Fri 7/2/2004 12:55 PM
> To: ccielab@groupstudy.com
> Subject: Re: Ping the subnet address
>
>
>
> Possible that he is running 12.0, and does not have 'no ip
> directed-broadcast' enabled on the interface?
>
> This command is the default in late 12.0 releases and forward, IIRC.
>
> robbie.
>
> john matijevic wrote:
>
> > Hello Guilherme,
> > This maybe a bit drastic, but I would look into what IOS version are
> you
> > using? Does this happen with another version of IOS? I tried to
> > reproduce here, I have version 12.2 but could not. Do you have
> support
> > agreement with Cisco? Perhaps you can open up trouble ticket and they
> > can possibly try to reproduce? Maybe you can also work on getting
> them
> > or us remote access?
> >
> > Sincerely,
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > Network Consultant
> > Hablo Espanol
> > 305-321-6232
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Guilherme Correia
> > Sent: Friday, July 02, 2004 11:55 AM
> > To: matijevi@bellsouth.net; tig@wiltecinc.com; ccielab@groupstudy.com
> > Cc: KWygand@customonline.com
> > Subject: RE: Ping the subnet address
> >
> > there is no nat...
> >
> > 3745#sh ip nat trans
> > 3745#
> >
> > 7204-1#sh ip nat tra
> > 7204-1#
> >
> > unfortunately, there is no remote access..
> >
> >
> > From: "john matijevic" <matijevi@bellsouth.net>
> > To: "'Guilherme Correia'"
> >
> <razzolini80@hotmail.com>,<tig@wiltecinc.com>,<ccielab@groupstudy.com>
> > CC: <KWygand@customonline.com>
> > Subject: RE: Ping the subnet address
> > Date: Fri, 2 Jul 2004 11:48:54 -0400
> >
> > Hello Guilherme,
> > Is there anyway we can have remote access? Are you using NAT? If so,
> can
> > you do a sh ip nat translation after the ping? Can you test without
> > using NAT to see if NAT is the issue?
> >
> > Sincerely,
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > Network Consultant
> > Hablo Espanol
> > 305-321-6232
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Guilherme Correia
> > Sent: Friday, July 02, 2004 11:35 AM
> > To: matijevi@bellsouth.net; tig@wiltecinc.com; ccielab@groupstudy.com
> > Cc: KWygand@customonline.com
> > Subject: RE: Ping the subnet address
> >
> > yes, it happens on all routers, exactly the same behaviour..I have
> > rebooted
> > them in the hope this was going to change but still the same after
> > reboot.
> >
> >
> > From: "john matijevic" <matijevi@bellsouth.net>
> > Reply-To: "john matijevic" <matijevi@bellsouth.net>
> > To: "'Tom Martin'" <tig@wiltecinc.com>, <ccielab@groupstudy.com>
> > CC: "'Kenneth Wygand'" <KWygand@customonline.com>
> > Subject: RE: Ping the subnet address
> > Date: Fri, 2 Jul 2004 11:19:48 -0400
> >
> > Guilherme,
> > Does this issue only appear on one router where you ping? In
> otherwords
> > can you go to another router, and ping and you see the same issue on
> > that same subnet?
> >
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > Network Consultant
> > Hablo Espanol
> > 305-321-6232
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Tom Martin
> > Sent: Friday, July 02, 2004 11:13 AM
> > To: ccielab@groupstudy.com
> > Cc: Kenneth Wygand
> > Subject: RE: Ping the subnet address
> >
> > Ken,
> >
> >
> >
> > I'd be very hesitant to try and block any traffic just because I
> thought
> > it might be strange, especially if everything was working properly. I
> > assumed that this was a lab scenario...
> >
> >
> >
> > -- Tom
> >
> >
> >
> > ________________________________
> >
> > From: Kenneth Wygand [mailto:KWygand@customonline.com]
> > Sent: Friday, July 02, 2004 11:07 AM
> > To: Tom Martin; ccielab@groupstudy.com
> > Cc: Guilherme Correia
> > Subject: RE: Ping the subnet address
> >
> >
> >
> > Tom,
> >
> >
> >
> > I'd be -very- hesitant to put an ACL blocking all broadcasts in a
> > production environment. Guilherme may have all kinds of services
> running
> > over this network, and blocking broadcasts may bust a lot of other
> > things.
> >
> >
> >
> > Thanks!
> >
> > Ken
> >
> >
> >
> > ________________________________
> >
> > From: nobody@groupstudy.com on behalf of Tom Martin
> > Sent: Fri 7/2/2004 10:55 AM
> > To: ccielab@groupstudy.com
> > Cc: Guilherme Correia
> > Subject: RE: Ping the subnet address
> >
> > Hello,
> >
> > You didn't include any excerpts from your packet capture, but I
> > recreated the scenario using "debug ip packet" instead of using a
> packet
> > capture. When you ping the all-zeroes or all-ones broadcast address,
> the
> > pinging router actually sends packets out to destination
> > 255.255.255.255, not the IP that you specified!
> >
> > Sending router debug output:
> >
> > r2#ping 192.168.12.0
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 192.168.12.0, timeout is 2 seconds:
> >
> > Mar 15 02:48:12.975: IP: s=192.168.12.2 (local), d=255.255.255.255
> > (FastEthernet0), len 100, sending broad/multicast
> > Mar 15 02:48:12.979: IP: s=192.168.12.1 (FastEthernet0),
> d=192.168.12.2
> > (FastEthernet0), len 100, rcvd 3
> > Reply to request 0 from 192.168.12.1, 4 ms
> > Mar 15 02:48:14.975: IP: s=192.168.12.2 (local), d=255.255.255.255
> > (FastEthernet0), len 100, sending broad/multicast
> > Mar 15 02:48:14.979: IP: s=192.168.12.1 (FastEthernet0),
> d=192.168.12.2
> > (FastEthernet0), len 100, rcvd 3
> > Reply to request 1 from 192.168.12.1, 4 ms
> > Mar 15 02:48:16.975: IP: s=192.168.12.2 (local), d=255.255.255.255
> > (FastEthernet0), len 100, sending broad/multicast
> > Mar 15 02:48:16.979: IP: s=192.168.12.1 (FastEthernet0),
> d=192.168.12.2
> > (FastEthernet0), len 100, rcvd 3
> > Reply to request 2 from 192.168.12.1, 4 ms
> > Mar 15 02:48:18.975: IP: s=192.168.12.2 (local), d=255.255.255.255
> > (FastEthernet0), len 100, sending broad/multicast
> > Mar 15 02:48:18.979: IP: s=192.168.12.1 (FastEthernet0),
> d=192.168.12.2
> > (FastEthernet0), len 100, rcvd 3
> > Reply to request 3 from 192.168.12.1, 4 ms
> > Mar 15 02:48:20.975: IP: s=192.168.12.2 (local), d=255.255.255.255
> > (FastEthernet0), len 100, sending broad/multicast
> > Mar 15 02:48:20.979: IP: s=192.168.12.1 (FastEthernet0),
> d=192.168.12.2
> > (FastEthernet0), len 100, rcvd 3
> > Reply to request 4 from 192.168.12.1, 4 ms
> > r2#
> >
> > Confirmation that 255.255.255.255 is the destination, output from the
> > receiving router:
> >
> > r1#
> > *Mar 1 00:30:00.339: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, rcvd 2
> > *Mar 1 00:30:00.339: IP: s=192.168.12.1 (local), d=192.168.12.2
> > (Ethernet1/0),len 100, sending
> > *Mar 1 00:30:02.339: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, rcvd 2
> > *Mar 1 00:30:02.339: IP: s=192.168.12.1 (local), d=192.168.12.2
> > (Ethernet1/0),len 100, sending
> > *Mar 1 00:30:04.339: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, rcvd 2
> > *Mar 1 00:30:04.339: IP: s=192.168.12.1 (local), d=192.168.12.2
> > (Ethernet1/0),len 100, sending
> > *Mar 1 00:30:06.339: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, rcvd 2
> > *Mar 1 00:30:06.339: IP: s=192.168.12.1 (local), d=192.168.12.2
> > (Ethernet1/0),len 100, sending
> > *Mar 1 00:30:08.339: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, rcvd 2
> > *Mar 1 00:30:08.339: IP: s=192.168.12.1 (local), d=192.168.12.2
> > (Ethernet1/0),len 100, sending
> > r1#
> >
> > To answer your question on how to stop it (assuming you still want to
> do
> > so), just use an access-list. I used:
> >
> > access-list 100 deny ip any host 255.255.255.255
> > access-list 100 permit ip any any
> > interface Ethernet1/0
> > ip access-group 100 in
> >
> > That resulted in failed pings from the sending side and the following
> > output from the receiving side:
> >
> > *Mar 1 00:32:05.739: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, access denied
> > *Mar 1 00:32:07.739: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, access denied
> > *Mar 1 00:32:09.739: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, access denied
> > *Mar 1 00:32:11.739: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, access denied
> > *Mar 1 00:32:13.739: IP: s=192.168.12.2 (Ethernet1/0),
> > d=255.255.255.255, len 100, access denied
> >
> > -- Tom
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Guilherme Correia
> > Sent: Friday, July 02, 2004 9:36 AM
> > To: ccielab@groupstudy.com
> > Subject: Ping the subnet address
> >
> > Hi
> >
> > I am experiencing this weird issue that when I ping the subnet
> address,
> > one
> > of the routers respond.
> > For example, when I ping 172.24.18.4 (subnet 172.24.18.4/30) one of
> the
> > routers with an interface on the subnet responds:
> >
> > 7204-1#ping 172.24.18.4
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 206.24.18.4, timeout is 2 seconds:
> >
> > Reply to request 0 from 172.24.18.5, 1 ms
> > Reply to request 1 from 172.24.18.5, 1 ms
> > Reply to request 2 from 172.24.18.5, 1 ms
> > Reply to request 3 from 172.24.18.5, 1 ms
> > Reply to request 4 from 172.24.18.5, 1 ms
> >
> > How can I stop this?
> >
> > TIA
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:46 GMT-3