Bug 28318 - Doku: Unterstützung für Bridges, VLANs, Bonding / Flexibilität via UCR
Doku: Unterstützung für Bridges, VLANs, Bonding / Flexibilität via UCR
Status: CLOSED FIXED
Product: UCS extended documentation
Classification: Unclassified
Component: IP and network management
unspecified
All Linux
: P4 enhancement (vote)
: UCS 3.1
Assigned To: Philipp Hahn
Moritz Muehlenhoff
:
Depends on: 26058 32297
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-27 10:58 CEST by Stefan Gohmann
Modified: 2015-04-01 13:50 CEST (History)
9 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): IPv6, Release Goal
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2012-08-27 10:58:49 CEST
Die Doku aus Bug #26058 sollte in die erweiterte Doku übernommen werden.

+++ This bug was initially created as a clone of Bug #26058 +++

Created an attachment (id=4157)
Überarbeitet Vorlage /etc/network/interfaces

/etc/network/interfaces wird derzeit von einem relativ starren Template
verwaltet, was es nur erlaubt Interfaces zu definieren, deren Name mit "eth"
beginnt. Das reicht nicht.
* Bug #23947, Bug #23514, Bug #22670: Bridges heißen normalerweise brX
* Bug #23411, Bug #19460: Bonding-Interfaces heißen normalerweise bondX
* Bug #22967: Unterstützung für VLAN-Interfaces, je nach Modus u.a. vlanX
* dummyX, wlanX, ...-Interfaces
Gerade in Verbindung mit Virtualisierung und HA sind solche Konfigurationen
heute öfters notwendig und sollten abbildbar sein, ohne das man das Template
anfassen muß.
Die angehängte Version implementiert keine spezielle Unterstützung für die
obigen 3 Hauptfällt, sondern vergößert die Flexibilität, so daß sich diese dann
auch den bereits vorhandenen "options/"-Mechanismus abbilden lassen.

1. Im Gegensatz zu Attachment 3305 [details] entfernt der angehängte Patch die
Restriktion, das nur Interfaces verwendet werden, die mit "eth" beginnen, so
daß über UCR-Variablen nur beliebige Interfaces konfiguriert werden können.
2. Über die neue UCR-Variable interfaces/primary kann angegeben werden, welches
das primäre Interface (Standard: "eth0") sein soll. Innerhalb des Templates
wird das für das default-Gateway verwendet.
3. Da sich interfaces verschachteln lassen (bridge → vlan → bonding), kann man
über die UCVR "interfaces/$name/active" das automatische Aktivieren per
"auto"-Statement unterdrücken. Standard ist hier weiterhin "true".

TODOs:
4. Die UCR-info-Dateien sind noch anzupassen, das nicht nur auf interfaces/eth*
getriggert wird.
5. Hier wäre aber nochmal generell zu überprüfen, ob andere Templates nicht
auch stillschweigend davon ausgehen, das eth0 das Standardinterface ist; die
müssten das dann auch auch besagter UCRV auslesen (initramfs.conf, slapd.conf,
dhclient.conf, initramfs.conf, issue, ifplugd, hosts)
6. testen, testen, testen ...

Beispiele:
 Auf einem Testsystem in folgendes Konstrukt einrahmen:
  ifdown -a ; ifup lo
  ucr unset $(ucr search --brief '^interfaces/.*/' | sed -ne 's/: .*//p')
  ...
  ucr commit /etc/network/interfaces ; ifup -a

 Bonding mit eth{0,1}:
  #ucr set kernel/modules="$(ucr get kernel/modules) bridge"
  ucr set \
   interfaces/eth{0,1}/{\
    type=manual,\
    start=false} \
   interfaces/bond0/{\
    address=192.168.122.13,\
    broadcast=192.168.122.255,\
    netmask=255.255.255.0,\
    network=192.168.122.0,\
    options/1="bond-slaves eth0 eth1",\
    options/2="bond-mode 1",\
    options/3="mmimon 100",\
    options/4="bond-primary eth0 eth1",\
    start=true} \
   interfaces/primary=bond0

 Bridge mit eth{0,1}:
  #ucr set kernel/modules="$(ucr get kernel/modules) bonding"
  ucr set \
   interfaces/eth{0,1}/{\
    type=manual,\
    start=false} \
   interfaces/br0/{\
    address=192.168.122.13,\
    broadcast=192.168.122.255,\
    netmask=255.255.255.0,\
    network=192.168.122.0,\
    options/1="bridge_ports eth0 eth1",\
    options/2="bridge_fd 0",\
    start=true} \
   interfaces/primary=br0

 VLAN {1,2} über eth0:
  #ucr set kernel/modules="$(ucr get kernel/modules) 8021q"
  ucr set \
   interfaces/eth0/{\
    type=manual,\
    start=false} \
   interfaces/eth0.2/{\
    address=192.168.122.13,\
    broadcast=192.168.122.255,\
    netmask=255.255.255.0,\
    network=192.168.122.0,\
    start=true} \
   interfaces/eth0.3/{\
    address=10.200.17.1,\
    broadcast=10.200.17.255,\
    netmask=255.255.255.0,\
    network=10.200.17.0,\
    start=true} \
   interfaces/primary=eth0.2

 Alles: bonding über eth{0,1] für HA, Host-übergreifende VLANs, Bridging für
VMs, Host über eth2
  ucr set \
   interfaces/eth{0,1}/{\
    order=2,\
    type=manual,\
    start=false} \
   interfaces/bond0/{\
    order=3,\
    type=manual,\
    options/1="bond-slaves eth0 eth1",\
    options/2="bond-mode 1",\
    options/3="mmimon 100",\
    options/4="bond-primary eth0 eth1",\
    start=true} \
   interfaces/bond0.{2,3}/{\
    order=4,\
    type=manual,\
    start=false} \
   interfaces/br2/{\
    order=5,\
    type=manual,\
    options/1="bridge_ports bond0.2",\
    options/2="bridge_fd 0",\
    start=true} \
   interfaces/br3/{\
    order=5,\
    type=manual,\
    options/1="bridge_ports bond0.3",\
    options/2="bridge_fd 0",\
    start=true} \
   interfaces/eth2/{\
    order=1,\
    address=192.168.122.13,\
    broadcast=192.168.122.255,\
    netmask=255.255.255.0,\
    network=192.168.122.0,\
    start=true} \
   interfaces/primary=eth2
  # VLAN _muß_ indirekt über Bridging gestartet werden, deswegen dort unbedingt
start=false
Comment 1 Moritz Muehlenhoff univentionstaff 2012-10-09 11:36:44 CEST
Die Einrichtung von Bridges/Bonding/VLANs wird nun in der erweiterten Computer-Dokumentation beschrieben (extended-docs/computers.xml)

Das Rechnerkapitel (7.2.4.1.4) verweist auf diese Doku.
Comment 2 Philipp Hahn univentionstaff 2012-10-15 11:10:53 CEST
Nochmal grundlegend überarbeitet, insbesondere das Beispiel für eine Kombination von bond+VLAN+bridge aufgenommen, weil das i.d. Praxis oft gewünscht ist (z.B. Kunde 26).
Auch habe ich probiert die Abschnitte ein bisschen besser zu strukturieren, gerade was Hard- und Software-Voraussetzungen angeht.

svn15254, <http://jenkins.knut.univention.de:8080/job/UCS-3.1%20Handbooks/152/artifact/extended-docs/computers.pdf>


(In reply to comment #1)
> Das Rechnerkapitel (7.2.4.1.4) verweist auf diese Doku.

Der Verweis auf das Handbuch scheint noch nicht so ganz zu funktionieren:

# xsltproc -o handbuch.html ... handbuch.xml
ERROR: xref linking to ext-doc-computers has no generated link text.
Error: no ID for constraint linkend: ext-doc-computers.
# grep ext-doc-computers *
computers-de.xml:                                 <xref linkend="ext-doc-computers"/>.
computers-en.xml:                       <!--   <xref linkend="ext-doc-computers"/>. -->
Comment 3 Moritz Muehlenhoff univentionstaff 2012-10-16 16:15:35 CEST
Ein paar Anpassungen habe ich direkt commitet, ansonsten VERIFIED.
Comment 4 Janis Meybohm univentionstaff 2012-11-09 17:04:12 CET
Beim lesen des "Combined setup" wurde mir nicht klar warum die Begriffe trusted/untrusted verwendet werden um die Funktion bzw. Verwendung der VLAN Bridges zu beschreiben.

Ich denke die Beschreibung sollte entweder auf die trusted/untrusted Beschreibung verzichten können oder deren Verwendung durch eine Erläuterung der Anforderung an das Setup deutlicher machen.
Comment 5 Philipp Hahn univentionstaff 2012-11-09 17:43:20 CET
Ich habe noch eine kurze Szenariobeschreibung ergänzt.
svn28318
Comment 6 Moritz Muehlenhoff univentionstaff 2012-11-13 13:58:03 CET
(In reply to comment #5)
> Ich habe noch eine kurze Szenariobeschreibung ergänzt.
> svn28318

Ich habe ein paar Kleinigkeiten direkt angepasst (Revision 15566)