RE: ISP BGP change processes and non-aggregate announcements

 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Higham, Josh
> Sent: Friday, September 21, 2007 12:22 PM
> To: [email protected]
> Subject: RE: ISP BGP change processes and non-aggregate announcements
> 
> > [mailto:[email protected]] On Behalf Of Kevin Kargel
> > 
> > First off, your upstream provider is not "required" to accept or 
> > advertise anything.  This is completely dependent of the agreement
> > (contract?) you have with them.
> 
> The 'require' comment was asking what level3 (or cogent) 
> requires from the downstream before they'll announce a route. 
>  I understand that my announcements is a contractual issue.
> 
> > Having said that there are a lot of things here that could 
> influence 
> > your question.  Is your netblock your own PI space or is it 
> PA space 
> > you got from one or the other provider?
> 
> Our PI.
> 
> > Most BGP providers will advertise
> > down to a /24 on a special request.  I have done so with 
> AT&T and with 
> > Sprint.  Virtually nobody will advertise smaller than a 
> /24, and even 
> > if they did it would not be widely accepted.
In my case, and I use Cisco hardware, I accept anything my local peers
want to send me.  This is effectively just local routing, and I can then
use the most specific route from what I have.  From others I reject
routes longer than /21, which really doesn't seem to make a difference
in route choices and greatly reduces my bgp table size.

> 
> I don't need anything smaller than /24, but I haven't had 
> problems previously announcing that, so I wanted to find out 
> the state of the internet, as it is.  Currently I'm trying to 
> announce a /20 and it's going nowhere.
> 
I should think there would be no problem announcing a /20.  

> In addition, is it common to aggregate incoming announcements 
> if otherwise identical?  From a technical side, how is this 
> done (I know outbound BGP aggregation, but not inbound)?  
> Actually, I think someone on cisco-nsp was expressing 
> frustration that Cisco couldn't do this (and might not have 
> plans to support it).
> 
> > You can always register your ASN with Merit's RADB 
> (radb.net) to get 
> > around the altdb issue.
> 
> The question is whether I need to register with all these 
> databases (ARIN, altdb, radb), or if a single authoritative 
> source is acceptable (ARIN in this case).  In addition, is it 
> common to only permit BGP announcements for networks defined 
> in the database?  If so, is it a strictly manual process, or 
> have people automated it?
The only place I register is ARIN.  I used to do RADB but saw no
benefit.

> 
> Thanks,
> Josh
> 
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of Higham, Josh
> > > Sent: Friday, September 21, 2007 10:52 AM
> > > To: [email protected]
> > > Subject: ISP BGP change processes and non-aggregate announcements
> > > 
> > > I have a question for the ISP people out there regarding BGP 
> > > announcements.  I used to be on the ISP side, but am not on the 
> > > enterprise side and having problems with one of our providers.
> > > 
> > > First, does anyone have specifics on what level3 and cogent (our 
> > > ISP's upstream providers) require to accept a new 
> announcement?  I 
> > > have asked for the flexibility to announce anything 
> within our ARIN 
> > > allocation (down to a /24) with a max-prefix cap (not 
> that I want to 
> > > regularily do so, but because I want to be able to do so in an 
> > > emergency).
> > > 
> > > Our provider says that level3 requires any routes be 
> listed in altdb 
> > > as objects (as opposed to ARIN), and it sounds like adding is a 
> > > manual process (during which level3 will verify against 
> altdb).  For 
> > > cogent they said they have to list the specific route 
> announcement, 
> > > and cannot allow longer-prefixes.
> > > 
> > > Is this how the providers work, or is my ISP just not willing to 
> > > make the necessary requests?  I am trying to announce both our 
> > > aggregate and a smaller block as a temporary fix for an 
> external BGP 
> > > problem, and I think they are just trying to keep me from doing 
> > > something 'bad'.
> > > 
> > > Thanks,
> > > Josh
> > > _______________________________________________
> > > "Eat sushi frequently". - Avi
> > > [email protected] is the human contact address.
> > > [email protected] is the list posting address.
> > > See below URL for subscribe/unsubscribe and list options:
> > > http://inet-access.net/mailman/listinfo/list
> > > 
> > _______________________________________________
> > "Eat sushi frequently". - Avi
> > [email protected] is the human contact address.
> > [email protected] is the list posting address.
> > See below URL for subscribe/unsubscribe and list options:
> > http://inet-access.net/mailman/listinfo/list
> > 
> _______________________________________________
> "Eat sushi frequently". - Avi
> [email protected] is the human contact address.
> [email protected] is the list posting address.
> See below URL for subscribe/unsubscribe and list options:
> http://inet-access.net/mailman/listinfo/list
> 
_______________________________________________
"Eat sushi frequently". - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list