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] ro
On 27/09/2023 at 4:15:31 PM, Mark Tinka wrote:
>
>
> On 9/24/23 03:43, Nathan Ward wrote:
>
> 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
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
On 24/09/2023 at 4:18:23 AM, Mark Tinka via cisco-nsp <
cisco-nsp@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
ex
So I eventually figured this out... for the router to apply the extended
community on inbound routes, one has to configure the export RT in the
VRF itself.
Originally, I had used only import and export maps, without defining the
RT explicitly in the VRF.
Turns out that even if you use import
Hi all.
I have a simple inbound route-map on a VPNv4 PE-CE BGP session that does
the below:
route-map TEST deny 10
match rpki invalid
!
route-map TEST permit 20
match ip address prefix-list test-in
set metric 0
set local-preference 120
set extcommunity rt 65200:5
!
route-map TEST deny 655
