Hi everyone, I wanted to bring attention to an issue that affects ovn-bgp-agent deployments after upgrading to newer versions of the iproute2 package. Problem: In newer iproute2 package versions, the default rt_tables file has been moved from /etc/iproute2/rt_tables to /usr. This change was introduced as part of iproute2's move to a "stateless" configuration pattern where configuration files are read from /etc first, falling back to /usr if they don't exist. You can see the related iproute2 commit here: https://github.com/iproute2/iproute2/commit/0a0a8f12fa1b03dd0ccbebf5f85209d1... When iproute2 is upgraded on Rocky Linux (and other RHEL-based systems), if /etc/iproute2/rt_tables was modified, it gets moved to /etc/iproute2/rt_tables.rpmsave and the original file isn't recreated. See https://access.redhat.com/solutions/7123966 for more details. I suspect Debian-based systems have the same issue. The ovn-bgp-agent has a hard requirement on /etc/iproute2/rt_tables existing, which causes it to fail with a FileNotFoundError when it attempts to read the file: FileNotFoundError: [Errno 2] No such file or directory: '/etc/iproute2/rt_tables' The error occurs in ensure_routing_table_for_bridge() when the agent tries to check for existing routing table entries for bridges. Proposed Solution: I've proposed a fix that ensures the /etc/iproute2/rt_tables file exists before attempting to read it. The solution: 1. Creates a new privileged function ensure_routing_tables_file() that: - Creates the /etc/iproute2/ directory if it doesn't exist - Copies the default rt_tables file from /usr/share/iproute2/rt_tables to /etc/iproute2/rt_tables if the latter doesn't exist 2. Calls this function before reading rt_tables in ensure_routing_table_for_bridge() This approach maintains backward compatibility while handling the new iproute2 package structure gracefully. Bug Report: https://bugs.launchpad.net/ovn-bgp-agent/+bug/2141421 Proposed Patch: https://review.opendev.org/c/openstack/ovn-bgp-agent/+/976242 Has anyone else hit this issue? We didn't find any upstream fix for it yet, so we'd appreciate feedback on the patch. Thanks, Max