Original Message:
Sent: 04-24-2025 03:49
From: Chris Mendoza
Subject: L3VPN/VRF Help
Thanks Oliver.
So if the policy will treat the below as an "AND" logic...
community VPRN_700_Community members [ target:11.11.11.11:700 target:22.22.22.22:700 target:44.44.44.44:700 target:55.55.55.55:700 target:66.66.66.66:700 ]
Then it should not match anything because all the routes only have one community in them and nothing should appear in the bgp.l3vpn.0 route table at all? And that's what threw me off, I thought it was treating it as an "OR" logic.
This was the output when the community was configured as shown above.
cmendoza@vMX_R3> show route table bgp.l3vpn.0 detail
bgp.l3vpn.0: 20 destinations, 40 routes (20 active, 0 holddown, 0 hidden)
11.11.11.11:700:10.11.15.0/24 (2 entries, 0 announced) ---> But this did not appear in the vprn_700.inet.0 table
*BGP Preference: 170/-101
Route Distinguisher: 11.11.11.11:700
Next hop type: Indirect
Address: 0x9683d84
Next-hop reference count: 12
Source: 11.11.11.11
Next hop type: Router
Next hop: 10.2.3.2 via ge-0/0/2.1, selected
Label-switched-path to_R1
Label operation: Push 524285, Push 524276(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 524285: None; Label 524276: None;
Session Id: 0x0
Protocol next hop: 11.11.11.11
Label operation: Push 524285
Label TTL action: prop-ttl
Load balance label: Label 524285: None;
Indirect next hop: 0x9710330 - INH Session ID: 0x0
State: <Active Int Ext ProtectionPath ProtectionCand>
Local AS: 65000 Peer AS: 65000
Age: 8:40 Metric2: 40
Validation State: unverified
Task: BGP_65000.11.11.11.11+49989
AS path: I
Communities: target:11.11.11.11:700 --> Only one community
Import Accepted
VPN Label: 524285
Localpref: 100
Router ID: 11.11.11.11
Is it possible that when matching on the bgp.l3vpn.0 table is uses the "OR" logic but when it comes installing the bgp.l3vpn.0 to the vprn_700.inet.0 table it uses the "AND" logic?
Doing further experiment, I deleted the community target:11.11.11.11:700
[edit policy-options community VPRN_700_Community]
cmendoza@vMX_R3# delete members target:11.11.11.11:700
[edit policy-options community VPRN_700_Community]
cmendoza@vMX_R3# show
members [ target:22.22.22.22:700 target:55.55.55.55:700 target:66.66.66.66:700 ];
cmendoza@vMX_R3> show route table bgp.l3vpn.0 community target:11.11.11.11:700
bgp.l3vpn.0: 10 destinations, 20 routes (10 active, 0 holddown, 0 hidden) --> nothing
cmendoza@vMX_R3>
While the routes from community target:22.22.22.22:700 are still present cant help but say that looks to be an "OR" logic to me.
cmendoza@vMX_R3> show route table bgp.l3vpn.0 community target:22.22.22.22:700
bgp.l3vpn.0: 10 destinations, 20 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
22.22.22.22:700:10.2.13.0/24
*[BGP/170] 00:32:12, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
[BGP/170] 00:32:12, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
So even though the vrf import policy is for the importing of routes into the VRF table it also affects bgp vpnv4/inet-vpn routes reception from remote PE routers.
(Side note: is my statement correct that the bgp.l3vpn.0 are the vpnv4/inet-vpn routes received from the remote/other PE?)
------------------------------
Chris Mendoza
Original Message:
Sent: 04-24-2025 02:35
From: Olivier Benghozi
Subject: L3VPN/VRF Help
In a policy term, when you match several community-lists , it's a logical OR between each community-list.
In a policy term, when you match a community-list containing several communities, it's a logical AND inside the community-list (all the values must be present at the same time in order to match).
It's documented here: https://www.juniper.net/documentation//us/en/software/junos/bgp/topics/topic-map/routing-policies-communities.html#id-understanding-bgp-communities-extended-communities-and-large-communities-as-routing-policy-ma
When more than one value is assigned to a community name, the routing device interprets this as a logical AND of the community values.
...and here: https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/policy-configuring-match-conditions-in-routing-policy-terms.html
match community: Matches the name of one or more communities. If you list more than one name, only one name needs to match for a match to occur. (The matching is effectively a logical OR operation.)
------------------------------
Olivier Benghozi
Original Message:
Sent: 04-23-2025 10:56
From: Chris Mendoza
Subject: L3VPN/VRF Help
Hi Dmitriy,
So I did as you suggested.
I created separate community names for each community.
community target:11.11.11.11:700 members target:11.11.11.11:700;
community target:22.22.22.22:700 members target:22.22.22.22:700;
community target:44.44.44.44:700 members target:44.44.44.44:700;
community target:55.55.55.55:700 members target:55.55.55.55:700;
community target:66.66.66.66:700 members target:66.66.66.66:700;
And separated the communities in their respective term numbers.
policy-statement VPRN_700_Policy {
term 1 {
from community target:11.11.11.11:700;
then accept;
}
term 2 {
from community target:22.22.22.22:700;
then accept;
}
term 4 {
from community target:44.44.44.44:700;
then accept;
}
term 5 {
from community target:55.55.55.55:700;
then accept;
}
term 6 {
from community target:66.66.66.66:700;
then accept;
}
term REJECT {
then reject;
}
}
And guess what, I can now see all the routes in the vprn_700.inet.0 which I did not see before.
cmendoza@vMX_R3> show route table vprn_700.inet.0
vprn_700.inet.0: 22 destinations, 42 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.13.0/24 *[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
10.4.7.0/24 *[BGP/170] 00:14:13, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
[BGP/170] 00:14:13, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
10.4.10.0/24 *[BGP/170] 00:14:13, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
[BGP/170] 00:14:13, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
10.5.12.0/24 *[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R5
[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R5
10.10.10.10/32 *[BGP/170] 00:14:13, MED 11, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
[BGP/170] 00:14:13, MED 11, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
10.11.15.0/24 *[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
10.15.15.15/32 *[BGP/170] 00:29:16, MED 2, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, MED 2, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
10.16.16.16/32 *[BGP/170] 00:29:16, MED 2, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
[BGP/170] 00:29:16, MED 2, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
10.17.17.17/32 *[BGP/170] 00:29:16, MED 3, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, MED 3, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
10.18.18.18/32 *[BGP/170] 00:29:16, MED 3, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
[BGP/170] 00:29:16, MED 3, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
10.66.16.0/24 *[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
10.115.117.0/24 *[BGP/170] 00:29:16, MED 2, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, MED 2, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
10.116.118.0/24 *[BGP/170] 00:29:16, MED 2, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
[BGP/170] 00:29:16, MED 2, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
12.12.12.12/32 *[BGP/170] 00:29:16, MED 11, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R5
[BGP/170] 00:29:16, MED 11, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R5
13.13.13.13/32 *[BGP/170] 00:29:16, MED 2, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
[BGP/170] 00:29:16, MED 2, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R2
77.77.77.77/32 *[BGP/170] 00:14:13, MED 0, localpref 100, from 11.11.11.11
AS path: 700 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
[BGP/170] 00:14:13, MED 0, localpref 100, from 66.66.66.66
AS path: 700 I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R4
88.88.88.88/32 *[BGP/170] 01:09:19, MED 0, localpref 100
AS path: 800 I, validation-state: unverified
> to 192.168.30.2 via ge-0/0/5.700
192.168.1.0/24 *[BGP/170] 00:29:16, MED 0, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, MED 0, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
192.168.10.0/24 *[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.2.3.2 via ge-0/0/2.1, label-switched-path to_R1
192.168.30.0/24 *[Direct/0] 01:11:45
> via ge-0/0/5.700
[BGP/170] 01:09:19, MED 0, localpref 100
AS path: 800 I, validation-state: unverified
> to 192.168.30.2 via ge-0/0/5.700
192.168.30.1/32 *[Local/0] 01:11:47
Local via ge-0/0/5.700
192.168.60.0/24 *[BGP/170] 00:29:16, localpref 100, from 66.66.66.66
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
[BGP/170] 00:29:16, localpref 100, from 11.11.11.11
AS path: I, validation-state: unverified
> to 10.3.6.6 via ge-0/0/1.1, label-switched-path to_R6
And these same routes are now being advertised into the CE router R8...
RP/0/0/CPU0:XRv8#sho route bgp
Thu Apr 24 11:38:10.610 AEST
B 10.2.13.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.4.7.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.4.10.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.5.12.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.10.10.10/32 [20/0] via 192.168.30.1, 00:04:59
B 10.11.15.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.15.15.15/32 [20/0] via 192.168.30.1, 00:04:59
B 10.16.16.16/32 [20/0] via 192.168.30.1, 00:04:59
B 10.17.17.17/32 [20/0] via 192.168.30.1, 00:04:59
B 10.18.18.18/32 [20/0] via 192.168.30.1, 00:04:59
B 10.66.16.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.115.117.0/24 [20/0] via 192.168.30.1, 00:04:59
B 10.116.118.0/24 [20/0] via 192.168.30.1, 00:04:59
B 12.12.12.12/32 [20/0] via 192.168.30.1, 00:04:59
B 13.13.13.13/32 [20/0] via 192.168.30.1, 00:04:59
B 77.77.77.77/32 [20/0] via 192.168.30.1, 00:04:59
B 192.168.1.0/24 [20/0] via 192.168.30.1, 00:04:59
B 192.168.10.0/24 [20/0] via 192.168.30.1, 00:04:59
B 192.168.60.0/24 [20/0] via 192.168.30.1, 00:04:59
By the way, your version of the policy also works.
term 1 {
from community [ target:11.11.11.11:700 target:22.22.22.22:700 target:44.44.44.44:700 target:55.55.55.55:700 target:66.66.66.66:700 ];
then accept;
So these two versions below are treated differently, are you able to offer an explanation to this?
community VPRN_700_Community members [ target:22.22.22.22:700 target:44.44.44.44:700 target:55.55.55.55:700 target:66.66.66.66:700 target:11.11.11.11:700 ];
community target:11.11.11.11:700 members target:11.11.11.11:700;
community target:22.22.22.22:700 members target:22.22.22.22:700;
community target:44.44.44.44:700 members target:44.44.44.44:700;
community target:55.55.55.55:700 members target:55.55.55.55:700;
community target:66.66.66.66:700 members target:66.66.66.66:700;
Thanks by the way for answering my questions, this is really helping me with my learning with Juniper.
------------------------------
Chris Mendoza
Original Message:
Sent: 04-22-2025 10:17
From: Dmitriy
Subject: L3VPN/VRF Help
For Item 1
As I assumed, if you use import policy in your way, the policy tries to catch routes, which have all enumerated five communities.
That's why that output is empty.
vMX_R3> show route table bgp.l3vpn.0 community-name VPRN_700_Community
Please define the communities separately.
policy-statement VPRN_700_Policy_Import {
term 1 {
from community [ target:11.11.1.11:700 target:22.22.22.22:700 target:44.44.44.44:700 target:55.55.55.55:700 target:66.66.66.66:700 ];
then accept;
}
then reject;
}
community target:11.11.1.11:700 members target:11.11.1.11:700;
community target:22.22.22.22:700 members target:22.22.22.22:700;
community target:33.33.33.33:700 members target:33.33.33.33:700;
community target:44.44.44.44:700 members target:44.44.44.44:700;
community target:55.55.55.55:700 members target:55.55.55.55:700;
community target:66.66.66.66:700 members target:55.55.55.55:700;
Please also be familiar with an article:
https://www.networkcuriosity.com/junos-and-bgp-community-strings/
Your case in middle of the article.
------------------------------
WBW,
Dmitriy
Original Message:
Sent: 04-22-2025 08:49
From: Christopher Mark Mendoza
Subject: L3VPN/VRF Help
Hi Dmitriy,
Item 1
A little weird.
cmendoza@vMX_R3> show route table bgp.l3vpn.0 community-name VPRN_700_Community
bgp.l3vpn.0: 14 destinations, 28 routes (14 active, 0 holddown, 0 hidden) --> this is the whole output
cmendoza@vMX_R3>
But is this what you are looking for?
cmendoza@vMX_R3> show route table bgp.l3vpn.0 detail community target:44.44.44.44:700 | match Communities
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
Communities: target:44.44.44.44:700
cmendoza@vMX_R3>
Item 2
set routing-instances vprn_700 vrf-target export target:33.33.33.33:700 --> I thought this config works fine...because a remote PE and remote CE are receiving the 88.88.88.88/32 and 192.168.30.0/24 subnets, please see further down below.
And additionally I thought I can not advertise community using policy on "vrf-target export"
cmendoza@vMX_R3# set vrf-target export ?
Possible completions:
<export> Target community to use when marking routes on export
While the "vrf-export" allows export using policy
cmendoza@vMX_R3# set vrf-export ?
Possible completions:
<value> Export policy for VRF instance RIBs
( Open an expression
R3_Policy
Redist_eBGP_R8
VPRN_700_Policy
[ Open a set of values
evpn-pplb
For me the "vrf-target" is fine because I am only advertising one community and therefore there is no need for a policy. But I am more than willing to be corrected if I am wrong with these two observations.
Remote Nokia SROS PE
A:R4# show router bgp routes vpn-ipv4 community target:33.33.33.33:700
===============================================================================
BGP Router ID:44.44.44.44 AS:65000 Local AS:65000
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 33.33.33.33:700:88.88.88.88/32 100 0
33.33.33.33 None 120
800 16
*i 33.33.33.33:700:88.88.88.88/32 100 0
33.33.33.33 None 120
800 16
u*>i 33.33.33.33:700:192.168.30.0/24 100 None
33.33.33.33 None 120
No As-Path 16
*i 33.33.33.33:700:192.168.30.0/24 100 None
33.33.33.33 None 120
No As-Path 16
-------------------------------------------------------------------------------
Routes : 4
Remote Cisco IOS XR CE Router that connects to the above PE (R4)
RP/0/0/CPU0:XRv7#sho route bgp
Wed Apr 23 09:11:07.912 AEST
[some output omitted]
B 88.88.88.88/32 [20/0] via 10.4.7.4, 00:07:31
B 192.168.30.0/24 [20/0] via 10.4.7.4, 00:07:31
------------------------------
Christopher Mark Mendoza
Original Message:
Sent: 04-22-2025 07:21
From: Dmitriy
Subject: L3VPN/VRF Help
1) Your output of vMX_R3> show route table bgp.l3vpn.0 doesn't show any attached community on the inet-vpn routes without "detail" option.
With detail option it has so long outcome. That's why I asked to run the command vMX_R3>show route table bgp.l3vpn.0 community-name VPRN_700_Community to catch any routes with any community in the list VPRN_700_Community to be sure they present in the mp-bgp routing table.
2) Route 88.88.88.88/32 you receives from CE XR, but the route doesn't get into the table bgp.l3vpn.0 cause you have one incomprehensible line:
set routing-instances vprn_700 vrf-target export target:33.33.33.33:700
You shoud apply some kind of a route-policy for the export as well.
set routing-instances vprn_700 vrf-target export VRF-VPRN_700-Export
set policy policy-statement VRF-VPRN_700-Export term 1 from protocol direct then accept
set policy policy-statement VRF-VPRN_700-Export term 2 from protocol bgp then accept
------------------------------
WBW,
Dmitriy
Original Message:
Sent: 04-22-2025 06:54
From: Christopher Mark Mendoza
Subject: L3VPN/VRF Help
cmendoza@vMX_R3> show route table vprn_700.inet.0
vprn_700.inet.0: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
88.88.88.88/32 *[BGP/170] 2d 01:18:57, MED 0, localpref 100
AS path: 800 I, validation-state: unverified
> to 192.168.30.2 via ge-0/0/5.700
192.168.30.0/24 *[Direct/0] 2d 01:21:39
> via ge-0/0/5.700
[BGP/170] 2d 01:18:57, MED 0, localpref 100
AS path: 800 I, validation-state: unverified
> to 192.168.30.2 via ge-0/0/5.700
192.168.30.1/32 *[Local/0] 2d 01:21:39
Local via ge-0/0/5.700
cmendoza@vMX_R3>