[c-nsp] Conditional BGP

[Paul Stewart]

Thanks Bill...

"finally, 'down' can mean a lot of things and your customer needs to
figure out if that means 'interface loss', 'loss across cogent' (frequent
occurrence), 'latency spike', etc. in IOS, using IP SLA and a track
object is probably the best way to implement those checks"

This is a very good point - there's a good reason they need backup when
using a Cogent feed ;)  Sorry, couldn't resist saying that...  their
viewpoint will be "loss across cogent" I'm sure...

I believe they will want a full feed and just look after it all - or we can
offer them a managed customer prem router solution and take care of it for
them....

Take care,

Paul



-----Original Message-----
From: bill fumerola [mailto:billf at mu.org] 
Sent: Tuesday, September 23, 2008 12:26 PM
To: James Slepicka
Cc: Paul Stewart; 'cisco-nsp'
Subject: Re: [c-nsp] Conditional BGP

On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote:
> >>they both wish to use us as a backup provider and wish to ONLY use 
> our network if their primary provider (Cogent) is down.
> 
> I'm currently doing this with Cogent and another provider.  I get 
> default routes from both and simply prepend my AS a few times on the 
> backup connection.  In your situation this would mean that all of the 
> config is on the customer side.  e.g.:
> 
> router bgp xxxx
> ...
> neighbor backup route-map prepend_outbound out
> neighbor x.x.x.x peer-group backup
> ...
> 
> route-map prepend_outbound permit 10
> set as-path prepend xxxx xxxx xxxx

avoid manual peer-groups.. templates using 'inherit peer-(session|policy)'
are more flexible and easier to change later. if your neighbors have the
same outbound policy, they'll get stuffed into the same update group w/o
the peer-group.

and to answer the OP question: this is a question of local policy for
the customer. give them lots of options. let them use weight (and/or
localpref, if they have multiple routers in the AS) to determine egress.
give them communities if that will help their route selection decision
making. i wouldn't go much further than the previous suggestions of
'full routes', 'customer routes', 'default origination' unless $customer
is paying you to rig something up or you're feeling particularly nice.

finally, 'down' can mean a lot of things and your customer needs to
figure out if that means 'interface loss', 'loss across cogent' (frequent
occurrence), 'latency spike', etc. in IOS, using IP SLA and a track
object is probably the best way to implement those checks.

-- bill