Ok, I've got my BGP4 announcement configured for my new /19 which I feel much better about after the response I got from this list (thanks for all that replied). I'm now waiting for inbound filter changes on my upstream BGP sessions. Once upon a time, I used to also have to enter a new route into the raddb. Unfortunately, it's been some time since I have done that and am uncertain of the state of the raddb and whether or not it is still in use. Or, if it has been replaced/supplemented with something else. Is there a FAQ I should have bookmarked which contains this information? Or, if there isn't could someone point me in the right direction? Thanks again, -forrestc@imach.com
Once upon a time, I used to also have to enter a new route into the raddb. Unfortunately, it's been some time since I have done that and am uncertain of the state of the raddb and whether or not it is still in use. Or, if it has been replaced/supplemented with something else. Is there a FAQ I should have bookmarked which contains this information? Or, if there isn't could someone point me in the right direction?
Half of the information in the raddb is outdated and erroneous. brad reynolds ber@cwru.edu "Faith: not wanting to know what is true." -- Friedrich Nietzsche
On Wed, 12 Nov 1997, Bradley Reynolds wrote:
Once upon a time, I used to also have to enter a new route into the raddb. Unfortunately, it's been some time since I have done that and am uncertain of the state of the raddb and whether or not it is still in use. Or, if it has been replaced/supplemented with something else. Is there a FAQ I should have bookmarked which contains this information? Or, if there isn't could someone point me in the right direction?
Half of the information in the raddb is outdated and erroneous.
That is why everyone should do their part and clean it up. Visit http://engr.ans.net/route-dumps/ and make sure your AS is registered properly. To answer the original question, yes, register your route objects in the RADB. If you don't, you may experience reachability problems to some providers. (Although ANS says that they don't currently deny unregistered prefixes, you should still register.) For more info on registering your objects, see: http://www.ra.net/RADB.tools.docs/register.html Bradley
I meant in the RADB, not the raddb, sorry. I just took a look through it. Maybe I found all the errors, but I highly doubt that. brad reynolds ber@cwru.edu "Faith: not wanting to know what is true." -- Friedrich Nietzsche On Wed, 12 Nov 1997, Randy Bush wrote:
Half of the information in the raddb is outdated and erroneous.
Interesting. How did you measure that?
randy
Date: Wed, 12 Nov 1997 01:35:10 -0500 (EST) From: Bradley Reynolds <brad@b63695.student.cwru.edu>
Half of the information in the raddb is outdated and erroneous.
While there is a great deal of old data that is obsolete, we use the RADB to configure our routers and also for peering via the route servers and find few problems that impact operations. I do suspect that a "sunset" clause will be needed some day to clear out old cruft. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Hi Kevin, (comments to follow) "Kevin Oberman" writes:
While there is a great deal of old data that is obsolete, we use the RADB to configure our routers and also for peering via the route servers and find few problems that impact operations.
Well, we hope that the amount of obsolete/incorrect/bad data is small. I don't think anyone really knows from a quantitative standpoint as the problem is complex. The notion that the IRR represents current routing policy is not held by everyone, so of course there will be incorrect data. For example I've known people to pre-register policy based on changes that are to occur sometime in the future. Also, people make mistakes and what they register does not always align with reality. We (merit) have been working on a tool called PAIR which is designed to help people identify obsolete/incorrect routing information. PAIR basically compares route announcements as seen at the route servers to registered policy. Users can check their AS and see what they are actually announcing, to whom and what they have configured in the IRR. The routes are colorized, green being good and red (ie, not announced but registered) and grey (ie, announced but not registerd) probably indicating a problem. We have been working on quantitative indicators for incorrect data and hope to have something soon. (www.rsng.net/rs-views)
I do suspect that a "sunset" clause will be needed some day to clear out old cruft.
The idea of time-stamping and removing old objects has come up in the past but has not gotten public support. The other registeries are leery of crossing the line and taking a measure of resposibility for the db correctness. The public is leery of giving any third party the power to delete/update their objects. What if an ISP lost connectivity because of so called "obsolete data" and then pointed the finger at the registry administrator? A sunset clause would have to take into consideration other factors in order to work. For example, just because an object is old does not mean it is obsolete or stale. Good data can remain good for an indefinite period of time. And just because an object is new does not mean it is good data or up to date (ie, there is no safeguard in place that dissallows the registering of incorrect data.) I do agree with you that it would be nice to implement a system that would allow the registry administator some power to take corrective action to remove/update obsolete/incorrect db objects. I really believe that if the user community really wants to do something about obsolete information (and I do believe this is true) then the registries need to have limited power to fix the situation. The question is what should the power be and under what situation? --Gerald -- Gerald A. Winters, Ph.d gerald@merit.edu Merit Network, Inc. (313) 647-3522 (office) 4251 Plymouth Road, Suite C. (313) 647-3185 (fax) Ann Arbor, MI 48105-2785
Gerald, I think there may be an issue of terms here. I believe that there is relatively little truly incorrect data in the RADB. By "incorrect", I mean data that would result in incorrect or missing routing. There is a fairly large amount of "obsolete" data that is virtually impossible to track down because it is abandoned. Routes that were transferred from the PRDB are especially likely to be obsolete, but I have stumbled on a number of routes registered to various organization and placed in the RADB when the organization either no longer exists or no longer is connected using that route. This is a less serious problem in that it never results in failed routing. It does have some slight security implications, but I don't see a really significant way to exploit these. The bottom line is that we (ESnet) has been using the IRR to generate portions of our router configuration for several years with very good results. And I still believe that record expiration will be needed some day because the database will accumulate abandoned data and continue to grow until things start to get un-manageable. I have no idea how close this is to happening, but I suspect that it is NOT near. In any case, I think we are in basic agreement. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
We use both RIPE Data base and our own network data base to generate STRICT filtering by IP prefixes for our peers and customers (except some who are _trusted_ because they are too big or are our providers for the european/USA connectivity. On Wed, 12 Nov 1997, Kevin Oberman wrote:
Gerald,
I think there may be an issue of terms here.
I believe that there is relatively little truly incorrect data in the RADB. By "incorrect", I mean data that would result in incorrect or missing routing.
There is a fairly large amount of "obsolete" data that is virtually impossible to track down because it is abandoned. Routes that were transferred from the PRDB are especially likely to be obsolete, but I have stumbled on a number of routes registered to various organization and placed in the RADB when the organization either no longer exists or no longer is connected using that route.
This is a less serious problem in that it never results in failed routing. It does have some slight security implications, but I don't see a really significant way to exploit these.
The bottom line is that we (ESnet) has been using the IRR to generate portions of our router configuration for several years with very good results.
And I still believe that record expiration will be needed some day because the database will accumulate abandoned data and continue to grow until things start to get un-manageable. I have no idea how close this is to happening, but I suspect that it is NOT near.
In any case, I think we are in basic agreement. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
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)
On Wed, 12 Nov 1997, Gerald Winters wrote:
I do agree with you that it would be nice to implement a system that would allow the registry administator some power to take corrective action to remove/update obsolete/incorrect db objects. I really believe that if the user community really wants to do something about obsolete information (and I do believe this is true) then the registries need to have limited power to fix the situation. The question is what should the power be and under what situation?
A nondestructive and possibly sufficient mechanism would be to send PAIR errors/warnings to the appropriate maintainers monthly by email. People with clean RADB entries wouldn't be sent anything. This would be a good periodic reminder for engineering groups that have it in the back of their mind to clean up their RADB entries but never get around to it unless a peer or customer opens a trouble ticket. Heck, the warnings could even have the appropriate RADB object (or mail command) preformatted and ready to email. This way the maintainer has final control. Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 408 282 1540 | | Hurricane Electric Web Hosting & Co-location Fax 408 971 3340 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
Hello All, I personally like the Idea of mailing PAIR errors/warnings to the POC in the RADB . Tia, JimL On Fri, 14 Nov 1997, Mike Leber wrote:
On Wed, 12 Nov 1997, Gerald Winters wrote:
I do agree with you that it would be nice to implement a system that would allow the registry administator some power to take corrective action to remove/update obsolete/incorrect db objects. I really believe that if the user community really wants to do something about obsolete information (and I do believe this is true) then the registries need to have limited power to fix the situation. The question is what should the power be and under what situation?
A nondestructive and possibly sufficient mechanism would be to send PAIR errors/warnings to the appropriate maintainers monthly by email. People with clean RADB entries wouldn't be sent anything. This would be a good periodic reminder for engineering groups that have it in the back of their mind to clean up their RADB entries but never get around to it unless a peer or customer opens a trouble ticket.
Heck, the warnings could even have the appropriate RADB object (or mail command) preformatted and ready to email. This way the maintainer has final control.
Mike.
+------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 408 282 1540 | | Hurricane Electric Web Hosting & Co-location Fax 408 971 3340 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
participants (9)
-
Alex P. Rudnev -
Bradley Dunn -
Bradley Reynolds -
Forrest W. Christian -
Gerald Winters -
Kevin Oberman -
Mike Leber -
Network Operations Center -
Randy Bush