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

[Layer8]

Wie heißen die Treibernamen mit 4 und 5 Zeichen?

VLAN, LAGG, VXLAN, QinQ ?

Sehe da zwei Möglichkeiten. Entweder man schneidet den Treibernamen einfach nach dem dritten Buchstaben ab. VLAN = VLA, LAGG = LAG, QinQ = Qin, VXLAN = VXL. Sieht manchmal doof aus und ist nicht gerade einleuchtend.

Oder, so machen wir es oft, man wird kreativ: VLAN = vID, VXLAN = xID oder VXL, LAGG = LAG, QinQ = qiq.

Mein Favorit im Aufbau wenns um VLAN und QinQ geht:

phy11.2222.3333

phy = Treibername wie igb, vmx, re, lag, etc.
11 = 0 - 99
2222 = Wenn kein QinQ genutzt wird ist das die VLAN ID, wenn QinQ genutzt wird ist es die QinQ ID. Bereich 1-4094
3333 = Wenn nur VLAN genutzt wird, entfält diese Zahl. Wenn QinQ genutzt wird, wird damit die innere VLAN-ID dargestellt. Bereich 1-4094


Und noch besser wärs, wenn man den Devicename einfach selbst wählen darf. ;-)


Bei VXLAN ist sowieso alles zu spät, weil da allein 8 Stellen für die ID drauf gehen können. Da bleibt dann oft nur vxlan12345678 oder sowas.

[meyergru]

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

...

Die Grenze ist 15. Das habe ich bereits gesagt.

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

Das geht - automatisch - natürlich nicht aufgrund der Grenze von 15 Zeichen.

Ich habe nur noch nicht verstanden, wieso man manuell nicht innerhalb der normalen Freiheitsgrade Interface-Namen vergeben kann - zudem legacy-Namen ja ohnehin nicht dem Pattern für manuelle Vergabe entsprechen.

Theoretisch denke ich mir, man könnte doch den Nutzer selbst den Namen vergeben lassen, die Automatik so belassen wie sie ist und vor / beim Speichern auf Kollisionen prüfen? Die Prüfung benötigt man doch sowieso, falls vorher jemand zufällig den automatisch vergebenen Namen belegt hat.

Damit wären die künstlichen Limits überflüssig. Und bei der automatischen Vergabe kann man bei etwaigen Kollisionen einfach solange weiter hochzählen, bis keine Kollision mehr auftritt - wahrscheinlich ist das sowieso schon so implementiert.

Vielleicht entgehen mir auch nur die offensichtlichen "Annahmen des Codes", die feste Regeln für die manuelle Vergabe erzwingen.

[franco]

> Wie heißen die Treibernamen mit [...] 5 Zeichen?

"vtnet" sind fünf. Ich würde meine Hand nicht ins Feuer legen, dass dann auch bei 5 schon die Grenze heute oder in der Zukunft erreicht ist.

> Ich habe nur noch nicht verstanden, wieso man manuell nicht innerhalb der normalen Freiheitsgrade Interface-Namen vergeben kann - zudem legacy-Namen ja ohnehin nicht dem Pattern für manuelle Vergabe entsprechen.

Ganz einfach: weil viel vorhandener Code darauf angewiesen ist definierte Namen und Pattern zu erkennen und dann entsprechend zu handeln: vom Erkennen von Hardware Interfaces in get_interface_list() oder wenn eine Entscheidung über die Zugehörigkeit oder Verhalten eines Treibers erkannt werden muss, z.B. https://github.com/opnsense/core/blob/da9c21c550d915ef5edff8e013700e8d68371652/src/etc/inc/plugins.inc.d/core.inc#L289 usw.

Lassen wir alles zu, dann wird langfristig ein Bug gemeldet, der auf die manuelle Benennung abzielte oder wo sich darüber beschwert wird, dass das Zeichenlimit überschritten wurde. Z.B. auch in https://github.com/opnsense/core/issues/3222 ging es um überlange automatische Interfaces, amüsanterweise auch in Verbindung mit dem (fast zu langen) VLAN Legacy Namen.

Man könnte jetzt annehmen das passiert hier alles böswillig, oder weil viel umgestellt und verbessert wurde, weil aus Fehlern gelernt werden muss und wir uns keine absehbaren Patzer leisten können. Und hier sind viele vorhersehbare Patzer in Ideen vorhanden auf die ich nicht weiter eingehen muss.


Grüsse
Franco

[meyergru]

Nachvollziehbar, danke für die Erklärung, Franco.

Wie ich schrieb: die Probleme durch implizite Annahmen über den Inhalt von Interface-Namen an anderen Stellen sind von außen natürlich nicht offensichtlich. Böswilligkeit hätte ich niemals unterstellt.

Ich kenne das Problem aus Legacy-Code nur zu gut und auch viel neuere Software wird so designed. Ich versuche eigentlich immer zu vermeiden, Inhalt und Form zu vermischen. Der Merksatz, den einer meiner Mitarbeiter dazu mal geprägt hat, war: "Namen sind nicht das, was sie bedeuten." Anders gesagt, Namen sollten dem Benutzer erlauben, etwas zu benennen, nicht implizit Attribute des benannten Objekts beinhalten.

Tatsächlich kann man über die Bezeichnung ja beliebige symbolische Namen für Interfaces vergeben, bei VLANs fällt es nur eher auf, z.B. weil bei der Konfiguration von PPPoE-Interfaces eben nicht die Bezeichnung, sondern der technische Name verwendet wird, der weniger sprechend ausfällt.

[Patrick M. Hausen]

Dann aber eine Frage, Franco - denn das nervt dann tatsächlich meine "OCD" (habe ich natürlich nicht klinisch, aber so als Nerd, der es gerne ordentlich hat ...)

Weshalb vlan01, vlan02, vlan03, ...

Ich kann mit automatischer Benennung im Gegensatz zu anderen prima leben und brauch auch gar keine manuellen Namen. Aber dann doch bitte genau wie für alle anderen Interfaces: vlan0, vlan1, vlan2, ... vlan10, vlan11 ...

Ja, das geht bei alphabetischer Sortierung in die Hose, aber das war schon immer so, ist bei allen anderen Interfaces so  - bitte einheitlich.

Ginge das? Issue aufmachen?

Gruß
Patrick

[franco]

Ja, pppoe, lagg, gif, gre, bridge usw. -- da ist das irgendwie weniger relevant.

Es gibt leider 2 Sachen die schon jahrelang die Modernisierung aufhalten: die Device Namen aus dem System sind hard verdrahtet in der Konfiguration, Hardware-Interfaces alle implizit und leider der Gerätename auch noch direkt im Interface eingetragen anstatt eine Referenz-ID zu verwenden.

D.h. ändert man einen Device-Namen muss auch zwangsläufig die Interface-Referenz geändert werden und dann auch die Konfiguration neu eingespielt werden mit erneuern der Firewall Regeln sogar. In dem Sinne sind die VLANs aus alter Konfiguration eine Augenweide an Seiteneffekten und Sonderbehandlung.

Schöner wäre das Loslösen über einen Gruppennamen, aber auch der ist auf 15 Zeichen beschränkt und auch anderweitig reglementiert:

# ifconfig vlan06 group igb03434445476de
ifconfig: setifgroup: group name too long
# ifconfig vlan06 group igb0.343
ifconfig: setifgroup: group names may not end in a digit

Das schränkt den Spielraum eigentlich genau so ein und nicht immer kann eine Gruppe referenziert werden (ifconfig selber zum Beispiel behandelt keine Gruppen).

Man könnte natürlich einen Wrapper bauen, oder die internen Tools anpassen:

# pluginctl -d
bridge
gif
gre
lagg
ppp
vlan
wlan
ipsec
loopback
openvpn
vxlan
# pluginctl -d vlan
igb2_vlan42
vlan01.
vlan0.3
vlan0.5.6.7
vlan05
vlan06
qinq0.123
vlan0.1.23

Aktuell nur eine Auflistung aus einer Überarbeitung aus der Entwicklungsversion, aber wer sich im ifconfig verloren sieht angesichts der "Unklarheiten" könnte hiermit Licht ins dunkel bringen wenn man mehr Informationen hinzufügt bei der Auflistung. Das würde dann auch dem Kern nicht schaden da es alles im Tool erledigt werden kann.

Die frühere Frage bleibt: ist das arbeiten in der GUI beeinträchtigt? Dann können wir noch was verbessern.  Ist das arbeiten in der Konsole beeinträchtigt Dann können wir ja... auch noch was verbessern?


Grüsse
Franco

[franco]

Patrick: Die Motivation der 0 war die eindeutige Abgrenzung zu Systeminterfaces die manuell angelegt wurden und dabei gleichzeitig die Regex [a-z]+[0-9]+ zu erfüllen, genau wie "qinq" verwendet wurde anstatt "vlan". Kann kein Erfolg versprechen, aber werde mich am Ticket beteiligen.


Grüsse
Franco

[Patrick M. Hausen]

Es gibt ja nun ein z.B.

Code: [Select]

ifconfig em0 name i0
ifconfig igb0 i1
...
Das hat z.B. die Sidewinder-Firewall gemacht und damit abstrahiert man die Hardware-Typen weg.

Wir haben in unserer Hosting-Plattform alle "uplink" Interfaces "inet0" genannt. Alle bridges für Jails "jail0, jail1, ...". Haben wir erst geändert als wir durchgängig lagg bekommen haben und alles auf VLANs gelegt. Seitdem heißen die alle lagg0.<vlan-id> - wie FreeBSD das eben automatisch macht.

Aber die Treiber-Eigenheiten wegbenennen wie die Sidewinder - wäre das was?

[franco]

Wäre es nicht sinnvoller die Zeichenbeschränkung zu erhöhen?


Grüsse
Franco

[Patrick M. Hausen]

Let's see 

Ich frag morgen mal nett auf freebsd-net ...

[Layer8]

Absicht hätte ich auch nicht unterstellt. Alles hat irgendwie Gründe. Danke franco, dass die Diskussion jetzt in Gang gekommen ist und für die Erklärungen.

Wäre es nicht sinnvoller die Zeichenbeschränkung zu erhöhen?

+1 für den Königsweg.

Die frühere Frage bleibt: ist das arbeiten in der GUI beeinträchtigt? Dann können wir noch was verbessern.  Ist das arbeiten in der Konsole beeinträchtigt Dann können wir ja... auch noch was verbessern?

Ja, wenns darum geht, würd ich mir auch die Finger wund tippen. Ist nur immer die Frage ob das auch jemand liest oder jemanden interessiert. Hab ich schon mal gemacht, aber es kam keine Reaktion mehr  Das ganze zu scrennshotten, beschreiben, etc., kost ja auch seine Zeit.

Ganz allgemein gefragt (vielleicht trifft das auch den Kern des angesprochenen Wrappers?):

Kann man für die GUI und CLI nicht einfach ne Übersetzungstabelle bauen? So dass im Unterbau einfach das Device so heißen kann, wie es für die Codepflege am besten ist, und dass in der GUI oder in der CLI Bezeichnungen benutzt werden können, die einfach sprechender sind und keinen nennenswerten Restriktionen unterliegen?

[Patrick M. Hausen]

Aber im UI heißen die Objekte doch schon WAN, LAN, OPT1, ... und du kannst statt OPT1 Dinge wie Customer_ACME, Uplink_Telekom, ... verwenden.

Wo braucht man im UI jemals den Device-Namen? Den Teil begreife ich wirklich nicht. OPßnsense legt da doch auch ganz ohne VLANs schon eine Abstraktionsebene drüber?

[Layer8]

Ich seh das halt so:

vlan01 ist genauso vielsagen wie eine kryptische UUID. Es ist eine Information, die zwar mit zusätzlichen Infos verortbar ist, aber ohne zusätzliche Wissen nicht weiter hilft. Man muss im Kopf haben wofür es steht oder wo anders nachschauen um zu wissen was es bedeutet. Einenen schnelle Überblick, der nur das Auge bemüht, kann man sich so nicht verschaffen. Und das ist einfach anstrengend.


Wenn ich mir Interfaces - Assignements angucke, sehe ich in der spalte Network Port ein Durcheinander aus den alten Bezeichnungen vmx1_.... und vlan01, vlan02, etc.. Da dort auch nicht alles in die Felder rein passt, sind die Informationen auch teilweise noch abgeschnitten. Diese Tabelle ist zum Beispiel ein wichtiger Anlaufpunkt um schnell sehen zu können, ob das richtige Interface zum richtigen Device passt.

Wenn ich mir Interface - Other Types - VLAN angucke, hab ich wieder so ein Durcheinander. Die alten Interfaces mischen sich mit den neuen vlan07 und vlan0.1234. Ich kann da nicht auf die Schnelle gucken, ob alle vmx1 parent interfaces nur mit vmx1_*-Devices verknüpft sind, weil sich halt zwischendrin die vlan0*-Interfaces tummeln.

Wenn ich Logfiles durchsuchen will, muss ich mal nach vlan0* , mal nach vmx1_vlan10, mal nach vlan0.1234  suchen. Ich brauch drei Anläufe, muss 3x ein Logfile durchgucken und dann vielleicht Informationen aus den drei Suchdurchläufen kombinieren. Das dauer länger, als wenn man ein Logfile einmal durchsuchen muss und einem dann Infos ins Auge springen.

Wenn in der Konsole Events auftauchen, dann steht dort auch öfter mal vlan0* und ich weiß erstmal nicht, um welches Netz es sich genau handelt. Auch da muss ich erstmal nachschauen.


Ich arbeite viel mit Descriptions, was einiges abfängt. Solang die aber nicht konsequent als führende Information angezeigt, geloggt, in Grafiken verabeitet, in Spalten nach vorne gerückt werden etc., bleibts ein Durcheinanders.

[JeGr]

@franco:
> "vtnet" sind fünf. Ich würde meine Hand nicht ins Feuer legen, dass dann auch bei 5 schon die Grenze heute oder in der Zukunft erreicht ist.

Nur als kurze Info dazu: Da darf ich gern auf pfSense bzw. deren ARM Build für die espressobin Boxen (1100/2100) verweisen. Das verwendete Switch/Interface hat als Benennung

"mvnetaX"

6-stellige Bezeichner sind also durchaus ein Ding.