dpowles@CCD.BBN.COM ("Drew M. Powles") (10/30/87)
We are doing a survey for a local client on IP implementations. The descriptions in the vendors guide don't really go into the detail we're looking for in one respect: Subnetting support (ala RFC 950). I realize that both RFC 1011 and RFC 1009 require subnetting be supported, but I have run into many folks in the 'biz that insist most vendors do not implement nor plan to implement subnetting support. For instance, does the Wollongong software implement RFC 950? What about Berkeley, or AT&Ts 3B TCP/IP? What about the gateway vendors (of course I know about BBN's) such as cisco Systems? I do note the Fuzzballs support it; the fuzzball description was one of the few that called out subnetting specifically. How about the interface and front-end vendors like ACC? Any and all help would certainly be appreciated. You can send directly to me, dpowles@bbn.com and I'll summarize to the community if you'd like. thanks! Drew Powles Columbia Professional Services BBN Communications
per@erix.UUCP (Per Hedeland) (05/05/88)
Excuse me if the question below is trivial, but I really haven't seen much
discussion on subnetting, and neither RFC reading nor local asking-around
has gotten me very far...
This is the scenario: The basic structure of our LAN is a backbone segment,
to which a number of Sun server/client groups are connected. Each client group
has it's own Ether segment, with the server acting as gateway to the backbone.
Typically there are 5-10 clients in each group. There are currently some 20
such groups, but predictions are for hundreds in the not too distant future,
i.e. considering other connected equipment, far more than 256 addresses are
required for the backbone.
Due to us not being connected to the Internet, and inadequate planning of the
growth of the LAN, network numbering is a mess, which we would like to clean up
as soon as possible, and this prompts my question: It seems to be a terrible
waste of adress space to use a separate class C number for each of the client
groups, so we figured that subnetting would be appropriate, but how do we use
it to an advantage?
Specifically, given the abovementioned structure, there's a conflict between:
a) It appears that the intended use of subnetting assumes that all the "subs"
of a "whole" net are interconnected, i.e. the backbone and the client
segments in our case should be "subs" of the same "whole" - in particular,
"automatic" routing by means of routed (which we desire) will not work
otherwise, as far as I can understand.
and:
b) "Subs" of a given "whole" must be of equal size.
We do believe that the arguments for the current structure (such as handling
the load from diskless clients, avoiding extra cabling given the physical
location of servers and clients, allowing use of the backbone for e.g. DECnet
traffic) are valid, and it seems rather silly having to modify it to
accommodate the IP adressing scheme. But of course, neither the structure nor
the requirement for "automatic" routing are carved in stone, i.e. any and all
suggestions are welcome (preferrably via e-mail, and I will summarize to the
net if requested).
Thanks In Advance
--Per Hedeland
Internet: per@erix.ericsson.se
Non-MX: per%erix.ericsson.se@uunet.uu.net
UUCP: {mcvax,munnari,uunet}!enea!erix!perbc@halley.UUCP (Bill Crews) (05/06/88)
In article <1607@erix.UUCP> per@erix.ericsson.se (Per Hedeland) writes: > >Typically there are 5-10 clients in each group. There are currently some 20 >such groups, but predictions are for hundreds in the not too distant future, >i.e. considering other connected equipment, far more than 256 addresses are >required for the backbone. > It seems to be a terrible >waste of adress space to use a separate class C number for each of the client >groups, so we figured that subnetting would be appropriate, It does to me, too. So, why not just use class B addresses? Based on the criteria you dictate, that would seem to be adequate for now and the future. -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350
Doug_Nelson@UM.CC.UMICH.EDU (05/07/88)
In message <1607@erix.UUCP>, Per Hedeland writes: > a) It appears that the intended use of subnetting assumes that all the "subs" > of a "whole" net are interconnected, i.e. the backbone and the client > segments in our case should be "subs" of the same "whole" - in particular, > "automatic" routing by means of routed (which we desire) will not work > otherwise, as far as I can understand. Yes, that has to be true - you can only advertise your full network, not your subnets, to the Internet at large. > b) "Subs" of a given "whole" must be of equal size. This is a mistaken assumption. There is nothing that prevents you from using subnets of different sizes on a given net, except for software that isn't up to speed on subnetting (notably SunOS 3.x). For example, our campus-wide network is a class B sized subnet of a class A network. The Merit network itself is a class A/2 subnet, and Univ of Michigan has parceled out a number of class C-sized subnets. I plan to pass out class C-sized subnets of our network (or possibly smaller) to several other campus Ethernets, as soon as we get SunOS 4.0 installed. Doug Nelson den@serv1.cl.msu.edu Michigan State University 08071den@msu.bitnet Computer Laboratory
joe@tekbspa.UUCP (Joe Angelo) (05/09/88)
in article <358@halley.UUCP>, bc@halley.UUCP (Bill Crews) says: > Xref: tekbspa comp.dcom.lans:150 comp.protocols.tcp-ip:495 > > > It does to me, too. So, why not just use class B addresses? Based on the > criteria you dictate, that would seem to be adequate for now and the future. > Now, the classes of IP addresses is simple enough to understand -- But what about subnetting? When does one want to *really* use two IP network address on the same cable? And what performance advantages does this give you? Were does the netmask come it at? Is subnetting just a nice admistrativia thing? Or does your local enet board not receive the packets, period? Or is it the high level software that ignores the packet? Does anything really ignore anything? -- "I'm trying Joe Angelo -- Senior Systems Engineer/Systems Manager to think at Teknekron Software Systems, Palo Alto 415-325-1025 but nothing happens!" uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (05/09/88)
> > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. You may be able to live with the effects of misinterpretations if things are kept simple enough (so long as nothing sends you a network redirect :->). The subnetting RFCs, e.g. 917, 936, 950 discuss some possible conventions for determining subnet sizes, including equal sizes on a given network (easy) and self-encoding subnet sizes analogous to the class A/B/C sizing for ordinary networks. I suppose it would also be possible to distribute a table of subnet sizes to every host and gateway on a network. But in general, you -do- have to be able to know the sizes of sibling subnets, and the equal-size case seems to be the closest one to a standard. Stuart Levy
dls@mace.cc.purdue.edu (David L Stevens) (05/09/88)
Differing subnet sizes are not really a problem on all systems--
the "only if your software isn't up to snuff" comment applies.
4.3BSD includes enhancements to ICMP to ask for the interface's
netmask ("ICMP_MASKREQ"). I don't know of any user-level program that uses
this (yet).
Also, I don't think it's been clear that the "variable size" subnets
are by individual bits, not just bytes. You can split a class B net number
into 17 bits of network and 15 bits of host, if that's what you really want
to do. Some software only supports A subnetted to B and B subnetted to C
(ie, by bytes), though. Void where prohibited. Your mileage may vary.
Of course, if you have sources, you can fix it.
--
+-DLS (dls@s.cc.purdue.edu)braden@VENERA.ISI.EDU (05/09/88)
> > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. Stuart, Let's consider the three examples you cite. Network Redirect: It is recognized that network redirects are a problem in a subnetted environment, and therefore the Gateway Specification RFC-1009 says that gateways should only be sending host redirects. If you have a gateway within your subnetted environment that is sending network redirects, it should be brought up to spec. Synthesizing a remote broadcast -- presumably you mean a directed broadcast. Yes, this is a real engineering problem, although it is an application-level problem, not an IP level problem. If you have an application that is sending directed broadcasts into another subnet of the same network, that application needs some configuration information -- obviously, it needs the remote subnet number. You might as well configure it with the complete 32-bit Internet directed broadcast address. Synthesizing IP addresses should be avoided whenever possible. Routing to a remote subnet -- This is entirely a gateway problem. The solution, as RFC-1009 suggests, is simply to include the subnet masks with the network numbers in the routing updates among the subnet gateways. I wonder why no one has extended RIP in this obvious way yet. As you say, it is merely a matter of a little engineering. After all this, I would challenge your statement that "in general, you -do- have to be able to know the sizes of sibling subnets" (at least, if "you" is a host, not a gateway). Bob Braden
Doug_Nelson@UM.CC.UMICH.EDU (05/09/88)
As a couple of you have pointed out, routing is the problem with multiple subnets of different sizes. We manage routing within our subnet very trivially - we don't really do routing, since we have only a single gateway to the outside world. I encourage our Sun owners to add a default route pointing to their own system, which adds a few ARPs to our local network, but finds the gateway just fine. What really is needed is a subnet routing protocol which passes netmasks along with the network numbers. Is anyone working on this yet? Can anyone tell me if 4.3bsd includes the netmask in each routing table entry? We need this to make such a protocol usable. Doug Nelson
ed@mtxinu.UUCP (Ed Gould) (05/10/88)
>Now, the classes of IP addresses is simple enough to understand -- > >But what about subnetting? When does one want to *really* use >two IP network address on the same cable? And what performance >advantages does this give you? Were does the netmask come it at? The purpose of subnetting is not to run multiple IP addresses on the same cable, but to make a local collection of networks appear as if it were one network from the outside. To do this, one takes a standard IP adress (ususally a Class B address, but this isn't required) and uses some of the bits that are normally the "host number" part of the address as if they were part of the "network number." The netmask determines the division between host part and network part that is used locally. For example, consider the following /etc/hosts excerpt, which lists several Class B addresses. Keep in mind a netmask of 0xFFFFFF00 (the normal Class B netmask is 0xFFFF0000). 129.1.1.1 main-sys 129.1.2.1 main-sys-gw 129.1.2.2 second-sys 129.1.2.3 third-sys One topology this could represent is net to outside internal net (129.1.1) (129.1.2) ________ _________________________________ | | | | | | | | ----------- ------------- -------------- | | | | | | | main-sys| | second-sys| | third-sys | | | | | | | ----------- ------------- -------------- In this case, there are two physical networks: one connecting the three machines locally, and one connecting the main system to the outside world. To the outside world, the three machines look as if they are connected together on a single Class B network. Internally, though, they look as if they were on two separate Class C networks with a gateway. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,uunet}!mtxinu!ed +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (05/10/88)
OK. If we have permission to squash systems sending subnet redirects it'll make the situation easier. (At the University of Minnesota we've had real operational problems with this in the past.) And when we do have routing protocols that carry explicit subnet masks I'll happily shut up. It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. Again, routing protocols designed for variable-sized subnets would let this happen naturally. Stuart
braden@VENERA.ISI.EDU (05/10/88)
It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Stuart, Directed broadcast is generally a poor idea (the right solution is the IP multicasting). No architectural decision should be taken on the grounds that it makes makes directed broadcasting easier. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. I disagree. The Internet standard approach for a host: pick any gateway and let it redirect you... is simple and effective. You REALLY DON'T want hosts to know about routing, even subnet routing!! Bob Braden
jqj@HOGG.CC.UOREGON.EDU (05/11/88)
> The Internet standard approach for a host: pick any >gateway and let it redirect you... is simple and effective. .... but works abysmally given the typical host software that allows you either to (1) set a static default route to the world, or (2) run passive RIP or something like it. If I choose option 1 and the default gateway crashes, it won't be around to send ICMP redirects telling me to use the backup gateway. Phrased differently, the "Internet standard" does not adequately address the issue of how a host should pick the first gateway to try. >You REALLY DON'T want hosts to know about routing. At issue here is a critical point: how smart is it desirable for hosts to be? Braden argues that they should be very dumb. I would argue that they can be dumb if they don't really need connectivity off their network, but should be a little bit smarter if possible. If you concede that, then the next step is to decide whether it is better for a host to have: (1) a static list (n>1) of gateways to try; (2) some as yet undefined dynamic discovery mechanism for a host on a network to find the list of gateways without getting routing data; (3) hosts that listen to routing traffic and hence could potentially use the data to avoid that first bad choice of a gateway. My personal bias: Passive RIP works just fine in the XNS world as a HOST protocol as well as as a gateway protocol. It works adequately in the IP world for typical CANs and moderately complex LANs. I see no real alternative available at present.
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (05/11/88)
It looks as though 4.3BSD subnetting code doesn't store a net mask per route. There's a net mask per -interface-, but it doesn't seem to be used the way you'd hope. There's effectively just one subnet mask per net for routing purposes (I think it uses the mask set by the first interface on the net) -- that is, 4.3BSD silently assumes equal-sized subnets on a given net. If I say ifconfig ex0 128.101.1.2 netmask 255.255.255.0 ifconfig ex1 128.101.27.27 netmask 255.255.240.0 the interface route for ex1 has a destination address of "128.101.16.0" (reasonable) BUT the route is only used when sending to 128.101.16.anything. Sending to 128.101.17.anything, ..., 128.101.31.anything does not increment the interface route's usage count. 4.3's multiple subnet masks are meaningful for interfaces on different nets but not for variable-sized subnets on a single net. It'll be interesting to see whether SUN 4.0 works the same way.
per@erix.UUCP (Per Hedeland) (06/01/88)
While it may be a bit late, I thought I should post a short summary of the information I got in response to my query a few weeks back - it did generate some discussion, after all. If you recall, the issue was how to use subnetting on a network structure with a big backbone net and many small ones hanging off of it. I think the below is the essence of what I found out; I also have a pile of mail for those particularly interested. - Unequal-sized subnets, whether or not a Good Thing, is not currently implemented in any generally accepted way (and thus of little interest to us). - Partitioned subnets (i.e. subnets of a given net interconnected only by some other net) are out. - One can have several logical subnets on the same wire (i.e. the backbone in our case), thus effectively increasing the address space, at the expense of some manual "routing" (i.e. gateways have to be explicitly told that the different subnets can be accessed via the same interface - hosts on such a wire can be "fooled" into believing that it's all one (bigger) subnet). We will probably go for the latter method, with a long-term goal of splitting our backbone by using dedicated routers. Thanks to all who offered help and advice! ---Per Hedeland
scottp@se-sd.SanDiego.NCR.COM (Scott Platenberg) (03/19/91)
I am trying to build up a case for proper coordination of subnet masks on hosts and gateways in a medium sized network. There is a central router which employs the 8-bit subnet mask connecting 8 physical nets in a class B network. Some hosts on the segments have 8-bit subnet masks and others do not. The network functions with this hodge-podge config, but when I want to further subnet off one of the segments I run into problems that I feel are attributed to the subnet config. When this further segmented net tries to reach hosts on the segment which it has the direct connection to it fails if the host is not using the subnet mask. What are some other specific reasons for not having hosts on the same network have different subnet masks? Also, what problems may arise if there is a gateway with one interface using masking and the other interface not? If you feel this discussion is inappropriate for the group, please email. Thanks. +-------------------------------------------------------+ | Scott Platenberg, NCR NPD-San Diego | | 9900 Old Grove Road, San Diego, CA | | Scott.Platenberg@se-sd.SanDiego.NCR.com | | VOICE: (619) 693-5714, VOICEplus: 442-5714 | | FAX: 619-693-5705 | +-------------------------------------------------------+