I agree that in some cases, improperly written or configured software
assumes that anything that ends in ".255" is a broadcast, or might be.
This problem is even further perverted by the interpolation of the net vs
host vs bcast scheme not allowing the fist and last nets to be used in a
subnet scheme.  This problem has been recently overcome by more updated
RFCs.

The purists view, to which I subscribe, says that only the highest address
in the subnet is the bcast address.  In the case of a class B, they usually
end in 255, but not every address that ends in ."255" is a bcast.  This is
enforced by the results of subnetting a class C network and getting bcast
addresses that end in 15 or 31.  RFC 917 is fairly ambiguous about this
point and RFC 950 goes some distance toward helping clear this matter up.
This was a recognized problem when Douglas Comer wrote his Internetworking
with TCP/IP book, one of the defact-o standards for the construction of IP
based networks.  Section 4.5 is fairly clear on this matter.

To wrap up my rant, I propose that just because it's often done incorrectly
and often even excepted in that way, does not mean that we should let it go
on that way.   The code that interprets bcast addresses should not rely on
a  "255" in the address because it will not work properly in all but one
subnet of a C and will often cause false alarms in subnetted class A and B
networks.

--

J. Eric Josephson
Director of Network and System Operations
978-720-2159
mailto:[EMAIL PROTECTED]



                                                                                       
                              
                    "Colin M.                                                          
                              
                    Valentine"           To:     [EMAIL PROTECTED]             
                              
                    <[EMAIL PROTECTED]        cc:                                           
                              
                    g>                   Subject:     Re: [Ntop] duplicate MACs, 
missing modules, etc.               
                                                                                       
                              
                    10/13/2001                                                         
                              
                    05:19 PM                                                           
                              
                                                                                       
                              
                                                                                       
                              





Note .255 may be not be LEGAL.  I ran into a major problem the other
day on my DSL line.  Some sites worked (slashdot, for example), but others
(CNN) did
not.  Drove me nuts.

Turned out Telekom gave me a .255 address on my DSL line (ppoe).  I reset
the link, got a new IP, worked like a charm.

I suspect router ACLs.....perhaps part of the security framework.

All the references I find tonight state .255 is broadcast.

One example here:

http://www.cisco.com/univercd/cc/td/doc/product/atm/l2020/2020r21x/planning/appndxa.htm#xtocid87496


The host ID that is all 1s in binary is reserved as a broadcast address
within a given (sub)network for all hosts on this (sub)network. (The IP
specification also reserves a net or subnet number whose binary
representation is all 1s.)

Longer set of references here:

http://directory.google.com/Top/Computers/Internet/Protocols/Transmission_Protocols/Networking_Resources/Addressing/



Colin
PS Love Groove, playing with it at work....

On Sat, 13 Oct 2001 [EMAIL PROTECTED] wrote:

>
> Same here, plus I get yellow flags on any class B IP address that ends
with
> 255.  While it's not a broadcast address, it's being interpreted as one.
> For example,
>
> 10.10.6.255 is an actual address on our network with a SNM of
255.255.0.0.
> NTOP flags that as having a bogus SNM or flags others that communicate
with
> it as using a bogus broadcast address, i.e. my router.
>
>
>
> --
>
> J. Eric Josephson
> Director of Network and System Operations
> 978-720-2159
> mailto:[EMAIL PROTECTED]
>
>
>
>

>                     W Brock

>                     <wbrock@yahoo        To:     [EMAIL PROTECTED]

>                     .com>                cc:

>                     Sent by:             Subject:     Re: [Ntop]
duplicate MACs, missing modules, etc.
>                     ntop-admin@un

>                     ipi.it

>

>

>                     10/13/2001

>                     06:55 AM

>                     Please

>                     respond to

>                     ntop

>

>

>
>
>
>
> Same here.
>
> Wally
>
> --- Shane Wilson <[EMAIL PROTECTED]> wrote:
> > I second the MAC address problem.  I have seen this
> > myself in the latest
> > versions with sample symptoms that you see.
> >
> > Shane
> >
> > > Buon Giorno ntoppers,
> > >
> > > I have a few questions about ntop version  ntop
> > v.2.0.0 MT (SSL)
> > > [i686-pc-linux] (10/12/01 11:36:50 AM build).  I
> > grabbed this from CVS
> > > earlier today (12 Oct 2001).
> > >
> > > First, some hosts are showing up with red flags
> > and a message about
> > > different MACs for the same IP address.  As we are
> > a small intranet
> > > behind a safe firewall I really doubt this.
> > Furthermore, if I look at
> > > the web page for the two hosts (one listed by the
> > IP address, the other
> > > listed by the FQDN) with the same IP and different
> > MAC the MACs are
> > > actually the same (or, I think, the web page is
> > the same).  Has anyone
> > > else noticed a problem like this?
> > >
> > > Second, I see that the modules for nfs and
> > lastseen are being loaded
> > > but they show up as active in the status panel
> > (Stats->Plugins) of the
> > > web interface:
> > > 12/Oct/2001:15:39:12 Welcome to
> > LastSeenWatchPlugin. (C) 1999 by Andrea
> > > Marangoni.
> > > 12/Oct/2001:15:39:12 Welcome to nfsWatchPlugin.
> > (C) 1999 by Luca Deri.
> > >
> > > Finally, I've started ntop with the "-S 1" flag
> > but stats aren't
> > >surviving between startups... any ideas?
> > >
> > > Ahh, one more... I'm getting frequent segmentation
> > faults.  If someone
> > > would like I can take a look at it with gdb.
> > >
> > > I lied, one more... I made an SSL key per the
> > instructions in
> > > README.SSL and put it in /etc (had to look at the
> > source code for
> > > that... maybe the error message should say where
> > it is looking for SSL
> > > keys?):
> > > 12/Oct/2001:15:39:12 SSL initialized successfully
> > > But when I connect to localhost:3001 I get "host
> > contacted, waiting for
> > > reply" that never returns.
> > >
> > > Any pointers to solve the above problems is
> > greatly appreciated.
> > >
> > > Thanks for a very cool program!
> > >
> > >                  Rich
> > > _______________________________________________
> > > Ntop mailing list
> > > [EMAIL PROTECTED]
> > > http://listmanager.unipi.it/mailman/listinfo/ntop
> >
> > _______________________________________________
> > Ntop mailing list
> > [EMAIL PROTECTED]
> > http://listmanager.unipi.it/mailman/listinfo/ntop
>
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listmanager.unipi.it/mailman/listinfo/ntop
>
>
>
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listmanager.unipi.it/mailman/listinfo/ntop
>





_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop

Reply via email to