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.h...@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-boun...@puck.nether.net> On Behalf Of
> > Saku Ytti via juniper-nsp
> > Sent: Wednesday, April 3, 2024 1:58 AM
> > To: Mark Tinka <mark@tinka.africa>
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
> >
> > On Wed, 3 Apr 2024 at 09:45, Saku Ytti <s...@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@puck.nether.net
> > https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/junip
> > er-nsp__;!!Mak6IKo!JQJvgDK7yNf4-
> > 3MbfcDkWHvNajBUNxt3ZAC3DefzEkRkebYhpy3c7RX5em7pvvTJZrdrNKw79P
> > QweWqGaJdIwLpkAng$
--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
