[c-nsp] Extended Route Target Community Bug - Solved!

[Mark Tinka]

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.