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"
- AppleTalk MIB question Jay Laefer
- AppleTalk MIB question Robert_Jeckell
- Re: AppleTalk MIB question RL Bob Morgan
- Re: AppleTalk MIB question RL Bob Morgan