Jira (FACT-1907) facter 3.12.2 choses wrong ip as main ip

[Tim Meusel (JIRA)]

Tim Meusel created an issue

Facter / FACT-1907 facter 3.12.2 choses wrong ip as main ip Issue Type: Bug Assignee: Unassigned Created: 2019/01/23 1:43 PM Priority: Normal Reporter: Tim Meusel Hi people, I did some debugging with Eric Sorenson on slack about this. I have a server with multiple ip addresses on a single interface. One address is considered the main address. This one is persistant and always present. the others are floating ips.they might be added/removed during runtime. The setup at the moment: # facter -p networking.interfaces.enp5s0.ip 10.254.4.100 # facter -p networking.ip 10.254.4.100 # facter --version 3.12.2 # ip -4 a s dev enp5s0 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 10.254.4.100/32 scope global enp5s0 valid_lft forever preferred_lft forever inet 10.254.4.103/32 scope global enp5s0 valid_lft forever preferred_lft forever inet 10.254.4.17 peer 10.254.4.1/32 scope global enp5s0 valid_lft forever preferred_lft forever # ip -4 r s default via 10.254.4.1 dev enp5s0 proto static 10.254.4.1 dev enp5s0 proto kernel scope link src 10.254.4.17 # The system run Archlinux, the addresses are configured via systemd-networkd. I consider 10.254.4.17 as the main ip address. This is the only static ip address and used as source in the routing table. In my opinion this should be the identifier for the primary address. A long long time ago, I can still remember... this system was configured with puppet4+facter2. The fact ipaddress was written into multiple templates, this was 10.254.4.17. That's why I know for sure, that something changed and facter now detects a different ip as main ip. The box was also rebooted in the past. One thought was that facter simply uses the first configured ip on the interface as main ip. I don't know if the ordering was different in the past. Eric assumed that maybe facter expects a source address at the default route. I tried that: # ip -4 route replace default via 10.254.4.1 dev enp5s0 src 10.254.4.17 # ip -4 r s default via 10.254.4.1 dev enp5s0 src 10.254.4.17 10.254.4.1 dev enp5s0 proto kernel scope link src 10.254.4.17 # facter -p networking.ip 10.254.4.100 facter -p networking: { "networking": { "domain": "REMOVED", "fqdn": "REMOVED", "hostname": "REMOVED", "interfaces": { "enp5s0": { "bindings": [ { "address": "10.254.4.100", "netmask": "255.255.255.255", "network": "10.254.4.100" }, { "address": "10.254.4.103", "netmask": "255.255.255.255", "network": "10.254.4.103" }, { "address": "10.254.4.17", "netmask": "255.255.255.255", "network": "10.254.4.17" } ], "bindings6": [ { "address": "REMOVED", "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "network": "REMOVED" }, { "address": "fe80::ae16:2dff:fea4:fde", "netmask": "ffff:ffff:ffff:ffff::", "network": "fe80::" } ], "ip": "10.254.4.100", "ip6": "REMOVED", "mac": "ac:16:2d:a4:0f:de", "mtu": 1500, "netmask": "255.255.255.255", "netmask6": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "network": "10.254.4.100", "network6": "REMOVED" }, "lo": { "bindings": [ { "address": "127.0.0.1", "netmask": "255.0.0.0", "network": "127.0.0.0" } ], "bindings6": [ { "address": "::1", "netmask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "network": "::1" } ], "ip": "127.0.0.1", "ip6": "::1", "mtu": 65536, "netmask": "255.0.0.0", "netmask6": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "network": "127.0.0.0", "network6": "::1" } }, "ip": "10.254.4.100", "ip6": "REMOVED", "mac": "ac:16:2d:a4:0f:de", "mtu": 1500, "netmask": "255.255.255.255", "netmask6": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "network": "10.254.4.100", "network6": "REMOVED", "primary": "enp5s0" } } I'm not sure if https://tickets.puppetlabs.com/browse/FACT-1282 is related. Please let me know if you need more debugging information. Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Branan Riley (JIRA)]

Branan Riley commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip The intent is definitely that Facter picks up the "global" IP from the default route. I think we may only pick up the interface from that, and we don't have a good heuristic for determining which IP on an interface is the "main" one. We can probably fix that to actually pick up the IP from the default route, and use info from the routing table to determine which IP from each interface to report as the "main" binding.

Add Comment

[Branan Riley (JIRA)]

Branan Riley updated an issue

Facter / FACT-1907

facter 3.12.2 choses wrong ip as main ip

Change By: Branan Riley Labels: networking

Add Comment

[Branan Riley (JIRA)]

Branan Riley updated an issue

Facter / FACT-1907 facter 3.12.2 choses wrong ip as main ip

Change By: Branan Riley Team: Platform OS

Add Comment

[Tim Meusel (JIRA)]

Tim Meusel commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip As a workaround, I would be totally fine by reconfigering the network so facter the detects the correct ip address again, but I've no idea how facter would like to have it. Are you able to figure out how facter detects it by reading the code? I failed

Add Comment

[Branan Riley (JIRA)]

Branan Riley commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip

We determine the primary interface from the routing table at https://github.com/puppetlabs/facter/blob/master/lib/src/facts/linux/networking_resolver.cc#L223 We then use the primary interface to set the ipaddress fact at https://github.com/puppetlabs/facter/blob/master/lib/src/facts/resolvers/networking_resolver.cc#L233-L236 In all cases where we use add, it means that the first value added is the one that ends up being used (redundant add}}s with the same key are ignored) I believe this will mean we'll always use the top address returned by {{ip

Add Comment

[Sigbjorn Lie (JIRA)]

Sigbjorn Lie commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip

I was just discussing a facter issue with Tim Meusel Slack, and he pointed me to this ticket. We use keepalived for both IPv4 and IPv6 addresses. "facter -p ipaddress" returns the correct IPv4 address for the system, however "facter -p ipaddress6" returns the vrrp_instance virtual IP address set by keepalived.   "ip -4 addr" returns the systems IP address as the first ip address in the list, the keepalived vrrp_instance ipv4 address is listed as the second address.   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet DELETED/24 brd DELETED scope global eth0 valid_lft forever preferred_lft forever inet DELETED/32 scope global eth0 valid_lft forever preferred_lft forever     "ip -6 addr" returnes the keepalived vrrp_instance ipv6 address as the first ip address in the list. The keepalived address has a netmask of /128 and the "deprecated nodad" flags set. Is is still chosen as the global ipv6 address of the system.   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 DELETED:ff/128 scope global deprecated nodad valid_lft forever preferred_lft 0sec inet6 DELETED::aa/64 scope global   It seem like we are hit by this issue, and a fix would be greatly appreciated. Please let me know if further information is required to resolve this issue.

Add Comment

[Thore Bödecker]

Thore Bödecker commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip

Hey, I've just hit this issue as well. Scenario: Hypervisor with RFC1918 node addresses for internal infrastructure, but with additional public IPv4 addresses assigned to the uplink interface for various SNAT use-cases for the virtual machines. As soon as the first public address is added to "eth0", facter will use that one and mess up all following templates and configs (e.g. zabbix agent ListenIP, nginx listen) and put the public address there. That is definitely not what I want. In my case facter should be able to retrieve the "uplink" address by looking at the routing table: root@hv02 ~ # ip -4 a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

inet 1.2.3.4/32 scope global eth0 valid_lft forever preferred_lft forever inet 10.92.27.11 peer 10.92.27.1/32 scope global eth0 valid_lft forever preferred_lft forever   root@hv02 ~ # ip -4 r s default via 10.92.27.1 dev eth0 proto static 10.92.27.1 dev eth0 proto kernel scope link src 10.92.27.11 (The public address has been masked as "1.2.3.4" here) By resolving the default route to gateway address and source addresses it is possible to find the actual "primary" / "uplink" ip address. Would be great if we could get a fix for this.

Add Comment

[Adam Winberg (Jira)]

Adam Winberg commented on FACT-1907

Re: facter 3.12.2 choses wrong ip as main ip

We just hit this with RHEL9 - we use dhcp as source for our primary ip and then add secondary ip's as static configuration via Puppet. In newer versions of NetworkManager the static configurations have higher priority than dhcp addresses which results in facter using the wrong ip to set for example 'ip', 'netmask' and 'network' facts. https://access.redhat.com/solutions/6961919 To make sure that our dhcp address is used as primary address in routing we therefore have had to set the netmask to '/32' for our secondary addresses. This solves the routing problem (i.e. outgoing traffic uses wrong source ip) but the facter facts are still wrong since the 'ip addr' output puts the statically configured addresses above the primary (dhcp) address.

Add Comment

This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)