-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EVPN route type does not match route map #14419
Comments
I tested with #14599, and I can't reproduce it with 9.0.1, and/or the master version... |
Could you also show the libyang packet version installed on your system? |
2.1.80-1~deb12u1 |
Then not related to libyang, this version is not affected. |
Hi, I think it's related again to route-map optimization. on 8.4.4, it's working with the below config: after 7603eca, i's not working with or without disabling optimization (so maybe we have 2 bugs here) here an example with a l3vni 10000 in vrf vrf_evpn, announce a default 0.0.0.0 type-5 route
a default type-5 is announced, but it should be filtered. (on frr 8.4.4, it's correctly filtered)
|
I finish to bisect it, |
I think I have a clue, Using my same config but filtering with a prefix-list,
before 272c6d5 and for "match evpn", this is the reverse. could it be related to
? so we can't use "match evpn" anymore ? I'm adding issue about prefix-list filtering |
|
…match "match evpn" in route-map is broken since 8.5.0 FRRouting/frr#14419 the patch FRRouting/frr@272c6d5 is converting type-2 && type-5 evpn routes to prefix-prefix. (fixing prefix-list not working previously, but breaking "match evpn") So, simply use prefix-list now, as "match epvn" was a workaround anyway. reported on the forum, where user have routing loop between the 2 exit-nodes: https://forum.proxmox.com/threads/sdn-with-evpn-controller-routing-loop-when-using-multiple-exit-nodes.137362/ Signed-off-by: Alexandre Derumier <[email protected]>
* simple topology with 2 routers doing BGP EVPN for type 5 routes * r1 is advertising 3 EVPN Type-5 routes, outbound route-map filters on each prefix with a different matcher * evpn matchers don't work as shown in the test
Hello @ton31337 , I tested your topotest and indeed it works. However I defined a new topotest with type-5 evpn routes, and tested several evpn matchers ( Here is my topotest if you want to test it by yourself: Good news is that the |
* simple topology with 2 routers doing BGP EVPN for type 5 routes * r1 is advertising 3 EVPN Type-5 routes, outbound route-map filters on each prefix with a different matcher * evpn matchers don't work as shown in the test
* simple topology with 2 routers doing BGP EVPN for type 5 routes * r1 is advertising 3 EVPN Type-5 routes, outbound route-map filters on each prefix with a different matcher * evpn matchers don't work as shown in the test
thanks @ton31337 I'll have a look today |
@ton31337 I confirm it works fine now, thanks a lot! |
FRR 8.5.1 doesn't support `match evpn vni` because of FRRouting/frr#14419
Backport based on comment #18669 (comment) Why I did it Fix the below FRR issues FRRouting/frr#14419 FRRouting/frr#13792
Why I did it Upgrading FRR 8.5.4 to include latest fixes. Work item tracking Microsoft ADO (number only): How I did it New patches that were added: Patch FRR Pull request Issue fixed 0024-lib-use-snmp-s-large-fd-sets-for-agentx.patch FRRouting/frr#13396 FRRouting/frr#14143 0025-bgp-community-memory-leak-fix.patch FRRouting/frr#15466 FRRouting/frr#15459 0026-bgp-fib-suppress-announce-fix.patch FRRouting/frr#15634 FRRouting/frr#15626 0027-lib-Do-not-convert-EVPN-prefixes-into-IPv4-IPv6-if-n.patch FRRouting/frr#15418 FRRouting/frr#14419 Removed patches: Patch Upstream FRR commit that is present in 8.5.4 0019-zebra-Abstract-dplane_ctx_route_init-to-init-route-w.patch FRRouting/frr@3f01977 0020-zebra-Fix-crash-when-dplane_fpm_nl-fails-to-process-.patch FRRouting/frr@fe5f624 0022-bgpd-Don-t-read-the-first-byte-of-ORF-header-if-we-a.patch FRRouting/frr@3515178 0023-bgpd-Make-sure-we-have-enough-data-to-read-two-bytes.patch FRRouting/frr@460ee93 0024-bgpd-Do-not-process-NLRIs-if-the-attribute-length-is.patch FRRouting/frr@f291f1e 0025-bgpd-Use-treat-as-withdraw-for-tunnel-encapsulation-.patch FRRouting/frr@8a4a88c 0026-zebra-Add-encap-type-when-building-packet-for-FPM.patch FRRouting/frr@f0f7b28 0028-bgpd-Check-mandatory-attributes-more-carefully-for-U.patch FRRouting/frr@21418d6 0029-bgpd-Handle-MP_REACH_NLRI-malformed-packets-with-ses.patch FRRouting/frr@30b5c2a 0030-bgpd-Treat-EOR-as-withdrawn-to-avoid-unwanted-handli.patch FRRouting/frr@01f232c 0031-bgpd-Ignore-handling-NLRIs-if-we-received-MP_UNREACH.patch FRRouting/frr@a0c4ec2 0032-zebra-Fix-fpm-multipath-encap-addition.patch FRRouting/frr@10a9a5f Realigned patches: Old Patch New patch 0005-Add-support-of-bgp-l3vni-evpn.patch 0005-Add-support-of-bgp-l3vni-evpn.patch 0021-zebra-remove-duplicated-nexthops-when-sending-fpm-msg.patch 0019-zebra-remove-duplicated-nexthops-when-sending-fpm-msg.patch 0027-zebra-Fix-non-notification-of-better-admin-won.patch 0020-zebra-Fix-non-notification-of-better-admin-won.patch Disable-ipv6-src-address-test-in-pceplib.patch 0021-Disable-ipv6-src-address-test-in-pceplib.patch cross-compile-changes.patch 0022-cross-compile-changes.patch 0033-zebra-The-dplane_fpm_nl-return-path-leaks-memory.patch 0023-zebra-The-dplane_fpm_nl-return-path-leaks-memory.patch How to verify it Running sonic-mgmt test suite.
Describe the bug
When using expression
match evpn route-type
no route matches.There are no problems in versions below 8.5.3.
To Reproduce
Checking the route:
Expected behavior
Screenshots
Versions
The text was updated successfully, but these errors were encountered: