[c-nsp] Extended Route Target Community Bug - Solved!
Mark Tinka
mark at tinka.africa
Thu Sep 28 00:11:29 EDT 2023
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.
More information about the cisco-nsp
mailing list