Dear forum !
I have a strange behavior regarding the EVPN route exchange between two PE (PE1 and PE2) in DC1. I have a iBGP sessions between two PE that share the same CE connectivity. Those two PE are connected to other PE on other DC2 (PE3 and PE4). The two PE play the role of anycast gateway. I have some vlans (vlan 102 and 202) that are shared between the DC and some other vlan that didn’t (vlan 101 and 201).
So the design is to use a global and auto route-target for all the vlan that are shared between the two DC and a specific route-target for the vlan that are local to each DC.
#
## The configuration on PE1 is :
#
admin@PE1# show protocols evpn
encapsulation vxlan;
extended-vni-list [ 101 102 201 202 301 302 ];
multicast-mode ingress-replication;
default-gateway advertise;
vni-options {
vni 101 {
vrf-target export target:11:101;
}
vni 201 {
vrf-target export target:11:201;
}
}
admin@PE1# show switch-options
service-id 1;
vtep-source-interface lo0.0;
route-distinguisher 10.118.51.104:1;
vrf-import [ IMPORT-DC1-VNI IMPORT-ALL-VNI REJECT-ANY ];
vrf-target {
target:65000:0;
auto;
}
{master:0}[edit]
admin@PE1# show policy-options
policy-statement IMPORT-ALL-VNI {
term ALL {
from community EVPN-MATCH-GLOBAL;
then accept;
}
}
policy-statement IMPORT-DC1-VNI {
term DC1 {
from community EVPN-MATCH-DC1;
then accept;
}
}
policy-statement REJECT-ANY {
then reject;
}
community EVPN-GLOBAL members target:65000:0;
community EVPN-MATCH-DC1 members target:11:.*;
community EVPN-MATCH-DC1-V101 members target:11:101;
community EVPN-MATCH-DC1-V201 members target:11:201;
community EVPN-MATCH-DC2 members target:22:.*;
community EVPN-MATCH-GLOBAL members target:65000:.*;
#
## The PE2 configuration is:
#
admin@PE2# show protocols evpn
encapsulation vxlan;
extended-vni-list [ 101 102 201 202 301 302 ];
multicast-mode ingress-replication;
default-gateway advertise;
vni-options {
vni 101 {
vrf-target export target:11:101;
}
vni 201 {
vrf-target export target:11:201;
}
}
admin@PE2# show switch-options
service-id 1;
vtep-source-interface lo0.0;
route-distinguisher 10.118.51.105:1;
vrf-import [ IMPORT-DC1-VNI IMPORT-ALL-VNI REJECT-ANY ];
vrf-target {
target:65000:0;
auto;
}
admin@PE# show policy-options
policy-statement IMPORT-ALL-VNI {
term ALL {
from community EVPN-MATCH-GLOBAL;
then accept;
}
}
policy-statement IMPORT-DC1-VNI {
term DC1 {
from community EVPN-MATCH-DC1;
then accept;
}
}
policy-statement REJECT-ANY {
then reject;
}
community EVPN-GLOBAL members target:65000:0;
community EVPN-MATCH-DC1 members target:11:.*;
community EVPN-MATCH-DC1-V101 members target:11:101;
community EVPN-MATCH-DC1-V201 members target:11:201;
community EVPN-MATCH-DC2 members target:22:.*;
community EVPN-MATCH-GLOBAL members target:65000:.*;
But that doesn't work. Actually whaterver I configure on my vrf-import policy, it doesn't accept or reject anything. It's like there is no manual overwrite with the "auto"
In my case I'm supposed to receive some prefix that PE2 send to PE1 with the community target:11:101 :
#
## What PE2 Send to PE1
#
admin@PE2> show route advertising-protocol bgp 10.118.51.104 community-name EVPN-MATCH-DC1 extensive default-switch.evpn.0: 94 destinations, 94 routes (94 active, 0 holddown, 0 hidden) [...] // output truncated * 2:10.118.51.105:1::101::4c:16:fc:3e:fd:04/304 (1 entry, 1 announced)
BGP group VXLAN-OVERLAY type Internal
Route Distinguisher: 10.118.51.105:1
Route Label: 101
ESI: 00:00:00:00:00:00:01:01:00:00
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65000] I
Communities: target:11:101 encapsulation0:0:0:0:vxlan [...] // output truncated
#
## What PE1 Receive from PE2 (no route with community target:11:X
#
admin@PE1> show route receive-protocol bgp 10.118.51.105 extensive community-name EVPN-MATCH-DC1 inet.0: 37 destinations, 39 routes (37 active, 0 holddown, 0 hidden) :vxlan.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) bgp.evpn.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) default-switch.evpn.0: 52 destinations, 52 routes (52 active, 0 holddown, 0 hidden) __default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
admin@PE1> show route receive-protocol bgp 10.118.51.105 extensive | match target:
Communities: target:65000:268435558 encapsulation0:0:0:0:vxlan
Communities: target:65000:268435558 encapsulation0:0:0:0:vxlan
Communities: target:65000:268435558 encapsulation0:0:0:0:vxlan evpn-default-gateway
Communities: target:65000:268435658 encapsulation0:0:0:0:vxlan
Communities: target:65000:268435658 encapsulation0:0:0:0:vxlan evpn-default-gateway
Communities: target:65000:268435757 encapsulation0:0:0:0:vxlan
Communities: target:65000:268435757 encapsulation0:0:0:0:vxlan evpn-default-gateway
Communities: target:65000:268435758 encapsulation0:0:0:0:vxlan
Communities: target:65000:268435758 encapsulation0:0:0:0:vxlan evpn-default-gateway
[...] // output truncated
#
## BGP traceoptions gave me
#
BGP RECV 10.118.51.105+179 -> 10.118.51.104+53283 Jul 26 15:31:37.373780 BGP RECV message type 2 (Update) length 108 Jul 26 15:31:37.373785 BGP RECV Update PDU length 108 Jul 26 15:31:37.373791 BGP RECV flags 0x40 code Origin(1): IGP Jul 26 15:31:37.373798 BGP RECV flags 0x40 code ASPath(2) length 0: <null> Jul 26 15:31:37.373803 BGP RECV flags 0x40 code LocalPref(5): 100 Jul 26 15:31:37.373811 BGP RECV flags 0xc0 code Extended Communities(16): 2:11:101 30c:0:0:0:0:0:8 Jul 26 15:31:37.373818 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 25/70 Jul 26 15:31:37.373827 BGP RECV nhop 10.118.51.105 len 4 Jul 26 15:31:37.373851 BGP RECV 2:10.118.51.105:1::101::4c:16:fc:3e:fd:04::192.168.101.11/304 (label 101) (esi 00:00:00:00:00:00:01:01:00:00) Jul 26 15:31:37.373872 bgp_should_merge_as2_and_as4_path():2111 AS4-Peer 10.118.51.105 (Internal AS 65000)(RECV): No merge of as-paths required as the peer is 4 byte as capable Jul 26 15:31:37.373879 bgp_process_aspath_and_aggr_attr():2603 AS4-Peer 10.118.51.105 (Internal AS 65000)(RECV): bgp_should_merge_as2_and_as4_path() says NO Jul 26 15:31:37.373886 bgp_process_aspath_and_aggr_attr():2640 AS4-Peer 10.118.51.105 (Internal AS 65000)(RECV): Merged asp: path_len 0, path_seg_len 0, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0 Jul 26 15:31:37.373910 bgp_rcv_nlri: Peer 10.118.51.105 (Internal AS 65000) Jul 26 15:31:37.373924 bgp_rcv_nlri: 2:10.118.51.105:1::101::4c:16:fc:3e:fd:04::192.168.101.11/304 Jul 26 15:31:37.373956 bgp_rcv_nlri: 2:10.118.51.105:1::101::4c:16:fc:3e:fd:04::192.168.101.11/304 rejected due to the lack of a valid target community Jul 26 15:31:37.373968 bgp_read_v4_message: done with 10.118.51.105 (Internal AS 65000) received 108 octets 1 update 1 route
As you can see the community is with the format "evpn-route-type:community-value" (here 2:11:101) and not "target:community-value" (should be target:11:101)...
Any idea ? Should I open the case because regarding this link (https://www.juniper.net/documentation/en_US/junos/topics/example/vrf-target-auto-manual.html) the policy is based on community fomat "target:community-value"
When I use a configuration with the community-value of "2:11:101" it works, and when I use "2:11:.*" it doesn't !
Hardware : QFX10K
Junos : 15.1X53-D63.9
--
Salah