RAF@NIHCU.BITNET ("Roger Fajman") (11/03/87)
MAIL FROM RAF SATURDAY 10/31/87 8:21:02 P.M. I guess that this may have been discussed before, but due to a problem with our mailer here I wasn't getting much mail from this list at the time. Anyway, we recently acquired a class B network number for our planned campus network and the issue arises about how to divide the 16-bit address space between subnet numbers and host numbers. If we make the subnet field small, we probably won't have enough subnet numbers (a 5 bit subnet field gives 30 networks of 2046 hosts each) and a lot of address space is wasted on small subnets. If we make the subnet field large, we won't have enough host numbers for our largest subnet (an 8 bit subnet field gives 254 networks of 254 nodes each). This naturally leads to the question: can multiple subnet numbers be assigned to the same physical network? Since we plan to use Proteon p4200 Gateways for at least some things, I called Proteon and asked them. They told me that there is no problem, as each network interface can be assigned up to 16 IP addresses, thus allowing it to respond to an IP address for each of up to 16 subnets that reside on the same physical network. I was told that this was desirable because many hosts require that any gateway that they use be on their own subnet. Now I was recently shown a copy of a message from last July that said that in such a situation, a Unix system would receive Ethernet broadcast packets containing IP broadcast packets for other subnet numbers, not realize that they were broadcast packets for another subnet, and try to process (forward or redirect) them in some way. More recently, I received a message on this list that said that a Unix system would not try to perform gateway functions unless it had more than one network interface, regardless of how its parameters were set. Anyway, what is the truth? Can we assign multiple subnet numbers to the same physical network or not? What have others done about this problem? Roger Fajman RAF@NIHCU.BITNET National Institutes of Health
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (11/07/87)
As usual, everyone was right, in the context. Mike Karels described the behaviour of his Unix, 4.3, which ought to work right in this situation. Other people have described *their* Unices, and other O/Ss, like Phil's LISPMs, which are going to give trouble. There are several problems you'll run into: The first is that some 4.2- derived systems believe in broadcast addresses of Net.0, and other systems believe in Net.255. The second is that some manufacturers leave their Unices believing that they are IP routers, even when they have only one network interface. The third is that some manufacturers don't include code to implement the law "don't reply to broadcast packets unless you're *really* *sure* you ought to". The fourth is that some manufacturers don't understand about subnets. The end result of this is that on one net I know, an Old-Broadcastian sends an rwho packet, and 29 (or more - my monitor was only an XT) Sun and Vax New-Broadcastians immediately attempt to either forward the packet (they think they're gateways), or send an ICMP Net Unreachable (gateway-ism partly disabled). Great fun. Also available between systems that do and don't grok subnets, and the two together are greater than the sum or the parts. Phil Karn cited some misbehavers. There are others. All can be fixed if you have source, most can be fixed through patience and vigilance on the part of a network administrator (watching and making people correct mis-configured systems). jbvb
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (11/09/87)
It is important for the general health of an complex IP network to keep hosts that are not supposed to be functioning as routers (gateways) from forwarding packets at all. This more than anything else has caused more problems, e.g.: Host receives broadcast packet with wrong type broadcast IP address and tries to ARP for it, sending host into tight loop (Old Wollongong VMS TCP/IP). Host receives packet for some host other than itself, tries to send an ICMP error packet and generates bogus ARP field causing other hosts to think that it was the host that sent the packet (Ungerman Bass TCP). -Ron