Bug bei der Benennung von neuen VLAN-Interfaces?

[Layer8]

Moin,

wir haben eine OPNsene mit aktueller Version 22.1.6 in einer VMware VM mit zwei vNICs laufen (vmx0 und vmx1).

Wenn wir in der Vergangenheit VLAN-Devices angelegt haben, haben diese immer die Device-Bezeichnung z.B. vmx0_vlan345 erhalten. Wir haben so schon etwa etwa 30-40 Interfaces auf vmx0 angelegt, die alle nach dem Schema benannt wurden.

Wenn ich jetzt ein neues VLAN-Interface anlegen möchte, wird das nicht mehr nach dem alten Schema vmx#_vlan#### benannt, sondern die heißen jetzt alle vlan01, vlan02 etc... und werden fortlaufen nummeriert. Wir können diese Bezeichnung aber nicht ändern.

Wenn ich also das VLAN-Device zu einem Interface assignen will, muss ich als Device vlan01 etc. in der Dropdown-Liste auswählen. Nach dem hinzufügen sehe ich in der Assignment-Liste nur noch diese neue Bezeichnung und kann nicht mehr erkennen, welchem Interface welches VLAN-Device untergeordnet ist.

Die alten Devices die mit vmx#_vlan#### angelegt wurden bleiben aber bestehen und funktionieren weiterhin.

Ist das ein Bug? Oder wie nennt man das VLAN-Interface nach seinen Vorstellungen um?

[Patrick M. Hausen]

Kann man nicht mehr. Ist ein Feature. Siehe Release Notes.

[Layer8]

Hilf mir bitte auf die Sprünge. Welche Release-Note ist das? Und wo ist die Diskussion dazu bzw. was waren die Hintergründe zu diesem Change? Würde da gerne meine Meinung zu kundtun. Ich kann da nicht wirklich Vorteile erkennen...

[Patrick M. Hausen]

https://docs.opnsense.org/releases/CE_22.1.html

interfaces: VLAN MVC conversion with API and QinQ support

https://forum.opnsense.org/index.php?topic=27931

[franco]

Ist das ein Bug? Oder wie nennt man das VLAN-Interface nach seinen Vorstellungen um?

Nein und nein. ;)


Grüsse
Franco

[Layer8]

Ich schreibs lieber hier auf deutsch, anstatt mir im englischen Thread einen abzuwürgen. ;-)

@franco: Ich verstehe den Grund wieso sich das geändert hat. Und ich würde deine Aussage, dass in der Oberfläche alles mögliche anzupassen ist und es unter der Haube möglichst einfach gehalten werden muss gerne aufgreifen.

Es wäre wirklich vorteilhaft, wenn in der Oberfläche weiterhin das alte Schema genutzt wird und das neue Schema nur beiläufig erwähnt wird - ähnlich wie das bei OPT-Interfaces ist. Heißt: Es wäre gut, wenn Interfaces mit VLAN-devices weiter im bisherigen Schema vmx0_vlan35 angezeigt werden.

Die ganzen Anleitungen im Internet und (zumindest unsere und wahrscheinlich auch viele andere) Dokumentationen bauen auf dem gewohnten Schema auf. Der Bezug sollte schon allein deshalb gewahrt bleiben, sonst endet das doch nur im Chaos, weil es in Anleitungen und Dokumentationen zu Verwirrung führt.

Bei QinQ-Interfaces sollte das genauso gehandhabt werden. Unter der Haube kann das gerne QinQ## heißen und auf irgend einem VLAN##-Interface aufbauen. In der Oberfläche sollte das aber sprechend sein und der Zusammenhang zwischen NIC, outer Q und inner Q sofort erkennbar sein.

Ich würde für QinQ/AD-Tagging eine Schreibweise bevorzugen, die sich an der Schreibweise von VLAN-Interfaces anlehnt. In der Oberfläche könnte das dann so aussehen: vmx0_vlan35_in450. Wer mit QinQ was anzufangen weiß, der wird gleich erkennen, was Sache ist. Konzequenterweise wäre auch vmx0_vlan35_qinq450 ganz gut.

Aus Erfahrung hab ich übrigens noch nie Probleme gehabt, wenn in der Oberfläche ein physisches oder VLAN-Interface mit mehr als 16 Zeichen benannt wurde, eben weil es im UI keine Rolle spielt. Das sollte bei QinQ dann doch auch möglich sein.

Die Bezeichnung vlan## und qinq## müssen in der Oberfläche dann nur noch beiläufig aufgeführt werden.

[rantwolf]

Grüße.

Ich klinke mich mal mit ein.
Habe das heute auch leider festgestellt.
Die Benennung ist definitiv nicht zielführend.
Also wenn da ein fremder daher kommt, denkt dieser sehr wahrscheinlich da ist das vlan03 gesetzt.
Vor Allem, wenn das VLAN dann zugewiesen wird...

Ich wünsche mir auch die alte Namensgebung zurück.
Da war ordnungsgemäß erkennbar, welches VLAN und welches Parent-Interface.

[Patrick M. Hausen]

Ich verstehe ehrlich gesagt das Problem nich ganz. Ob ein Interface "igb0" oder "em0" oder "em0_vlan7" heißt ist im Kontext OPNsense doch völlig Wurst?

Man weist einen symbolischen Namen wie LAN, WAN, DMZ, Kunde_X, ... zu und arbeitet in allen anderen Dialogen nur noch damit. Wann braucht man jemals wieder das konkrete Parent-Interface oder VLAN? Einmal eingerichtet, passenden Namen zugewiesen, gut ist.

[JeGr]

Um Patrick da zu ergänzen: Das ist mit der Grund, warum wir u.a. in Workshops etc. vorschlagen, die Interfaces in der UI bspw. so zu benennen, dass sowas am Namen erkennbar ist. Bspw. warum nicht das Interface V0123_KundeX nennen. V015_DMZ, V010_LAN oder sowas benennen? Hat nebenbei den Vorteil dass man die Interfaces dann auch alphabetisch sortieren lassen könnte und dann alles gleich in ner sinnvollen Ordnung hat. Nur als kleine Idee.

[franco]

Ach Leute, schreibt doch mal bitte konstruktiv welche GUI Seite was anders anzeigen soll. Pauschale Aussagen wie "wenn in der Oberfläche weiterhin das alte Schema genutzt wird" sind eben keine technischen Ansätze, die ohne riesigen Aufwand (der für einen einzigen Use Case einfach keinen wirtschaftlichen Sinn ergibt) nicht machbar sind.

Wir haben das Thema jetzt ca. 6 mal durchgerödelt und immer endet es mit "geht so nicht" weil die Argumentation unsererseits letztlich ignoriert wird, aber seit mehr als einer Dekade niemand auf die Idee kommt hier mal aufzuräumen weil es ja schon "perfekt" ist? Das Einzige was die Umstellung beweisst ist doch, dass sich alle auf die internen Namen verrannt haben aber keiner die Beschreibung nutzt mit der man das locker Abbilden kann?

Und noch mal: es ist ja nicht so, dass die UX leiden soll, daher bitte einfach klare Ansagen was wo nicht stimmig ist und dann kann man über Lösungen reden, z.B. die VLAN Beschreibung automatisch generieren als Anlehnung an die alten Interface-Namen. Und doch denke ich, dass sich dann die 3 Leute beschweren die eine eigene Beschreibung schon haben und nun gerne gleichzeitig eine automatische wollen wobei ja dann nicht mehr beides geht. ;)

So geht das halt immer weiter wenn die API gefordert wird und dann die API-Umstellung doch nicht passt.


Grüsse
Franco

[rantwolf]

Ich benenne meine Interfaces in der GUI schon seit Langen auch nach diesem Schema: 001_lan; 4000_guests,...
Soweit ist das klar und ich habe noch halbwegs den Überblick.

Aber in der Übersicht beim Anlegen des VLANs, steht es jetzt so drin:
"vlan01 | vtnet0 (xx:xx:xx:xx:xx:xx) [001_lan] | 4000 | ..."
Und das macht etwas konfus.

Bisher war es definitiv besser gelöst:
"vtnet0_vlan4000 | vtnet0 (xx:xx:xx:xx:xx:xx) [001_lan] | 4000"

[franco]

Hmm, die Informationen sind doch aber alle da: Parent Interface und VLAN ID. Man kann die auch nach vorne schieben in der Tabelle, aber "besser" gelöst finde ich Duplikationen von Informationen eher weniger. Vorrangig klingt das nach alter Gewohnheit es nicht so zu lesen wie es da steht.

Sofern das Sinn ergibt die Spalten zu tauschen können wir das jedenfalls gern machen?


Grüsse
Franco

[Layer8]

Ich versuchs mal ausführlich mit konkreten Beispielen und Verbesserungsvorschlägen. ;-)

Im ersten Moment stört sich an der neuen Notation vor allem das Gewohnheitstier in mir.  Im zweiten Moment und nachdem ich mich damit auseinander gesetzt habe stelle ich fest, dass die meisten Infos zwar da sind, aber eben ziemlich unübersichtlich. Ja, hier gehts um UX. :-)

Zum Menü Assignements:

So siehts aus, wenn man keine Bezeichnung fürs Parent-Interface angegeben hat:

Beispiel 1

Interface            Network port

LAN                   vmx1 ( AA:BB:CC:11:22:33 )
Test-QinQ           qinq01 ( Parent: vlan01, Tag:1000)
Test-VLAN          vlan01 ( Parent: vmx2, Tag:999)
WAN                  vmx0 ( 00:11:22:33:44:55 )

WAN und LAN sowie Test-VLAN sind in Ordnung. Man kann sofort sehen, auf welchem Device das basiert. Bei nur vier Einträgen ist das auch noch kein Problem.
Test-QinQ hat aber nicht alle Informationen enthalten, es fehlt die Info, welche physical NIC darunter steckt. Ich muss also durch die Tabelle springen und das parent-Interface raus suchen, damit ich an den outer Tag komme.

So siehts aus, wenn man das gleiche Setup mit Bezeichnungen (fett) fürs Parent-Device angegeben hat:

Beispiel 2

Interface            Network port

LAN                   vmx1 ( AA:BB:CC:11:22:33 )
Test-QinQ           qinq01  vmx2_vID0999_in1000 ( Parent: vlan01, Tag:1000)
Test-VLAN          vlan01 vmx2_vID0999 ( Parent: vmx2, Tag:999)
WAN                  vmx0 ( 00:11:22:33:44:55 )

Jetzt hab ich alle Infos in der Tabelle, sogar in einer Spalte Zeile. Aber auch nur, weil ich es selbst rein geschrieben habe. Und hier steckt auch schon das nächste Problem: Menschen machen Fehler. Ich will mich nicht auf irgendwelche Kommentare verlassen müssen, die falsch sein können. Selbst wenn die Bezeichnung inhaltlich nicht falsch ist, kann sie je nach Interpretation verwirren. Ich möchte mich beim Debugging lieber auf automatisch generierte Informationen verlassen können.


Wenn ich persönlich eine Installation aufsetze, benenne ich jedes Interface nach dem Schema
nicN_VLAN####_*Bezeichnung*
und zukünftrig wirds dann auch
NIC_VLAN####_in####_*Bezeichnung* geben.

Eine Installation von mir würde seit QinQ dann in etwa so aussehen:

Beispiel 3

Interface                                  Network port

vmx0_WAN                                   vmx0 vmx0_WAN( 00:11:22:33:44:55 )
vmx0_WAN_PPPoE_Telekom           pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
vmx1_untagged_LAN                     vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )
vmx2_vID0100_WiFi_Privat            vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
vmx2_vID0200_WiFi_Gast             vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
vmx2_vID0300_WiFi_Smart           vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
vmx2_vID0400_WiFi_HomeOffice    vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
vmx2_vID0999_in1000_Kunde1_DB qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
vmx2_vID1000_Kunde1                  vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000

Ich finde das ziemlich unübersichtlich. Dem aufmerksamen Leser wird aufgefallen sein, dass hier ein paar Fehler  drin sind. Also sortiere ich die Liste doch mal nach Network port aufsteigend, vielleicht hilft das bei der Lesabarkeit und dem Debugging.

Beispiel 4

Interface                                  Network port

vmx0_WAN_PPPoE_Telekom           pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
vmx2_vID0999_in1000_Kunde1_DB                  qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
vmx2_vID0200_WiFi_Gast             vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
vmx2_vID0300_WiFi_Smart           vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
vmx2_vID0400_WiFi_HomeOffice   vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
vmx2_vID0100_WiFi_Privat            vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
vmx2_vID1000_Kunde1                vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000)
vmx0_WAN                                   vmx0 vmx0_WAN( 00:11:22:33:44:55 )
vmx1_untagged_LAN                     vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )

Ich finde, das hats nicht besser gemacht.

Nicht jeder ist bei der Benennung von Interfaces so gründlich und jeder hat auch ein anderes System wie er Interfaces bezeichnet. Daher gibts die Tabelle 3 jetzt mal ohne mein Schema, nur mit der Bezeichnung. Die Tabelle ist nach Interfaces sortiert.

Interface                                  Network port

Kunde1                                   vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000
Kunde1_DB                             qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
untagged_LAN                         vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )
WAN                                       vmx0 vmx0_WAN( 00:11:22:33:44:55 )
WAN_PPPoE_Telekom               pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
WiFi_Gast                               vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
WiFi_HomeOffice                     vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
WiFi_Privat                             vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
WiFi_Smart                             vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)

Das gleiche zum Spass noch nach Network port sortiert.

Interface                                  Network port

WAN_PPPoE_Telekom               pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
Kunde1_DB                             qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
WiFi_Gast                               vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
WiFi_Smart                             vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
WiFi_HomeOffice                     vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
WiFi_Privat                             vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
Kunde1                                   vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000
WAN                                       vmx0 vmx0_WAN( 00:11:22:33:44:55 )
untagged_LAN                         vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )

Ich hab das Beispiel jetzt nur mit 9 Interfaces gemacht. Wir haben in Produktivumgebungen weit mehr Interfaces.

Was ich damit aufzeigen will ist, dass mir das aktuelle Schema als Benutzer aktuell keine Chance lässt, bei einer Installation bei der ich die Interfaces nicht selbst benannt habe so zu sortieren, dass ich mir schnell einen Überblick verschaffen kann. Einfach deshalb, weil es keine Möglichkeit gibt, die Tabelle so zu sortieren, dass ich ein erwartbares Ergebnis habe. Im Verzeichnisdienst sortier ich die Objekte doch auch nicht nach SSID und co. ;-)

Und selbst wenn man ein durchdachtes Schema bei der Description des Interfaces einhält hilft mir das beim Debugging auch nicht schnell weiter, weil die Infos in der Spalte Network port durcheinander sind. Das Auge braucht einfach bis es sich zurecht findet und die richtigen Infos hat.


Daher für die Assignments-Tabelle folgenden konkreten Vorschlag:

Interface                  Network port (Dropdown-Menü)       

*Description*           *NIC*_VLAN####_QinQ#### ( *MAC* )

*Description* kann ohne individuelle Bezeichnung gerne WAN, LAN oder OPT* bleiben bzw. die Description, die man selbst gewählt hat
- *NIC* kann ein phys/virt NIC oder lagg sein
- VLAN#### und QinQ#### sind natürlich nur optional, aber mit dieser Notation ist weiterhin alles enthalten.
- VLAN#### sollte der Q-Tag sein, gerne auch immer mit führenden Nullen, das erleichtert die Lesbarkeit weiter.
- QinQ sollte der AD-Tag sein
- *MAC sollte klar sein. Sollte übrigens auch bei VLAN und QinQ-Interfaces dran stehen.


Anmerkungen dazu und alternativ ein paar Gedankenanstöße falls das konkret vorgeschlagene Schema nicht gefällt:

- "_" find ich als Trennzeichen gut. Das ist besser zu erkennen wie ein ".". Ich würde auch aus historischen Gründen für "_" stimmen. Letztendlich ist aber _, - oder . OK.
- Die Spalte Network-Port oder besser gesagt die Dropdowns dürfen gerne noch ein paar Zeichen länger sein.  FullHD ist heute Standard, in der Tabelle gibts aktuell nur zwei Spalten und es hat genügend Platz.
- Die Info, welches VLAN## oder QinQ## hinter einem Network Port steckt ist in etwa so interessant wie die Info, ob mein dreisigstes Interface tatsächlich OPT28 ist oder weil ich zwischenzeitlich schon welche gelöscht hab doch eher OPT50. Die Info passt besser ins Menü Overview.

- Es wäre auch vorteilhaft, wenn ich einer physical NIC, also dem Device vmx0 eine Description geben könnte. Das fehlt und es wäre vorteilhaft, wenn ich dem Adapter selbst die Info geben könnte, ob es sich um die rechte oder linke Karte in meinem Server handelt, etc.



Oben aufgeführte Argumente gelten in ähnlicher Form auch für das Menü Other Types -> VLAN:

- Aktuell hab ich dort nic#_vlan# -, vlan# - und qinq# -devices. Das ist durcheinander, wenn man es sortiert und dem geschuldet, dass man jetzt Altlasten mit rumschleppt bzw. die neue Bezeichnung drin hat.

- Selbst wenn ich nur noch vlan## und qinq## habe: was bringt mir die Sortierung danach (Stichwort SSID/UUID)? Ich würde auch dort gerne das alte Schema in der Spalte Device sehen. Von mir aus kann ja VLAN## oder QinQ## in Klammern dahinter stehen.

- Was wenn ich wissen will, welche VLANs auf dem Parent vmx1 liegen?
-> Sortiere ich nach Parent, sind die Tags in der nächsten Spalte durcheinander. Man hat also wieder keine Möglichkeit, ein erwartbares Ergebnis zu kommen sondern muss die Tabelle chaotisch durchsuchen.
-> Die Sortierung nach Tags ist da noch einigermaßen nützlich. Es hilft mir aber nicht, meine Frage zu beantworten.




Hoffe, das war ausführlich genug ;-)

[Layer8]

Eins noch....


Matured Altinstallationen (also alle, die es vor dem QinQ-Feature gab), die noch mit nic#_vlan#-Notation konfiguriert wurden könnten ja noch ein paar Jährchen überleben. Das muss ja auch im Code weiter berücksichtigt werden. Gibts dazu Infos wie das weiter geht? Oder werden solche Devices unter der Haube einfach irgendwann automatisch auf vlan#### und qinq#### umgestellt?

[Layer8]

Würde gern mal nachhaken, ob in Bezug auf dieses Thema nun noch was am UI gemacht wird?