[j-nsp] Dealing with multihomed customer BGP primary/backup links

[joel jaeggli]

On 7/13/16 1:41 AM, Mark Tinka wrote:
> 
> 
> On 13/Jul/16 10:36, Cydon Satyr wrote:
> 
>> What would be the optimal way to deal with following scenario.
>>
>> The customer of ours has a primary bgp connection over primary link on one
>> router, and a backup bgp connection (up) on backup link on our other
>> router. The customer may or may not (usually not) terminate both
>> primary/backup links on the same router.
>>
>> We want to stop customer using backup link at all as long as the primary
>> link is up. Since we police both primary and backup link, customer can just
>> load balance and use both links.
>>
>> Without asking changes on his side (so something link MC-LAG won't fit
>> here, I guess?), what are way to deal with this.
>>
>> I can think of making a script which will not import their routes as links
>> a primary link route is in our table.
>>
>> The bgp conditional policy doesn't work for importing routes, only
>> exporting... so that won't work either.
>>
>> Any other suggestions maybe?
> 
> I know this may not answer your question, but this is why we don't sell
> active/backup services to customers.
> 
> We sell active/active, and it's the customer's responsibility to control
> which link has traffic. We solve the issue commercially, incentivizing
> the customer to self-control or pay up. Works well.
> 
> Active/backup scenarios work best if you can control the CPE, i.e., a
> managed service. Without that, best never to trust the customer to
> honour anything.

I suppose the question is when you have one circuit with a customer you
can police an interface to a certain rate. when you have two you have a
coordination problem. when you have 100 well you're probably just better
off billing on 95th (that's probably best anyway).

to marks point I'd be rather unhappy if I couldn't shift my traffic from
one circuit to another for example in a prelude to a maintenance, in a
make before break fashion.

> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20160713/5af0f178/attachment.sig>