Project

General

Profile

Bug #3997

get_interface_ip() returns first IP on interface, not necessarily primary IP

Added by Chris Buechler almost 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
11/06/2014
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

In some circumstances, IPs can be added/removed from an interface in such ways that an interface's primary IP is no longer the first IP in ifconfig output. This leads to issues as described in #3811 and #2495 for instance.

Ermal's long since fixed most of these possibilities by ensuring consistency in IP change/add/remove. There are circumstances where this fails catastrophically though.

assigning to myself for further testing and analysis. Ermal, if you can add thoughts here it'd be appreciated.

Associated revisions

Revision 89f171b0 (diff)
Added by Ermal Luçi over 4 years ago

Ticket #3997, teach code to track carp through uniqids(). Missing carp GUI changes and upgrade code

Revision eef9a15d (diff)
Added by Ermal Luçi over 4 years ago

Ticket #3997 Put a uniq identifier on the carp settings.

Revision 19523ce2 (diff)
Added by Ermal Luçi over 4 years ago

Ticket #3997 s/_vhid/_vip/g

Revision c7474afc (diff)
Added by Chris Buechler over 3 years ago

handle bridge interface IPs so they don't get added in the wrong order. Matches behavior to what "apply changes" on interfaces.php does. Ticket #3997

History

#1 Updated by Ermal Luçi almost 5 years ago

That does not have issues with the first ip address but rather no strict linkage of vip/carp interface to its information.
That is what the patch i sent re-enforces.

#2 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2 to 2.2.1

We'll review Ermal's patch post-2.2.

#3 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.1 to 2.2.2

#4 Updated by Mike Noordermeer over 4 years ago

Just FYI, I have a bridge interface with x.x.x.106 as primary IP, and an IP alias x.x.x.105. This fails consistently, ending up with .105 as the primary IP.

#5 Updated by Ermal Luçi over 4 years ago

On which scenario and which version this happens?

#6 Updated by Mike Noordermeer over 4 years ago

2.1.5 and 2.2.0. After reboot the VIP becomes the primary IP, and all outbound traffic and firewall rules referencing 'bridge address' suddenly use the VIP instead of the interface IP, breaking things.

#7 Updated by Ermal Luçi over 4 years ago

Can you share your interfaces config or all of it so i can replicate that?

#8 Updated by Mike Noordermeer over 4 years ago

Interfaces config, slightly censored: https://gist.github.com/MikeN123/009bc5fb76347663e448

Virtual IP config, slightly censored as well: https://gist.github.com/MikeN123/86fd05a7fb4b3c1f75de

Please let me know if you need any additional information.

#9 Updated by Mike Noordermeer over 4 years ago

Oh, and bridges and gateway config: https://gist.github.com/MikeN123/22d50fa3d37834b9659a

#10 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.2 to 2.2.3

#11 Updated by Chris Buechler about 4 years ago

  • Target version changed from 2.2.3 to 2.3

#12 Updated by Chris Buechler almost 4 years ago

  • Status changed from New to Confirmed

#13 Updated by Guillaume Hilt almost 4 years ago

Same issue here, as stated in issue #5136.
Let me know if I can provide something useful.

#14 Updated by Chris Buechler over 3 years ago

This happens with bridges during boot because in interfaces_configure, interfaces_vips_configure is run before the interface_configure of the bridge interface, which leaves the IP alias first. There are a variety of catch 22s there with dynamic interface types (GRE, gif at least) because they may be dependent on VIPs, and the bridge may be dependent on them.

It works upon applying changes on interfaces.php because that uses interface_reconfigure rather than interface_configure, the process of which removes the IP aliases and adds them back so their order is correct.

#15 Updated by Chris Buechler over 3 years ago

  • Status changed from Confirmed to Feedback

what I just pushed fixes the bridge issue.

The subject issue still exists and is difficult because FreeBSD has no concept of a primary IP on an interface. The bridge scenario should be the only circumstance that was still an issue in 2.2.x and 2.3, as the remainder of interface types are all handled correctly in that regard to ensure appropriate order of IPs.

Leaving to feedback for a bit more testing.

#16 Updated by Chris Buechler over 3 years ago

  • Status changed from Feedback to Resolved

fixed

Also available in: Atom PDF