Mailing List Archive

RFC1918 conformance
As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the
netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been
allocated for "Private Internets". Consequently, these netblocks
should not be routed over the Internet.

As shown below, they are currently advertised from AS6848 and these
advertisements are carried to us (AS6453) through various AS's of the
SprintLink system.

>sh ip bgp reg _6846$
BGP table version is 9335417, local router ID is 207.45.201.5
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
*> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
*> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
[...]

AS6846 responsibles should take immediate action to remove these
announcements. SprintLink, as any conscientious operator, should take
action to filter out these announcements from any of its peers.

Regards.
__

Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA>
TELEGLOBE CANADA |
1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257
Montreal, QC H3B 4X5 |
Canada | fax: +1-514-868-8446





- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
> As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the
> netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been
> allocated for "Private Internets". Consequently, these netblocks
> should not be routed over the Internet.
>
> As shown below, they are currently advertised from AS6848 and these
> advertisements are carried to us (AS6453) through various AS's of the
> SprintLink system.

while what you say is absolutely true (people shouldn't adversite
them) i would say that it's as much your responsibility to block them
at your edge routers.

-brett

> >sh ip bgp reg _6846$
> BGP table version is 9335417, local router ID is 207.45.201.5
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> [...]
>
> AS6846 responsibles should take immediate action to remove these
> announcements. SprintLink, as any conscientious operator, should take
> action to filter out these announcements from any of its peers.
>
> Regards.
> __
>
> Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA>
> TELEGLOBE CANADA |
> 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257
> Montreal, QC H3B 4X5 |
> Canada | fax: +1-514-868-8446
>
>
>
>
>

-brett


- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
On Mon, 10 Feb 1997, Brett D. Watson wrote:

> while what you say is absolutely true (people shouldn't advertise
> them) i would say that it's as much your responsibility to block them
> at your edge routers.

After several recent incidents involving obviously incorrect
advertisements from several of the 'big name' companies, I've concluded
that it's as important to filter their advertisements for sanity as it
is for one's own customers.

David Schwartz
WIZnet

- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
Re: RFC1918 conformance [ In reply to ]
Hi, Pierre.

These are the changes I have made in our sl-dc-10 router:

>router bgp 1790
> neighbor 144.228.120.130 remote-as 6846
> neighbor 144.228.120.130 version 4
> neighbor 144.228.120.130 distribute-list 50 in
> neighbor 144.228.120.130 distribute-list 111 out
> neighbor 144.228.120.130 route-map transit-in in
> neighbor 144.228.120.130 route-map transit-out out
> neighbor 144.228.120.130 filter-list 53 in
>
> access-list 50 deny 10.0.0.0 0.255.255.255
> access-list 50 deny 172.16.0.0 0.15.255.255
> access-list 50 deny 192.168.0.0 0.0.255.255
>
> clear ip bgp 144.228.120.130 soft out

Please let us know if there are any problems with this new configuration.
Thank you.

Ray,
Sprintlink


On Mon, 10 Feb 1997, Pierre Thibaudeau wrote:

> As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the
> netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been
> allocated for "Private Internets". Consequently, these netblocks
> should not be routed over the Internet.
>
> As shown below, they are currently advertised from AS6848 and these
> advertisements are carried to us (AS6453) through various AS's of the
> SprintLink system.
>
> >sh ip bgp reg _6846$
> BGP table version is 9335417, local router ID is 207.45.201.5
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> [...]
>
> AS6846 responsibles should take immediate action to remove these
> announcements. SprintLink, as any conscientious operator, should take
> action to filter out these announcements from any of its peers.
>
> Regards.
> __
>
> Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA>
> TELEGLOBE CANADA |
> 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257
> Montreal, QC H3B 4X5 |
> Canada | fax: +1-514-868-8446
>
>
>
>
>

- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
Sorry, I forgot to include in the last email:

> access-list 50 permit any

And I did a "clear ip bgp 144.228.120.130" without the "soft out".
Thanks.

Ray,
Sprintlink

On Mon, 10 Feb 1997 bgp4-adm@sprint.net wrote:

> Hi, Pierre.
>
> These are the changes I have made in our sl-dc-10 router:
>
> >router bgp 1790
> > neighbor 144.228.120.130 remote-as 6846
> > neighbor 144.228.120.130 version 4
> > neighbor 144.228.120.130 distribute-list 50 in
> > neighbor 144.228.120.130 distribute-list 111 out
> > neighbor 144.228.120.130 route-map transit-in in
> > neighbor 144.228.120.130 route-map transit-out out
> > neighbor 144.228.120.130 filter-list 53 in
> >
> > access-list 50 deny 10.0.0.0 0.255.255.255
> > access-list 50 deny 172.16.0.0 0.15.255.255
> > access-list 50 deny 192.168.0.0 0.0.255.255
> >
> > clear ip bgp 144.228.120.130 soft out
>
> Please let us know if there are any problems with this new configuration.
> Thank you.
>
> Ray,
> Sprintlink
>
>
> On Mon, 10 Feb 1997, Pierre Thibaudeau wrote:
>
> > As specified in RFC1918 (ftp://ds.internic.net/rfc/rfc1918.txt) the
> > netblocks 10.0.0.0/16, 172.16.0.0/12 and 192.168.0.0/16 have been
> > allocated for "Private Internets". Consequently, these netblocks
> > should not be routed over the Internet.
> >
> > As shown below, they are currently advertised from AS6848 and these
> > advertisements are carried to us (AS6453) through various AS's of the
> > SprintLink system.
> >
> > >sh ip bgp reg _6846$
> > BGP table version is 9335417, local router ID is 207.45.201.5
> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
> > internal
> > Origin codes: i - IGP, e - EGP, ? - incomplete
> >
> > Network Next Hop Metric LocPrf Weight Path
> > *> 10.0.0.0 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> > *> 172.16.0.0/12 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> > *> 192.168.0.0/16 144.228.164.57 0 90 0 1794 1239 1790 6846 ?
> > [...]
> >
> > AS6846 responsibles should take immediate action to remove these
> > announcements. SprintLink, as any conscientious operator, should take
> > action to filter out these announcements from any of its peers.
> >
> > Regards.
> > __
> >
> > Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA>
> > TELEGLOBE CANADA |
> > 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257
> > Montreal, QC H3B 4X5 |
> > Canada | fax: +1-514-868-8446
> >
> >
> >
> >
> >
>

- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
> My standard in & out route filters are attached.
> Everyone should use something like this.
> --asp@partan.com (Andrew Partan)
>
> ! Deny martian routes
> ! 1st and last classical B and C nets (guard nets).
> access-list 180 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255
> access-list 180 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255
> access-list 180 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255
> access-list 180 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255

In a classless environment, these prefixes are legitimate.
Correct behaviour is now known for these subnets and so I
wonder why you still have them in your standard list.


--
--bill
- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
> > ! Deny martian routes
> > ! 1st and last classical B and C nets (guard nets).
> > access-list 180 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255
> > access-list 180 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255
> > access-list 180 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255
> > access-list 180 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255
>
> In a classless environment, these prefixes are legitimate.
> Correct behaviour is now known for these subnets and so I
> wonder why you still have them in your standard list.

They sure look reserved to me:
note% whois RESERVED
IANA (RESERVED-1) RESERVED 0.0.0.0
IANA (RESERVED-3) RESERVED 128.0.0.0
IANA (RESERVED-4) RESERVED 191.255.0.0
IANA (RESERVED-5) RESERVED 223.255.255.0
IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.0.0
IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.0.0

Actually it looks like I should add the top 1/2 of the old A space as well.

It also looks like someone did something really silly with 192.0.0/24:

note% whois 192.0.0
IANA (NET-ROOT-NS-LAB)
c/o Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292-6695

Netname: ROOT-NS-LAB
Netnumber: 192.0.0.0

Coordinator:
Manning, Bill (WM110) bmanning@ISI.EDU
310-322-8102

Domain System inverse mapping provided by:

ORB.ISI.EDU 128.9.160.66
NS.ISI.EDU 128.9.128.127

Record last updated on 01-Jul-96.

This idea looks really dumb, and since my >/24 filter blocks these
in any case, I see no reason to listen to silly people to unblock
this /24.

Poking a bit further at this, it looks like 192.0/16 is all reserved
as well:
Netname: RESERVED-192
Netblock: 192.0.0.0 - 192.0.255.0

Humm, more bogons to add to my filter?
--asp@partan.com (Andrew Partan)
- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
Andrew Partan <asp@partan.com> writes:

* They sure look reserved to me:
* note% whois RESERVED
* IANA (RESERVED-1) RESERVED 0.0.
* 0.0
* IANA (RESERVED-3) RESERVED 128.0.
* 0.0
* IANA (RESERVED-4) RESERVED 191.255.
* 0.0
* IANA (RESERVED-5) RESERVED 223.255.25
* 5.0
* IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.
* 0.0
* IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.
* 0.0
*
* Actually it looks like I should add the top 1/2 of the old A space as well.
*
This would be good as I report each week in my report possible bogus
routes but no one seems to care to filter (or fix this). Today it says:

*** Bogus 69.1.0.0/16 from AS1849
*** Bogus 69.2.0.0/16 from AS1849
*** Bogus 90.0.0.0 from AS4747
*** Bogus 103.40.99.0/24 from AS3249

--Tony
- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
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.




On Tue, 11 Feb 1997, Tony Bates wrote:

>
> Andrew Partan <asp@partan.com> writes:
>
> * They sure look reserved to me:
> * note% whois RESERVED
> * IANA (RESERVED-1) RESERVED 0.0.
> * 0.0
> * IANA (RESERVED-3) RESERVED 128.0.
> * 0.0
> * IANA (RESERVED-4) RESERVED 191.255.
> * 0.0
> * IANA (RESERVED-5) RESERVED 223.255.25
> * 5.0
> * IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.
> * 0.0
> * IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.
> * 0.0
> *
> * Actually it looks like I should add the top 1/2 of the old A space as well.
> *
> This would be good as I report each week in my report possible bogus
> routes but no one seems to care to filter (or fix this). Today it says:
>
> *** Bogus 69.1.0.0/16 from AS1849
> *** Bogus 69.2.0.0/16 from AS1849
> *** Bogus 90.0.0.0 from AS4747
> *** Bogus 103.40.99.0/24 from AS3249
>
> --Tony
>

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)

- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
Re: [NANOG] RFC1918 conformance [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 11 Feb 1997 22:04:19 +0300 (MSK), alex@relcom.eu.net writes:
>
>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.]

Date: Tue, 11 Feb 1997 14:23:20 -0600
From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us>
In-reply-to: Your message of "Tue, 11 Feb 1997 22:04:19 +0300."
<Pine.SUN.3.91.970211213356.1420T-100000@virgin>
Subject: Re: [NANOG] RFC1918 conformance
To: nanog@merit.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.

iQCVAwUBMwDVPZwkOQz8sbZFAQEXugP/csBBgGpX2pDm14HDL3RJAmzQIbqgQ+Tu
cxTNolAGpgUIXTx1zJEUqfIREZ9CnTe2BBdbD1BNpn8Ns/m9iY7yKtbNzHWOS2yR
dGkwhRrnXefjh3KPt/iGFVfwndpzYEzjZIpIUAfslfujY03bPXQe0YgTRt68q34S
13cWSHT1C3I=
=wM5u
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
Python Hacker, Mac Lover |
- - - - - - - - - - - - - - - - -
Re: [NANOG] RFC1918 conformance [ In reply to ]
> >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 -:)).

- - - - - - - - - - - - - - - - -
Re: [NANOG] RFC1918 conformance [ In reply to ]
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


On Wed, 12 Feb 1997, Alex P. Rudnev wrote:

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

- - - - - - - - - - - - - - - - -
Re: [NANOG] RFC1918 conformance [ In reply to ]
On Wed, 12 Feb 1997, Dana Hudes wrote:

> 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
>
>
> On Wed, 12 Feb 1997, Alex P. Rudnev wrote:
>
> > 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)

- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 13 Feb 1997 13:47:24 +0300 (MSK), alex@relcom.eu.net writes:
>
>On Wed, 12 Feb 1997, Dana Hudes wrote:
>
>> 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_.

I don't think that Internet engineering decisions should be based
solely on the basis of Cisco's bad decsisions regarding their OSPF
implementation. You claim that there are other reasons why reserving
1.0.0.0/8 and 223.255.0.0/16 are a good idea. Can you share some of
these reasons? I'm not totally against reserving these networks, but I
do require more convincing.


[A copy of the headers and the PGP signature follow.]

Date: Thu, 13 Feb 1997 08:01:01 -0600
From: "Jeffrey C. Ollie" <jeff@ollie.clive.ia.us>
In-reply-to: Your message of "Thu, 13 Feb 1997 13:47:24 +0300."
<Pine.SUN.3.91.970213134530.11961d-100000@virgin>
Subject: Re: RFC1918 conformance
To: nanog@merit.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: AnySign 1.4 - A Python tool for PGP signing e-mail and news.

iQCVAwUBMwMeopwkOQz8sbZFAQE4gQP+N/jvy38bdxJlsqmiRhbfT9Nga6y5R57G
opT5uzRpTa2B17ikDzYUEZgmjtXKcFTj6jCNXmcNoh3Be9g5SDFqZHvaiXUrvVwG
Lcorm1iSN/x2HwXfkjKBxP7b2bAvjbCJinpIQp1cWU4BJymemwX+Bjwn7zMTtkl2
4b6oeADxi+A=
=nUMC
-----END PGP SIGNATURE-----
--
Jeffrey C. Ollie | Should Work Now (TM)
Python Hacker, Mac Lover |
- - - - - - - - - - - - - - - - -
Re: RFC1918 conformance [ In reply to ]
Right now it checks for:
>= 64/8 && <= 127/8
> 211/8
RFC1918 set of prefixes

--Tony

Andrew Partan <asp@partan.com> writes:
* > This would be good as I report each week in my report possible bogus
* > routes but no one seems to care to filter (or fix this). Today it says:
*
* Which routes to you consider to be bogons?
* --asp@partan.com (Andrew Partan)
- - - - - - - - - - - - - - - - -