On 9/27/23 13:23, Nathan Ward wrote:
In JunOS you can’t use regexes or wildcards for “target:” communities.
You can use wildcards in IOS-XR RT sets - so if your RPL has something
like the following, without defining the RTs you care about in the
VRF, you’ll generate a bunch of rtfilter[1] routes.
Perhaps it could optimise and generate rtfilter routes using prefix
lengths other than 0 and 96 - though I’ve never actually tested that
before, so I’d be wary of how well it is implemented… :-)
route-policy make-lots-of-rtfilter-routes
if extcommunity rt matches-any (64496:*) then
pass
else
drop
endif
end-policy
IOS-XR has a more complex language than JunOS for policy, too. Without
the above being an issue, it feels like jumping through parameterised
RPL could make it pretty difficult to figure out all the possible RTs
you might want to accept. Noting that communities can be built up from
parameters.
Impossible? No. More difficult? Yeah.
If sticking all the possible RTs in a VRF definition is the cost of
getting RPL, I think that’s a fair trade.
I recall IOS and IOS XE also had a number of options with which you
could create RT permutations.
As with IOS XR, a lot of them seem nice-to-have, for us anyway, in the
context of where the Internet is today.
I’m a Juniper guy mostly, but, RPL is pretty good I’ve got to admit.
I think it's a bit over-the-top, but that's just me :-).
--
Nathan Ward
[1] I have forgotten what Cisco calls constrained route distribution.
rtfilter is a JunOS term and is what I call it. From memory vendors
all call it different things.
RTC (Route Target Constraint), as defined in RFC 4684.
I looked into implementing it back in 2008, but decided it wasn't worth
the effort for the network I was engineering at the time.
Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
