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

On 9/24/23 03:43, Nathan Ward wrote:

> 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.

Agreed - the Juniper option makes more sense to me, even though I first 
interacted with VRF's in IOS.


> 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.

My only assumption was that early versions of VRF implementation in IOS 
did not expect that operators would require more fine-grained use of 
import/export policies, and may just mostly rely on the RT defined in 
the VRF.


> Perhaps in XR RPL where it would maybe be more difficult to generate a 
> list of expected RTs?

Why would that be more difficult?


> 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.

I can't think of a reason why implementation in IOS XR would be more 
onerous.

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