[j-nsp] reinject traffic from DDoS filtering device

[Saku Ytti]

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
routing-instance scrubber. Where scrubber has default-route to
scrubber. And then clean traffic from scrubber follows global table.
This would also allow your customer to request scrubbing, if you so
want, by adding the magic community. For self-service.

If you'd go clean-in-VRF, you could have clean-side-interface in
scrubber in virtual-router which imports BGP-LU next-hops from all PE
routers, thus following LSP all the way out of network, without doing
IP lookups in between. However if your next-hops are PE loopback, not
CE, then this approach won't work.  If next-hop is PE loopback, you'd
need to import the actual scubbed prefixes themselves in a VRF facing
the scrubber _AND_ all the egress PEs, with next-hop in egress PE
imported from global table.


I personally think dirty-in-VRF is easier and cleaner, YMMV.

On 4 May 2017 at 12:55, Alexander Dube <nsp at layerwerks.net> wrote:
> 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.
>
> This workaround requires a static route for the attacked ip to itself. For example 127.0.0.1 next-hop 127.0.0.1
>
>
>
> Configuration:
> set policy-options policy-statement FILTER-FORWARDING-IMPORT term IMPORT from instance master
> set policy-options policy-statement FILTER-FORWARDING-IMPORT term IMPORT from protocol direct
> set policy-options policy-statement FILTER-FORWARDING-IMPORT term IMPORT from protocol ospf
> set policy-options policy-statement FILTER-FORWARDING-IMPORT term IMPORT then accept
> set routing-instances MPLS-L3VPN-FILTER-FORWARDING instance-type forwarding
> set routing-instances MPLS-L3VPN-FILTER-FORWARDING routing-options instance-import FILTER-FORWARDING-IMPORT
> set routing-instances MPLS-L3VPN-FILTER-VRF instance-type vrf
> set routing-instances MPLS-L3VPN-FILTER-VRF interface xe-3/0/0.152
> set routing-instances MPLS-L3VPN-FILTER-VRF route-distinguisher 123:5001
> set routing-instances MPLS-L3VPN-FILTER-VRF vrf-target target:123:5001
> set routing-instances MPLS-L3VPN-FILTER-VRF vrf-table-label
> set routing-instances MPLS-L3VPN-FILTER-VRF routing-options static route 0.0.0.0/0 next-table MPLS-L3VPN-FILTER-FORWARDING.inet.0
>
> Regards
> Alex
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti