IOS upgradation of switch, router and pix

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" ...

whopps I just realised that was an answer!

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

correction. "191.254 " should read "191.255" the rest all applies.

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.

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 know about the all 0 and all 1 host addresses. i'm talking about a networks.

why Couldn't IANA give 128.0 and 191.255 as network addresses?

e.g. why wasn't 128.0.1.3 or 191.255.5.4 valid host addresses ? no host were allowed on those networks 'cos those networks were reserved. but Why?

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:

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.

better not to guess. It is a known reason.

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...

Oops. Misread the post. Appologies.

I understand what q_q was saying.

q_q was saying "all ones and all zeros" in the 'net' portion. I need to slow down and learn to read....

And yes, this does have 'something' to do with classfull addressing, as many rfcs state. But the question still is 'why?'

-ja

YEAH! We got the Why!!!

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

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.

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).

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

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.....

more generally. The network number

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.

Sounds reasonable to me.....

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,

So, I see no good reason in RFCs for those IPs to be reserved.