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

Facter 3 improperly recognizes 0.0.0.0/X (X != 0) as default routes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: FACT 3.1.0, FACT 3.4.0
    • Fix Version/s: FACT 3.1.7
    • Component/s: Community
    • Labels:
      None
    • Template:
    • Story Points:
      1
    • Sprint:
      Client 2016-04-20
    • Release Notes Summary:
      Hide
      Before this fix, 'facter ipaddress' could return the address of the wrong network interface when there are routes for 0.0.0.0, with non-zero subnet mask, in addition to the default route. The correct ip address is the address of the interface associated with the interface on the route table entry for the default gateway.
      Show
      Before this fix, 'facter ipaddress' could return the address of the wrong network interface when there are routes for 0.0.0.0, with non-zero subnet mask, in addition to the default route. The correct ip address is the address of the interface associated with the interface on the route table entry for the default gateway.

      Description

      Facter tries to determine the primary network interface by looking for the "default" route.

      However, it will decide that a route is "default" based solely on the destination network address being 0.0.0.0. It's perfectly legitimate to have a route to 0.0.0.0 that is not a default route. What makes a default route is a destination of 0.0.0.0 and a netmask of 0.0.0.0.

      My use case:

      I have a server that is in a private (RFC1918) network. Its primary network interface (bond0) talks to that private network via one router, but needs to talk to the Internet via a second router on a VLAN interface (bond0.300).

      Originally, this was set up with a very simple routing table:
      0.0.0.0/0 → Internet on dev bond0.300
      10.0.0.0/8 → Private on dev bond0
      172.16.0.0/12 → Private on dev bond0
      192.168.0.0/16 → Private on dev bond0

      However, this causes Facter to decide that the primary network interface is bond0.300 with all the associated settings, which breaks our Hiera configurations and puppet-controlled network setup.

      So I changed the routing table so that the default route went to bond0. This means every network besides the private RFC1918 networks now needs a direct route out through bond0.300:

      0.0.0.0/0 → Private on dev bond0
      0.0.0.0/5 → Internet on dev bond0.300
      8.0.0.0/7 → Internet on dev bond0.300
      10.0.0.0/8 skipped to be routed to the private network
      11.0.0.0/8 → Internet on dev bond0.300
      12.0.0.0/6 → Internet on dev bond0.300
      16.0.0.0/4 → Internet on dev bond0.300
      32.0.0.0/3 → Internet on dev bond0.300
      etc

      I expected Facter to find the correct default route. It didn't. It turns out this is due to two related facts:
      1 Facter looks for any route with a destination of 0.0.0.0 no matter what netmask it uses.
      2 Linux (at least, RHEL 6) sorts /proc/net/route from most specific to least specific, so the default route will always be last.

      So even with the complicated (34 line) routing table to catch everything except the RFC1918 networks, Facter is still finding the wrong primary interface.

      The solution is, in networking_resolver::get_primary_interface, to check both parts[1] == boost::as_literal("00000000") and parts[7] == boost::as_literal("00000000"). (And, by the way, so that you're not trapped if the columns change, you really should look at the first line to identify the Destination and Mask columns).

      I will be submitting a pull request for this shortly after I complete this ticket.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            JohnsonEarls Johnson Earls
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Zendesk Support