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

On 24/09/2023 at 4:18:23 AM, Mark Tinka via cisco-nsp <
[email protected]> wrote:

> This is different from how Junos does it, where import/export maps can
> be used without having to explicitly define the RT in the VRF.
>

Further than that, in JunOS if you define an RT in a VRF with an
export/import policy it has no effect.

Import/export RT is just a shortcut for creating and applying a policy if
no other policy exists.
It doesn’t (so far as I am aware) do anything else behind the scenes.

I have seen this catch out folks in the past, who either expected it to
pre-filter like Cisco, or expected it to permit RTs additional to the
policy.


Cisco have always been like this, where the VRF import/export RTs are an
additional layer of policy. I wonder if they see some performance benefit.
Perhaps in XR RPL where it would maybe be more difficult to generate a list
of expected RTs? It would certainly make it a lot faster to generate the
list of RTs to advertise with rtfilter - though given that’s only at config
commit time perhaps it’s not a big deal.

It means that policy in Cisco can be shorter, which is nice I suppose.

--
Nathan Ward
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/