From:   kuznet@ms2.inr.ac.ru
Message-Id: <200004291840.WAA11029@ms2.inr.ac.ru>
Subject: Re: neighbour cache vs. invalid addresses
To:     almesber@lrc.epfl.ch (Werner Almesberger)
Date:   Sat, 29 Apr 2000 22:40:49 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <200004291829.UAA08071@lrcsun15.epfl.ch> from "Werner Almesberger" at Apr 29, 0 08:29:13 pm
MIME-Version: 1.0
Content-Length: 1106      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk

Hello!

> Not nice for NBMA ... :-(

Why?

> > Actually, even CLIP could have some "broadcast router" on subnet without
> > any modifications to protocol.
> 
> If it has some means to read the ATMARP server's table, yes. Normal
> ATMARP (RFC1577) doesn't let it do this.

ATMARP is not obliged even to know about this.

Configure it to reply to address x.y.z.u with MAC ABCD.
And order machine ABCD to relay broadcasts to all known peers
or to some multicast group. And address x.y.z.u will be genuine
broadcast/multicast.

Actually, many NBMA media did exactly this, because life
without broadcasts is sort of... mmm... not easy.

> 			My preferred way is of course to do as I do
> now, i.e. to return the error as early as possible. But you seem to
> suggest that I change my preference ? :)

Stop. But who did say:

> Furthermore, the offending packets get killed before they show up
> on tcpdump, which makes it harder to debug the "network" problem.)

8)8)

No, I suggest to fix that bug. By the way, we will be able to get rid of
that annoyning wrong "neighbour table overflow" for loopback.

Alexey