Wie ist die VLAN- / QinQ- device name syntax seit 22.7.6 ?

[Layer8]

Moin,

seit 22.7.6 gibts folgende Änderung laut Changelog:

interfaces: allow user-configurable VLAN device names with certain restrictions

Hier das Issue in github: https://github.com/opnsense/core/issues/6038

Im Hilfetext steht:
Leave empty to generate a device name. Custom names are possible, but only if the start of the name matches the required prefix and contains numeric characters or dots, e.g. "vlan0.1.2" or "qinq0.3.4".


Ich entnehme daraus, dass  ein VLAN-Device dann immer mit vlan beginnen muss, dahinter können Zahlen folgen. Gleiches analog für QinQ. Dahinter dürfen dann nur Zahlen und Punkte folgen.

Nun hab ich da ein bisschen rumprobiert. Einfach nur vlan mit beliebiger Systematik an Zahlen und Punkten hinten dran scheint nicht zu gehen und führt zu folgender Fehlermeldung:


Only a maximum of 15 characters is allowed starting with "vlan0" combined with numeric characters and dots, e.g. "vlan0.1.104".

Welcher Regel nach bzw. Syntax entsprechend sind die Zahlen und Punkte anzuordnen? Das ist irgendwie nicht so ganz einleuchtend.

Bezogen auf die Beispiele im Hilfetext und der Fehlermeldung:
Was bedeutet die führende 0? Ist das der Adaptertyp? (z.B. vmx)
Ist die Zweite Zahl die Interface-Nummer des entsprechenden Adaptertyps?
Die letzte Zahl ist das VLAN-Interface?

Welchen Spielraum lässt die Syntax?

[meyergru]

Das exakte Pattern ist: "/^{$prefix}0([0-9\.]){1,10}$/". Soweit ich im Code sehe, trägt der Name keinerlei inhärente Bedeutung, anders als früher z.B. "igb0_vlan7".

Der Name für ein VLAN muss lediglich mit vlan0 beginnen und dann können 1-10 Zeichen aus der Menge 0123456789. folgen, es wäre also auch "vlan0...1" möglich oder "vlan0815", aber nicht "vlan666".

Die Idee war, mit Einführung von QinQ Kollisionen zu verhindern, indem einfach durchnumeriert wurde (vlan01, vlan02 usw.). Damit sieht man der Bezeichnung aber den Sinn nicht mehr an. Baut man z.B. für T-Online PPPoE ein VLAN 7, heißt es trotzdem vlan01, wenn es das erste ist.

Deswegen wurde die Möglichkeit, strukturierte Namen zu verwenden, wiederhergestellt.

Am Rande bemerkt kann man auch den Namen in einer gespeicherten Konfigurationsdatei später ersetzen und wieder einlesen - dann ist auch "igb0_vlan7" wieder möglich. Vorhandene Namen aus geladenen Konfigurationsdateien werden nämlich 1:1 übernommen.

[Layer8]

Deswegen wurde die Möglichkeit, strukturierte Namen zu verwenden, wiederhergestellt.

Sehr gut, vielen Dank. Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.

Wenn es sowieso keine Rolle spielt, wie das Interface heißt, wieso gibt man dann nicht gleich die Benennung ganz frei? Soll doch derjenige, der sich keine Gedanken drüber machen will ein vordefiniertes, automatisiertes Namensschema nutzen und der, der strukturiert bezeichnen will, soll seine Bezeichnung gleich selbst definieren. Dieses vlan0 prefix macht doch keinen Sinn...

Und ob das jetzt ein phy, vlan, qiniq, vxlan interface ist, kann man doch an anderer stelle definieren. Muss ja mit der Benennung nichts zu tun haben.

[meyergru]

QinQ bietet ja die Möglichkeit, VLANs zu schachteln, das alte Schema hätte dann zu Namen wie igb0_vlan1_vlan2_vlan3_vlan4 führen können. Es gibt aber eine Längenbeschränkung, die das verbietet.

Ich fände es auch besser, die eigene Benennung im Rahmen der syntaktischen Freiheitsgrade zu erlauben, zudem das über Umwege ja sowieso möglich ist. Die Automatik kann ja tun, was sie will (oder man lässt sie weg).

[franco]

> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.

Danke für die nicht hinreichende technische Analyse des vordergründigen Problems. ;)

Der Name ist letztlich egal, der Inhalt aber nicht: wir haben nur 15 Zeichen und wir müssen verhindern, dass dort auf einmal der Name eines anderen Interfaces auftaucht weil das einige Annahmen des Codes sprengt.

Und seien wir ehrlich, man würde doch gleich wieder "em0" in den VLAN Namen einfügen wollen wenn man könnte aus "Gründen".


Grüsse
Franco

[Layer8]

> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.

Danke für die nicht hinreichende technische Analyse des vordergründigen Problems. ;)

Muss diese Art der Kommunikation sein? Warum nicht sachlich bleiben?

Der Name ist letztlich egal, der Inhalt aber nicht: wir haben nur 15 Zeichen und wir müssen verhindern, dass dort auf einmal der Name eines anderen Interfaces auftaucht weil das einige Annahmen des Codes sprengt.

Ich versteh nicht, wieso kritische Zeichenfolgen nicht einfach abgefangen werden.

Wenn die Strings nicht länger als 15 Zeichen lang sein sollen, dann lässt sich das abfangen.
Wenn gewisse Zeichenfolgen nicht genutzt werden dürfen, dann lässt sich das doch sicher ganauso abfangen.

Alles was mit diesen Bedingungen nicht kollidiert, sollte erlaubt sein.

Wenn dann noch die Bedingungen und kritischen Zeichenfolgen im Wiki, hier im Forum oder in der Weboberfläche kommuniziert werden, dann ist doch alles getan um die Nutzer abzuholen.

Und seien wir ehrlich, man würde doch gleich wieder "em0" in den VLAN Namen einfügen wollen wenn man könnte aus "Gründen".


Grüsse
Franco

Und wenn es genau das ist, was deine Nutzer wollen? Nicht weil es früher immer so gemacht wurde und man daran aus Gewohnheit festhalten will, sondern weil es einfach Sinn egeben hat und sich etabliert hat?

Ich kann an der Stelle nur nochmal drauf aufmerksam machen, welchen Impact solche Änderungen auf die vielen Tutorials, Dokus, Howtos im Internet hat, denn die stimmen nun alle nicht mehr.

Diskutiert haben wir das auch hier schon. Es kam nur keine Reaktion mehr....
https://forum.opnsense.org/index.php?topic=28114

[franco]

> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.

Ganz sachlich also: technisch unmöglich sauber auszuführen auf 15 Zeichen pro Device, aber es reicht für eine pauschale Aussage, dass diese Alternative keine gute Idee ist? Eine Idee, die schon bei Bridges und LAGG und OpenVPN uvm. seit Jahrzehnten verwendet wird ist also keine gute Idee?

Auch ganz sachlich ohne Smiley, da die angespannte Situation hier wohl nicht aufgelockert werden kann.

[Patrick M. Hausen]

Weshalb darf eigentlich der Name des Parent-Interface da nicht drin vorkommen?

Das Standard FreeBSD-RC-System baut Namen wie lagg0.12 für VLAN 12 auf lagg0 - das passt prima in 15 Zeichen und reicht für beliebig viele laggs und beliebig viele vlans darauf - im Rahmen vernünftiger Zahlen für "beliebig". Mehrere Tausend wären kein Problem. Und bei QinQ hängt man halt noch ein .X hinten dran. Passt auch noch.

Ich kann mit durchnumerierten vlanX problemlos leben - es ist doch alle Info im UI. Und auf der Shell sowieso. Daher versteh ich die Aufregung nur teilweise. Aber aus Neugier: was spricht gegen das Standard FreeBSD-Schema, das man bekommt, wenn man z.B.

vlans_lagg0="12 13 14"

in rc.conf setzt?

Gruß
Patrick

[Layer8]

@franco:

Deinen ersten Satz könnte man schon als leicht unsachlich interpretieren. Deinen letzten Satz, indem du Gründen in Anführungszeichen packst ebenso. Aber es ist vielleicht nur ein Fall von "Text schluckt Seitenkanäle der Kommunikation" und ich habs völlig falsch aufgenommen. Darum ist für mich auch alles gut und es geht ganz sachlich weiter:

Kann es sein dass ich mich unklar ausgedrückt habe oder du was falsch verstanden hast? Ich hab mit dem Zitat was du nun schon 2x gebracht hast die Durchnummerierung nach dem Schema vlan01, vlan02, vlan03 usw. gemeint (seit 22.1.4) und nicht das aktuelle Schema, was mit 22.7.6 eingeführt wurde.

Ja, was dieses Schema ab 22.1.4 angeht, da bleib ich bei meiner Meinung, dass das keine gute Idee war.

Das Schema vor 22.1.4 war um Welten besser. Das jetzige was seit 22.7.6 eingeführt wurde geht in die richtige Richtung, aber ist trotzdem irgendwie nicht das gelbe vom Ei.

Würdest du bitte noch auf den Vorschlag eingehen, dass der Device-Name im Rahmen der syntaktischen Freiheitsgrade (schön formuliert, das trifft den Nagel auf den Kopf) einfach selbst vergeben werden darf?

[Layer8]

Ich kann mit durchnumerierten vlanX problemlos leben - es ist doch alle Info im UI. Und auf der Shell sowieso. Daher versteh ich die Aufregung nur teilweise.

Aktuell ist vlanX nicht möglich (zumindest wenn X eine beliebige, frei definierbare Zahl sein soll). Aktuell ist nur vlan0X möglich, wobei X entweder leer sein kann oder eine Kombination aus Punkten und Zahlen. Zumindest hab ich meyergru im zweiten Beitrag so verstanden.

Ich verstehe den Zweck der 0 hinter VLAN nicht.

[Patrick M. Hausen]

Ich benutze den automatisch erzeugte Standard vlan0-N und verstehe nicht, welche Info dann fehlt. Man sieht im UI doch überall die Beschreibung bzw. den symbolischen Namen wie LAN, OPT1, etc.

Und im CLI spuckt "ifconfig" auch die Beschreibung mit aus. Ist doch schnurz, wie die Dinger heißen. Das erste lagg ist lagg0, das zweite lagg1, ... das erste VLAN ist vlan0, das zweite vlan1, ...

Die Info zur Semantik, also Parent und VLAN-Tag findet sich doch woanders, die muss nicht in den Namen.

Aber wenn man das unbedingt braucht, weshalb macht die OPNsense dann nicht automatisch das, was auch FreeBSD macht: lagg0.12, em1.17, ... etc.

Cisco IOS auf Routern übrigens genau so. Einfach ".n" für 802.1q Subinterfaces.

Gruß
Patrick

[meyergru]

Also ich bin da nicht dogmatisch, aber @pmhausen: Es ist eben nicht vlan0, vlan1 usw., sondern vlan01, vlan02 usw., wenn ich dem Code trauen darf.

Es ist richtig, dass man über den symbolischen Namen (Description) den Interfaces selbst sprechende Namen geben kann, nur, wenn man z.B. ein VLAN für PPPoE braucht, sieht man z.B. beim zugeordneten Link-Interface ja nur den technischen Namen.

Suche ich nach dem Link-Status, sehe ich in der Overview-Sicht zwar den Status, aber nicht das "wirkliche" VLAN. Auch in den Assigments wurde die VLAN-ID erst vor kurzem hinzugefügt.

Das ist aber alles nur "Convenience" und limitiert funktional nicht die Bohne, zudem es einen Workaround gibt...  :D

[Layer8]

Das ist aber alles nur "Convenience" und limitiert funktional nicht die Bohne, zudem es einen Workaround gibt...  :D

Ja, da stimme ich zu. Die Sense läuft ja auch trotzdem noch. ;-)

Also ich bin da nicht dogmatisch, aber @pmhausen: Es ist eben nicht vlan0, vlan1 usw., sondern vlan01, vlan02 usw., wenn ich dem Code trauen darf.

So ist es. Habs grad ausprobiert, die VLAN-Interfaces beginnen immer mit vlan0.

Wenn man das Feld Device beim Anlegen eines VLAN nicht ausfüllt, wird nach wie vor stumpf hochgezählt. Also VLAN01, das näcshte VLAN02, VLAN03, usw...

Wenn man das Feld Device ausfüllt, muss zwingend "vlan0" vorne dran stehen. Danach dürfen dann Punkte und zahlen folgen.


Der angesprochene Convenience-Nachhteil ist doch schon ziemlich groß. Zumal ja auch an allen Ecken und Enden in der GUI immer wieder Darstellungsprobleme auftauchen, Tabellen sich nicht gut sortieren lassen, usw...

Der Nachteil vom Workaround bedeutet auch immer, dass man einen Neustart durchführen muss. Wir setzen schon recht stark auf Segmentierung. Das hat zur Folge, dass wir oft neue VLAN-Interfaces anlegen und wir dann recht häufig neu starten müssten für den Workaround. Mal von den Ausfallzeiten abgesehen (wer will das schon bei nem Core-Router/FW?), ist das doch ein ziemlich nerviger und kostentreibender Aufwand. XML runterladen, editieren, hochladen, neu starten, manchmal auch hoffen, dass der Faktor Mensch keinen Fehler ins XML gehackt hat.

Ich hatte früher bereits auch folgende Frage gestellt auf die bisher noch keine Antwort kam:

Was passiert mit Altinstallationen?

Entweder man supported solche Installationen mit z.B. igb0_VLAN0010 auf ewig weiter (und muss dementsprechend dann auch den Code pflegen). In dem Fall kann man die künstliche Einschränkung raus nehmen, denn dann wird der Workaround von meyergru auch auf ewig funktionieren.

Oder es ist absehbar, dass igb0_vlan0010 irgendwann nicht mehr unterstützt und nur noch vlan0.10 gehen wird und Altinstallationen dann ein Migrationsproblem haben werden.


Noch ein Aspekt:

Was ist, wenn ich mehrere Parent-NICs hab, also bspw. igb0, igb1, igb2, igb3, usw...
Und was ist, wenn ich auf igb2 und 3 jeweils VLAN 10 liegen habe, aber das eine VLAN 10 zu Kunde/Mandant A gehört, das zweite VLAN10 zu Kunde/MandantB und diese VLAN10 nix miteinander zu tun haben?

OK, ich könnte dann vlan0.2.10 für igb2 mit vlan10 schreiben und vlan0.3.10 für igb3 mit anderem vlan10.

Aber was wenn ich igb0 und re0 verbaut hab? Dann geht vlan0.0.10 wieder nicht, weil es zwei unterschiedliche Karten mit 0 gibt.

[Patrick M. Hausen]

igb2.10 und igb3.10 wären m.E. am sinnvollsten. Macht klar, dass es Subinterfaces sind - und das sind sie in OPNsense, FreeBSD ist kein Switch.

[franco]

Ok, also noch mal um die Absurdität des ständigen "aber" auszudrücken zu lesbaren Gerätenamen:

2-5 Zeichen Treibername
1-2 Zeichen Treiberindex
1 Trennzeichen VLAN
1-4 VLAN ID
1 Trennzeichen QINQ
1-4 VLAN ID

ergibt

Minimum 7 Zeichen Gerätename
Maximum 17 Zeichen Gerätename

Die Grenze ist 15. Das habe ich bereits gesagt.

Wie soll das technisch für alle Fälle funktionieren?