slevy@UC.MSC.UMN.EDU ("Stuart Levy") (05/21/88)
If you don't use hyroute, then the hyperchannel driver will demand an IP address of the form <anything>.<loopback_code>.<adapter_address>.<port_number> (with each <xxx> an 8-bit field) and then you really do need a class A net. But if you use hyroute, you can just put "direct" statements into /etc/hyroute.conf and create an arbitrary mapping of IP addresses to (loopback_code, adapter_addr, port_number, other_bits) tuples. In other words, you can use any IP addresses you wish -- they should fit just fine into a subnetted class B network. Since Crays don't do subnetting yet (in 3.0 at least, I think not in 4.0 either) you may have to use another machine as a subnet gateway, but that shouldn't be too troublesome. I know the above is true for the Cray-2 since we're actually using hyroute in this way. I'm reasonably certain that X-MP's act the same way. Stuart Levy, Minnesota Supercomputer Center slevy@uc.msc.umn.edu, (612) 626-0211
MURAKAMI@ntt-20.ntt.jp (ken-ichiro murakami) (05/22/88)
I have some questions about address mapping between HYPERchannel and IP
address. Please let me know if you know HYROUTE mapping mechanism.
We are using HYROUTE on SUN to connect hosts on HYPERchannel and hosts
on ethernet by TCP/IP. We used class A IP address on Hyperchannel and
class C IP address on ethernet so far. We did not obtained the class A
address from SRI-NIC. This is because these hosts are isolated from
our main network. Recently, we decided to connect the HYPER channel
network to our main network and change the address from class A to
subnetted class B which we obtained from SRI-NIC. When I asked our
support engineer to change it, he told me that it was impossible to
use subnetted class B address on HYPERchannel. I heard the problem was
caused by HYROUTE address mapping facility.
Since I could not find HYROUTE documents around me, I estimated the
mapping from /etc/hosts, /etc/networks and /etc/hycf files. It seems
there is no dynamic mapping between HYPERchannel address and IP
address. Static mapping is employed. In addition to it, the mapping is
so simple and HYPERchannel address(8bit physical address + 8bit
logical address) is used as the lower 2 byte of IP address. It
consumes a lot of IP address. Our network address is class B and we
cannot afford to assign a lot of subnet and host address to
HYPERchannel. So, I'd like to ask you the following questions;
(1) Is there any way to save IP address on HYPERchannel?
(2) Why does HYROUTE need class A address on HYPERchannel?
(3) Where are the documents for HYROUTE and its mapping algorithm?
Is it possible to get it?
Thanks in advance.
KEN
murakami%ntt-20.ntt.jp@relay.cs.net
Ken-ichiro Murakami
NTT Laboratories
3-9-11, Midori-cho, Musashino-shi
Tokyo, 180 Japan
-------shore@REASON.PSC.EDU (05/23/88)
I'm using class B addresses on a HyperChannel subnet (8 bit subnet portion) from a uVax running 4.3, but I had to tickle the device driver some. The problem was that the driver was using the host part of the address as a hash key, as was hyroute, but the kernel and library routines to get it are slightly different (the kernel strips off subnet bits - the library version doesn't). This is easily fixed, but you may be having different problems with the Sun driver. Melinda
dab@oliver.CRAY.COM (Dave Borman) (05/23/88)
I can proababaly answer quite a few questions about HYROUTE. First, it depends on what version of HYROUTE you are using. There have been two main versions of the HYPERchannel driver, the one written years ago at Tektronix (and distributed with 4.2BSD and 4.3BSD), and the one developed by CRAY research. The two drivers are incompattable with each other, because the Tektronix driver uses a variable size Message Proper, and the CRAY driver insists on a 64 byte Message Proper. From my experience, a lot of vendors that have HYPERchannel drivers are using the CRAY version (since there is now an RFC, #1044, that is compatable with the CRAY version) HYPERchannel does NOT have a broadcast mechanism. Therefore, if you are going to use TCP/IP over HYPERchannel, you can't use ARP, and you have to have some other method for translating IP address to HYPERchannel address. For those that do not use a HYROUTE command, the usual method is to put the 16 bit HYPERchannel address in the bottom 16 bits of the IP address. With that scheme, you can not use subnetted Class B addresses. Also, several implementations also use bits in the 3rd byte for loopback control information, hence meaning that this scheme only works with Class A addresses. I personally find this method as less than acceptable. The HYROUTE program provides the kernel with mappings between internet address and HYPERchannel addresses. Typically, it uses a hash table to speed up lookups. HYROUTE should work with Class A, B and C addresses. If you machine/driver doesn't work with all of them, complain to the vendor because the implementation is broken. For most implementations of HYROUTE, it does it's hashing, on just the host part of the address. I've been thinking long and hard on this. It can cause problems with subnets if the HYROUTE program and the kernel are not in sync with each on whether or not a network is subnetted. The HYROUTE builds the hash table and writes it into the kernel, so the kernel had better be hashing things the same way as HYROUTE or things won't work right. I'll probably be changing the CRAY UNICOS implementation of HYROUTE to hash on the entire 32 bit IP address, and then it won't matter any more whether an address is subnetted or not. The bottom line is that any implementation of HYROUTE that limits you to a subset of the IP addresses that the vendor supports is broken. (That is, if the vendor doesn't support subnets, then his HYROUTE program isn't broken because it doesn't work with subnets. But if the vendor does support subnets, as the vendor should, and HYROUTE does not work with subnets, then the vendor's implementation is broken) -Dave Borman CRAY Research, INC.
lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) (06/14/88)
The bottom line is that any implementation of HYROUTE that limits
you to a subset of the IP addresses that the vendor supports is
broken. (That is, if the vendor doesn't support subnets, then
his HYROUTE program isn't broken because it doesn't work with
subnets. But if the vendor does support subnets, as the vendor
should, and HYROUTE does not work with subnets, then the vendor's
implementation is broken)
I bet this problem stems from the fact that the BSD distributed
in_lnaof() in the C-library does not return the subnetted net, only
the main network number. (At least the version we have. I think
I've gotten all bug fixes.)
So, the typical clever programmer just calls in_lnaof(addr) in
both the hyroute and the kernel, and loses cause they return
different things for user and kernel space.
I fixed this here some time ago by sticking in a in_mainlnaof()
in the hy driver, and calling that. It returns only the class A,B,C
network. It would be better to repair the c-library, but
it does not seem to be a trivial fix, and I didn't want to
worry about breaking other things at this time.
I like the idea of hashing on the whole IP address better, but it
does mean a more difficult hashing algorithm, or else a really
big table. I know those few rotates and adds don't much matter,
but they have to happen on every packet.
john