[c-nsp] Extended Route Target Community Bug - Solved!
Nathan Ward
cisco-nsp at daork.net
Sat Sep 23 21:43:42 EDT 2023
On 24/09/2023 at 4:18:23 AM, Mark Tinka via cisco-nsp <
cisco-nsp at puck.nether.net> 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
More information about the cisco-nsp
mailing list