[GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR

[Job Snijders]

On Tue, Aug 11, 2020 at 10:51:25PM -0300, Douglas Fischer wrote:
> The 1st is corroborative
> ------------------------
> 
> OK, L3 filtering is the right way to deploy Blackhole on IXPs! But(there is
> always a but)
> The most feasible way to deploy L3 filtering on Fabric is based on FlowSpec.
> And... Switchs with support for FlowSpec are very expensive!
> 
> Considering that, on a brainstorm with a friend, we talked about a crazy
> idea to deploy Dynamic L3 Filtering on Switchs without Flowspec.
> 
> Maybe reinventing the wheel, but in a crude way the idea would be:
> 
>  a - ExaBGP as a peer of route-servers, receiving the blackhole prefixes.
>      On every change on those prefixes export then to txt.
>  b - Aggregate that txt with the prefixes to be blackholed
>  c - Convert those aggregated prefixes to a yang access-list format
>  d- Ansible(or equivalent) push that yang ACL via netconf/ssh to
> the Switchs of IXP.
> 
> Off course this is an alpha idea, and must consider a lot of other
> limitations:
> - ACL-L3 Limits of L2 devices of the fabric.
>   What would implicate on:
>    - Max Blackhole prefix by participant.
>    - Methodology to define what prefixes will not be filtered case the ACL
> limit get exceeded.

The above is the approach taken at United IX and some other places. The
concept is to take BGP and convert it into a deployed combined L2/L3
ACL.

I mention combined L2/L3 ACLs because if the MAC address of the
participant is used for matching, the IX operator can deploy the ACL in
many places inside the fabric, saving bandwidth on ingress->egress from
a platform-wide perspective.

I think you are right that deploying flowspec (from participant to
programming an IX switch) will be very hard, the path you propose makes
more sense.

Kind regards,

Job