cpw%sneezy@LANL.GOV (C. Philip Wood) (02/24/88)
Does anyone on this list have an inkling about why given the following
configuration that one specific hosts ethernet packets are not passed
through a "bridge":
segment 1 segment 2
Ha--| |--Hz
| |
Hb--| |--Hz-1
| |
Hp--| |
. .
. .
. .
Hq--| |--Hr
|--[D]--|
All the hosts Ha through Hz with the exception of Hp can communicate over
the ether. All the hosts Ha through Hq INCLUDING Hp can communicate over
segment 1.
Phil Wood
P.S. I'm afraid to mention any vendor's names for fear of getting sue'd.cpw%sneezy@LANL.GOV (C. Philip Wood) (02/24/88)
Naming names. No dispersions intended. But, hey, I want to know! Does anyone on this list have an inkling about why given the following configuration that 99.9% packets destined for an HP system are not passed through a DEC MacLevel Bridge? (Thats right, one maybe every 300 to 400 packets) segment #1 segment #2 8:0:20:1:33:1e Ha--| |--Hz 8:0:2b:3:92:23 | | 8:0:20:1:47:d2 Hb--| |--Hz-1 8:0:20:1:d7:e5 |icmp icmp |--Hy 2:7:1:0:a6:59 8:0:9:0:65:3d Hp*--|echo-> echo->|--Hx aa:0:4:0:da:4 hummmm. nada <-reply | . . . . . . 8:0:20:1:66:6a Hq--| |--Hr 8:0:2b:3:91:5c |----?[DEC lanBridge]?---| SUBNET 1 of Class B network 128.165, mask==0xfffffc00 There is probably alot of irreverent/irrelevant, but, it was fun. All the hosts Ha through Hz with the exception of Hp can communicate over the ether. By communicate, I mean ICMP echo, vanilla, no ip options. All the hosts Ha through Hq ***INCLUDING*** Hp* CAN communicate over segment #1. When attempting an ICMP Echo between Hp and Hx, an 'etherfind' on segment #2 shows an echo and echo reply reply packet. While an 'etherfind' on segment #1 shows an echo packet, one out of 400 reply's make it. Do this with any other pair, like Ha -- Hx, or Hp -- Ha, and it works bwainoh. * Hp == HP-UX hp320 6.01 B 9000/320 Is there something strange about that address? ... I don't think so. (Little is known about this one of a kind on our net. It would be nice if we could look at its "arp" tables, but they did it their way, what if? ..., Rumor has it that the system is BSD3.4 made to look like system V.) Ha == Sun UNIX 4.2 Release 3.4 (This release is known to be worthless on a subnet, however, it appears to work if it stands alone and does not use the yellow pages.) Hr == VAX-11/785 running VMS/Wollengon (3.1) (They do ICMP mask request replys correctly, its about time!, but don't send them too many packets in a row!) Hz == VAX-11/785 running BSD 4.3 (They forget to swap their subnetmask and mess up anyone foolish enough to broadcast an ICMP mask request, fixed by me, cause I got source!) Hz-1 == Sun 3/260 running 3.5 (Hey, I can ifconfig netmasks and broadcast addresses, but darn I still can't ip route between 128.165.4.xx (mask == 0xfffffc00) and 192.5.16.96 (mask == 0xffffffe0), and double darn the routed just chewed up all my cpu and flooded the net with gosh knows what kind of "routing" packets, and those yellow lights on the DEC LanBridge just don't blink anymore, their SOLID.) Hx == VAX-8600 running Ultrix V2.0-1 (Talk about skizoid, this dude talks DECNET and INTERNET of'n a one DEUNA and it's network application suite has been loaded at j random times with: gethostbyname from /etc/hosts gethostbyname from /etc/yp gethostbyname from /etc/resolv.conf (yup, ypserv -i) So try, and answer a vanilla users question like "why can I rsh and not rlogin!") Hy == Celerity running Accel UNIX, (They were nice to rush us a patch for their systems that fixed a bug that stomped on SUN clients attempting to boot. ... == Bridge, Inc. terminal servers, Bridge, Inc. GS7's and GS3's, pure DECNET VMS VAX systems, IBMPC's, KINETICS MacInTosh "gateway's", miscelaneous DEC terminal servers, IBM RT's which respond to ICMP echo requests and return the IP Record Route option, bless there heart!) Phil Wood P.S. I'm not afraid anymore. I think I'll save this one.
neerma@COD.NOSC.MIL (Merle A. Neer) (02/24/88)
In our own experience in a similar configuration we discovered that some segments have more errors occurring on them. In turn some hosts are less tolerant of errors and refused to talk over a 'corrupted' cable. I dont know if this is your problem but you might look at the local ether segment to see if some transcievers have been installed improperly etc. As I mentioned we had a similar problem in that some hosts could not communicate throught a bridge yet could talk to each other if they were on a local cable. When we moved these particular hosts to a new cable they were ok. What can I say..it worked! Merle. neerma at nosc ------- -------
ehrlich@blitz (Dan Ehrlich) (03/03/88)
Once upon a time, in another job far, far, away I also encountered these mysterious aa:0:4:0:xx:xx addresses. Read on. Maybe someone can explain to me why DEC does what it does. :-) In article <8802232312.AA02132@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes: >... > > segment #1 segment #2 > > 8:0:20:1:33:1e Ha--| |--Hz 8:0:2b:3:92:23 > | | > 8:0:20:1:47:d2 Hb--| |--Hz-1 8:0:20:1:d7:e5 > |icmp icmp |--Hy 2:7:1:0:a6:59 > 8:0:9:0:65:3d Hp*--|echo-> echo->|--Hx aa:0:4:0:da:4 hummmm. ^^^^^^^^^^^^^ This mystery number is from a VAX running DECnet, either under VMS or Ultrix. It could also be from another vendor that has implemented DECnet's host->ethernet address mapping. DEC in their infinite wisdom uses one of the maintenance functions in the DE[QU]NA to change the physical ethernet address from what is in the ROM to this magic number. I do not know if they have gotten around to documenting how it is computed, but if memory serves me correctly it goes something like this: aa:0:4:0 is a magic constant that appears on any VAX running DECnet. da:4 is, get ready, the DECnet host and area number (byte swapped of course). Educated guess says that this is DECnet host 1.218. (Area number) * 1024 + (Host number). When I asked DEC why they do this I got numerous excuses. "Keeping a table mapping DECnet host numbers to Ethernet addresses would soak up too much memory" "We do not have anything like ARP and do not expect to in the near future" "Whoes name is on the fron of the 'Blue Book' anyway?". All of these are from the 1986 time frame and as I have not had reason to ask the question of late do know know if the responses are still valid. > nada <-reply | > . . > . . > . . > 8:0:20:1:66:6a Hq--| |--Hr 8:0:2b:3:91:5c > |----?[DEC lanBridge]?---| > > SUBNET 1 of Class B network 128.165, mask==0xfffffc00 > >There is probably alot of irreverent/irrelevant, but, it was fun. >... Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}> The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723
gordan@maccs.UUCP (gordan) (03/05/88)
In article <3343@psuvax1.psu.edu> ehrlich@blitz.cs.psu.edu (Dan Ehrlich) writes:
-Once upon a time, in another job far, far, away I also encountered
-these mysterious aa:0:4:0:xx:xx addresses. Read on. Maybe someone
-can explain to me why DEC does what it does. :-)
-
-This mystery number is from a VAX running DECnet, either under VMS or
-Ultrix. [...] DEC in their infinite wisdom uses one of the maintenance
-functions in the DE[QU]NA to change the physical ethernet address from
-what is in the ROM to this magic number.
I wondered about those funny addresses myself when I found this in one
of my log files some time ago (it appeared to have snuck in as a
multicast packet). Then those lists of Ethernet packet types were
posted to this group, and 6003 was listed as "DEC/DNA Routing". Out of
sheer idle curiosity, anybody know what the protocol header fields are
for this packet?
aa 00 04 00 02 04 aa 00 04 00 01 04 60 03 1d 00 ............`...
81 26 00 00 aa 00 04 00 02 04 00 00 aa 00 04 00 .&..............
01 04 00 00 00 00 04 0a 18 0a 04 5d 86 00 00 00 ...........]....
00 00 00 00 00 00 00 00 00 00 00 00 ............
Ethernet -- aa 0 4 0 1 4 --> aa 0 4 0 2 4
Packet type (hex) : 6003