Project

General

Profile

Actions

Bug #12170

open

Interface assignment mismatch is not detected if VLAN-only parent interface is removed

Added by Jim Pingle 2 months ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
Release Notes:
Default
Affected Version:
Affected Architecture:

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.


Related issues

Has duplicate Feature #12166: Dashboard Interfaces should show "physical" interface failures Duplicate07/26/2021

Actions
Actions #1

Updated by Jim Pingle 2 months ago

  • Has duplicate Feature #12166: Dashboard Interfaces should show "physical" interface failures added
Actions #2

Updated by Louis van Breda 2 months ago

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

Actions #3

Updated by Jim Pingle 2 months ago

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.

Actions #5

Updated by Jim Pingle about 2 months ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.6.0
  • Plus Target Version set to 21.09
Actions #6

Updated by Louis van Breda about 2 months ago

@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

Actions #7

Updated by Jim Pingle about 2 months ago

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.

Actions #8

Updated by Anonymous about 1 month ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #9

Updated by Viktor Gurov about 1 month ago

  • Assignee set to Viktor Gurov
Actions

Also available in: Atom PDF