eshop@saturn.ucsc.edu (Jim Warner) (02/23/88)
Our campus net includes one DEC LB100 lan bridge. The LB100 sends a packet a second of type 8038 to ether multicast address 9:0:2b:1:0:1. We don't have RBMS so we haven't a clue as to what this is for. The LB100 manual is no help, of course. Is this normal for an LB100? Do nets that have ten LB100s have ten of these packets a second? If we had RBMS, could we turn this off? Do folks that have RBMS think it worth while? Thanks... jim warner
leichter@yale.UUCP (Jerry Leichter) (02/25/88)
In article <2070@saturn.ucsc.edu> eshop@saturn.ucsc.edu (Jim Warner) writes: >Our campus net includes one DEC LB100 lan bridge. The LB100 >sends a packet a second of type 8038 to ether multicast address >9:0:2b:1:0:1....Is this normal for an LB100? Do nets that have ten LB100s have >ten of these packets a second? If we had RBMS, could we turn >this off? Do folks that have RBMS think it worth while? These are messages that LanBridges send to each other to discover the topology of their interconnections and build a spanning tree. Yes, it's normal for them to do this. If you had 10 LanBridges, each would indeed be doing it. I don't know if RBMS provides a way to alter this. What it might let you do is change the interval at which the messages are sent; I doubt it would let you turn them off entirely. Why would you want to turn it off anyway? Even 10 maximum-length packets a second would represent 1.5% or your Ethernet bandwidth - and in fact (a) the packets are a lot smaller; (b) the packets don't pass through the bridges; the only packets you see on any given segment are those form bridges attached to that particular segment. If you are designing an extended LAN with all 10 or your bridges attached to one central segment, you are going to have other problems way before overhead for bridge control packets hurts you. -- Jerry
sullivan@esquire.UUCP (David J. Sullivan) (02/25/88)
In article <2070@saturn.ucsc.edu> eshop@saturn.ucsc.edu (Jim Warner) writes: > >Our campus net includes one DEC LB100 lan bridge. The LB100 >sends a packet a second of type 8038 to ether multicast address >9:0:2b:1:0:1. We don't have RBMS so we haven't a clue as to >what this is for. The LB100 manual is no help, of course. I noticed these on our VitaLink TransLAN NP/IIIa's, which from what I understand uses the same Spanning Tree Protocol to figure out what your net actually looks like. I called the people at VitaLink and was told that each box sends these packets out and looks for it on the "other side" of its connection to see if there are any loops in the network. I forgot to ask about turning it off (if you know there are no loops), but the overhead of a packet a second is quite neglible so I'm not concerned. David Sullivan Davis Polk & Wardwell USENET: ...!{ cmcl2 | uunet }!esquire!sullivan ARPANET: sullivan@acf4.nyu.edu
pritch@tut.cis.ohio-state.edu (Norm Pritchett) (02/26/88)
In article <2070@saturn.ucsc.edu> eshop@saturn.ucsc.edu (Jim Warner) writes: Our campus net includes one DEC LB100 lan bridge. The LB100 sends a packet a second of type 8038 to ether multicast address 9:0:2b:1:0:1....Is this normal for an LB100? Do nets that have ten LB100s have ten of these packets a second? If we had RBMS, could we turn this off? Do folks that have RBMS think it worth while? In article <23864@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes: These are messages that LanBridges send to each other to discover the topology of their interconnections and build a spanning tree. Yes, it's normal for them to do this. If you had 10 LanBridges, each would indeed be doing it.... -- Jerry --------- Actually, the only time all ten would send the multicasts is during startup while the spanning tree is being figured out. After the Bridges feel they have determined the layout of the other LANbridges (or rather a part of determining the layout) a "root" bridge is elected. After all this negotiation, he is the only one who will continue sending the multicast packets. When he goes down everyone starts in with the multicasts again to refigure the spanning tree algorithm and elect a new root. -- Norm Pritchett, The Ohio State University College of Engineering ARPA: pritchett@eng.ohio-state.edu BITNET: TS1703 at OHSTVMA UUCP: cbosgd!tut.cis.ohio-state.edu!pritch