timk@NCSA.UIUC.EDU (Tim Krauskopf) (01/01/88)
Here are some facts which should interest anyone running Ethernet networks,
especially those who have a lot of MAC level bridges.
How will EtherTalk broadcast packets affect you?
1. AppleTalk over Ethernet, known as EtherTalk, has a registered Ethernet
packet type of Hex 809B. Your network analyzer probably doesn't
recognize this one yet, but you will want it soon.
2. RTMP is the AppleTalk routing information scheme. It calls for a broadcast
packet every 10 seconds. We can live with this one, we know other routers
do this, but what interval would you like to encourage Apple to use? I
would like to see these packets closer to one minute apart.
3. Look out for AARP broadcasts! Apple has a registered AppleTalk Address
Resolution Protocol (AARP) packet type for Ethernet (Hex 80F3) and the
packet format looks a lot like ARP. There is a special broadcast packet
under AARP called a "probe" which prompted this warning message.
When EtherTalk is initialized (machine is booted), an EtherTalk node must
defend its unique 8-bit node number. Probe packets are sent out to try
to identify any machine with a matching node number. If no machine
responds, then the number is assumed to be unique.
Here's the kicker: The official EtherTalk specification calls for 20
retries of this broadcast packet spaced at intervals of 1/30th of a
second. Measurements confirm this is true for all of the EtherTalk
implementations that we have. So, you get a 20 packet broadcast storm
every time a Mac is booted.
What effect will this have on our networks? What about when there are 100
Macs on the same physical wire as your Suns? This obviously is of some
concern because we get bug reports from people who have noticed. Our
problem is that EtherTalk sometimes chooses to defend its node number when
our NCSA Telnet application is launched. Then we get blamed for an EtherTalk
problem. Note for Ethernet snoopers: If the packet type is 80F3 or 809B,
then we didn't generate it. We only generate IP (0800) and ARP (0806)
packet types.
Tim Krauskopf timk@ncsa.uiuc.edu (ARPA)
National Center for Supercomputing Applications 14013@ncsavmsa (BITNET)
(217)244-0638louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") (01/01/88)
Gee, it's too bad EtherTalk doesn't use an ethernet multicast address, rather than using the (global) broadcast address. This way, only those who feel they are interested would have to listen for this stuff. By the way, how did this "big-lan@suvm.bitnet" address escape on to the internet? This is a little unfriendly. louie
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (01/02/88)
As it stands, I see it as an excelent argument for IP routers in the great router vs. bridge debate. From what you say, it appears that you can't have more than 250 MACs using EtherTalk anywhere in your bridged Ether, and if you have even a hundred, people will notice. Presumably the 8-bit node ID is *really* built-in, even if the 20 broadcasts in less than a second aren't? Or, do they do it quickly because the defense protocol breaks down when two nodes try to defend the same address at the same time? Whichever, I assume that it won't be long before they lose a big order because of it, and set some engineers to work on inserting a slightly more global world-view. jbvb
ragge@nada.kth.se (Ragnar Sundblad) (01/30/88)
In article <305731.880101.JBVB@AI.AI.MIT.EDU> JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") writes: >As it stands, I see it as an excelent argument for IP routers in the great >router vs. bridge debate. From what you say, it appears that you can't >have more than 250 MACs using EtherTalk anywhere in your bridged Ether, Right, you must have a more intelligent bridge. Then you can give the nets appletalk net numbers. >and if you have even a hundred, people will notice. Presumably the 8-bit >node ID is *really* built-in, even if the 20 broadcasts in less than a >second aren't? They save the number for use next time. But they still have to check that the number is unique. >Or, do they do it quickly because the defense protocol >breaks down when two nodes try to defend the same address at the same >time? Ha, ha, ha... 1. The mac (II) does not auto-power-on (normally) 2. The broadcast "storm" will not be sent before the user tries to use the network. (by printing etc) /ragge@nada.kth.se