Re: [j-nsp] reinject traffic from DDoS filtering device

> > particularly if you speak flowspec to your customers. > We don't. This is for intradomain use. We use different methods to sell wholesale ddos scrubbing along with normal RTBH (which still suffices to most customers). But it is quite possible we might give some customers flowspec peering in

Re: [j-nsp] reinject traffic from DDoS filtering device

On 5 May 2017 at 00:48, Nikos Leontsinis wrote: Hey, > you still need to have a way to leak between 2 routing domains. No. The dirty side of scubber is in VRF and destination for default route in VRF. Clean side of scrubber is normal INET interface. So scrubber is

Re: [j-nsp] reinject traffic from DDoS filtering device

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 wrote: > Using flowspec to redirect traffic to routing-instance. Scrubbing device > returns traffic to global

Re: [j-nsp] reinject traffic from DDoS filtering device

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,

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

I was concentrating on 'then next-term" usage. You are right, in this case second version is certainly better ! BR, +Dragan On Thu, May 4, 2017 at 3:17 PM, Sebastian Wiesinger wrote: > * Dragan Jovicic [2017-05-04 14:30]: > > To nitpick, policing

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Dragan Jovicic [2017-05-04 14:30]: > To nitpick, policing is terminating (implicit accept for conforming > traffic), so you'd need "the next-term" to pass conforming traffic to next > term. Otherwise you'd pass 200m of ntp plus 1g of other traffic. > Cascaded policing: > >

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

Hello, thank you both for your feedback. Both versions work for me as far as I see. If the 200MBit are included in the total bandwidth does not matter in my case, I just want to make sure a 15GBit ddos to a 1 GBit customer does not impact the 10GBit uplink of the access switch, so I will it be

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Dragan Jovicic [2017-05-04 14:30]: > To nitpick, policing is terminating (implicit accept for conforming > traffic), so you'd need "the next-term" to pass conforming traffic to next > term. Otherwise you'd pass 200m of ntp plus 1g of other traffic. > Cascaded policing: > >

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

To nitpick, policing is terminating (implicit accept for conforming traffic), so you'd need "the next-term" to pass conforming traffic to next term. Otherwise you'd pass 200m of ntp plus 1g of other traffic. Cascaded policing: term agg then policer 1g then next-term term ntp from ntp

Re: [j-nsp] reinject traffic from DDoS filtering device

* Alexander Dube [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

Re: [j-nsp] reinject traffic from DDoS filtering device

Hey Alex, For traffic scrubbing you either want clean-in-VRF or dirty-in-VRF, both have upside and downside, if you are not committed to either solution, please reconsider if you are even walking the correct solution. If you'd go dirty-in-VRF, you can do 'match DCU' (community) then

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* Sebastian Wiesinger [2017-05-04 11:23]: > * "Rolf Hanßen" [2017-05-03 15:13]: > > But as long as the filter for family inet/inet6 is set, the logical > > interface filter is ignored for that family. > > If I remove the family filter, the logical

[j-nsp] reinject traffic from DDoS filtering device

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

Re: [j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.

* Alain Hebert [2017-05-03 16:29]: > Hi, > > As for a bit before 14.1X53-D42.3 (sorry I do not have the exact > version) NSSU worked on the 6 members fab with 2 re, all QFX 5100. Okay, we have 15.1 at the moment. Do you not configure spanning-tree on your box or how

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

* "Rolf Hanßen" [2017-05-03 15:13]: > But as long as the filter for family inet/inet6 is set, the logical > interface filter is ignored for that family. > If I remove the family filter, the logical interface filter is used. > > How do I combine that on a Juniper MX? You need