Re: outages, quality monitoring, trouble tickets, etc

[Curtis Villamizar <curtis () ans net>]

In message <Pine.LNX.3.91.951129134921.25369D-100000 () netrail net>, Matt Zimmerm
an writes:
> On Tue, 28 Nov 1995, Ed Morin wrote:
>
> [AOL unreachability]
> > I've seen several providers claim "it's AOL's fault" because the provider
> > themselves didn't properly set up an RADB entry so the ANS network would
> > carry their packets.  Given that AOL is on the other side of the ANS
> > network, that could be a big problem.  So, just sitting down and showing
> > the site is accessible from a dozen other sites proves nothing about it
> > not being the provider's problem -- it helps to show that it works in
> > some cases though.
>
> Hmm.  I was under the impression that our maintainer object 
> (NETRAIL-NOC), AS object (AS4006), and route object (205.215.0.0/18, 
> containing the server in question) were sufficient.  Do I need to go 
> through some additional motions to satisfy ANS?  Also, this seems to 
> only be an intermittent problem (I would think that ANS not carrying our 
> packets would result in complete unreachability).
>
> // Matt Zimmerman       Chief of System Management           NetRail, Inc.
> // mdz () netrail net                                       sales () netrail net
> // (703) 524-4800 [voice]    (703) 524-4802 [data]    (703) 534-5033 [fax]


The policy toward AS4006 was set to 1:3561 2:1239 based on the
advisories for the 3 AS4006 nets that existed when we froze the
aut-num.  If you add prefixes to AS4006, you don't have to do
anything except to make sure to register route objects with the
correct origin AS.

For AS that have never registered an AS690 advisory (there were 20 AS
covering 59 prefixes in the IRR) we didn't have any policy.  For AS
that have never registered anything in the IRR, we don't have any
import policy and we won't be importing their routes.

We plan to run a perl program to detect new aut-nums and keep md5 sums
of prior aut-nums so we can detect changes (assuming the changed field
won't get changed).  We will be basing any new import policy on the
paths seen in the IRR, just sending a notification message to the AS
affected when we change things.  This will give us as reliable routing
as we have now, but less burden on others to tell us how they want us
to route towards them.

I'm hoping to be able to catch things we need to change by noting
changes to the aut-nums.  Right now the tools to do this are not
available, so we need to trace paths manually.  It might be that
updating prpaths is about all that is needed.

Curtis