Actions
Feature #11169
openChanging interface index order
Status:
New
Priority:
Very Low
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
12/17/2020
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Description
Current configuration operates interface indexes instead of real interfaces, e.g.
wan->igb0
lan->igb1
opt1->igb2
opt2->igb3
opt3->igb1.10
opt4->igb1.20
opt5->ovpn1
opt6->igb1.30
and so on. That makes configuring more smooth and flexible. But in the current implementation if some interfaces were deleted indexes are not rearranged and this might lead to some issues especially in config sync. E.g. in the example above if opt5 is deleted opt6 will not become opt5. Moreover, if a new interface assigned it acquires the lowest free index in the case above opt5. This situation can easily lead to errors in the HA cluster configuration. E.g. 3 interfaces add on primary and 2nd was deleted due to it was added by mistake. E.g. opt1, opt2, opt3 were added, opt2 was deleted, so final it is opt1, opt3. But during configuring secondary final picture is different it is opt1, opt2 because of no mistake. That leads to a config sync issue. And this is totally unclear for people who do not know what really happens under the hood. The only way to fix it on secondary is setup from scratch or manual config editing. Sometimes even setup from scratch becomes tricky. See 1st example, it is not possible to create opt5 without making a fake OpenVPN.
It would be good to solve this issue. There are some ways for that:
wan->igb0
lan->igb1
opt1->igb2
opt2->igb3
opt3->igb1.10
opt4->igb1.20
opt5->ovpn1
opt6->igb1.30
and so on. That makes configuring more smooth and flexible. But in the current implementation if some interfaces were deleted indexes are not rearranged and this might lead to some issues especially in config sync. E.g. in the example above if opt5 is deleted opt6 will not become opt5. Moreover, if a new interface assigned it acquires the lowest free index in the case above opt5. This situation can easily lead to errors in the HA cluster configuration. E.g. 3 interfaces add on primary and 2nd was deleted due to it was added by mistake. E.g. opt1, opt2, opt3 were added, opt2 was deleted, so final it is opt1, opt3. But during configuring secondary final picture is different it is opt1, opt2 because of no mistake. That leads to a config sync issue. And this is totally unclear for people who do not know what really happens under the hood. The only way to fix it on secondary is setup from scratch or manual config editing. Sometimes even setup from scratch becomes tricky. See 1st example, it is not possible to create opt5 without making a fake OpenVPN.
It would be good to solve this issue. There are some ways for that:
- allow rearranging index manually from indexes list
- make indexes totally unique and set indexes manually during assigning interface
- sync interface settings from primary to secondary with auto assigning IP/mask from the predefined network
Also for escaping making fake VPN instances during initial secondary setup, change index enumeration and use increased numbers from 0 for physical interface and decreased from uint32 max for software interfaces like VPN, etc, e.g.
opt1->igb2
opt2->igb3
opt4294967295->ovpn1
opt4294967294->ovpn2
No data to display
Actions