Re: BIRD / BGP-ORR experiences?

2020-04-17 Thread Chris Jones

On 16 Apr 2020, at 22:35, Mark Tinka  wrote:
> 
> 
> 
>> On 15/Apr/20 19:07, Saku Ytti wrote:
>> 
>> 
>> Don't run Cisco ORR RR or have IGP next-hops :/
> 
> Does it break NEXT_HOP=self in Cisco-land?
> 
> Mark.

We’re testing ORR at the moment as part of core upgrades (XRv on ESXi), and 
next-hop self not only works, it’s required for ORR to work properly

I’ve not noticed any major issues with it yet but it’s still early days in 
terms of our deployment

Re: Request comment: list of IPs to block outbound

2019-10-18 Thread Chris Jones


> On 19 Oct 2019, at 04:42, Saku Ytti  wrote:
> 
> On Fri, 18 Oct 2019 at 20:15, Lukas Tribus  wrote:
> 
>> This has the potential to brake things, because it requires symmetry
>> and perfect IRR accuracy. Just because the prefix would be rejected by
>> BGP does not mean there is not a legitimate announcement for it in the
>> DFZ (which is the exact difference between uRPF loose mode and the ACL
>> approach).
> 
> It's interesting to also think, when is good time to break things.
> 
> CustomerA buys transit from ProviderB and ProviderA
> 
> CustomerA gets new prefix, but does not appropriately register it.
> 
> ProviderB doesn't filter anything, so it works. ProviderA does filter
> and does not accept this new prefix. Neither Provider has ACL.
> 
> 
> Some time passes, and ProviderB connection goes down, the new prefix,
> which is now old prefix experiences total outage. CustomerA is not
> happy.
> 
> 
> Would it have been better, if ProviderA would have ACLd the traffic
> from CustomerA? Forcing the problem to be evident when the prefix is
> young and not in production. Or was it better that it broke later on?

Having been through this exact situation recently (made worse by the fact that 
it was caused by provider b’s upstreams not having updated their filters and 
not provider b itself), I would suggest its 100 times better for it to happen 
right at the start rather than randomly down the track

> 
> -- 
>  ++ytti