Disable start up interface reassignment

Patch

@Justaguy-0
Btw for me the solutions was

When it is working as desired, document externally the interface configuration including:- Physical computer box lan label, Function, Proxmox PCI device port address, Proxmox VBR, MAC, pfsense NIC lable, pfsenese IP & VLAN.
Reboot the Proxmox hypervisor. In hindsight one of the passed through NIC got in an unusable state at the hypervisor level.

I however still believe pfsense interface reassignment could be improved by better utilisation of information from the last working configuration. Perhaps the simplest would be just to display all data from the last assignment when reassignment is required. Better again allow the user to just reassign interfaces which have changed.

Justaguy 0

I agree the pfSense interface reassignment could use some improvement. As stephenw10 suggests it is the number of NICs that is causing the assignment script to run, but why should it reassign unchanged NICs? Or why does it list non physical interfaces such as bridges or VPN taps? What is going to happen when I free up some time and build some scripts to create interfaces with rule/routing sets to further my SD-LAN aspirations?

SteveITS

@Patch I think the concern is, a NIC is added, detected first, or in the middle, and all others shift up one…0>1, 1>2, etc. Assuming 0 is still LAN or 1 is router management could be dangerous depending on firewall rules.

stephenw10

Yes, the current behaviour is required because the NIC order is determined only by the order they are parsed in he PCIe device tree. Thus if an expansion card is removed or fails the remaining NICs, using the same driver, may not be assigned as the same interfaces. In that situation it is safer to drop to the re-assign prompt than to continue to boot and end up with the wrong rules on an interface.
To do anything else requires non-trivial work.

Steve

Patch

I can see handing the problem completely back to the console is safer for pfsense (if it does nothing then it can't make a mistake).

However it could be more helpful for the user.

pfsense assigns interfaces based on the order however more data about past interface assignments is or could be recorded / displayed / matched.
With the current design approach loss of one NIC disabled the function of all NIC on reboot, making rebooting a more expensive (in operator time) debugging technique.

stephenw10

Mmm, an interface check at shutdown/reboot could mitigate that maybe?

SteveITS

@stephenw10 Maybe but I think he’s suggesting this in the console:

(Msg about interface changes detected)

Old assignments used on previous boot (found in config file):
Ix0 WAN
ix1 LAN
ix2 OPT

Assign interfaces:
(Choices)

Patch

@SteveITS
Together with any other identifying information such as MAC address or bus address both for the old assignment and currently detected interfaces.

stephenw10

Yes it would require the MAC/NIC relationships to be stored and displayed in order to know which NIC has gone AWOL. The user needs that info to re-assign/remove the appropriate interface.

Justaguy 0

I have 1 pfSense instance where assignment script runs on every reboot. The big issue for me is that I can't reboot pfSense without manual intervention as it won't come up on it's own. I am adding and removing Nics the Virto driver and pfSense is adding them and removing them respectively live while booted. There are no Nic interface changes while rebooting. To get it to boot and where I don't have to rebuild rules is that I do have to add 2 Nic interfaces for the assignment script as it asks me to assign a Bridge interface and Ovpns interface to a physical Nic. Next time I'll rebuild the VPN and bridge configuration.

I do have other pfSenses where once in a while the script runs and I'm not making interface changes. But I can't say for sure a hypervisor update didn't change something in how it is representing the Nic interface to pfSense.

stephenw10

A bridge or openvpn or any other virtual interface type is excluded from the interface check because they may not exist at that point. So whatever is triggering it is one of the other interfaces. What do you have assigned?

Justaguy 0

I have 6 physical interfaces assigned. 1 PCI pass-through for WAN, 2 are VFs and 3 are bridges. All of the MACs are set in the VM config other than the PCI pass-through. For virtual interfaces there are 4, 3 ovpns and 1 bridge. The ovpns that is tied to the bridge that comes up in the assignment script along with the bridge. When I get a chance I'll redo that ovpns and bridge to see if it makes a difference.

stephenw10

Hmm, I wouldn't expect an issue there then. What does that actually look like in the interface list?

Justaguy 0

I have 2 issues. This pfSense won't boot without my intervention and that the assignment script asks me to assign a physical interface to the bridge and a opvns interface. If I don't give the a bridge and a opvns an interface I'm having to rebuild rules and routing.

stephenw10

Yes, that's a problem at the console because those sub-interface types don't exist yet when you are presented with the menu. However the fact it is shown at all means one of the assigned 'physical' interfaces is not present.
What interfaces do you see listed at the console menu after it has booted correctly?

Justaguy 0

All physical interfaces are present, none have been removed.

stephenw10

Right but what does it show there? I can't guess what interface(s) are likely to be causing the problem without seeing that list. It doesn't have to include any IPs.

w0w

I've had another problem — when my 4-port Chinese card went crazy after a firmware update, it started to randomly change the ports order on startup. I did not see startup reassignment this time, but it was a total mess, I replugged the cables almost every time it booted. It is clear that this will almost never happen during normal use, and just because of this, there is definitely no need to redo anything there.
But… it would be good to store MAC instead of just interface name. The fun thing is that LAGG, for example, already shows the MAC address, when you configure it in GUI, but don't use it anywhere.

Simple case — you have 4 physical ports, for example igc0 to igc3. You have assigned igc0, igc1 to LAGG0 and igc2, igc3 to LAGG1. What will be happening if igc1 is dead?
I think it will just shift igc2 to LAGG0, becoming igc1 and igc3 is still in LAGG1, is not it?
If it is configured just as failover it will work as expected, util for some reason there is no more link on the LAGG0 igc0 and when it's happening the LAGG0 will be connected to the LAGG1 network as igc1 became Master.

If interfaces are assigned using those LAGGs so I am not sure that startup reassignment will be started even if there is no one interface is left in LAGG.

stephenw10

@w0w said in Disable start up interface reassignment:

my 4-port Chinese card went crazy after a firmware update

A pfSense upgrade? A BIOS update?

It would only be re-ordered in pfSense if the NICs appeared on the PCIe bus in a different order, which is hard to imagine. I'd guess only the PCIe bridge could do that, if it has one.

w0w

@stephenw10 said in Disable start up interface reassignment:

A pfSense upgrade? A BIOS update?

Card firmware. As I already stated it is not happening in the wild, must be only me the lucky one . I think it was zeroed MAC or even two ports got the same MAC address in the corrupted firmware update process. Nevermind, as I already said there is nothing to do with that on pf side.
But in case of disappeared port... Maybe there's something to improve.