Mehr Komfort durch trunk?

berni51

Open-Net-FreeBSD user
Um meine Laptops mit OpenBSD auf Reisen etwas komfortabler zu machen, bin ich auf trunk gestoßen. Kannte ich bisher nicht, aber die automatische Erkennung der aktiven Netzwerkverbindung finde ich reizvoll. Die Konfiguration scheint spielend einfach, also hab ichs mal ausprobiert.
Tatsächlich erkennt trunk, ob die LAN-Schnittstelle aktiv ist, und weil die Priorität hat, ist das dann die Schnittstelle der Wahl. Ist die LAN-Schnittstelle inaktiv, wird auf die WLAN-Schnittstelle umgeswitcht.
So weit, so gut und bis dahin klappt das ordentlich.
Ein Wechsel der Schnittstellen im Betrieb allerdings funktioniert nicht wirklich. Mal ist ein device busy, mal kennt die Schnittstelle ihre Route nicht mehr. Erst mit einem Neustart ist die Welt dann wieder in Ordnung.
Der Manpage nach ist ja nicht viel zu beachten, deshalb meine Frage:
Verlange ich zuviel von trunk oder mache ich was falsch?

Meine Konfiguration sieht wie folgt aus:
/etc/hostname.re0:
up

/etc/hostname.iwn0:
nwid waspnet wpakey **********
up

/etc/hostname/trunk0:
trunkproto failover trunkport re0
trunkport iwn0
dhcp

Wo liegt der Fehler?
 
Ich war jetzt irritiert wegen trunk und dachte an asterisk. :rolleyes:

Mal geraten, habe keine Ahnung davon:
Kann man das statts failover als parallel einrichten? Meiner Erfahrung nach funktioniert was aktives (round-robin) bei Ausfall besser als was nachgelagertes.
 
Ich glaube das geht nicht. Und mit roundrobin habe ich ja keine Möglichkeit, eine Priorität zu setzen.
 
Hoi, bei mir läuft das Super, hab das 1:1 aus dem OpenBSD FAQ übernommen - ist wlan und lan denn das gleiche physikalische netz?

cat /etc/hostname.trunk0
trunkproto failover trunkport em0
trunkport iwm0
inet 192.168.100.13 255.255.255.0
inet6 autoconf

cat /etc/hostname.em0
#dhcp
up

cat /etc/hostname.iwm0
nwid lalalala wpakey lalalalahierkönnteihrpasswortstehen
#inet 192.168.100.13 255.255.255.0
#inet6 autoconf
up

Hab auch noch nen 2. Notebook mit gleichem trunk, da läuft das auch problemlos.

Edit: Kleines PS, poste doch mal die Ausgabe von ifconfig, ggf. auch nach einem netzwechsel.
 
Hab jetzt noch mal alles gecheckt und dabei ein licht wackeliges LAN-Kabel entdeckt. Womöglich lags daran. Sieht schon besser aus:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
index 4 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000

iwn0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 4c:72:b9:0e:7a:2e
index 1 priority 4 llprio 3
trunk: trunkdev trunk0
groups: wlan
media: IEEE802.11 autoselect (HT-MCS3 mode 11n)
status: active
ieee80211: nwid waspnet-fritzbox24 chan 11 bssid 34:81:c4:b2:a8:50 -28dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

re0: flags=8b02<BROADCAST,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
lladdr 4c:72:b9:0e:7a:2e
index 2 priority 0 llprio 3
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
enc0: flags=0<>
index 3 priority 0 llprio 3
groups: enc
status: active

trunk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 4c:72:b9:0e:7a:2e
index 5 priority 0 llprio 3
trunk: trunkproto failover
trunkport iwn0 active
trunkport re0 master
groups: trunk egress
media: Ethernet autoselect
status: active
inet 192.168.0.99 netmask 0xffffff00 broadcast 192.168.0.255

pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
index 6 priority 0 llprio 3
groups: pflog

Allerdings meint die Fritbox, ich wäre immer noch über WLAN am Netz, obwohl jetzt ein LAN-Kabel gesteckt ist. Wie könnte ich das mal testen, welches if wirklich aktiv ist?
 
Einfach mal pingen? Oder kriegt WLAN schon <0.2ms hin?
Doch eigentlich schon :)

Hmm du kannst glaub irgenwo schauen welche if gerade aktiv ist, ich habs einfach mit nem zugriff auf meinen fileserver gemacht :)

trunkport iwn0 active klingt so als wäre da gerade das wlan aktiv.

Die anzeige der Fritzbox ist leider ziemlicher müll
 
hi

ich glaube ihr missversteht , miss braucht , die funktion des trunk.

ein trunk ist / soll eine link aggregation sein zur z.b. ausfall sicherheit.
deswegen kann das ding auch lacp sprechen.

es ist keine Bridge !

holger
 
hi

ich glaube ihr missversteht , miss braucht , die funktion des trunk.

ein trunk ist / soll eine link aggregation sein zur z.b. ausfall sicherheit.
deswegen kann das ding auch lacp sprechen.

es ist keine Bridge !

holger

Hi,

janein, grundsätzlich ist ein trunk mit lacp (bei switchherstellen oft link-aggregation oder bridge-aggregation, da ist ein trunk dann z.B. oft ein interface das mehrere vlans weitergibt, also etwas komplett anderes) zur ausfallsicherung oder "bündelung"* von zwei oder mehr interfaces gedacht. (*Ich weiß, bündelung ist nicht ganz richtig)

In diesem speziellen Szenario wird der trunk innerhalb von openbsd als eine einfache möglichkeit verwendet zwischen wlan und lan zu wechseln, da der trunk so konfiguriert ist das er feststellt wenn das "lan" interface up ist er das nutzt und wenn es down ist er das wlan-interface nutzt sofern verfügbar. Dadurch geht der wechsel schnell, also in unter einer sekunde und da sich auch die mac nicht ändert e.t.c. bleiben sessions, z.B. ssh meist bestehen was u.U. sehr praktisch ist. Deshalb kann man in dem szenario auch kein lacp verwenden.
(U.a. wird in diesem szenario immer nur ein interface "aktiv" verwendet was sonst zu problemen führen kann und openbsd muss keine "gegenseite" aktiv irgendetwas abfragen was es unter wifi auch glaub ich garnicht gibt und die meisten soho router & switche auch nicht können)

Dieses vorgehen wird in der OpenBSD FAQ https://www.openbsd.org/faq/faq6.html#Wireless so durchaus empfohlen.

LG
Zed
 
Du nicht, arp e.t.c. schon :)

Ich weiß ehrlich gesagt nicht so genau warum ohne trunk son wechsel so lange dauert bzw. sessions droppen wenn man z.B. zwei interfaces mit eigenen ips im gleichen netz aktiv hat und die eine wegfällt.

Hab jetzt nicht so viel Ahnung von der Materie, vermute aber das wenn die über verbindung a gehen die session halt komplett "weg" ist wenn b ein komplett eigenständiges interface mit eigener ip & mac ist.
Für das "ziel" sieht es ja wie ein komplett anderer host aus von dem dann die Datenpakete kommen, ziel kann da ja auch der router sein.

Wie entscheidet sich denn bei 2 interfaces im gleichen Netz generell welches ausgehend verwendet wird? Gibts da irgend ne Prio oder so?

/edit Kleine rechtsschreibkorrektur
 
IP-Wechsel -> Session definitiv weg, weil TCP eindeutige IP:Port-Kombination benutzt
MAC-Wechsel -> ARP-Caches müssen erneuert werden, dann hält die Session. TCP benötigt stabilen Layer 3 und 4, alles darunter kann man austauschen, z.B. kann einem OSPF eine andere Route über ein anderes Gateway zuschieben (= andere MAC-Adresse, an die man sendet). Solange die Pakete mit unveränderter IP:Port-Kombo rumfliegen, hält die Session.

2 Interfaces im gleichen Netz ohne Mechanismus, der einen gemeinsamen Layer 3 darauf abbildet, sollte man nicht machen.
 
Hi,
Würde ne Bridge da nicht nen loop bauen wenn ich im gleichen lan zwei ports miteinander verbinde?
Und funktioniert das überhaupt? Wifi ist ja nicht ganz exakt ethernet?

Ich glaube die OpenBSD entwickler haben sich mit dem FAQ eintrag schon etwas gedacht ...

@tcm> Das ist ja in dem szenario auch immer ein ip wechsel, da ja nicht beide interfaces die gleich ip haben können, dann war ich ja gedanklich nicht so weit weg :)
 
Zurück
Oben