Uploaded image for project: 'Facter'
  1. Facter
  2. FACT-2907

networking: add binding flags to bindings6 entries

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: FACT 4.2.0
    • Component/s: None
    • Template:
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      This release adds a new `flags` key under the `networking.interfaces.*.bindings6` fact which parses the lower 8-bit encoded flags from `/proc/net/if_inet6`. Note that the higher bit flags (managetempaddr, noprefixroute, mcautojoin, stableprivacy) are not yet supported/shown in the fact output. Feature contributed by community member b4ldr.
      Show
      This release adds a new `flags` key under the `networking.interfaces.*.bindings6` fact which parses the lower 8-bit encoded flags from `/proc/net/if_inet6`. Note that the higher bit flags (managetempaddr, noprefixroute, mcautojoin, stableprivacy) are not yet supported/shown in the fact output. Feature contributed by community member b4ldr.
    • QA Risk Assessment:
      Needs Assessment

      Description

      It would be nice if we could update the networking.$iface.bindings6 entries to also include binding flags. As an example given the following:

      % sudo ip -6 addr show dev en0 
      2: en0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
       link/ether aa:aa:bb:bb:cc:cc brd ff:ff:ff:ff:ff:ff
      inet6 2001:db8::aaaa:bbff:febb:cccc/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
      inet6 2001:db8::1/64 scope global
       valid_lft forever preferred_lft forever
      inet6 fe80::aaaa:bbff:febb:cccc/64 scope link
       valid_lft forever preferred_lft forever
      

      It would be nice to get the following facts

      'en0' => {
        'bindings6' => [
              {
                address => "2001:db8::aaaa:bbff:febb:cccc",
                netmask => "ffff:ffff:ffff:ffff::",
                network => "2620:0:861:103::"
                'scope' => "global"
                'flags' => ['mngtmpaddr', 'dynamic']
              },
              {
                address => "2001:db8::1",
                netmask => "ffff:ffff:ffff:ffff::",
                network => "2620:0:861:103::"
                'scope' => "global"
              },
              {
                address => "fe80::aaaa:bbff:febb:cccc",
                netmask => "ffff:ffff:ffff:ffff::",
                network => "fe80::"
                'scope' => "link"
              }
        ]
      

      The flags are useful when deciding which addresses to configure daemons to bind to. for instance i would not want a daemon to bind to any binding6 which has either the dynamic or temporary

      Further i think this could be used in determining the network.ip6 fact. for instance we have environment that have static ipv6 addresses as well as a SLAAC address. I think in this instance when there multiple bindings the ones which have flags of mngtmpaddr or dynamic should no be prefered as the primary. however (at least in our environment) the SLAAC address is prefered (see below)

      % sudo ip -6 addr show dev private                                             
      6: private: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
          inet6 2620:0:861:101:1a66:daff:fea3:af25/64 scope global mngtmpaddr dynamic 
             valid_lft 2591993sec preferred_lft 604793sec
          inet6 2620:0:861:101:10:64:0:245/64 scope global 
             valid_lft forever preferred_lft forever
          inet6 fe80::1a66:daff:fea3:af25/64 scope link 
             valid_lft forever preferred_lft forever
      

      % sudo facter -p networking.interfaces.private                                 
      {
        bindings => [
          {
            address => "10.64.0.245",
            netmask => "255.255.252.0",
            network => "10.64.0.0"
          }
        ],
        bindings6 => [
          {
            address => "2620:0:861:101:1a66:daff:fea3:af25",
            netmask => "ffff:ffff:ffff:ffff::",
            network => "2620:0:861:101::"
          },
          {
            address => "2620:0:861:101:10:64:0:245",
            netmask => "ffff:ffff:ffff:ffff::",
            network => "2620:0:861:101::"
          },
          {
            address => "fe80::1a66:daff:fea3:af25",
            netmask => "ffff:ffff:ffff:ffff::",
            network => "fe80::"
          }
        ],
        ip => "10.64.0.245",
        ip6 => "2620:0:861:101:1a66:daff:fea3:af25",
        mac => "18:66:da:a3:af:25",
        mtu => 1500,
        netmask => "255.255.252.0",
        netmask6 => "ffff:ffff:ffff:ffff::",
        network => "10.64.0.0",
        network6 => "2620:0:861:101::"
      }
      

      I previously mentioned this in FACT-2843

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            b4ldr john
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Zendesk Support