Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Wed, 3 Apr 2024 at 09:45, Saku Ytti wrote:
> Actually I think I'm confused. I think it will just work. Because even
> as the EgressPE does IP lookup due to table-label, the IP lookup still
> points to egressMAC, instead looping back, because it's doing it in
> the CleanVRF.
> So I think it just works.
> routing-options {
> interface-routes {
> rib-groups {
> cleanVRF {
> import-rib [ inet.0 cleanVRF.inet.0 ];
> import-policy cleanVRF:EXPORT;
>
This isn't exactly correct. You need to put the cleanVRF in
interfacer-quotes and close it.
Anyhow I'm 90% sure this will just work and pretty sure I've done it.
The confusion I had was about the scrubbing route that on the
clean-side is already host/32. For this, I can't figure out a cleanVRF
solution, but a BGP-LU solution exists even for this problem.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On 4/3/24 08:45, Saku Ytti wrote:
Actually I think I'm confused. I think it will just work. Because even
as the EgressPE does IP lookup due to table-label, the IP lookup still
points to egressMAC, instead looping back, because it's doing it in
the CleanVRF.
So I think it just works.
So OP just needs to copy the direct route as-is, not as host/32 into
cleanVRF, with something like this:
routing-options {
interface-routes {
rib-groups {
cleanVRF {
import-rib [ inet.0 cleanVRF.inet.0 ];
import-policy cleanVRF:EXPORT;
Now cleanVRF.inet.0 has the connected TableLabel, and as lookup is
done in the cleanVRF, without the Scrubber/32 route, it'll be sent to
the correct egress CE, despite doing egress IP lookup.
Sounds like it should if I logic through your example, but in our case,
we took a different path.
We did not use RIB Groups. Everything happened in the virtual-router
instance (including IS-IS + LDP + a dedicated Loopback interface), and
then we connected it to the global table using an lt- interface (classic
virtual-router vibes).
Basically, we cut the router in half (or doubled it, whichever way you
look at it) so that one side of the router was dealing with traffic
on-ramp to send to the scrubber for cleaning, and the other side of the
router was dealing with traffic off-ramp to send the cleaned traffic
toward the egress PE. Both sides of the router were virtually
independent, even though in the same physical hardware.
You could achieve the same using two physical routers, but with the
available tech., it would have been a waste.
We did this with an MX204, which means there could be a PFE penalty down
the line if traffic grows, but I did not spend too much time digging
into that, as at the time, we were only dealing with about 40Gbps of
traffic, and needed to get the setup going ASAP.
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Wed, 3 Apr 2024 at 09:37, Mark Tinka via juniper-nsp
wrote:
> At old job, we managed to do this with a virtual-router VRF that carried
> traffic between the scrubbing PE and the egress PE via MPLS, to avoid
> the IP loop.
Actually I think I'm confused. I think it will just work. Because even
as the EgressPE does IP lookup due to table-label, the IP lookup still
points to egressMAC, instead looping back, because it's doing it in
the CleanVRF.
So I think it just works.
So OP just needs to copy the direct route as-is, not as host/32 into
cleanVRF, with something like this:
routing-options {
interface-routes {
rib-groups {
cleanVRF {
import-rib [ inet.0 cleanVRF.inet.0 ];
import-policy cleanVRF:EXPORT;
Now cleanVRF.inet.0 has the connected TableLabel, and as lookup is
done in the cleanVRF, without the Scrubber/32 route, it'll be sent to
the correct egress CE, despite doing egress IP lookup.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On 4/3/24 08:07, Saku Ytti via juniper-nsp wrote: If I understand you correctly, the problem is not that you can't copy direct into CleanVRF, the problem is that ScrubberPE that does clean lookup in in CleanVRF, has label stack of [EgressPE TableLabel], instead of [EgressPE EgressCE], this causes the EgressPE to do IP lookup, which will then see the Direct/32 advertised by the scrubber, causing loop. While what you want is end-to-end MPLS lookup, so that egressPE MPLS lookup has egressMAC. I believe in BGP-LU you could fix this, without actually paying for duplicate RIB/FIB and without opportunistically copying routes to CleanVRF, every prefix would be scrubbable by default. You'd have per-ce for rest, but per-prefix for connected routes, I believe then you would have [EgressPE EgressMAC_CE] label for connected routes, so each host route would have their own label, allowing mac rewrite without additional local IP lookup. I'm not sure if this is the only way, I'm not sure if there would be a way in CleanVRF to force each direct/32 to have a label as well, avoiding the egress IP lookup loops. One doesn't immediately spring to mind, but technically implementation could certainly allow such mode. At old job, we managed to do this with a virtual-router VRF that carried traffic between the scrubbing PE and the egress PE via MPLS, to avoid the IP loop. It was quite an involved configuration, but it actually worked. It sort of mimicked the ability of the scrubbing device being able to participate in your IGP (which is something I wanted but the scrubbing vendor was not keen to support). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Tue, 2 Apr 2024 at 18:25, Michael Hare via juniper-nsp wrote: > We're a US research and education ISP and we've been tasked for coming up > with an architecture to allow on premise DDoS scrubbing with an appliance. > As a first pass I've created an cleanL3VPN routing-instance to function as a > clean VRF that uses rib-groups to mirror the relevant parts of inet.0. It > is in production and is working great for customer learned BGP routes. It > falls apart when I try to protect a directly attached destination that has a > mac address in inet.0. I think I understand why and the purpose of this > message is to see if anyone has been in a similar situation and has > thoughts/advice/warnings about alternative designs. > > To explain what I see, I noticed that mac address based nexthops don't seem > to be copied from inet.0 into cleanL3VPN.inet.0. I assume this means that > mac-address based forwarding must be referencing inet.0 [see far below]. > This obviously creates a loop once the best path in inet.0 becomes a BGP /32. > For example when I'm announcing a /32 for 1.2.3.4 out of a locally attached > 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 > as the nexthop correctly, arrives in cleanL3VPN which decides to forward to > 5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see > below], cleanL3VPN Is dependent on inet.0 for resolution. Even if I could > copy inet.0 mac addresses into cleanL3VPN, eventually the mac address would > age out of inet.0 because the /32 would no longer be directly connected. If > I want to be able to protect locally attached destinations so I think my > design is unworkable, I think my solutions are If I understand you correctly, the problem is not that you can't copy direct into CleanVRF, the problem is that ScrubberPE that does clean lookup in in CleanVRF, has label stack of [EgressPE TableLabel], instead of [EgressPE EgressCE], this causes the EgressPE to do IP lookup, which will then see the Direct/32 advertised by the scrubber, causing loop. While what you want is end-to-end MPLS lookup, so that egressPE MPLS lookup has egressMAC. I believe in BGP-LU you could fix this, without actually paying for duplicate RIB/FIB and without opportunistically copying routes to CleanVRF, every prefix would be scrubbable by default. You'd have per-ce for rest, but per-prefix for connected routes, I believe then you would have [EgressPE EgressMAC_CE] label for connected routes, so each host route would have their own label, allowing mac rewrite without additional local IP lookup. I'm not sure if this is the only way, I'm not sure if there would be a way in CleanVRF to force each direct/32 to have a label as well, avoiding the egress IP lookup loops. One doesn't immediately spring to mind, but technically implementation could certainly allow such mode. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (No subject)
Barry, Thanks for the link. I had to laugh at this: 'you are tired of arguing with your network architecture team (“we are here to transport packets” vs “the Internet firewall” ;-)'. 20 years later, that still rings awfully true for me. This diagram accurately displays how I've built a dirtyVRF that can use either FBF or, these days, Flowspec to vrf redirection. For example I have 5 ASBR and the inspection POC is only attached to a single POP. FBF indeed works great and scales “good enough” if well designed. -Michael From: Barry Raveendran Greene Sent: Tuesday, April 2, 2024 11:30 AM To: Michael Hare Cc: juniper-nsp@puck.nether.net Subject: Re: (No subject) Have you reviewed the MPLS Shunt work from the mid-2000s? David Smith figured this out with AT&T. [note: attachment removed by michael.hare, my outlook helpful tried to inline it. See Barry’s original message] On Apr 2, 2024, at 10:25, Michael Hare via juniper-nsp mailto:juniper-nsp@puck.nether.net>> wrote: Hi there, We're a US research and education ISP and we've been tasked for coming up with an architecture to allow on premise DDoS scrubbing with an appliance. As a first pass I've created an cleanL3VPN routing-instance to function as a clean VRF that uses rib-groups to mirror the relevant parts of inet.0. It is in production and is working great for customer learned BGP routes. It falls apart when I try to protect a directly attached destination that has a mac address in inet.0. I think I understand why and the purpose of this message is to see if anyone has been in a similar situation and has thoughts/advice/warnings about alternative designs. To explain what I see, I noticed that mac address based nexthops don't seem to be copied from inet.0 into cleanL3VPN.inet.0. I assume this means that mac-address based forwarding must be referencing inet.0 [see far below]. This obviously creates a loop once the best path in inet.0 becomes a BGP /32. For example when I'm announcing a /32 for 1.2.3.4 out of a locally attached 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 as the nexthop correctly, arrives in cleanL3VPN which decides to forward to 5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see below], cleanL3VPN Is dependent on inet.0 for resolution. Even if I could copy inet.0 mac addresses into cleanL3VPN, eventually the mac address would age out of inet.0 because the /32 would no longer be directly connected. If I want to be able to protect locally attached destinations so I think my design is unworkable, I think my solutions are = use flowspec redirection to dirty VRF, keep inet.0 as clean and use flowspec interface filter-group appropriately on backbone interfaces [routing-options flow interface-group exclude, which I already have deployed correctly]. This seems easy but is less performant. = put my customers into a customerVRF and deal with route leaking between global and customerVRF. This is a well-known tactic but more complicated to approach and disruptive to deploy as I have to airlift basically all the customers to into a VRF to have full coverage. For redirection, to date I've been looking at longest prefix match solutions due to the presumed scalability vs using flowspec. I have an unknown amount of "always on" redirects I might be asked to entertain. 10? 100? 1000? I'm trying to come up with a solution that doesn't rely on touching the routers themselves. I did think about creating a normal [non flowspec] input firewall term on untrusted interfaces that redirects to dirty VRF based in a single destination prefix-list and just relying on flowspec for on demand stuff with the assumption one firewall term with let's say 1000 prefixes is more performant than 1000 standalone flowspec rules. I think my solution is fundamentally workable but I don't think the purchased turnkey ddos orchestration is going to natively interact with our Junipers, so that is looked down upon, since it would require " a router guy " or writing custom automation when adding/removing always-on protection. Seems technically very viable to me, I jus t bring up these details because I feel like without a ton of effort VRF redirection can be made to be nearly as performant as longest prefix match. While we run MPLS, currently all of our customers/transit are in the global table. I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone into an L3VPN; it's awfully big change I don't want to rush into especially for this proof of concept but I'd like to hear opinions if that's the best solution to this specific problem. I'm not sure it's fundamentally different than creating a customerVRF, seems like I just need to separate the customers from the internet ingress. My gut says "the best" thing to do is to create a customerVRF but it feels a bit complicated as I have to worry about things like BGP/static/direct and will
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Tue, Apr 02, 2024 at 07:43:01PM +0300, Alexandre Snarskii via juniper-nsp wrote: > On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp wrote: > > Hi! > > Workaround that we're using (not elegant, but working): setup a > "self-pointing" routes to directly connected destinations: > > set routing-options static route A.B.C.D/32 next-hop A.B.C.D Forgot to note one thing: these self-pointing routes shall have preference of 200 (or anytning more than BGP's 170): set routing-options static route A.B.C.D/32 next-hop A.B.C.D set routing-options static route A.B.C.D/32 preference 200 so, in case when traffic shall be diverted to scrubbing, bgp route will be active in inet.0 and static route will be active in cleanL3VPN: s...@rt1.ov.spb> show route A.B.C.D/32 inet.0: ... + = Active Route, - = Last Active, * = Both A.B.C.D/32 *[BGP/170] 00:06:33, localpref 100 AS path: 65532 I, validation-state: unverified > to Scrubbing via ae3.232 [Static/200] 00:02:22 > to A.B.C.D via ae3.200 cleanL3VPN.inet.0: + = Active Route, - = Last Active, * = Both A.B.C.D/32 *[Static/200] 00:02:22 > to A.B.C.D via ae3.200 and the corresponding forwarding entry: Routing table: default.inet [Index 0] Internet: Destination: A.B.C.D/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: Scrubbing Next-hop type: unicast Index: 2971 Reference: 6 Next-hop interface: ae3.232 RPF interface: ae3.200 RPF interface: ae3.232 Destination: A.B.C.D/32 Route type: destination Route reference: 0 Route interface-index: 431 Multicast RPF nh index: 0 P2mpidx: 0 Flags: none Nexthop: 0:15:17:b0:e6:f8 Next-hop type: unicast Index: 2930 Reference: 3 Next-hop interface: ae3.200 RPF interface: ae3.200 [...] Routing table: cleanL3VPN.inet [Index 6] Internet: Destination: A.B.C.D/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 0:15:17:b0:e6:f8 Next-hop type: unicast Index: 2930 Reference: 3 Next-hop interface: ae3.200 > > and export these to cleanL3VPN. Resulting forwarding-table: > > Routing table: default.inet [Index 0] > Internet: > > Destination: A.B.C.D/32 > Route type: user > Route reference: 0 Route interface-index: 0 > Multicast RPF nh index: 0 > P2mpidx: 0 > Flags: sent to PFE, rt nh decoupled > Nexthop: 0:15:17:b0:e6:f8 > Next-hop type: unicast Index: 2930 Reference: 4 > Next-hop interface: ae3.200 > RPF interface: ae3.200 > > [...] > > Routing table: cleanL3VPN.inet [Index 6] > Internet: > > Destination: A.B.C.D/32 > Route type: user > Route reference: 0 Route interface-index: 0 > Multicast RPF nh index: 0 > P2mpidx: 0 > Flags: sent to PFE, rt nh decoupled > Nexthop: 0:15:17:b0:e6:f8 > Next-hop type: unicast Index: 2930 Reference: 4 > Next-hop interface: ae3.200 > > Unfortunately, we found no way to provision such routes via BGP, > so you have to have all those in configuration :( > > If there is a better workaround, I'd like to know it too :) > > > > Hi there, > > > > We're a US research and education ISP and we've been tasked for coming up > > with an architecture to allow on premise DDoS scrubbing with an appliance. > > As a first pass I've created an cleanL3VPN routing-instance to function as > > a clean VRF that uses rib-groups to mirror the relevant parts of inet.0. > > It is in production and is working great for customer learned BGP routes. > > It falls apart when I try to protect a directly attached destination that > > has a mac address in inet.0. I think I understand why and the purpose of > > this message is to see if anyone has been in a similar situation and has > > thoughts/advice/warnings about alternative designs. > > > > To explain what I see, I noticed that mac address based nexthops don't seem > > to be copied from inet.0 into cleanL3VPN.inet.0. I assume this means that > > mac-address based forwarding must be referencing inet.0 [see far below]. > > This obviously creates a loop once the best path in inet.0 becomes a BGP > > /32. For example when I'm announcing a /32 for 1.2.3.4 out of a locally > > attached 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent > > to 5.
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp wrote: Hi! Workaround that we're using (not elegant, but working): setup a "self-pointing" routes to directly connected destinations: set routing-options static route A.B.C.D/32 next-hop A.B.C.D and export these to cleanL3VPN. Resulting forwarding-table: Routing table: default.inet [Index 0] Internet: Destination: A.B.C.D/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 0:15:17:b0:e6:f8 Next-hop type: unicast Index: 2930 Reference: 4 Next-hop interface: ae3.200 RPF interface: ae3.200 [...] Routing table: cleanL3VPN.inet [Index 6] Internet: Destination: 87.245.206.15/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE, rt nh decoupled Nexthop: 0:15:17:b0:e6:f8 Next-hop type: unicast Index: 2930 Reference: 4 Next-hop interface: ae3.200 Unfortunately, we found no way to provision such routes via BGP, so you have to have all those in configuration :( If there is a better workaround, I'd like to know it too :) > Hi there, > > We're a US research and education ISP and we've been tasked for coming up > with an architecture to allow on premise DDoS scrubbing with an appliance. > As a first pass I've created an cleanL3VPN routing-instance to function as a > clean VRF that uses rib-groups to mirror the relevant parts of inet.0. It > is in production and is working great for customer learned BGP routes. It > falls apart when I try to protect a directly attached destination that has a > mac address in inet.0. I think I understand why and the purpose of this > message is to see if anyone has been in a similar situation and has > thoughts/advice/warnings about alternative designs. > > To explain what I see, I noticed that mac address based nexthops don't seem > to be copied from inet.0 into cleanL3VPN.inet.0. I assume this means that > mac-address based forwarding must be referencing inet.0 [see far below]. > This obviously creates a loop once the best path in inet.0 becomes a BGP /32. > For example when I'm announcing a /32 for 1.2.3.4 out of a locally attached > 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 > as the nexthop correctly, arrives in cleanL3VPN which decides to forward to > 5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see > below], cleanL3VPN Is dependent on inet.0 for resolution. Even if I could > copy inet.0 mac addresses into cleanL3VPN, eventually the mac address would > age out of inet.0 because the /32 would no longer be directly connected. If > I want to be able to protect locally attached destinations so I think my > design is unworkable, I think my solutions are > > = use flowspec redirection to dirty VRF, keep inet.0 as clean and use > flowspec interface filter-group appropriately on backbone interfaces > [routing-options flow interface-group exclude, which I already have deployed > correctly]. This seems easy but is less performant. > = put my customers into a customerVRF and deal with route leaking between > global and customerVRF. This is a well-known tactic but more complicated to > approach and disruptive to deploy as I have to airlift basically all the > customers to into a VRF to have full coverage. > > For redirection, to date I've been looking at longest prefix match solutions > due to the presumed scalability vs using flowspec. I have an unknown amount > of "always on" redirects I might be asked to entertain. 10? 100? 1000? I'm > trying to come up with a solution that doesn't rely on touching the routers > themselves. I did think about creating a normal [non flowspec] input > firewall term on untrusted interfaces that redirects to dirty VRF based in a > single destination prefix-list and just relying on flowspec for on demand > stuff with the assumption one firewall term with let's say 1000 prefixes is > more performant than 1000 standalone flowspec rules. I think my solution is > fundamentally workable but I don't think the purchased turnkey ddos > orchestration is going to natively interact with our Junipers, so that is > looked down upon, since it would require " a router guy " or writing custom > automation when adding/removing always-on protection. Seems technically very > viable to me, I j us > t bring up these details because I feel like without a ton of effort VRF > redirection can be made to be nearly as performant as longest prefix match. > > While we run MPLS, currently all of our customers/transit are in the global > table. I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone > into an L3VPN; it's awfully big change I don't want to rush into especially > for this proof of concept bu
[j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
Hi there, We're a US research and education ISP and we've been tasked for coming up with an architecture to allow on premise DDoS scrubbing with an appliance. As a first pass I've created an cleanL3VPN routing-instance to function as a clean VRF that uses rib-groups to mirror the relevant parts of inet.0. It is in production and is working great for customer learned BGP routes. It falls apart when I try to protect a directly attached destination that has a mac address in inet.0. I think I understand why and the purpose of this message is to see if anyone has been in a similar situation and has thoughts/advice/warnings about alternative designs. To explain what I see, I noticed that mac address based nexthops don't seem to be copied from inet.0 into cleanL3VPN.inet.0. I assume this means that mac-address based forwarding must be referencing inet.0 [see far below]. This obviously creates a loop once the best path in inet.0 becomes a BGP /32. For example when I'm announcing a /32 for 1.2.3.4 out of a locally attached 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 as the nexthop correctly, arrives in cleanL3VPN which decides to forward to 5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see below], cleanL3VPN Is dependent on inet.0 for resolution. Even if I could copy inet.0 mac addresses into cleanL3VPN, eventually the mac address would age out of inet.0 because the /32 would no longer be directly connected. If I want to be able to protect locally attached destinations so I think my design is unworkable, I think my solutions are = use flowspec redirection to dirty VRF, keep inet.0 as clean and use flowspec interface filter-group appropriately on backbone interfaces [routing-options flow interface-group exclude, which I already have deployed correctly]. This seems easy but is less performant. = put my customers into a customerVRF and deal with route leaking between global and customerVRF. This is a well-known tactic but more complicated to approach and disruptive to deploy as I have to airlift basically all the customers to into a VRF to have full coverage. For redirection, to date I've been looking at longest prefix match solutions due to the presumed scalability vs using flowspec. I have an unknown amount of "always on" redirects I might be asked to entertain. 10? 100? 1000? I'm trying to come up with a solution that doesn't rely on touching the routers themselves. I did think about creating a normal [non flowspec] input firewall term on untrusted interfaces that redirects to dirty VRF based in a single destination prefix-list and just relying on flowspec for on demand stuff with the assumption one firewall term with let's say 1000 prefixes is more performant than 1000 standalone flowspec rules. I think my solution is fundamentally workable but I don't think the purchased turnkey ddos orchestration is going to natively interact with our Junipers, so that is looked down upon, since it would require " a router guy " or writing custom automation when adding/removing always-on protection. Seems technically very viable to me, I jus t bring up these details because I feel like without a ton of effort VRF redirection can be made to be nearly as performant as longest prefix match. While we run MPLS, currently all of our customers/transit are in the global table. I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone into an L3VPN; it's awfully big change I don't want to rush into especially for this proof of concept but I'd like to hear opinions if that's the best solution to this specific problem. I'm not sure it's fundamentally different than creating a customerVRF, seems like I just need to separate the customers from the internet ingress. My gut says "the best" thing to do is to create a customerVRF but it feels a bit complicated as I have to worry about things like BGP/static/direct and will lose addPath [I recently discovered add-path and route-target are mutually exclusive in JunOS]. My gut says "the quickest" and least disruptive thing to do is to go the flowspec/filter route and frankly I'm beginning to lean that way since I'm already partially in production and needed to have a solution 5 days ago to this problem :> I've done all of these things before [flowspec, rib leaking] I think it's just a matter of trying to figure out the next best step and was looking to see if anyone has been in a similar situation and has thoughts/advice/warnings. I'm talking about IPv4 below but I ack IPv6 is a thing and I would just do the same solution. -Michael ===/=== @$myrouter> show route forwarding-table destination 1.2.3.4 extensive Apr 02 08:39:10 Routing table: default.inet [Index 0] Internet: Destination: 1.2.3.4/32 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0
