Error in assignments....?

Mailman List Mirror (Read Only)
1

Uhm, from whois.ra.net :

route: 209.81.0.0/19
descr: ViaNet Communications
               1235 Pear Ave, Suite 107
               Mountain View, CA 94043
origin: AS7091
notify: gshaver@he.net
notify: mleber@he.net
mnt-by: HE-NOC
changed: mleber@he.net 19970808
source: RADB

route: 209.81.0.0/19
descr: CRL Network Services
               Box 326
               Larkspur
               CA 94977, USA
origin: AS2041
member-of: RS-COMM_NSFNET
mnt-by: MAINT-AS2041
changed: nsfnet-admin@merit.edu 19990223
source: RADB

???

- kurtis -

2

Kurt Erik Lindqvist wrote:

Uhm, from whois.ra.net :

route: 209.81.0.0/19
origin: AS7091
source: RADB

route: 209.81.0.0/19
origin: AS2041
source: RADB

RADB are a routing registry not an address space registry. Consult
ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB
member can register pretty much any route/AS pair and many members
don't bother to put real details when it comes to owner of the route,
etc (putting the ISP instead of the customer).

David.

3

Hi,

Uhm, from whois.ra.net :

route: 209.81.0.0/19
descr: ViaNet Communications
               1235 Pear Ave, Suite 107
               Mountain View, CA 94043
origin: AS7091

route: 209.81.0.0/19
descr: CRL Network Services
               Box 326
               Larkspur
               CA 94977, USA
origin: AS2041

A route is something different then an IP assignment/allocation. There can
be multipe routes and multiple originating AS's for a netblock. The
netblock you are referring to is not globally visible btw.

4

RADB are a routing registry not an address space registry. Consult
ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB
member can register pretty much any route/AS pair and many members
don't bother to put real details when it comes to owner of the route,
etc (putting the ISP instead of the customer).

Yes, and this is my point. There is one route with two different sources AS:es...

Now, if I where to try and filter on this, I would have a problem....and after all, one of the advantages of a routing registry is that you can filter from it...

- kurtis -

5

A route is something different then an IP assignment/allocation. There can
be multipe routes and multiple originating AS's for a netblock. The
netblock you are referring to is not globally visible btw.

Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es....

Best regards,

- kurtis -

6

Why not?

Suppose company A has a PA allocation 10.21.0.0/20. Company A gets a T1
from Carrier B. Carrier B announces 10.21.0.0/20 with their AS65531 and
statically route the /20 to company A. If Company A wants to be redundant
and gets another T1 from Carrier C, Carrier C will announce 10.21.0.0/20
with their AS65532 and statically route 10.21.0.0/20 to Company A.

I see no problem in this. If Carrier B screws up, the traffic will still
flow through Carrier C. If Carrier B screws up in such a way that they
still announce the netspace, Carrier C can announce 2 /21's instead of 1
/20 so it will still work.

7

[snip]

Ok, my fault. I ment to say route object. However, I fail to see why (if)
you would like to allow the same route to source from muliple AS:es....

The easy answer is that there is trash in the IRR. When looking a little
closer or talking about a well-run source DB consider the consolidation
of multiple ASNs, customers getting their BGP training wheels, etc other
typical origin changes. To smooth over any origin changes, it makes
sense to get route objects in at least a day or two in advance; if you're
doing large scale projects long-term overlaps are not at all uncommon.

If you think of the IRR as a 'flight plan' or the list of "intended
possibilities" then it makes more sense than trying to treat it as a
strict tracking of the live BGP table state. The latter would bring you
nothing but woe.

Cheers,

Joe

8

Ugh, this is why ASN's exist and is why ppl have been posting about
inconsistent BGP announcements of late

If you originate the same block from 2 ASNs then you no longer have a
single administrative area and need a 3rd ASN as per the RFC.

Steve

9

And if your regional registry refuses to assign an ASN you are cooked and
you will probably end up using a solution like this. I'm not saying its
good, I'm saying its bad, but unfortunately common practice.

10

Which RIR is refusing to assign an ASN if you want to multi-home? At least
not that one your living in ...

Arnold

11

This config can also exist for an interim period whilst a customer is
switching providers - hopefully the ex-provider will clean up, but there is
nothing now in place to enforce it.

Tim

12

I'm not familiar with all the RIR policies but RIPE is very
straightforward, if you want an ASN you have to be multihomed. I cant see
any logic why another RIR would be different in its approach...

In my experience its far easier to get an ASN from RIPE than an IP
assignment approved. For the latter you need to prove all kinds of things
as to why you need it, for an ASN all you have to do is prove you have two
upstream ISPs and nothing more!

Steve

13

Hi,

Which RIR is refusing to assign an ASN if you want to multi-home? At least
not that one your living in ...

I'm not bashing RIPE here, I'm just saying that not every PI assigned /24
automagically gets (needs) an ASN.

14

...exactly. So, again, I can't see a valid reason for a single route to originate from two different AS:es. Unless for transition purposes as was mentioned.

- kurtis -

15

209.81.0.0/19 has been announced by AS 7091 from the day it was assigned
to them by ARIN back in 1997. The CRL registration possibly predates
ViaNet's use as noted by the mention of RS-COMM_NSFNET, and the fact that
it was last updated by nsfnet-admin@merit.edu, not CRL. The CRL
registration is probably cruft left over from long ago.

$ whois 209.81.0.0@whois.arin.net
[whois.arin.net]
ViaNet Communications (NETBLK-VIANETCO)
   1235 Pear Ave, Suite 107
   Mountain View, CA 94043
   US

   Netname: VIANETCO
   Netblock: 209.81.0.0 - 209.81.63.255
   Maintainer: VIA

   Coordinator:
      Mcguckin, Joseph (JM7712-ARIN) joe@VIA.NET
      415 969-2203 (FAX) 415 969-2124

   Domain System inverse mapping provided by:

   NS.VIA.NET 209.81.9.1
   NS2.VIA.NET 216.218.130.58

   ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
   RWHOIS auth.via.net 4321

   Record last updated on 22-Mar-2000.
   Database last updated on 11-Jun-2002 20:00:57 EDT.

The ARIN Registration Services Host contains ONLY Internet
Network Information: Networks, ASN's, and related POC's.
Please use the whois server at rs.internic.net for DOMAIN related
Information and whois.nic.mil for NIPRNET Information.

Mike.

Uhm, from whois.ra.net :

route: 209.81.0.0/19
descr: ViaNet Communications
               1235 Pear Ave, Suite 107
               Mountain View, CA 94043
origin: AS7091
notify: gshaver@he.net
notify: mleber@he.net
mnt-by: HE-NOC
changed: mleber@he.net 19970808
source: RADB

route: 209.81.0.0/19
descr: CRL Network Services
               Box 326
               Larkspur
               CA 94977, USA
origin: AS2041
member-of: RS-COMM_NSFNET
mnt-by: MAINT-AS2041
changed: nsfnet-admin@merit.edu 19990223
source: RADB

???

- kurtis -

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

16

Suppose company A has a PA allocation 10.21.0.0/20. Company A gets a T1
from Carrier B. Carrier B announces 10.21.0.0/20 with their AS65531 and
statically route the /20 to company A. If Company A wants to be redundant
and gets another T1 from Carrier C, Carrier C will announce 10.21.0.0/20
with their AS65532 and statically route 10.21.0.0/20 to Company A.

I see no problem in this. If Carrier B screws up, the traffic will still
flow through Carrier C. If Carrier B screws up in such a way that they
still announce the netspace, Carrier C can announce 2 /21's instead of 1
/20 so it will still work.

This isn't being done.

Only one AS is announcing the route. The other registration is cruft.

Mike.

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

17

[snip]
> Ok, my fault. I ment to say route object. However, I fail to see why (if)
> you would like to allow the same route to source from muliple AS:es....

The easy answer is that there is trash in the IRR.

This is correct.

When looking a little
closer or talking about a well-run source DB consider the consolidation
of multiple ASNs, customers getting their BGP training wheels, etc other
typical origin changes. To smooth over any origin changes, it makes
sense to get route objects in at least a day or two in advance; if you're
doing large scale projects long-term overlaps are not at all uncommon.

These are operationally valid cases where multiple route objects might
exist for a single prefix (as opposed to errors such as left over cruft).

If you think of the IRR as a 'flight plan' or the list of "intended
possibilities" then it makes more sense than trying to treat it as a
strict tracking of the live BGP table state. The latter would bring you
nothing but woe.

Agreed.

For good reason you shouldn't be able to delete other networks route
objects. Correspondingly it is left to each network to clean up their own
registrations. This can be hard when the company in question no longer
exists per se. (CRL was acquired by Applied Theory which filed for
bankruptcy, whose assets were recently acquired by Fastnet.)

The IRRs don't check third party sources for validation of route objects
and even if they did the address registries don't map prefixes to AS
numbers. This is an interesting subject to think about, however many of
the solutions end up being very complicated like S-BGP if they try to
address every issue.

Mike.

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

18

Correct, ViaNet is announcing 209.81.0.0/18 now and the 209.81.0.0/19 is
an example of that cruft I was talking about that people should clean up.

(typing in the background as somebody sends in an update :wink:

Mike.

19

Even when CRL was alive (not just a zombie) we were never able to get them
to clean this up.

20

I had similar experiences with @Home. Could not get them to pull a record. Couldn't even get to someone with enough clue to know what the RADB was, for that matter.

Ultimately, whomever ARIN (or other RIR) says owns a netblock has to have the right to remove crap from the RADB/IRR type databases. That's the only way the data ever has a chance of getting clean.

Anyone trying to use such databases to build filters is going to have major trouble.