Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
On Thu, Apr 04, 2024 at 04:15:03PM +, Michael Hare wrote: > Alexandre, > > Thanks for your emails. I finally got around to trying it myself; > it definitely works! I first "broke" my A.B.C.D destination and =then= > added a static. When I reproduced this, instead of putting the static > route into inet.0 I chose to install in my cleanVRF, which gets around > the admin distance issues. Any reason you install the routes in global > instead of cleanVRF that I'm overlooking? I guess you have not only static A.B.C.D/32 but also covering direct A.B.C.0/24 in your cleanVRF ? Looks like I just overlooked that with the help of imported direct route I'll be able to resolve /32 into mac in VRF (not yet tested, but shall work). > I'm curious to know how safe it is to rely on working in the future. > How long have you been using this trick? Trick with self-pointing routes is from the times when there were no 'vrf-table-label' option in routing instances (there were no other option to provide VRF access without CE-router). Trick with redistributing them into cleanVRF is used since 2018 or something like. > I'll probably follow up with our Juniper support channels, as Saku > suggests, maybe something even better can come out of this. > > Thanks again, > -Michael > > =/ > > @# run show route A.B.C.D > > inet.0: 933009 destinations, 2744517 routes (932998 active, 0 holddown, 360 > hidden) > + = Active Route, - = Last Active, * = Both > > A.B.C.D/32 *[BGP/170] 00:24:03, localpref 100, from 2.3.4.5 > AS path: I, validation-state: unverified > > to 5.6.7.8 via et-0/1/10.3099 > > cleanVRF.inet.0: 319 destinations, 1179 routes (318 active, 0 holddown, 1 > hidden) > Limit/Threshold: 5000/4000 destinations > + = Active Route, - = Last Active, * = Both > > > > A.B.C.D/32 *[Static/5] 00:07:36 > > to A.B.C.D via ae17.3347 > > @# run show route forwarding-table destination A.B.C.D > Routing table: default.inet > Internet: > DestinationType RtRef Next hop Type IndexNhRef Netif > A.B.C.D/32 user 0indr 1048588 3 > 5.6.7.8 ucst 981 5 et-0/1/10.3099 > A.B.C.D/32 dest 0 0:50:56:b3:4f:fe ucst 1420 3 ae17.3347 > > Routing table: cleanVRF.inet > > > Internet: > DestinationType RtRef Next hop Type IndexNhRef Netif > A.B.C.D/32 user 0 0:50:56:b3:4f:fe ucst 1420 3 ae17.3347 > > > -Original Message- > > From: Alexandre Snarskii > > Sent: Tuesday, April 2, 2024 12:20 PM > > To: Michael Hare > > Cc: juniper-nsp@puck.nether.net > > Subject: 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 inter
Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
Alexandre, Thanks for your emails. I finally got around to trying it myself; it definitely works! I first "broke" my A.B.C.D destination and =then= added a static. When I reproduced this, instead of putting the static route into inet.0 I chose to install in my cleanVRF, which gets around the admin distance issues. Any reason you install the routes in global instead of cleanVRF that I'm overlooking? I'm curious to know how safe it is to rely on working in the future. How long have you been using this trick? I'll probably follow up with our Juniper support channels, as Saku suggests, maybe something even better can come out of this. Thanks again, -Michael =/ @# run show route A.B.C.D inet.0: 933009 destinations, 2744517 routes (932998 active, 0 holddown, 360 hidden) + = Active Route, - = Last Active, * = Both A.B.C.D/32 *[BGP/170] 00:24:03, localpref 100, from 2.3.4.5 AS path: I, validation-state: unverified > to 5.6.7.8 via et-0/1/10.3099 cleanVRF.inet.0: 319 destinations, 1179 routes (318 active, 0 holddown, 1 hidden) Limit/Threshold: 5000/4000 destinations + = Active Route, - = Last Active, * = Both A.B.C.D/32 *[Static/5] 00:07:36 > to A.B.C.D via ae17.3347 @# run show route forwarding-table destination A.B.C.D Routing table: default.inet Internet: DestinationType RtRef Next hop Type IndexNhRef Netif A.B.C.D/32 user 0indr 1048588 3 5.6.7.8 ucst 981 5 et-0/1/10.3099 A.B.C.D/32 dest 0 0:50:56:b3:4f:fe ucst 1420 3 ae17.3347 Routing table: cleanVRF.inet Internet: DestinationType RtRef Next hop Type IndexNhRef Netif A.B.C.D/32 user 0 0:50:56:b3:4f:fe ucst 1420 3 ae17.3347 > -Original Message- > From: Alexandre Snarskii > Sent: Tuesday, April 2, 2024 12:20 PM > To: Michael Hare > Cc: juniper-nsp@puck.nether.net > Subject: 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 expo
Re: [j-nsp] ifstrace log filling up with debug output
Hi Joerg, On 23-Mar-24 15:24, Joerg Staedele via juniper-nsp wrote: Hi, No traceoptions ... and meanwhile i've tested even with no configuration and after a zeroize it also does the same. I guess it’s a bug. I will try another version (maybe some 19.x) And I believe it will be the same because ifstraced daemon is enabled by default on SMP systems (for a while already) How much data do you get in your logs? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
