Hello @Jerems ,
thanks for the packet capture file. I have tried to open it in different wireshark versions with the same results you are showing.
Ref frame 9
There are two MPLS labels the packet comes from Cisco PE.
Actually the control word made of 00 00 then there are the destination MAC address, the source MAC address them there is the external 802.1Q with VLAN ID 0.
Then there is the internal 802.1Q header with VLAN ID 20.
if we look at a frame sourced by a Juniper source MAC address we see for frame n. 8 :
a single MPLS label for PHP occurring on the Juniper box in the path between the two PE nodes.
There is no control word !
After the single MPLS header there is the ethernet frame with single 802.1Q field with VLAN ID 20.
We can say the control plane is fine, but in the data plane the two PE ndoes are using different encapsulations as described above.
First of all there is the mismatch on the control word used by Cisco PE in sending its sourced frames not used by Juniper PE box.
In addition to this the Cisco PE is adding an 802.1Q tag with vlan id 0 before 802.1Q tag with vlan id 20.
Is this an inteoperability issue ? or one of the two devices is making something wrong ?
I have tried to search.
The reference RFC for EVPN based VPWS is RFC
https://datatracker.ietf.org/doc/rfc8214/
Now the RFC say that in the control plane in AF vpn vpws the field called Ethernet ID:
>>
For EVPN routes, the Ethernet Tag IDs are set to zero for port-based,
VLAN-based, and VLAN bundle interface mode and set to non-zero
Ethernet Tag IDs for VLAN-aware bundle mode. Conversely, for
EVPN-VPWS, the Ethernet Tag ID in the Ethernet A-D route MUST be set
to a non-zero value for all four service interface types
this is in the control plane in MP BGP NLRI AD route type.
For the data plane it says:
>>
For the EVPL
service, the Ethernet frames transported over an MPLS/IP network
SHOULD remain tagged with the originating VLAN ID (VID), and any VID
translation MUST be performed at the disposition PE. For the EPL
service, the Ethernet frames are transported as is, and the tags
are not altered
more in details in section 2.1 VLAN based service:
>>
n such scenarios, the Ethernet frames
Boutros, et al. Standards Track [Page 6]
RFC 8214 VPWS Support in EVPN August 2017
transported over an MPLS/IP network SHOULD remain tagged with the
originating VID, and a VID translation MUST be supported in the data
path and MUST be performed on the disposition PE
in section 2.2 for bundle vlan service type
>>
The transmitting PE can
cross-connect traffic from a group of VLANs on a specific port to the
MPLS label. The MPLS-encapsulated frames MUST remain tagged with the
originating VID.
For port level service section 2.2..1
>>
This service interface is a special case of the VLAN bundle service
interface, where all of the VLANs on the port are mapped to the same
VPWS service instance identifier. The procedures are identical to
those described in Section 2.2.
for VLAN aware service type section 2.3
Contrary to EVPN, in EVPN-VPWS this service interface maps to a
VLAN-based service interface (defined in Section 2.1); thus, this
service interface is not used in EVPN-VPWS. In other words, if one
tries to define data-plane and control-plane behavior for this
service interface, one would realize that it is the same as that of
the VLAN-based service
To be noted there is a variant of EVPN VPWS called seamless that allows to have a mix of VCs with legacy L2VPN VPWS and new EVPN VPWS for the same AC access circuit.
it is described in the following draft
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpws-seamless-00#name-data-plane-operations
It is supported in IOS XR
https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/l2vpn/711x/configuration/guide/b-l2vpn-cg-cisco8000-711x/evpn-virtual-private-wire-service.html
Hope to help
Giuseppe
