Help with bad announcement from UUnet

Steve Naslund snaslund at interaccess.com
Fri Mar 29 21:27:49 UTC 2002


I would say that if someone was announcing an IP block that I or a customer
of mine
owned, I would be justified in calling the NOC of whoever is announcing it.
I think the
owner of the IP block has the right and obligation to control its use.  I
would try to
determine who was making the original announcement and go to them directly.
If they
failed to correct the problem, you would be justified in trying to get their
upstream
provider to kill it.

	As a service provider, I feel that we are responsible for our BGP
announcements as
well as the announcements coming from my customers.  One thing we do that
helps in this regard is to filter the announcements we accept from our
customer to routes
that we expect them to announce (i.e. IP blocks that they own ).  This helps
us defend our
network (and the Internet in general) in the event that they misconfigure
their BGP.  If the
customer is an experienced service provider you can loosen the rules a
little as they prove
themselves, if they are a customer who just has two service providers it is
not very hard
to determine which block they should be announcing and stop all other
announcements.

Steven Naslund

> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
> Anne Marcel Roorda
> Sent: Friday, March 29, 2002 2:44 PM
> To: nanog at merit.edu
> Subject: Re: Help with bad announcement from UUnet
>
>
>
>
> > >   Having a support model in which anyone can call any NOC about a
> > > problem they're having does not scale very well.
> >
> > I felt justified in calling UUnet.  I know the conversation had
> > morphed by the time you made the above comment.  However in my case
> > UUnet was propagating an announcement that was stepping on one of
> > ours; the owner of the netblock was there to say that he did not want
> > that announcement being made; the UUnet customer making the
> > announcement (who I would rather have dealt with) was apparently
> > operating without a crew.  Here was a conversation between directly
> > affected parties.  It came down to who was bothering who: was it UUnet
> > bothering me by announcing my route, or was it me bothering them by
> > asking them to stop?
>
>   Let me begin by letting you know that my comments were not UUnet
> specific.
>
>   Getting the person announcing this block to open a ticket with the
> NOC and including your contact details, as well as a clear description
> of the prolem would have been my first suggestion.
>
>   It saves you having to convince the NOC that their customer should
> not be announcing this route, and that they should stop it. Instead it
> turns into an issue where a customer is unable to change his configuration
> reliably and needs help in doing so.
>
>   A suitable sollution would have been to either talk the customer
> through it, change the filters, or both.
>
> > The model of "I won't talk to anybody who isn't my customer" is
> > probably almost always right, but it does not work for every single
> > situation.  With that stand, you wouldn't have an abuse@ contact.
> > Sometimes your actions directly affect somebody and you should be
> > willing to deal with the consequences of that.
>
>   The comparison with an abuse department is not realistic. The primary
> goal of those departments is drasticly different.
>
> > While their initial reaction in my case was "I can't talk to you,"
> > they did indeed reconsider and help out.  Thanks again.  It happened
> > pretty much at the instant I asked for help here, which is the usual
> > sort of kharma..
>
>   Some things should not be to easy. Getting people to filter routes
> without a clear understanding of why, and apropriate checks is one of
> those things.
>
> > BTW as I mentioned when I contacted Genuity, they advised me to contact
> > UUnet directly.  So by inference at least one large carrier (Genuity)
> > seems to feel that contacting them directly is appropriate.
>
>   That is unfortunate.
>
> - marcel
>




More information about the NANOG mailing list