Hi! We started tracking this kind of information too... Check out: http://www.rsng.net/pair/ We're hoping that these tools make it easier for the community to diagnose and troubleshoot these types of routing and policy problems. Let us know what you think of them... -abha ;) On Thu, 26 Jun 1997, Curtis Villamizar wrote:

In message <Pine.SOL.3.95.970618151012.15875A-100000@roofdog.acsi.net>, "Eric D . Madison" writes:

...

There still seems to be a lot of Routes out there that are not in the RADB. I know that ANS is not excepting routes not in a routing database, and others are starting to follow. It's a good idea!

I am not getting some of these routes because of the lack of an RADB entry, and it's very frustrating..

Anyone else having the same problems??

Ohh one more thing.. Seems that there are also some routes that are being advertised that don't even have a InterNIC/RIPE/APNIC entry either.. If they don't have an entry, then they are not real "Valid" routes, so I don't want to route them.. but the Origin is from a large provider.. any suggestions? Seems that they have build their whole infrastructure on these routes too.

Eric

_______________________________________________________ Eric D. Madison - Senior Network Engineer - ACSI - Advanced Data Services - ATM/IP Backbone Group 24 Hour NMC/NOC (800)291-7889 Email: noc@acsi.net

The route-dumps anaylsys page has been updated. It provides quite a bit more detail, some ANS specific (sorry). The URL is:

http://engr.ans.net/route-dumps/

New stuff on this page are:

Listing by border AS - so we know who we can bug if a reachability problem is reported and we know how much will be missing due to filtering on a per border AS basis. It also helps us concentrate on routes passed to us by our direct customers. This would be useful to others if they peer with some of the same border AS.

Reports now include (as of the most recent one):

2477 unregistered prefixes 240 prefixes unreachable due to incorrect origin AS 2 prefixes with no ANS policy 15 prefixes with incorrect ANS policy

2074 prefixes registered with incorrect origin AS (a warning)

Each problem category is also sorted by border AS and origin AS

Pages are available which report on only a specific border AS and/or origin AS. These are useful to anyone wanting to clean up their own AS, since the observed paths for each prefix is provided.

Information is available down to the prefix, with observed AS paths reported, as well as the [sort of encrypted - consider it a bug] ANS policy in cases where ANS policy is thought to be the problem.

Of the 22 border AS with any unregistered prefixes (46 with some sort of problem or warning), the worst offenders are the border AS with over 90 unregistered prefixes:

AS174 (149), AS286 (94), AS568 (166), AS701 (550), AS1239 (1131), AS1800 (443).

There are 398 origin AS with unregistered prefixes, most with just a few.

Curtis

btw- the "15 prefixes with incorrect ANS policy" both seem to be due to a transient where we intentionally do not accept a backup route from the CIX for certain providers we directly peer with yet the CIX was announcing one. The "2 prefixes with no ANS policy" are one prefix origin AS and we addressed this after the report.

__________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc.

### On Thu, 26 Jun 97 12:02 PDT, randy@psg.com (Randy Bush) wrote to Abha ### Ahuja <ahuja@Merit.Net> concerning "Re: Lots of non-existant networks ": RB> > http://www.rsng.net/pair/ RB> RB> I am confused as usual. E.g. RB> RB> http://www.rsng.net/rs-views/mae-west/AS2914/grey.html RB> RB> shows RB> RB> GREY 205.238.0.0/18 (4553) 2914 IGP This is fine. As a matter of fact, all AS2914 routes in the RSes should be GREY because you have specified to not have any of your routes redistributed by the RSes. GREY does not necessarily indicate "bad". It just denotes a route that the RS knows about but which has no policy for because the evaluation engine returned a null. The order by which policy filters for each peer of the RS is evaluated as follows. [1] Route Server Peering Request (extended inet-rtr) [2] aut-num registered in the IRR [3] route registered in the IRR In the case of [1] and [2], pairwise reciprocal policy must exist otherwise a null is returned. RB> Yet the registered policy is RB> RB> route: 205.238.0.0/18 RB> descr: RG-TIG-NIC-0 RB> origin: AS2914 RB> remarks: this is non-portable space, no shorter prefixes allowed RB> notify: rw@rg.net RB> mnt-by: MAINT-RGNET RB> changed: randy@psg.com 960829 RB> source: RADB Actually that's the registered route. Registered policy (aut-num) is also fine, however, Route Server specific policy (via the import()/export() statements in your peering session as specified via the inet-rtr object you submitted to us) evaluates out to a null list, thus we do not redistribute your routes or distribute routes to you. In the future, we will include "shades" of colors (by comparing the data we already have with additional datasets generated during the policy evaluation phase of the RSes' reconfigs) to more greatly explain and distinguish not just the status but the reason for the state of each route. RB> So what is inconisitent about this? The fault here is ours. Currently we state in our pages that GREY routes are routes that do not match prescribed policy in the IRR. However, in actuality, GREY routes are routes that _either_ do not match policy specific to peering with the RSes _or_ policy registered in the IRR. In the very short future, policy for route servers via the optional extended attributes to the inet-rtr will be merged into the RADB/IRR so the original statement will be true. The list of GREY routes for your network actually is proof that things are consistant with what you want. I suppose in some ways you can view it as an inconsistancy if you expected the RSes to pass your routes on but since you don't then there is no inconsistancy. -- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (313) 763-4907 FAX: (313) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/