Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-5514

Set fb_tunnels_only_for_init_net=2 or fb_tunnels_only_for_init_net=1 by default for new deployments

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Node, RHEL CoreOS
    • None

      1. Proposed title of this feature request

      Set fb_tunnels_only_for_init_net=2 or fb_tunnels_only_for_init_net=1 by default for new deployments

      2. What is the nature and description of the request?

      When tunnel modules are loaded, the Linux kernel will create a corresponding default device in each namespace, with attributes local=any and remote=any. When receiving packets for the protocol in question, the kernel will forward them to the created tunnel interface as a fallback device if it can't find another device with matching local/remote attributes.

      This was the only available behavior in older versions of Linux until patches
      net: do not create fallback tunnels for non-default namespaces
      and
      net: add option to not create fall-back tunnels in root-ns as well
      made it possible to disable fallback interface creation system wide, or inside namespaces.

      For backwards compatibility, all versions of the Linux kernel use fb_tunnels_only_for_init_net=0 by default, and administrators must explicitly disable fallback tunnels. If no userspace application makes use of the default behavior, that is if all applications rely on the explicit creation of tunnels, fallback tunnels can safely be disabled.

      Creating these extra tunnels is an expensive operation. It is also not necessary and has no advantages nowadays. The current setup means that if a single container requests a tunnel interface, these fallback interfaces will be created in all other containers, breaking container isolation principles (an action in container a has an impact on container b).

      We should apply this change for new deployments only, not for upgrades, just in case.

      For further details, see: https://access.redhat.com/solutions/7069859

      3. Why does the customer need this? (List the business requirements here)

      We ran into this issue at a customer site where an application listed interfaces, and couldn't handle the presence of tunnel interfaces. The customer will likely fix their application. Nevertheless, the default behavior looks wrong to me.

      4. List any affected packages or components.

      RHCOS or Node

            gausingh@redhat.com Gaurav Singh
            akaris@redhat.com Andreas Karis
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: