[j-nsp] reinject traffic from DDoS filtering device
Nikos Leontsinis
nikosietf at gmail.com
Thu May 4 17:48:45 EDT 2017
you still need to have a way to leak between 2 routing domains.
Let alone the problems that you will have with flowspec...
On 4 May 2017 at 22:17, Dragan Jovicic <draganj84 at gmail.com> wrote:
> Using flowspec to redirect traffic to routing-instance. Scrubbing device
> returns traffic to global table.
> Since 16.1 you may exclude interface from installing filter as well, making
> it possible to have scrubbing device on same PE running flowspec.
>
> BR,
>
> +Dragan
>
> On Thu, May 4, 2017 at 12:55 PM, Sebastian Wiesinger <sebastian at karotte.org>
> wrote:
>
>> * Alexander Dube <nsp at layerwerks.net> [2017-05-04 11:55]:
>> > Hello,
>> >
>> > i've a problem reinjecting filtered traffic from a anti ddos device
>> > into our network. What we want to achive is, that traffic which
>> > comes from our upstreams/peerings is redirected to a filtering
>> > device. This is the easy part, as this can be done with a static or
>> > bgp routing.
>> >
>> > Now the part where I stuck at the moment. The router which the
>> > filter is connected to, is the same where upstreams and direct
>> > customer networks are connected to.
>> >
>> > The first try was to create a new vrf and import all direct routers
>> > from master instance. This works for ospf routes perfectly, but not
>> > for direct routes. For direct routes it is possible to get it
>> > working with a workaround, but we need a solution which does not
>> > requires configuration on the router on new attacks.
>>
>> We put all interfaces of customers that want DDoS scrubbing in a vrf
>> and leak the direct and static routes to the main table (via
>> rib-group). The scrubbing engine attracts dirty traffic by advertising
>> /32 (or /128) BGP routes in the main table and puts clean traffic in
>> the vrf the customers are in.
>>
>> The only small drawback is when customers speak BGP with us and want a
>> full table. As the vrf does not have a full table these interfaces
>> stay in the main table and their BGP routes are put into the "clean"
>> vrf by specifying a rib group in the BGP neighbor configuration which
>> will leak the customers received BGP routes into the vrf.
>>
>> Regards
>> Sebastian
>>
>> --
>> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
>> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
>> SCYTHE.
>> -- Terry Pratchett, The Fifth Elephant
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list