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

[Mark Tinka]

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.