Hello, A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result. The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones. Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now. But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not? -- Marco Davids / SARA - Academic Computing Services Amsterdam Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt
Hi just a quick question We have been recently been allocated our /19 however RIPE have assigned us only the first 700 address this I believe is pretty standard procedure. However our connectivity supplier will not advertise our routes unless we have our full /19 assigned and registered with RIPE, obvioulsy as the range is too small. Is there any other way around this problem other than getting RIPE to register our full /19 reserved pre-allocation, if not how do RIPE stand on registering the full /19????? Hope this makes sense thanks in advance Graham GB-10488 Network Sys Admin -- NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK http://www.nsl.net
It seems Graham Burke wrote:
Hi just a quick question We have been recently been allocated our /19 however RIPE have assigned us only the first 700 address this I believe is pretty standard procedure.
However our connectivity supplier will not advertise our routes unless we have our full /19 assigned and registered with RIPE, obvioulsy as the range is too small. Is there any other way around this problem other than getting RIPE to register our full /19 reserved pre-allocation, if not how do RIPE stand on registering the full /19?????
If a /19 has been allocated to you, any sensible transit provider will advertise it, too. Is the allocation's inetnum object in the RIPE DB? Cheers, -Simon
On Fri, 1 Sep 2000, Graham Burke wrote:
Hi just a quick question We have been recently been allocated our /19 however RIPE have assigned us only the first 700 address this I believe is pretty standard procedure.
However our connectivity supplier will not advertise our routes unless we have our full /19 assigned and registered with RIPE, obvioulsy as the range is too small.
Graham, Your transit provider is almost certainly in error. Unless you are asking them to route individual prefixes to places other than your network, it is simply a matter of them announcing your /19 at their border. Then you can run an IGP (e.g. OSPF) with them, placing you inside their AS. Alternatively you could speak BGP to them using a private AS that is stripped before public announcement. Finally, if you are multihomed, you can apply for an AS number and simply announce your prefix using standard BGP. Implementing this is definitely way beyond the scope of this mailing list, and should be between your routing engineers, their routing engineers, and your router vendor. I suspect RIPE would never assign padding space in an allocation. Joshua -[ Joshua Goodall ]----------------------------------------------- -[ Chief Systems Architect, IP R&D, InterXion ]------------------- -[ joshuag@interxion.com ]--------------[ joshua@roughtrade.net ]-
GB-10488
p.s. shouldn't that be GB10488-RIPE? pps Edinburgh still lovely at this time of year?
Joshua Goodall wrote:
On Fri, 1 Sep 2000, Graham Burke wrote:
Hi just a quick question We have been recently been allocated our /19 however RIPE have assigned us only the first 700 address this I believe is pretty standard procedure.
However our connectivity supplier will not advertise our routes unless we have our full /19 assigned and registered with RIPE, obvioulsy as the range is too small.
Graham,
Your transit provider is almost certainly in error. Unless you are asking them to route individual prefixes to places other than your network, it is simply a matter of them announcing your /19 at their border.
Hiya, The problem the connectivity provider has is that the fact that the whole /19 is assigned to nsl is not reflected in the RIPE database, the allocated /23 and bit of /24 are indeed there however the /19 is not. The providor is meerly trying to make sure they do not announce other peoples address space by checking the database to ensure that this /19 does indeed belong to NSL. Not that NSL are not to be trusted, far from it, but a simple error in an email and no RIPE checks can mean that a network starts announcing bits of other peoples address space :) -- Leigh Porter INS
On Fri, 1 Sep 2000, Leigh Porter wrote:
Hiya,
The problem the connectivity provider has is that the fact that the whole /19 is assigned to nsl is not reflected in the RIPE database, the allocated /23 and bit of /24 are indeed there however the /19 is not.
mm, maybe, but on closer inspection... joshua@juice:~$ ripewhois -r 62.128.192.0/19 % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 62.128.192.0 - 62.128.223.255 netname: UK-NSL-20000626 descr: PROVIDER country: GB admin-c: CS9003-RIPE tech-c: SZ1652-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 20000626 changed: hostmaster@ripe.net 20000901 source: RIPE ... which is probably the object that Graham should beat the transit provider with. Joshua
Hi, Marco Davids wrote:
Hello,
A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result.
The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones.
Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now.
But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not?
Currently RIPE whoisd server doesn't mirror RADB. The reason for this is that RADB is a RPSL database while the RIPE one is not (yet). However mirroring a database does not mean that integrity, auth, etc. checks are performed across the databases. That's why, though according to RPSL as-set attribute is a class key and should be unique, the query result contains 3 objects (but all from different databases/sources). Regards, Andrei Robachevsky DB Group Manager RIPE NCC
-- Marco Davids / SARA - Academic Computing Services Amsterdam
Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt
--
On Thu, 31 Aug 2000, Marco Davids wrote:
Date: Thu, 31 Aug 2000 16:31:27 +0200 (MET DST) From: Marco Davids <marco@sara.nl> To: lir-wg@ripe.net Cc: db-wg@ripe.net Subject: Is this normal behaviour?
Hello,
A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result.
The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones.
Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now.
But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not?
as-sets (and all objects) are unique _within one registry_. When a given object is registered in multiple registries, synchronization is the responsibility of whoever register those multiple instances because when they reach servers like whois.radb.net (which mirrors multiple registries) they are kept as distinct objects. When you query whois.radb.net you will see all instances of a given object (eg. AS-GLOBALCENTER that's registered in four different registries). The problem with inconsistent objects is that unlike a whois client (which returns all objects found on a given server), tools that builds BGP filters from the IRR will only consider the first instance found for an as-set; the search order beeing dependant on the whois server admin. Another aspect of synchronization is mirroring, which, under normal conditions, is never too far behind on well managed servers like whois.radb.net. (There are exceptions though [even on whois.radb.net]: some registries - like CW, ARIN, etc. - do not offer real time mirroring possibilities; they can only be mirrored from checkpoint files that are made available for ftp only once a day.) Cheers. __ Pierre Thibaudeau | e-mail: <prt@Teleglobe.net> TELEGLOBE CANADA | e-page: <prt@txt.bellmobilite.ca> 1000, rue de La Gauchetiere ouest | Montreal, QC H3B 4X5 | Tel: +1-514-868-7257 Canada | fax: +1-514-868-8446
-- Marco Davids / SARA - Academic Computing Services Amsterdam
Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt
participants (7)
-
Andrei Robachevsky -
Graham Burke -
Joshua Goodall -
Leigh Porter -
Marco Davids -
Pierre Thibaudeau -
Simon Skals