-
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
[frr 8.5.1] orphan routes with bgp suppress-fib-pending #15626
Comments
So, as I understand you have this issue when |
Yes please actually post the configuration and the exact sequence of events you used to generate this situation. There is absolutely not enough information here to do anything useful with this data. |
below is the configuration, there is a T1 device, upstream peers are 4 T2, and downstream peers are 20 T0. Current configuration: |
repro steps: check the advertised routes to T0 from T1. they are same. Step 2. withdraw 50 routes from all 4 T2s, check from T1 for recieved routes and advertised routes, the expectation is that both should be empty, but it is not. there are 4 orphans. admin@str3-7260cx3-acs-14: |
below is our debug logs from bgpd for withdraw procedure, from our observation, the last step for deletes routes should be sending out UPDATE withdraw to it's neighbor, for but orphan routes, it doesn't. and we also notice that right before sending UPDATE withdraw, it should be group_announce_route_walkcb to check the routes, but orphan routes, it doesn't, we suspect there are some timing issues when bgp suppress-fib-pending enabled. Mar 27 14:34:45.889657 str3-7260cx3-acs-14 DEBUG bgp#bgpd[52]: [PCFFM-WMARW] 10.0.0.1(Unknown) rcvd UPDATE wlen 5 attrlen 0 alen 0 |
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.
Description
On FRR 8.5.1, one router setup bgp sessions with four neighbors, to announce / withdraw same routes from all four neighbors, there are orphan routes left after withdraw all routes.
Version
How to reproduce
Set up a topology with 4 upstream and one down stream peers in a different ASN. Have all 4 upstream peers advertise / withdraw the same 50 routes to the device.
Then, check the advertised to for the down stream peer, some orphan routes lefted.
with this config disabled, the issue is gone.
bgp suppress-fib-pending
Expected behavior
after announce / withdraw from upstream peers, no routes advertised to downstream peer.
Actual behavior
some orphan routes left, and still advertised to down stream peer. and if check from received routes, there is nothing.
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: