Project

General

Profile

Bug #10206

VIP alias-ip's disappear from nic (caused by running ifconfig twice.?.)

Added by Pi Ba 6 months ago. Updated 6 months ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Interfaces
Target version:
Start date:
01/23/2020
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.5.0
Affected Architecture:
amd64

Description

Using "pfSense-CE-2.5.0-DEVELOPMENT-amd64-20200123-1059.iso" for a fresh install on a VirtualBox VM my configured VIP's are can only be pinged for a second or two during bootup.. (firewall does allow icmp..) Traced it down to the fact that running the same ifconfig command twice makes the ip-alias disappear from the nic! See below with a 'new' IP 192.168.0.234 that wasn't configured before.

Below em0 is a real nic that is 'bridged' to the Vbox-VM.. However the same effect happens for em1 which is configured as 'internal network' in the VM configuration so that one would certainly not depend on the real nic used..

Also just a 'ifconfig down'/'ifconfig up' makes the primary ip of the interface that is configured by dhcp disapear to never come back until a reboot is done..

What can be done to diagnose this further? (As the issue seems to come from the 'binaries' / kernel.. My php reading skills don't really help anymore.. and my C skills are pretty much nonexistent..)

[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=81009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER>
        ether 08:00:27:4e:1a:e2
        inet6 fe80::a00:27ff:fe4e:1ae2%em0 prefixlen 64 scopeid 0x1
        inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig em0 192.168.0.234/24 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=81009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER>
        ether 08:00:27:4e:1a:e2
        inet6 fe80::a00:27ff:fe4e:1ae2%em0 prefixlen 64 scopeid 0x1
        inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.234 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig em0 192.168.0.234/24 alias
ifconfig: ioctl (SIOCAIFADDR): File exists
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=81009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER>
        ether 08:00:27:4e:1a:e2
        inet6 fe80::a00:27ff:fe4e:1ae2%em0 prefixlen 64 scopeid 0x1
        inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: uname -a
FreeBSD pfSense.localdomain 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 b03a341e64a(RELENG_2_5) pfSense  amd64
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root:

History

#1 Updated by Jim Pingle 6 months ago

The down/up loss is already covered by #8815

Might not be much to do here but wait until 2.5.x moves to a FreeBSD 12-STABLE base. It's possible that's been fixed in the OS already.

#2 Updated by Pi Ba 6 months ago

Well maybe its fixed in the FreeBSD-OS, however maybe it was never broken in the FreeBSD-OS in the first place? (as pfSense does apply some patches here and there to extend functionality of various parts..)

I've installed FreeBSD12.0-RELEASE and upgraded it to P10 (or more exactly svn revision -r350649 ). And this does not seem to have the same problem. So that leaves me to wonder is it something that pfSense (system patches/additions/configuration?) does to the system that breaks the ifconfig command? Or is it really certain that the issue does reproduce on native FreeBSD12.0p10 when certain modules are loaded or options are set?

Also the FreeBSD RELEASE versions are (supposed to be) 'stable software' right.? Seeing also that 2.4.4 is also based on a 11.2-RELEASE-p6 version.?. I don't see why we should use 12-STABLE?

B.t.w. on the pfSense install i did find a possibly helpful error.?: "in_scrubprefix: err=51, prefix delete failed"

Perhaps moving 2.5 to a more recent FreeBSD version as you suggest would be a easy step? Any plans when that might happen as the ticket you reference has been open for a year..?

Also available in: Atom PDF