[48008] in North American Network Operators' Group
Re: RADB mirroring
daemon@ATHENA.MIT.EDU (Jake Khuon)
Mon May 20 17:46:38 2002
Message-Id: <200205202145.g4KLjgPn012973@wooj.com>
From: "Jake Khuon" <khuon@NEEBU.Net>
To: nanog@merit.edu
In-reply-to: Randy Bush's message of Mon, 20 May 2002 13:35:34 -0700.
<E179tsU-0001ke-00@rip.psg.com>
Reply-To: khuon@NEEBU.Net (Jake Khuon)
Date: Mon, 20 May 2002 14:45:42 -0700
Errors-To: owner-nanog-outgoing@merit.edu
### On Mon, 20 May 2002 13:35:34 -0700, Randy Bush <randy@psg.com> casually
### decided to expound upon "Peter E. Fry" <pfry@swbell.net> the following
### thoughts about "Re: RADB mirroring":
RB> > An IRR not mirrored by the RADB (to act as a member) and not
RB> > mirroring every RR mirrored by the RADB (to hijack the top level)
RB> > seems pointless.
RB>
RB> auto-config tools, such as ratoolset, do not use the mirrored data,
RB> only the origin data. one specifies the list of registries to
RB> search. so, mirroring by the irr is neither necessary nor
RB> sufficient, though it can be convenient for lookup by wetware.
RADB and other IRRs running IRRd accept a "!s" command to set (change from
default) the specified sources (including mirrored sources). The return for
each query is done on a first-hit matching mechanism. One may conceivably
switch/modify search orders prior to each query. IRRToolSet (formerly
RAToolSet) has the capability of specifying a different IRR server but this
means one would incur a penalty for closing and reopening connections
between switching servers. It is far better (and friendlier to the IRRs)
from a performance standpoint to keep persistant connections to a single
server that is fully mirroring.
--
/*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+
| Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- |
| for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S |
+=========================================================================*/
