[c-nsp] Conditional BGP

[Andrew Gristina]

The classics on BGP are Routing TCP/IP vol 1 and 2 by Doyle and
Internet Routing Architectures by Sam Halabi.

If you understand those, you understand enough to have some "BGP kung fu".

On Tue, Sep 23, 2008 at 4:34 PM, Brandon Price <brandon at sterling.net> wrote:
> Could you guys recommend some good books or other documentation on some
> of these BGP "best practice" methodologies? I am a BGP novice but would
> like to get myself more up to speed on BGP kung fu.
> I found this current thread somewhat fascinating.
>
> Thanks
> Brandon
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
> Sent: Tuesday, September 23, 2008 10:15 AM
> To: 'Pete Templin'
> Cc: 'cisco-nsp'
> Subject: Re: [c-nsp] Conditional BGP
>
> Thanks Pete.... yeah, thought that through as well - been there done
> that ;)
> We'll offer them a full feed (well, all three options but I know they'll
> want a full feed I believe - that's what they get via Cogent as well)
> and
> then they can control everything - with communities as well on our side.
> We
> always local-pref customers 300, peers 200, transit 100 and been caught
> on
> that before hehe...  I'm happy if the decisions are on the customer and
> we're "just" the provider....
>
> Take care,
>
> Paul
>
>
> -----Original Message-----
> From: Pete Templin [mailto:petelists at templin.org]
> Sent: Tuesday, September 23, 2008 1:06 PM
> To: Paul Stewart
> Cc: 'cisco-nsp'
> Subject: Re: [c-nsp] Conditional BGP
>
> Paul Stewart wrote:
>
>> What is common practice for this scenario?  We would still prefer to
> just
>> send a full table and put the control into their hands but I'm also
>> concerned if they will have the technical expertise to accomplish
> this..
> On
>> their side, what would be common practice?  I've been looking at
> conditional
>> BGP advertisements using route-maps but don't believe that's the best
>> solution..
>
> They can control their outbound fairly easily.  They should make sure
> they're getting the same level (default-only, partial, full) of routes
> from you as from Cogent - if they take more from you, those routes are
> more-specific and would win regardless.  I'd suggest they take
> default-only from you (or more but filter out everything but default so
> they can change on the fly later) and whatever they wish from Cogent.
>
> Controlling inbound is often tougher.  Any smart provider sets a higher
> local pref on customer routes than on transit/peer routes (make money
> rather than pay money), so if you do this you'll need to make an
> exception for them (or offer the exception via communities).  Otherwise,
>
> you'll prefer their announcement no matter how many prepends they do,
> and if that happens for a minute, your transits will likely prefer your
> propagation no matter how many prepends they do.  Even if you don't do
> this today, if Cogent goes down, you'll choose the direct link (it's the
>
> only one live) and your transits will do the same thing (your routes
> have customer LP in their network).  When Cogent comes up, your transits
>
> will ignore the Cogent-propagated route since it's only peer LP.  They'd
>
> have to bounce the link to you to restore their preferred balance.
> You'll need to find out how to accomplish the same thing in your
> providers' networks as well.  (Been there, done that, got the t-shirt.)
>
> pt
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>