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
