Sorry, but while I was looking to this list, I just reminded interesting
issue. Why IANA did not reserved 223.255.0.0/16 or something simular; by
other words, I'd like to have short (256, 512, 1024) private address
space in the END of total address space for the normal IP (excluding D
class etc).
For example. I have a lot of CISCO routers with OSPF protocol. Thnis
crazy IOS use highest loopback interface address as router-ID address; I
use loopbacks to install load balancing etc. and I can't prevent
loopbacks from being equal on the different routers. That's why I hardly
need some IP addresses for 'Loopback 98' interface to use it as
router-ID; and this have to be higher than any user's addresses. I use
233.255.254.0/24 for this purposes, but it's not reserved address.
This is one, simple, example why it's nessesary to reserve some short
address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol
implementation. One ought to be able to specify an arbitrary router id
for OSPF (heh - even Bay routers can do that 
rather that relying on
such an odd algorithm. I was so surprised by this that I just had to go
look it up:
<http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
The equivalent Bay reference:
<http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
[A copy of the headers and the PGP signature follow.]
>For example. I have a lot of CISCO routers with OSPF protocol. Thnis
>crazy IOS use highest loopback interface address as router-ID address; I
>use loopbacks to install load balancing etc. and I can't prevent
>loopbacks from being equal on the different routers. That's why I hardly
>need some IP addresses for 'Loopback 98' interface to use it as
>router-ID; and this have to be higher than any user's addresses. I use
>233.255.254.0/24 for this purposes, but it's not reserved address.
>
>This is one, simple, example why it's nessesary to reserve some short
>address space in the begin and in the end of total addresses.
No, that's an example of a poorly designed protocol
implementation. One ought to be able to specify an arbitrary router id
for OSPF (heh - even Bay routers can do that rather that relying on
such an odd algorithm. I was so surprised by this that I just had to go
look it up:
I know _it's example of poorly designet software_. But I'd like to note
it's not only example when it's usefull to have some addresses _greater
than any other_ for private usage.
<http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
The equivalent Bay reference:
<http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
Yes, I was more surprised when they (cisco) did not implement something
like _ip ospf router-id A.B.C.D_ into new IOS 11.2. We have 3 or 4
routing troubles due to this IOS property (and it always looked as
_hidden bug_ because it is si,ular to the delayed bomb - it explodes 1
week below some mistake was made in the config files -:)).
Gated allows you to specify the ospf router id. AS others have mentioned
so does Bay. Out of curiousity, is anyone running anything other than
Cisco, Bay or something with GateD (which includes IBM 6611, Netstat
Gigarouter and a few others which escape recall at the moment) for
routing in the Internet (not private nets; I know that Mitsubishi
Electric Corp of America uses IBM 6611 and some 2210, all with backlevel
software).
Dana
Gated allows you to specify the ospf router id. AS others have mentioned
so does Bay. Out of curiousity, is anyone running anything other than
I know it well (really we have few gated-based routers there). Let me to
point my mind - it may be usefull to have short reserved address space in
the beginning (net 1.0.0.0) and the end (223.255.0.0/16 or simular)
address space. CISCO's router-id was used as amazing example _why it mey
be usefull_.
Cisco, Bay or something with GateD (which includes IBM 6611, Netstat
Gigarouter and a few others which escape recall at the moment) for
routing in the Internet (not private nets; I know that Mitsubishi
Electric Corp of America uses IBM 6611 and some 2210, all with backlevel
software).
Dana
> Date: Wed, 12 Feb 1997 13:58:30 +0300 (MSK)
> From: "Alex P. Rudnev" <alex@Relcom.EU.net>
> To: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us>
> Cc: nanog@merit.edu
> Subject: Re: [NANOG] RFC1918 conformance
>
> > >For example. I have a lot of CISCO routers with OSPF protocol. Thnis
> > >crazy IOS use highest loopback interface address as router-ID address; I
> > >use loopbacks to install load balancing etc. and I can't prevent
> > >loopbacks from being equal on the different routers. That's why I hardly
> > >need some IP addresses for 'Loopback 98' interface to use it as
> > >router-ID; and this have to be higher than any user's addresses. I use
> > >233.255.254.0/24 for this purposes, but it's not reserved address.
> > >
> > >This is one, simple, example why it's nessesary to reserve some short
> > >address space in the begin and in the end of total addresses.
> >
> > No, that's an example of a poorly designed protocol
> > implementation. One ought to be able to specify an arbitrary router id
> > for OSPF (heh - even Bay routers can do that rather that relying on
> > such an odd algorithm. I was so surprised by this that I just had to go
> > look it up:
> I know _it's example of poorly designet software_. But I'd like to note
> it's not only example when it's usefull to have some addresses _greater
> than any other_ for private usage.
>
> > <http://www.cisco.com/univercd/data/doc/software/11_2/cnp1/5ciprout.htm#REF38888>
> >
> > The equivalent Bay reference:
> >
> > <http://support.baynetworks.com/Library/tpubs/content/114065A/J_55.HTM#HEADING55-6>
> >
> Yes, I was more surprised when they (cisco) did not implement something
> like _ip ospf router-id A.B.C.D_ into new IOS 11.2. We have 3 or 4
> routing troubles due to this IOS property (and it always looked as
> _hidden bug_ because it is si,ular to the delayed bomb - it explodes 1
> week below some mistake was made in the config files -:)).
>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)