From: USU::JRD "Joe Doupnik" 13-OCT-1995 14:19:32.69 To: IN%"NOVELL@LISTSERV.SYR.EDU" CC: JRD Subj: RE: Routing >Joe D. - stop reading now. Take a coffee break ;) Nah, this is too much fun to pass up. I'll be kind. >I'm still up the wall with my routing problem, and despite best efforts >I need to risk a severe flaming here again from Joe (2nd degree burns >last time ;) > >Scenario >-------- >I have a 3.11 server with three NE2000's in. One talks to the Internet, the >other two talk to my workstations (2 IPX segments). I have a range of 64 >consecutive IP numbers. > >Ideally, I'd like all 64 numbers to be seen by both segments but I understand >this isn't possible. So... how can I route either 32 each way, or 16 one >way, 48 the other. Let's make an inference in lieu of hard numbers. You have been given a piece of a Class B or C IP address. As given you have only the lower 6 bits for hosts. That means the Class B/C is already subnetted before it gets to you. Classes are identified by the leading few bits of the IP number and there is not a thing we can do about it. Class A starts at 1.0.0.0, Class B at 128.0.0.0, and Class C at 192.0.0.0, with the host fields being the last three, two and one octets, resp. The rules say (refresher, feel free to skip ahead) the "network" portion (the Class A/B/C part), and the subnet portion, and the host portion may not be all 1's nor all 0's individually. So, may we assume that the given subnetting obeys those rules down to your system? If so you steal host bits to create networks AND you can use Your Bits as all 0's and 1's because the other part of the subnet mask does not have all 0's or 1's. The next and last step is to realize subnetting is by bit, and hence divides regions by halves. It's not by value, but by binary bit. Ok, now let's look at a real example lifted from one of my servers. The site has a Class B address, 129.123.0.0. By the time I get a slice of it the given address is 129.123.30.0. That is still a Class B address; recall the top few bits determine Class. The given subnet uses up the third octet and, being value 30, it's neither all 0's nor all 1's. I use four boards in that server: one NE-2000 to the backbone and three NE-3200's to the lab. 129.123.30.0 is the lab side of things. ELfoobar are lab room numbers. file server name EDU-USU-ENGRLAB ipx internal net 817b0421 ... load ne3200 slot=1 frame=Ethernet_II name=EL105F load ne3200 slot=2 frame=Ethernet_II name=EL105B load ne3200 slot=6 frame=Ethernet_II name=EL103 load ipxstack load ipxrtr routing=nlsp mcast=yes bind ipx EL105F net=817b1e00 bind ipx EL105B net=817b1e40 bind ipx EL103 net=817b1e80 rem NE2000 to the world load ne2000 int=2 port=360 frame=Ethernet_II name=bbone bind ipx bbone net=817b0400 ... rem load TCP/IP routing material rem Backbone board BBONE is 129.123.4.33 rem Net 129.123.30.0 is sub-subnetted 2 bits to 255.255.255.192 rem Lab board EL105F is 129.123.30.62 and is the front half of the room rem Lab board EL105B is 129.123.30.126 and is the back half of the room rem Lab board EL103 is 129.123.30.190 and is the whole room rem EL105 front half uses 129.123.30.1-62, (gate=.62, sub-subnet bits 00) rem EL105 back half uses 129.123.30.65-126, (gate=.126, sub-subnet bits 01) rem EL103 whole room uses 129.123.30.129-190, (gate=.190, sub-subnet bits 10) load snmp ControlCommunity=password TrapCommunity=password load tcpip forward=yes rip=no bind ip BBONE ad=129.123.4.33 mask=255.255.255.192 ga=129.123.4.254 bind ip EL105F addr=129.123.30.62 bind ip EL105B addr=129.123.30.126 bind ip EL103 addr=129.123.30.190 My additional subnet bits are just two, taken from the fourth octet. They can be all 0's, and are in one case, without making the total subnet field being that way (the other part given in the third octet). I labeled my two as "sub-subnet" bits to fit the screen above. Host's can't be identified with all 0 nor all 1 bits. That means I lose two host addresses per sub-subnet. The all 0's case means "this network", and the all 1's case means to all machines on this network. If the need were present I could add another lab board on sub-subnet 11, address range 129.123.30.193-254 for hosts. As it is, I took the last octet and created currently three wires of 62 hosts each, with one more like that to spare inside the lab. Astute readers will note the IPX network addresses are exactly the same as the IP network (not host) addresses. The machine's internal IPX address is the same as the entire IP address of the board closest to the campus backbone, IP 129.123.4.33, IPX 817b0421. That's the Utah Standard (often cited doc UTAHSTD.TXT in directory misc on netlab2.usu.edu) Now that does deserve a coffee break. Thanks Roy for suggesting it. Say, I have a really good lecture prepared on RIP; just ask. Joe D. -------------- > Roy Coates > Dept Computer Manager, > Dept of Mech Eng, Phone: 0151-794-4862 > Liverpool University, Fax: 0151-794-4848 > L69 3BX England E-Mail: roysan@liverpool.ac.uk ------------------- Prime references: RFC791.TXT and RFC1122.TXT (see directory rfc on netlab2.usu.edu). From RFC791.TXT - Addressing To provide for flexibility in assigning address to networks and allow for the large number of small to intermediate sized networks the interpretation of the address field is coded to specify a small number of networks with a large number of host, a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. In addition there is an escape code for extended addressing mode. Address Formats: High Order Bits Format Class --------------- ------------------------------- ----- 0 7 bits of net, 24 bits of host a 10 14 bits of net, 16 bits of host b 110 21 bits of net, 8 bits of host c 111 escape to extended addressing mode A value of zero in the network field means this network. This is only used in certain ICMP messages. The extended addressing mode is undefined. Both of these features are reserved for future use. From RFC1122.TXT - 3.2 PROTOCOL WALK-THROUGH 3.2.1 Internet Protocol -- IP 3.2.1.1 Version Number: RFC-791 Section 3.1 A datagram whose version number is not 4 MUST be silently discarded. 3.2.1.2 Checksum: RFC-791 Section 3.1 A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum. 3.2.1.3 Addressing: RFC-791 Section 3.2 There are now five classes of IP addresses: Class A through Class E. Class D addresses are used for IP multicasting [IP:4], while Class E addresses are reserved for experimental use. A multicast (Class D) address is a 28-bit logical address that stands for a group of hosts, and may be either permanent or transient. Permanent multicast addresses are allocated by the Internet Assigned Number Authority [INTRO:6], while transient addresses may be allocated Internet Engineering Task Force [Page 29] RFC1122 INTERNET LAYER October 1989 dynamically to transient groups. Group membership is determined dynamically using IGMP [IP:4]. We now summarize the important special cases for Class A, B, and C IP addresses, using the following notation for an IP address: { , } or { , , } and the notation "-1" for a field that contains all 1 bits. This notation is not intended to imply that the 1-bits in an address mask need be contiguous. (a) { 0, 0 } This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address. See also Section 3.3.6 for a non-standard use of {0,0}. (b) { 0, } Specified host on this network. It MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its full IP address. (c) { -1, -1 } Limited broadcast. It MUST NOT be used as a source address. A datagram with this destination address will be received by every host on the connected physical network but will not be forwarded outside that network. (d) { , -1 } Directed broadcast to the specified network. It MUST NOT be used as a source address. (e) { , , -1 } Directed broadcast to the specified subnet. It MUST NOT be used as a source address. Internet Engineering Task Force [Page 30] RFC1122 INTERNET LAYER October 1989 (f) { , -1, -1 } Directed broadcast to all subnets of the specified subnetted network. It MUST NOT be used as a source address. (g) { 127, } Internal host loopback address. Addresses of this form MUST NOT appear outside a host. The is administratively assigned so that its value will be unique in the entire world. IP addresses are not permitted to have the value 0 or -1 for any of the , , or fields (except in the special cases listed above). This implies that each of these fields will be at least two bits long. For further discussion of broadcast addresses, see Section 3.3.6. A host MUST support the subnet extensions to IP [IP:3]. As a result, there will be an address mask of the form: {-1, -1, 0} associated with each of the host's local IP addresses; see Sections 3.2.2.9 and 3.3.1.1. When a host sends any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or multicast address). A host MUST silently discard an incoming datagram that is not destined for the host. An incoming datagram is destined for the host if the datagram's destination address field is: (1) (one of) the host's IP address(es); or (2) an IP broadcast address valid for the connected network; or (3) the address for a multicast group of which the host is a member on the incoming physical interface. For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; we use the term "specific-destination address" for the equivalent local IP Internet Engineering Task Force [Page 31] RFC1122 INTERNET LAYER October 1989 address of the host. The specific-destination address is defined to be the destination address in the IP header unless the header contains a broadcast or multicast address, in which case the specific-destination is an IP address assigned to the physical interface on which the datagram arrived. A host MUST silently discard an incoming datagram containing an IP source address that is invalid by the rules of this section. This validation could be done in either the IP layer or by each protocol in the transport layer. DISCUSSION: A mis-addressed datagram might be caused by a link- layer broadcast of a unicast datagram or by a gateway or host that is confused or mis-configured. An architectural goal for Internet hosts was to allow IP addresses to be featureless 32-bit numbers, avoiding algorithms that required a knowledge of the IP address format. Otherwise, any future change in the format or interpretation of IP addresses will require host software changes. However, validation of broadcast and multicast addresses violates this goal; a few other violations are described elsewhere in this document. Implementers should be aware that applications depending upon the all-subnets directed broadcast address (f) may be unusable on some networks. All- subnets broadcast is not widely implemented in vendor gateways at present, and even when it is implemented, a particular network administration may disable it in the gateway configuration.