Bug #12170
closed
Interface assignment mismatch is not detected if VLAN-only parent interface is removed
Added by Jim Pingle about 3 years ago.
Updated over 2 years ago.
Plus Target Version:
22.01
Description
If an interface is used only for VLANs (e.g. it is not assigned directly) and that interface is removed, the system does not detect this as a problem at boot time and will appear to indicate that the VLANs are up and working when they are not. Attempting to change assignments fails as that part of the code detects the missing the VLAN parent.
The system should fail to boot with an interface assignment prompt when this happens, same as if any other interface is removed. At the very least it should disable/remove affected VLAN interfaces but that would be inconsistent with other behavior.
- Has duplicate Feature #12166: Dashboard Interfaces should show "physical" interface failures added
Jim,
Note that:
- the interface assignment was completely legal when it was created (the x520 was functioning at that moment)
- the x520 problem started when the router was running, the dashboard status did not show, that the underlying x520 was gone
- the router was still booting even when the x520 interface had errors and also when it was not visible for the OS any more (pciconf lv)
and the router is booting "without problem" now that the x520 has been removed. In fact I am quite happy with that since my network has an 1G part and an 10G part. The 1G-part is still active allowing me to write this report, where the 10G side of my network is not reachable, since I lost the x520
Sincerely,
Louis
None of that matters. If the interface is missing when it must be present, the configuration should be rejected as with any other interface mismatch.
Hardware may fail in some way but that is not always possible to detect at runtime. A reboot should always catch since it would be missing at that time.
It doesn't matter if your particular environment still functioned partially in that state with the interface removed, it's not a valid state and must always be rejected.
- Status changed from New to Pull Request Review
- Target version set to 2.6.0
- Plus Target Version set to 21.09
@Jim,
I object !!
- I am very glad that the system was still running even with the defect x520. That allowed the rest of the network to stay operational *!!! If the system had rejected the config, I would have had a much bigger problem:
- the network had stopped completely !!!*
- Now the 1G-part of the network was running completely normal. Just the 10G part was effected.
- I would have had lots of work to create a new config! Impossible in reasonable time !!!
- second point less service!, it is nonsense that a running system can not detect failing hardware. For example if a pciconf -lv does not show the used interfaces, you know something is wrong! Using pings is perhaps another option, etc. That kind of info could be shown in a hardware widget
So, very bad decisions to stop the router if there is any hardware issue! Just show it on the dashboard and let the administrator decide!
Louis
That is not the philosophy taken by pfSense for other interfaces, and it won't be changed here. There are other open issues for requests to allow disconnected or removable interfaces, but this is not the place for it.
Because it happened to partially work for you by pure luck doesn't mean we should accommodate a broken and invalid configuration when it could lead to catastrophic failures for others.
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
- Assignee set to Viktor Gurov
- Plus Target Version changed from 21.09 to 22.01
Jim,
As stated before, IMHO the fact that a particular interface fails, should NOT be a reason to shut the whole system down! I was very glad (!!) that the system was still running, at the moment one of the interfaces failed. That made it possible to use at least a significant part of the network!
However / of course the dashboard should correctly show which interfaces are down. And that was not the case when I originally initiated the ticket :(
Sincerely,
Louis
And as noted above, that may be true for your environment but not for most others. Your experience is unusual and not indicative of what most users would encounter in similar failures.
Halting and forcing the user to correct the failure is the safest path and the path we have chosen to take.
Jim,
Your choice of course however note:
- I took me longer than necessary to understand the problem by then, because the dashboard / gui did not show the problem !
- After I had identified the problem, I immediately ordered a replacement interface board ......
- however it took of course two days before that board arrived.
- I would not have been happy if the consequence had been a complete firewall outage for 2,5 days!
Louis
Behaves as expected on
2.6.0-RELEASE (amd64)
built on Tue Jan 25 19:18:35 UTC 2022
FreeBSD 12.3-STABLE
Assigned VLAN to interface, rebooted without interface, and it prompted for interface assignments.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF