[j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Saku Ytti]

This might be grounds for a feature request to Juniper, if there isn't
already some magic toggle to MakeItGo.

But yeah, the forwarding-table looks suspect, as if it'll do table
lookup, and then will fail to discover the more-specific host-route,
and discard, as the ARP entries are not copied. And yeah Alexandres'
workaround seems like a cute way to force the host route into VRF, if
provisioning intensive.

I think two features would be nice to have

a) this to copy the arp/nd entries from inet to vrf (if not already possible)
b) feature to assign labels to each arp/nd host route, to avoid doing
egressPE lookup (this labeled route would only be imported to the
interface facing scrubber clean side, rest of the network sees the
unlabeled direct aggregate)

On Wed, 3 Apr 2024 at 17:04, Michael Hare <michael.hare at wisc.edu> wrote:
>
> Saku, Mark-
>
> Thanks for the responses.  Unless I'm mistaken, short of specifying a selective import policy, I think I'm already doing what Saku suggests, see relevant config snippet below.  Our clean VRF is L3VPN-4205.  But after I saw the lack of mac based next hops I started searching to see if there was a protocol other than direct that I wasn't aware of.  I intend to take a look at Alexandre's workaround to understand/test, just haven't gotten there yet.
>
> I was able to get FBF via dirtyVRF working quickly in the meantime while I figure out how to salvage the longest-prefix approach.
>
> -Michael
>
> ==/==
>
> @ # show routing-options | display inheritance no-comments
> ...
> interface-routes {
>     rib-group {
>         inet rib-interface-routes-v4;
>         inet6 rib-interface-routes-v6;
>     }
> }
> rib-groups {
>     rib-interface-routes-v4 {
>         import-rib [ inet.0 L3VPN-4205.inet.0 ];
>     }
> ...
>     rib-interface-routes-v6 {
>         import-rib [ inet6.0 L3VPN-4205.inet6.0 ];
>     }
> ...
> }
>
> > -----Original Message-----
> > From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of
> > Saku Ytti via juniper-nsp
> > Sent: Wednesday, April 3, 2024 1:58 AM
> > To: Mark Tinka <mark at tinka.africa>
> > Cc: juniper-nsp at puck.nether.net
> > Subject: Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
> >
> > On Wed, 3 Apr 2024 at 09:45, Saku Ytti <saku at ytti.fi> 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 at puck.nether.net
> > https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/junip
> > er-nsp__;!!Mak6IKo!JQJvgDK7yNf4-
> > 3MbfcDkWHvNajBUNxt3ZAC3DefzEkRkebYhpy3c7RX5em7pvvTJZrdrNKw79P
> > QweWqGaJdIwLpkAng$



-- 
  ++ytti