Project

General

Profile

Bug #7405

FreeBSD bond interfaces lead to constant switching of primary interface

Added by Michael Moll about 5 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Network
Target version:
Difficulty:
Triaged:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

On FreeBSD bonding is called "link aggregation" and here is an example facter output for one such interface bundled with LACP (lagg0 = em0 + em1):

interfaces => em0,em1,lo0,lagg0
ipaddress => 192.168.200.11
ipaddress_lagg0 => 192.168.200.11
ipaddress_lo0 => 127.0.0.1
macaddress => 00:1e:67:15:02:79
macaddress_em0 => 00:1e:67:15:02:79
macaddress_em1 => 00:1e:67:15:02:79
macaddress_lagg0 => 00:1e:67:15:02:79

As the MAC address is the same on all those interfaces, I see a lot of audit logs which log the change of the primary interface of that host.


Related issues

Related to Foreman - Feature #7401: Add support for bond interfacesClosed2014-09-10
Related to Foreman - Tracker #2409: NetworkingNew

Related to Foreman - Refactor #7456: Extract primary interface from hostClosed2014-09-16

History

#1 Updated by Marek Hulán about 5 years ago

We don't detect bonds as virtual devices. This will be fixed by #7401.

#2 Updated by Marek Hulán about 5 years ago

  • Related to Feature #7401: Add support for bond interfaces added

#3 Updated by Marek Hulán about 5 years ago

#4 Updated by Michael Moll almost 5 years ago

  • Related to Refactor #7456: Extract primary interface from host added

#5 Updated by Michael Moll almost 5 years ago

As Linux does not set the same MAC address for the master all slave interfaces, the bonding changes did not resolve that issue, but #7456 should help as then the MAC address won't be used anymore for primary interface detection.

#6 Updated by Martin Jackson over 4 years ago

This behavior also seems to occur under Linux with Xen:

macaddress => D8:9D:67:1D:F7:10
macaddress_bond0 => D8:9D:67:1D:F7:10
macaddress_bond1 => D8:9D:67:75:0A:50
macaddress_eth0 => D8:9D:67:75:0A:50
macaddress_eth1 => D8:9D:67:75:0A:54
macaddress_eth2 => D8:9D:67:1D:F7:10
macaddress_eth3 => D8:9D:67:1D:F7:11
macaddress_eth4 => D8:9D:67:1D:F7:12
macaddress_eth5 => D8:9D:67:1D:F7:13
macaddress_eth6 => D8:9D:67:21:53:28
macaddress_eth7 => D8:9D:67:21:53:29
macaddress_vif27_0 => FE:FF:FF:FF:FF:FF
macaddress_vif27_1 => FE:FF:FF:FF:FF:FF
macaddress_vif30_0 => FE:FF:FF:FF:FF:FF
macaddress_vif30_1 => FE:FF:FF:FF:FF:FF
macaddress_vif30_2 => FE:FF:FF:FF:FF:FF
macaddress_xenbr110 => D8:9D:67:21:53:29
macaddress_xenbr150 => D8:9D:67:1D:F7:11
macaddress_xenbr20 => D8:9D:67:1D:F7:10

We are observing significant audit activity with "Primary interface" changing twice per node checkin, presumably due to the duplicate MAC address condition.

#7 Updated by Marek Hulán over 4 years ago

Martin, does it happen with nightly version or is that 1.7.x?

#8 Updated by Michael Moll over 4 years ago

It's also happening on nightly for me, it's expected that the merge of https://github.com/theforeman/foreman/pull/1988 fixes this, however I don't want to test that PR on my home instance. ;)

#9 Updated by Martin Jackson over 4 years ago

It's 1.7.1.

My git-fu might not be up to this completely, but it seems to me that ignore_puppet_facts_for_provisioning will control the update behavior (i.e. setting it to true will disable Primary Interface updates). Is that a correct reading of the patch?

#10 Updated by Michael Moll over 4 years ago

after ##1988 got merged, I'm still seeing swichting around of the "primary interface" on the said box between em0 and em1. It's an unmanaged node, if that's making any difference...

#11 Updated by Marek Hulán over 4 years ago

Michael, do you see primary flag changes on interfaces? Primary interface could change only if

!host.managed? && host.primary_interface.mac.blank? && host.primary_interface.identifier.blank?

in your case, the first part is true but I suppose the second and third should be false

Could you maybe run rake foreman-console and paste the output of

Host.find_by_name("$hostname").interfaces

Ideally for host for which you posted facts (mac 00:1e:67:15:02:79). Beware, if there's BMC device, the output may contain password so double check before paste.

#12 Updated by Michael Moll over 4 years ago

sure, no problem:

irb(main):003:0> Host.find_by_name('marduk.kvedulv.de').interfaces
  Host::Managed Load (0.5ms)  SELECT "hosts".* FROM "hosts" WHERE "hosts"."type" IN ('Host::Managed') AND "hosts"."name" = 'marduk.kvedulv.de' LIMIT 1
  Nic::Base Load (3.8ms)  SELECT "nics".* FROM "nics" WHERE "nics"."host_id" = 2 ORDER BY identifier
=> [#<Nic::Bond id: 14, mac: "00:1e:67:15:02:79", ip: "192.168.200.11", type: "Nic::Bond", name: "", host_id: 2, subnet_id: nil, domain_id: nil, attrs: {"network"=>"192.168.200.0", "ipaddress6"=>"2001:6f8:12f2:1::11", "netmask"=>"255.255.255.0", "mtu"=>"1500"}, created_at: "2014-10-07 12:22:48", updated_at: "2015-01-28 12:01:20", provider: nil, username: nil, password: nil, virtual: true, link: true, identifier: "lagg0", tag: "", attached_to: "", managed: false, mode: "802.3ad", attached_devices: "em0,em1", bond_options: "">]
<pre>

#13 Updated by Michael Moll over 4 years ago

that was a brainfart, that instance wasn't really updated, as it seems. have to reinvestigate.

#14 Updated by Michael Moll over 4 years ago

OK, fully updated now and it seems the bug is gone. :)
Martin, I guess, there's no possibility for you to update to current -develop?

#15 Updated by Michael Moll over 4 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Closing this as fixed.

#16 Updated by Dominic Cleal over 4 years ago

  • Legacy Backlogs Release (now unused) set to 28

Also available in: Atom PDF