Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Any updates on this FRR issue?
Just a reminder that this impacts an OpenShift component. The workaround imposes temporary network dataplane disruption.
Hi Carlos,
sorry I had to move to other stuff before actually coming up with the solution here. I was thinking of using the PR that you issued for upstream as a solution in RHEL8 and wait for anything the upstream comes up with but here it seems they don't have this on their radar at this point.
I think that for RHEL8 we could use the solution that you provided but it needs a little tweak in the code as well. The frr-reload.py script is a bit simple in a way that it takes differences in the config and applies them to the running config. Your suggestion works great with the latest version but version of FRR in RHEL8 has a problem when printing the bfd information. It leaves out the part with 'neighbor PEER bfd':
if (!CHECK_FLAG(bfd_info->flags, BFD_FLAG_PARAM_CFG)
&& (bfd_info->type == BFD_TYPE_NOT_CONFIGURED)) {
vty_out(vty, " neighbor %s bfd", addr); <<----here it should be separated by \n
if (bfd_info->profile[0])
vty_out(vty, " profile %s", bfd_info->profile); <<---- neighbor <peer> bfd should be here.
vty_out(vty, "\n");
}
I am fixing this part with my patch, it has worked for me so far.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (frr bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7560
Description of problem: Despite the user's desire to disable BFD altogether, the reloader is just unsetting the custom BFD profile falling back to the default built-in profile. Version-Release number of selected component (if applicable): FRR 7.5 How reproducible: 100% Steps to Reproduce: 1. Create an FRR configuration with a BGP router and a BFD profile associated to it: [...] router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 bfd profile bfd-profile-1 [...] 2. Verify the running configuration: $ sudo vtysh -c 'show running-config' [...] router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 bfd neighbor 10.0.0.1 bfd profile bfd-profile-1 [...] 3. Copy the initial FRR configuration file (step 1) and delete the "bfd profile" line: [...] router bgp 65000 neighbor 10.0.0.1 remote-as 65000 [...] 4. Apply the new FRR configuration using the FRR reloader script: $ /usr/lib/frr/frr-reload.py --reload --stdout frr.conf.wanted.7.5 [...] router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 bfd [...] 2022-02-14 10:02:39,023 INFO: Called via "Namespace(bindir='/usr/bin', confdir='/etc/frr', daemon='', debug=False, filename='frr.conf.wanted.7.5', input=None, log_level='info', overwrite=False, pathspace=None, reload=True, rundir='/var/run/frr', stdout=True, test=False, test_reset=False, vty_socket=None)" 2022-02-14 10:02:39,024 INFO: Loading Config object from file frr.conf.wanted.7.5 2022-02-14 10:02:39,294 INFO: Loading Config object from vtysh show running 2022-02-14 10:02:39,561 INFO: Executed "no bfd" 2022-02-14 10:02:39,694 INFO: Executed "bfd no profile my_bfd_profile" 2022-02-14 10:02:39,827 INFO: Executed "router bgp 65000 no neighbor 10.0.0.1 bfd" 2022-02-14 10:02:39,960 INFO: Executed "router bgp 65000 no neighbor 10.0.0.1 bfd profile my_bfd_profile" 2022-02-14 10:02:39,960 INFO: Loading Config object from vtysh show running Actual results: # vtysh -c 'show running-config' Building configuration... Current configuration: [...] router bgp 65000 no bgp suppress-duplicates neighbor 10.0.0.1 remote-as 64512 neighbor 10.0.0.1 bfd <------------------- [...] Expected results: BFD should not be enabled on the 10.0.0.1 BGP neighbor. Additional info: Issue reproducible on FRR 7.5 (RHEL 8.4, CentOS 8 Stream) and FRR 8.1 (community RPM builds).