I realised my argument about collision domains was incorrect.
I'm not sure what you though I meant when I said "running hosts at half-duplex on a switch is a waste of functionallity and lessens throughput" but I certainly wasn't suggesting 10HALF devices are a waste of space. How did you get that I was in anyway suggesting otherwise? I was simply stationg a mater of fact (if you've got 100 mbps devices).
BTW.. I'm sure you know this anyway but while the 'duplex' setting is important having a mismatch is not always a 'show stopper'. It's the speed ie. 10/100/1000 that MUST be the same for the link to come up in the first place.
Yes, glad to see you'd worked out the collision domain thing--I saw your subsequent post just after my previous one was sent.
Duplex mismatch actually CAN be a real pain in the ass, precisely because it isn't a "show stopper" at link-up time. I can't begin to count how many funky problems I've investigated over the years that turned out to be caused by a duplex mismatch.
Say you've got a host ("A") connected to a switch port at 100mb, and you get a mismatch on the duplex setting: the host is set for FULL, but the port gets set for HALF. The host believes it is operating on fully bi-directional media, and will completely ignore any collisions. The switch, however, will detect and respond to collisions, and will expect the host to do the same. So host A sends a frame to host B, and about the same time, host C sends a broadcast. The C-* frame reaches host A just fine, but it happens to traverse the link between the switch and A at the same time as the A-B frame. Host A says "no problem", ignores the C-A frame (because it wasn't for him anyway), and considers the A-B frame to be done & gone. The switch, however, sees a collision, DROPS THE A-B FRAME, waits a moment, and resends the C-* frame. If it was part of a TCP/IP connection, the dropped A-B frame will eventually get re-transmitted, but not as the result of collision detection. Instead, the frame gets re-sent by layer 4 when host B fails to acknowledge it, AFTER waiting for a time-out. The net effect of this is extremely sluggish response, but only under certain traffic conditions. Fix the mismatch, and everything magically works fine.
I've certainly had my fair share of problemns associated with duplex mismatches. It's the first thing I look for now days. I subscribe to Network News through work. They had an interesting article a little bit back ... "It's the duplex stupid" ...
thanks, but it doesn't get to the crux . What is wrong with using the network address as a host address ? Surely if a packet has the so-called 'network address' it can only mean host 0 on that network. I don't see why some say it can 'cause confusion'. i.e. they're saying it's human psychology, I find that doubtful since subnetting can also cause *far more* confusion if you don't know what you're doing. .
Besides. The issue I meant to get at, was not so much that , not an issue regarding every network address, but only the first and last addresses in each class Class B 128.0 and 191.254 (note - the former isn't all 0s network address and the latter isn't an All 1s network address) similarly for classes C D and E also, this was all an issue even before subnetting. - even before FLSM
The problem with using 128.0.0.0 or 128.255.255.255 as host addresses is that the all-ones and all-zeroes host addresses on any prefix are already reserved as directed broadcast addresses.
What did you save, anyway? 2 out of 16,581,375 addresses? For /31 prefixes the standards-writers made an important exception.
15.33.33.2/31 and 15.33.33.3/31 are host addresses! G>
That's a neat way to picture things, but routers were never called hubs in "the old days" (mid-1980s). They were called gateways.
In a hub-and-spoke remote-access network, today or in the past, I'm sure someone would refer to the routers as "the hub" and "a spoke", though I prefer "the hub router" and "a spoke router" for clarity.
I can not say exactly "why," but the low and high blocks were reserved (probably) because it is always a good thing to set aside a small portion of a limited resource for some unanticipated need sometime in the future. Sortta like what many of us do with an "emergency" savings account.....
But, it looks like we may see these blocks used in formal assignments soon enough......
From RFC 3330:
128.0.0.0/16 - This block, corresponding to the numerically lowest of the former Class B addresses, was initially and is still reserved by the IANA. Given the present classless nature of the IP address space, the basis for the reservation no longer applies and addresses in this block are subject to future allocation to a Regional Internet Registry for assignment in the normal manner.
191.255.0.0/16 - This block, corresponding to the numerically highest to the former Class B addresses, was initially and is still reserved by the IANA. Given the present classless nature of the IP address space, the basis for the reservation no longer applies and addresses in this block are subject to future allocation to a Regional Internet Registry for assignment in the normal manner.
Whatever reason is , it a)was only relevant to classful addressing b)is to do with there being all 1s or all 0s in the netwrok address after the class identification bits have been stripped off
now the question remains WHY is that a problem!! I don't know Very few ppl would know the answer, i'm hoping there are some lurking about!
btw, this doesn't seem to be to do with an All 0s or All 1s network address. This is All 0s or All 1s, after the class identification bits have been stripped off.
The point you make does not answer the issue regarding :
So, we are not talking about an "all zero" or an "all ones" issue. The entire BLOCK has been set aside as 'reserved.' Regardless, it would be nice to have a difinitive answer as to why the high and low blocks have been set aside...
The info you just posted actually provides enough to answer the "why" !!!!
RFC 791 defines network number as including the class id. - that is, the way I was using the term 'network number'.
RFC 810 and 796 define network number as excluding the class id. The way you used network number/net num.
Now, I think RFC 791 is wrong , it was written in the same month as RFC
796 so it can't be that one simply outdated the other and they didn't say explicitly abotu changing the definition of network number.
RFC 3330 is thus misleading in saying that 0/8 is special and stating its usage, but not saying that 128.0 and 192.0.0 are special and stating their usage. Though they are special, see ARIN, they are reserved for special use. Now we know what the use is.
128.0 and 192.0 all have network number =0. THey refer to this network, and say that it is Class B or Class C respectively, so that the router knows where the network number is to read it and check to se if it is - for example - 0.
Let's go by RFCs 810 and 796 in our definition of network number. When a Router receives a packet it first reads the first 1-4 bits and that tells it what mask to use, Class A-E. The mask is applied to the dest ip address to give the network number. Then it knows if the network number = 0 For example, if it receives 128.0/16 then it knows that the network number is 0. similarly with 0/8 or 192.0.0/24
I am speculating now, and lack experience with routers, but I guess it'd look at the source ip and know which network to send to. And it'd look at the dest ip and find which host to send to.
Funnily enough, it seems to me that RFC 791's definition of network number, would work too. Perhaps with less waste if just 0/8 means 'this network' (and not also 128.0/16 and the rest).
0/8 can never refer to a 'valid' class A network 'cos it's not allowed to be used for that, so the router could immediately know that the packet is for 'this network', it could then read the mask from the Source IP address, apply it the Source IP address to get the particular network to send to. It could then apply that mask to the dest ip and get the host. Or it could just read past the 0s in the dest ip adderss to the first non zero.
Or if it's all 0s, then it's the zeroth host. Though I guess the zero network and 0 host might have issues because of the old usage of that as the broadcast address
If this really is correct and RFC 791 is in error! Then credit to John Agosta, and the 2 posts by Dave Saunders(specifically the one mentioning net num), and to zchrist of IRC (who mentioned to me some months ago that classful addressing might have been faster on the old technology for it not requiring preset/stored masks).
I hope, from all the AFAIKs and admitions, that my lack of router experience (only theory!) isn't too ridiculous ;)
I would be suprised if I did spot an error in an RFC, but i'm just persuing that line of reasoning because it seems to make sense
Well, I dunno. I have gone one for years beleiveing that an all zeros and all ones network address is 'illegal' (broadcast conventions) but I have yet to see a specific call in any rfc that this is 'the' reason why low and high blocks have been reserved.
Of course, some (old) routers and some OS's don't understand all
0 and all 1 networks addresses, and this may have been the rationale for the reservations, but my persuit has been to find a 'specific reference' in an RFC or other standard on the exact 'reason_why' the high and low blocks have been reserved. I haven't found a specific call in any standard for this, but I am comfortable with my ages old understanding/assumption.
It's all really moot, I guess at this time.
Perhaps only John Postel can tell us the real reason why these addresses are 'reserved.' But, alas, he's not around to help us. Will have to ask him on the other side, and thank him for his help, especially with Class E and CDPD addressing - but that's another story for another day.....
I wouldnt' say illegal. Reserved for special meaning. Not subject for assignment.
I'm not trying to prove anybody wrong. Just getting the facts out. I'm delighted to be corrected.
I think the reason can be rightly concluded from the RFCs.
RFC 1122 " { , } "
" { 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. "
so, I was wrong in thinking that it could be sent. But point is. a network number / net number = 0 , is special. It cannot even be sent. (so its usage is more restricted than I thought). So I think one can rightly conclude that this is clearly the reason why those bordering ip addresses (net number=0) are listed as reserved in RFC 3330.
one may imagine that there is some other undocumented reason why they are reserved - without having any positive evidence to support that. But, here we have a documented reason why those address have to be reserved - i.e not subject to assignment.
it seems now that it was and is still unclear. There is a question mark over whether RFC 1122 (similarly in RFC 1716). When it says network number whether it means including class id bits or excluding them. RFC 1716 hint a bit better. It says that network number=0 is to do with initialization , and protocols like BOOTP . Well, I don't think BOOTP uses 128.0
Historically, 0.0.0.0 is also avoided for being the broadcast address on some routers. But, I don't think this applies to 128.0 or 192.0.0 either.
Similar problem exists for 191.255 , I don't think that is/was a broadcast , not now, nor in classful days. And, at least nowadays,
255.255.255.255 doesn't go past the network it came. I doubt there was ever a broadcast to all Class B networks.
So, I see no good reason in RFCs for those IPs to be reserved.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.