Re: AppleTalk MIB question

RL Bob Morgan <morgan@networking.stanford.edu> Tue, 22 March 1994 11:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01083; 22 Mar 94 6:48 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bo00841; 22 Mar 94 6:48 EST
Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa01854; 22 Mar 94 5:29 EST
Received: from localhost (daemon@localhost) by cayman.Cayman.COM (8.6.4/ECB-1.3) id EAA13351 for apple-ip-list; Tue, 22 Mar 1994 04:40:17 -0500
Received: from Mordor.Stanford.EDU (Mordor.Stanford.EDU [36.53.0.155]) by cayman.Cayman.COM (8.6.4/ECB-1.3) with ESMTP id EAA13348 for <apple-ip@cayman.Cayman.COM>; Tue, 22 Mar 1994 04:40:13 -0500
Received: from ucsf-pm-dial3.barrnet.net by Mordor.Stanford.EDU (8.6.4/inc-1.0) id BAA04639; Tue, 22 Mar 1994 01:39:51 -0800
Date: Tue, 22 Mar 1994 01:37:49 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: RL Bob Morgan <morgan@networking.stanford.edu>
To: Robert_Jeckell@3mail.3com.com, jay@gordian.com
Subject: Re: AppleTalk MIB question
Cc: apple-ip@cayman.cayman.com, anf-disc@netcom.com
Message-ID: <Mailstrom.1.05.64621.-15445.morgan@mordor.stanford.edu>
In-Reply-To: Your message <940302.185620@3Mail.3Com.COM> of Wed, 2 Mar 94 18:56 PST
Content-Type: TEXT/plain; charset="US-ASCII"

> I'm having trouble understanding what ddpBroadcastErrors is supposed
> to count.
> According to the text:
> 	"The total number of input DDP datagrams dropped because
> 	this entity was not their final destination and they
> 	were addressed to the link level broadcast."
>
> The text implies that there's a rule that says that link level
> broadcasts should not be forwarded by a router.

I don't know if there's any such rule in Inside AppleTalk, but the justification
is straightforward, it seems to me.  If a node sends a datagram to an off-subnet
destination as a link-level broadcast, and routers forward such a datagram, it
will be forwarded by each of the (possibly very many) local routers that receive
it.  This is obviously undesirable.  The original sending node must be
misconfigured for this to happen; forwarding its datagrams will only make it
likely to remain so for a longer time.

I think the general theory here is that datagrams that arrive as link-level
broadcasts should be treated with great wariness by routers.  Only those with
well-defined purposes (eg AARP, NBP) should get processed.  The goal is the
prevention of broadcast storms.

Presumably the idea behind this counter is to detect nodes that are broken in
this way.  I can't see that this counter would cost anything, since presumably
the router is already checking for this error condition (*yours* is, isn't it?
8^).  Whether this condition is common or rare, well, I guess it's time to look
at some of those counters ...

As to whether link-layers provide this indication, for what it's worth this
indication is required by IP (from RFC 1122):

      The packet receive interface between the IP layer and the link
      layer MUST include a flag to indicate whether the incoming packet
      was addressed to a link-layer broadcast address.

Any multiprotocol router that also handles IP should have this available, then.

 - RL "Bob"