U of Iowa (JNFORDPB%UIAMVS.BITNET@wiscvm.wisc.edu)
Thursday 19 Nov 87 12:36 PM CT
This is a request for network configuration suggestions. Any
responses should be sent to me rather than to the list.
How have other sites approached and/or solved the problems associated
with establishing and administering large campus networks?
Is the topology outlined below feasible without having static,
manually-entered routes for the entire campus?
Will an ARP (or any) ethernet-level broadcast from a host on one
ethernet make it through a gateway to a host on another ethernet?
Will the ARP reply make it back to the broadcaster? Is it necessary
to have something along the lines of proxy-ARP to make this work?
Does existing software support proxy-ARP?
Does anyone have suggestions addressing problems at any level which
would alleviate some of the routing complexity?
We are new at this, and very well might have incorrect
interpretations of the problems we face. By the same reasoning, we
certainly are not aware of all the possible solutions to our
problems. Any help would be appreciated. Thank you.
The University of Iowa is in the process of establishing a campus
network consisting of departmental LANs hung off of a broadband
backbone. The departmental nets use various technologies including
Ethernet/IEEE 802.3, proprietary token rings, and fiber. Some
departments have multi-level networks (see figure below).
Access to the broadband backbone is provided through ethernet bridges
(Bridge IB/1 boxes), with each department having one IB/1. The IB/1
is a MAC-level bridge, so that a host on a baseband ethernet
connected to an IB/1 in one department appears to be on the same
physical cable as a host on a baseband ethernet connected to an IB/1
in another department.
We have a mixture of machines and OSs, including VAXes running 4.2 &
4.3 BSD, VAXes running VMS, Encores running UMAX 4.2, Apollos, Suns,
PCs, Primes, and IBMs running MVS; we also have a handful of Encore
Annex terminal servers.
The U of Iowa has been granted a class B Internet number of 128.255.
We will soon activate a connection to MIDnet -> NSFnet -> world.
The current network topology (with only two departments connected) is:
|| Annex1 ---|
|| +------+ |
||---| IB/1 |-----(ethernet1)-----|
|| +------+ |
|| Encore1 ---|
|--- Encore2 (broadband)
|--- Alliant ||
| +------+ ||
|-----(ethernet2)-----| IB/1 |---||
| +------+ ||
|--- VMSVax1 || +---------+
| ||---| Proteon |----> (MIDnet)
|--- Apollo1 || +---------+
\ / |--- BSDVax1
| |--- BSDVax2
We would like to assign a subnet number to each physical network.
network internet subnet
Apollo ring 128.255.21
The presence of independently administered networks within the campus
lends itself to a subnetting scheme, with each department receiving a
block of subnet numbers from which to allocate numbers for the
networks under the control of the department. We have encountered
some routing problems which may be attributable to the coexistence of
IP implementations which do support subnetting and those which do
The broadband bridging makes ethernet1 and ethernet2 appear to be one
physical network, so we end up with one network having more than one
subnet number. This seems to cause problems with routing for the
hosts which understand subnetting. They think the hosts on the other
subnet should be on a different physical network and expect to have a
gateway to get there. Since there is no gateway, they don't see a
path to the other subnet.
Disabling subnetting (by changing the netmask to 255.255.0.0 in the
subnetting hosts) makes everybody think that the entire campus is one
big physical (class B) network. This solves the problem just
described, but it defeats the subnet-based routing required to access
the networks which are actually subnetted, such as Apollo-ring and
One proposed solution is to place a router between the IB/1 and the
networks within each department. This has the advantage of making
the broadband a separate subnet and providing the gateways (arguably)
needed for subnet-based routing as described above. Disadvantages
include the decrease in throughput (compared to just the bridge), the
added cost of the router (or an additional ethernet interface for a
host acting as a router), and the restriction on the protocols which
may then cross the broadband. Furthermore, I am not convinced that
such a configuration would solve all our problems without introducing
Weeg Computing Center
University of Iowa
Iowa City, IA 52242
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:56 GMT