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.
Bug 1402610 - ebtables or ebtables_filter kernel module does not load automatically with RHEL 7.3
Summary: ebtables or ebtables_filter kernel module does not load automatically with RH...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ebtables
Version: 7.3
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Thomas Woerner
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2016-12-08 00:07 UTC by Shail
Modified: 2021-09-09 12:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-21 19:39:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Shail 2016-12-08 00:07:11 UTC
ebtables or ebtables_filter kernel module does not load automatically with RHEL 7.3. Even when the module is loaded manually bridges were not created. Issue seen with ebtables-2.0.10-15.el7.x86_64. This affects LinuxBridge/VXLAN and LinuxBridge/VLAN based OpenStack deployment and none of the bridges are created

Version-Release number of selected component (if applicable):
7.3
Linux j10-buildnode 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
consistent

Steps to Reproduce:
1. Deploy RHEL7.3
2. Deploy OpenStack LB/VXLAN
3. Launch VM
4. No DHCP IP addresses get allocated to the VM

Actual results: Following message is observed in /var/log/neutron/neutron-linuxbridge-agent.log logs:
--
2016-12-07 04:17:10.631 27 ERROR neutron.agent.linux.utils [req-fcfad3e1-7dea-43df-a04a-54f2d8687c55 - - - - -]
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ebtables', '-L']
Exit code: 255
Stdin:
Stdout:
Stderr: The kernel doesn't support the ebtables 'filter' table.
--

Expected results:
The functionality should not break upgrading the ebtables RPM

Additional info:
Downgrading to ebtables-2.0.10-13.el7.x86_64 fixes the issue where bridges were created and VM were assigned IP addresses in OpenStack setup

Comment 2 Thomas Woerner 2016-12-08 15:31:02 UTC
Are there errors or AVCs in the logs?

Comment 3 Ajay Kalambur 2016-12-08 18:14:09 UTC
Does not work even with ebtables-2.0.10-13.el7.x86_64

looks like ebtables module is not autoloaded on RHEL 7.3

Comment 4 Shail 2016-12-08 20:02:15 UTC
with RHEL7.3, ebtables and ebtable_filter module are not loaded by default. Is this behavior changed with RHEL7.3? After, manually loading both these modules using "modprobe", the OpenStack VMs are getting DHCP IP addresses.

No errors (related to ebtable) are reported in /var/log/messages or  /var/log/audit/audit.log

Comment 5 Shail 2016-12-08 20:24:00 UTC
In RHEL7.2, upon running LinuxBridge agent, both kernel modules ebtables and ebtable_filter gets automatically loaded

In RHEL7.3, upon running LinuxBridge agent, none of the kernel modules ebtables and ebtable_filter get automatically loaded which is breaking the LB functionality. Is this expected change in behavior with RHEL7.3?

Comment 7 Thomas Woerner 2016-12-14 09:27:25 UTC
As the issue also appears with ebtables-2.0.10-13.el7.x86_64 which has been part of RHEL-7.0, this can not be an ebtables package problem.

This seems to be an issue with systemd-module-load.

Reassigning to systemd.

Comment 12 Lukáš Nykrýn 2017-03-09 10:43:27 UTC
can you post here content of:
/etc/modules-load.d/
/usr/lib/modules-load.d/

Comment 13 David Hill 2017-03-27 15:03:05 UTC
Nothing is in those folders.  Should there be something?

Comment 16 Kyle Walker 2017-04-19 13:46:27 UTC
Good morning,

I don't believe that the systemd-module-load is the source of the behaviour here. The ebtables modules are ordinarily loaded in the context of firewalld initialization, but that shouldn't really matter. On a default Server installation, if we print the parentage of the loading process within the "module_load()" function call within the kernel, we get:

 swapper/0[0]
  -> systemd[1]
   -> firewalld[688]
    -> modprobe[734] "/sbin/modprobe ebtables" - 0x0: ebtables


However, when the firewall is disabled, the first "ebtables -L" should result in the ebtables modules being loaded:

  # lsmod | grep ebtables

  # ebtables -L
  [  541.205414] Ebtables v2.0 registered
  Bridge table: filter

  Bridge chain: INPUT, entries: 0, policy: ACCEPT

  Bridge chain: FORWARD, entries: 0, policy: ACCEPT

  Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

  # lsmod | grep ebtables
  ebtables               35009  1 ebtable_filter


This is due to the ebtables library including a module loading subroutine:

  char *ebt_modprobe;
  /* Try to load the kernel module, analogous to ip_tables.c */
  int ebtables_insmod(const char *modname)
  {
        char *buf = NULL;
        char *argv[3];

        /* If they don't explicitly set it, read out of /proc */
        if (!ebt_modprobe) {
                buf = get_modprobe();
                if (!buf)
                        return -1;
                ebt_modprobe = buf; /* Keep the value for possible later use */
        }

        switch (fork()) {
        case 0:
                argv[0] = (char *)ebt_modprobe;
                argv[1] = (char *)modname;
                argv[2] = NULL;
                execv(argv[0], argv);

                /* Not usually reached */
                exit(0);
        case -1:
                return -1;

        default: /* Parent */
                wait(NULL);
        }

        return 0;
  }


Would it be possible to gather an strace of the "ebtables -L" command that is failing in the end environment?

  # strace -Tttfv -o /tmp/ebtables.strace ebtables -L

- Kyle Walker


Note You need to log in before you can comment on or make changes to this bug.