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 <n...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
