EVPN-MPLS T1 Label lost

[murrant]

Description

I'm attempting to use FRR as a route reflector for our EVPN/MPLS/ISIS-SR network. It seems to be losing the label for type 1 circuits and sending 1048575 instead (binary 11111111111111111111).

Update received by FRR:

Update sent by FRR:

Version

FRRouting 9.1 (hv-reflector-vm) on Linux(5.15.0-97-generic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--enable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

How to reproduce

Set up EVPN-MPLS VPWS circuit on equipment with BGP peering and confirm functionality. Add FRR as route reflector and remove peering. The VPWS no long functions because the devices receive the wrong remote labels.

Expected behavior

Correct labels are sent.

Actual behavior

Labels are sent as 1048575

Additional context

Unclear if this is related to #7292 I have a packet capture with some moderately sensitive data (ASN) in it I can provide access to.

Checklist

• [X] I have searched the open issues for this bug.
• [X] I have not included sensitive information in this report.

[baldoarturo]

Can confirm I am able to reproduce this with a client We can provide PCAPs if needed

[murrant]

@baldoarturo If you can provide some PCAPs with generic data, that might help make it easier for someone to tackle this issue.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.

[murrant]

This issue still exists. Unfortunately, I do not have a lab to test it at this time.

[frrbot[bot]]

This issue will no longer be automatically closed.

[pguibert6WIND]

@murrant , do you have the evpn configuration to share, pls? for instance, ios xr config?

[pguibert6WIND]

https://github.com/FRRouting/frr/pull/17985 should help

[baldoarturo]

This is a sample config from a couple IP Infusion OcNOS boxes Using the same box as RR works as expected. With FRR we do see the missing label

evpn mpls enable
evpn mpls multihoming enable
evpn mpls vtep-ip-global 10.3.3.31

mac vrf EVPN-NE-VLAN250
 evpn-vlan-service vlan-based
 rd 10.3.3.31:250
 route-target both 65000:250

evpn mpls id 250
 host-reachability-protocol evpn-bgp EVPN-NE-VLAN250

interface po31
 description EVPN-MH-NE
 mtu 9216
 evpn multi-homed system-mac 0000.5e00.0001
!
interface po31.250 switchport
 description EVPN-MH-NE-VLAN250
 encapsulation dot1q 250
 mtu 9216
 access-if-evpn
  map vpn-id 250
!