From: id@sifon.cc.mcgill.ca (Ian Duncan)
Subject: Re: Can NW bridge, and not route IP? (lengthy)
Organization: McGill University Computing Centre
Date: Thu, 30 Jul 1992 20:38:13 GMT


My apologies for the length of this message but the topic has been kicked
around for awhile now and I'm getting mixed signals from various voices at
Novell. I also should note that these are just my opinions, not official
McGill policy statements. 

In article <1992Jul29.232649.12279@novell.com> keith@novell.com (Keith Brown) writes:
>In article <1992Jul29.153952.57631@cc.usu.edu> jrd@cc.usu.edu writes:
>>
>>	Just one (today): *when*
>
>Joe, how many times do I have to tell you about using the 'W' word on
>this forum? :-)
>
>>This problem of forced subnetting to handle small situations is
>>very common,
>
>Right. Lets not forget that OSPF and support for variable length subnet
>masks within a single IP subnet will ease the strain a little too. What
>your asking for is so called "BROUTER" functionality though (I think?).

If you think OSPF is going to solve the existing problem for large
installed heterogenous networks (ie. existing networks that involve more
than Netware for routing) then I can only hope someone else at Novell is
making the strategic decisions! Sorry if that seems a little harsh but I'm
not about to recommend reconstruction of a network with over a 1000
routing entities because 60 odd Netware servers are so crippled that
they can't provide a basic router service.

A properly implemented Proxy-ARP is all I need (well, all that I'll ask
for today). Now **when**?

>Keith Brown                                      Phone: (408) 473 8308
>Novell San Jose Development Center               Fax:   (408) 473 8990
>2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

My previous postings about this question generated a couple of private
notes asking for details about the problem and my suggested solution.  In
an effort to increase the technical content of the debate I'm attaching a
copy of the response I made to one of them. It is offered as a sacrificial
lamb to be carved up and critiqued. And despite the metaphor I'm not out for
blood. When I see red I'd much rather be happily opening a new box from
Novell. As our network address space gets tighter this is becoming more and
more of an issue. I'm beginning to appreciate how the IAB must feel.

On Sun, 26 Jul 92 22:54:29 PDT, Jonn Martell wrote:

> Subject: Re: Subnetting for Novell routing.
> To: id@sifon.CC.McGill.CA
>
> Hi Ian,
>
> Can you describe what Proxy-ARP is?  I know that Novell doesn't support it
> and that it is a limitation for IP routing but I am wondering to
> what degree.
>
> If you can suggest a book or reference I would be grateful.
>
> Thanks.

OK.

Chapter 16 of Comer's Internetworking with TCP/IP (Vol1, second Ed.)
explains it and the related subnet issues well. If you plan to spend any
time trying to understand the guts of IP networking you need this book.
Also check out RFC1027 by Carl-Mitchell & Quarterman and all the
references they point to. 

And here's my take on it.

The idea is simple. ARP is the mechanism used to discover the media
address (eg. ethernet) associated with any local (within a pysical
subnetwork) internet address and is the basis for local routing in most IP
LAN schemes. ARP requests are a broadcast to the world asking "is there a
machine out there answering to this IP address?". A response comes back
with the media address of device assigned that IP address, this gets tuck
in a table and is used from then on whenever a datagram for that IP
address turns up in the outbound queue. 

Proxy-ARP extends this media address resolution across a gateway as long
as certain conditions with respect to net masks and other details are met.
The so called 'transparent' gateway provided by Proxy-ARP indentifies ARP
requests addressed beyond the local physical subnet (eg. a single
ethernet). Based on its internal ARP cache or on the response to
forwarding the request, it will offer its own media address in the ARP
response. The implication of this is that the gateway will, behind the
scenes, provide a forwarding service (or 'proxy') for the device you're
really looking for.

My concrete example (and the problem which begs the question) is our
Netware-TCP/IP internet. McGill has a large campus network with IP sharing
the wire with IPX. Most of our Novell fileservers are running the IP
routing code. 

The IP side of the net is contained in one class B net address,
132.206.0.0. This provides for 2^16 (less a few) IP addresses. For a
number of reasons the people who set up the network carved that address up
into subnets, using the third octet to make up a 24 bit netmask. RIP is
used to provide routing within the network. In spite of the low opinion
that consensus has for RIP, this all works reasonably well.

RIP does have some shortcomings. The one encountered here is that it can't
deal with variable subnet sizes,  so we can't organise the net with IP
subnets sized to come close to the number of machines in each physical
subnet. RIP II and OSPF both offer a 'correct' solution to this problem.
Unfortunately neither are commonly available across the range of hosts and
routers that make up our net.

Here's a simple diagram of a potential fragment of our net.

    ... _____ campus backbone ______
                                    \
				     |
                                 [ file server ]
                                     |     |
  ... ________ Subnet1 _____________/       \ _______ Subnet2 _______ ...
           |             |                        |             |
       [ Mach.1A ]   [ Mach.1B ]              [ Mach.2A ]   [ Mach.2B ]

Currently, to satisfy RIP and so on, we have to assign a subnet address to
each spur (physical network) connected to a netware server. On the diagram
we might asssign 132.206.15 to Subnet1 and 132.206.16 to Subnet2. The
machines in each subnet are assigned addresses within that subnet --
Mach.1A is 132.206.15.39 and Mach.2B is 132.206.16.75.

Datagrams destined for Mach.1A from Mach.2B will be identified by the
routing code internal to the machine as being outside the local network
(ie. for a device in another subnet) so the datagram gets sent directly to
the default gateway, the local interface on the fileserver. The file
server checks the routing table and forwards the datagram out its
interface on Subnet1 with the media address of Mach.1A. So far this sounds
perfect.

But we have many servers, most have 2 or 3 physical networks attached and
most of these contain just a few machines. Abstractly, given 50 servers
with an average of 2 subnets and 10 machines in each subnet, we use 100
out of 250+ subnet addresses (more than 25,000 potential addresses) to
provide addresses for a just a 1000 stations. Suddenly that class B net
address doesn't seem so big anymore.

Correctly implemented and properly installed, Proxy-ARP would solve this
problem by allowing us to assign a single subnet address (from the point
of view of RIP) to each fileserver. Machines would continue to treat
addresses within the IP subnet as local, even those outside the physical
subnet. The fileserver would provide transparent gateway service for all
of the spurs attached to it as well as continuing to be identified by each
machine as the default gateway for the world beyond.

Going back to the diagram, we could reorganise the assigned addresses so
that the server would hub for the subnet 132.206.15. For simple example
assign Mach.2B the address 132.206.15.75 and leave Mach1A alone. Traffic
between Mach.1A and Mach2B would continue to flow forwarded through the
Proxy code, RIP would continue to work and I could retrieve subnet 16. 

This one simple facility would permit us to reassign at least 40 subnet
addresses and put off indefinitely major reorganisation of our network, a
project which looms rather large right now. If we can put it off for a few
years better solutions may be more available.

And from what I gather from conversations with others McGill is a very
typical installation so many people share this problem.

Does that answer your question?

-- 
   ...   ian   <id@cc.mcgill.ca>
Ian Duncan  ---  McGill University Computing Center  ---  +.514.398.3714