Bug #10206
closed
VIP alias-ip's disappear from nic (caused by running ifconfig twice.?.)
100%
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:
Updated by Jim Pingle almost 5 years 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.
Updated by Pi Ba almost 5 years 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..?
Updated by Luiz Souza over 4 years ago
- Status changed from New to Feedback
- Assignee set to Luiz Souza
I can't reproduce any of the two reported issues with a current 2.5 snapshots.
Repeated ifconfig commands for add address aliases do not cause any error and the address is not removed.
The NIC is also capable to handle an ifconfig down/up and reacquire the DHCP IP.
Could you please check if these problems are still happening for you ?
Updated by Ronald Schellberg over 4 years ago
I can reproduce it here
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0 192.168.51.234/24 alias
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
inet 192.168.51.234 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0 192.168.51.234/24 alias
ifconfig: ioctl (SIOCAIFADDR): File exists
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: uname -a
FreeBSD Gateway.Lilypad 12.1-STABLE FreeBSD 12.1-STABLE 1c8651b7685(devel-12) pfSense amd64
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root:
Updated by Louis B over 4 years ago
Hello,
Sometime I have the same verdict! If you see what happens during boot, things are beeing started over and over again (sometimes started, stoped 1 second later by a next phase, started again etc, sometimes started twice at the same moment!).
I can not prove that that is causing problems, but my verdict is that it ..... lets put it a nice way ..... does not help! I really would appriciate if:
- the OS is started first
- then the pfSense application it self
- and than the rest
and of cause every thing only one's !!!!
Louis
Updated by Luiz Souza over 4 years ago
Ronald Schellberg wrote:
I can reproduce it here
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0 192.168.51.234/24 alias
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
inet 192.168.51.234 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0 192.168.51.234/24 alias
ifconfig: ioctl (SIOCAIFADDR): File exists
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=81259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether fc:aa:14:93:68:f7
inet6 fe80::feaa:14ff:fe93:68f7%em0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x1
inet6 2602:xx:xxxx:xxxx::1 prefixlen 64
inet 192.168.51.1 netmask 0xffffff00 broadcast 192.168.51.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root: uname -a
FreeBSD Gateway.Lilypad 12.1-STABLE FreeBSD 12.1-STABLE 1c8651b7685(devel-12) pfSense amd64
[2.5.0-DEVELOPMENT][root@Gateway.localdomain]/root:
I can reproduce this, but it is also kind of expected as, in this example, the network settings are wrong!
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.1/24 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.2/24 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.2/24 alias
ifconfig: ioctl (SIOCAIFADDR): File exists
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1
mvneta1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>
ether 00:e0:ed:a9:96:66
inet6 fe80::2e0:edff:fea9:9666%mvneta1 prefixlen 64 scopeid 0x2
inet6 fe80::1:1%mvneta1 prefixlen 64 scopeid 0x2
inet6 2001:db8:0:fc:2e0:edff:fea9:9666 prefixlen 62
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
media: Ethernet 2500Base-KX <full-duplex>
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
The second alias, for an already existent network, must have the /32 mask and not the /24.
Once this is fixed, everything works:
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.1/24 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.2/32 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1 192.168.123.2/32 alias
[2.5.0-DEVELOPMENT][root@pfSense.localdomain]/root: ifconfig mvneta1
mvneta1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM>
ether 00:e0:ed:a9:96:66
inet6 fe80::2e0:edff:fea9:9666%mvneta1 prefixlen 64 scopeid 0x2
inet6 fe80::1:1%mvneta1 prefixlen 64 scopeid 0x2
inet6 2001:db8:0:fc:2e0:edff:fea9:9666 prefixlen 62
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
inet 192.168.123.2 netmask 0xffffffff broadcast 192.168.123.2
media: Ethernet 2500Base-KX <full-duplex>
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
So, this is not exactly a bug, but maybe a bug in pfSense for allowing such settings (or a documentation bug).
I'll not fix this one (that's a configuration issue, not a bug in the OS).
Updated by Luiz Souza over 4 years ago
Louis van Breda wrote:
Hello,
Sometime I have the same verdict! If you see what happens during boot, things are beeing started over and over again (sometimes started, stoped 1 second later by a next phase, started again etc, sometimes started twice at the same moment!).
I can not prove that that is causing problems, but my verdict is that it ..... lets put it a nice way ..... does not help! I really would appriciate if:
- the OS is started first
- then the pfSense application it self
- and than the rest
and of cause every thing only one's !!!!Louis
This is a known issue in pfSense, I think there is even a ticket for it.
But let's not pollute this ticket which is specifically for analyzing the IP alias that disappear under some circumstances.
Updated by Luiz Souza over 4 years ago
- Status changed from Feedback to Not a Bug
Updated by Jim Pingle over 4 years ago
- Status changed from Not a Bug to Feedback
FreeBSD dropped the /32 requirement years ago, though, and it's been working fine until recently. Still feels like a regression here.
Can someone confirm for sure that it this same problem doesn't happen on 2.4.4-p3 and/or 2.4.5-p1?
Updated by Ronald Schellberg over 4 years ago
Jim Pingle wrote:
FreeBSD dropped the /32 requirement years ago, though, and it's been working fine until recently. Still feels like a regression here.
Can someone confirm for sure that it this same problem doesn't happen on 2.4.4-p3 and/or 2.4.5-p1?
Same alias step on 2.4.5-p1 can be repeated multiple times without the "ifconfig: ioctl (SIOCAIFADDR): File exists" error response.
Updated by Luiz Souza about 4 years ago
- % Done changed from 0 to 100
Found the regression.
For the record, this only affects the kernels built with RADIX_MPATH.
Updated by Anonymous about 4 years ago
- Assignee changed from Luiz Souza to Pi Ba
Would you please confirm this fix?
Updated by Anonymous about 4 years ago
- Status changed from Feedback to Resolved