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/
