Dotaz: Bridge eth0 a wlan0

[RadekXxX]

Ahoj, snažím se propojit eth0 a wlan0 do jednoho rozhraní br0, ale chová se to takto:

1) Restart, mám připojen eth i wlan(to že je připojen vidím na AP), připojení jede, odpojím kabel eth, zůstává pouze wlan a konec 2) Restart, mám připojený pouze wlan, připojení nejede

výpis /etc/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
  wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto br0
iface br0 inet static
  bridge_ports eth0 wlan0
  address 192.168.1.254
  netmask 255.255.255.0
  gateway 192.168.1.1

Když vyhodím br0 a vše nastavím zvlášť (do jedné sítě) eth0-192.168.1.254 wlan0-192.168.1.253, tak při připojeném eth to jede, když odpojím kabel, tak spojení spadne, když dám ifconfig eth0 down, tak naběhne spojení přes wlan (wlan je od počátku připojen na AP)

Zkoušel jsem i bonding, ale tam jsem měl problém stím, že občas vypadávaly pingy (třeba 5 sec) a wlan se odpojovala od AP. Běží to Debianu, ARMv7 (A20 Allwinner) Linux test 4.1.3 #25 SMP Tue Feb 26 16:01:16 CET 2019 armv7l GNU/Linux

Jednoduše jde o to, aby když je zasunutý kabel, jel přes kabel, jinak přes wifi a idealně přes 1 IP.

Nemáte někdo nějakou radu ?

Odpovědi

[Max]

Tím, že dáš oba nechráněné porty do bridge, tak uděláš vlastně něco jako když v nemgmt switchi propojíš dva porty. Prostě uděláš smyčku na síti a zabiješ provoz a nejslabší článek v síti chcípne (broadcast storm apod.).
Aby toto mohlo fungovat přes bridge, musel by jsi mít v rámci sítě i toho linucha rozjetý RSTP (Rapid Spanning Tree), ale možná by to šlo i jinak, nevím.
To by bylo asi tak k tomu koncepčnímu hledisku.

To, co chceš, je tedy skutečně bonding, ale v režimu active-backup (mode=1)
Zdar Max

[Michal Kubeček]

Podle popisu bude chtít i "primary eth0 primary_reselect always".

Na druhou stranu z toho popisu není moc jasné, jestli se eth0 a wlan0 opravdu připojují do stejné sítě, aby to mělo šanci fungovat.

[RadekXxX]

To vysvětluje, proč se ledky i switch tak zběsile rozbliká. Nicméně jsem znovu zkoušel ten bonding, ale pořád mě běží v módu load balancing (round-robin)

# cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 28:f3:66:a0:66:ce
Slave queue ID: 0

Slave Interface: eth0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 02:87:06:43:24:e2
Slave queue ID: 0

# cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0 wlan0

allow-hotplug wlan0
iface wlan0 inet manual
    bond-master bond0
    bond-primary eth0 wlan0
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto bond0
iface bond0 inet static
    address 192.168.1.254
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
#    bond-slaves none
    bond-mode 1
#    bond-miimon 100
#    bond-downdelay 200
#    bond-updelay 200

Zkoušel jsem "bond-mode 1" i "bond-mode active-backup", ale pořád se to spouští v load balancing.

[Max]

Minimálně to "bond-primary eth0 wlan0" máš špatně. Nezkoušel jsem, ale zkusil bych to nějak takto :

nano /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
    bond-master bond0
   
auto wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    bond-master bond0

auto bond0
iface bond0 inet static
    address 192.168.1.254
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    bond-slaves eth0 wlan0
    bond-primary wlan0
    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

Zdar Max

[Max]

Nebo takto :

nano /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
    bond-master bond0
   
auto wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    bond-master bond0
    bond-primary wlan0

auto bond0
iface bond0 inet static
    address 192.168.1.254
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    bond-slaves none
    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

Zdar Max

[debian+]

snažím se propojit eth0 a wlan0 do jednoho rozhraní br0

Uz toto je chyba.

Jednoduše jde o to, aby když je zasunutý kabel, jel přes kabel, jinak přes wifi a idealně přes 1 IP.

Napis si skript alebo deamon program. Ak je siet - vypnuta je wifi. Ak nie je siet, wifi je zapnuta. Ak si neskuseny, tak wifi konfiguraciu budes len zapinat/vypinat deamon na auto-login wifi a zapinat/vypinat wifi zariadenie.

# zapnuta:
#    1 - ano
#    0 - nie
IS_UP=`ip link show enp5s0 |grep ,UP,|wc -l`

[Josef Kufner]

Já to řeším tak, že v Network Manageru mám hook, který při nahození jedné síťovky vypne tu druhou a od DHCP serveru dostávají obě MAC adresy stejnou IP adresu. Na routeru pak je vypnutá ochrana proti kradení IP adresy (rp filter?) a je to všechno hezké a funkční. Pro domácí použití je to docela vyhovující, ale zajímalo by mne nějaké čistší řešení, nejlépe zahrnující VPN pro vzdálený přístup do domácí LAN.

[k3dAR]

btw: prave sem resil bond v Ubuntu 18.04, s tim ze eth0 je auto dhcp a zbyle lan v bond, nefungovalo to kdyz pro bond0 byla nastavana gw, coz v predchozich (resp <=14.04) bylo ok... zaroven 18.04 prisla s netplan a kdyz se ma pouzit misto toho /etc/network/interfaces je potreba doinstalovat balicek ifupdown a ifenslave, nevim ted zda kvuli netplan, nebo systemd, ani zda to plati i pro Debian...

[Michal Kubeček]

ifenslave už by dávno neměl potřeba. Přidání interface do bondu se dá udělat buď pomocí

ip link set eth0 master bond0

nebo

echo +eth0 >/sys/class/net/bond0/bonding/slaves

[k3dAR]

any to bylo persistent, to davass do rc.local? nebo v interfaces do pre-up/up? s ifenslave se to provede samo, mam nejakou spatnou zkusenost s tim ze je lepsi misto toho to resit jak pises rucne?

[Michal Kubeček]

Samo se to neprovede, ten ifenslave musí někdo zavolat. A ten někdo by měl už dávno používat ip, sysfs nebo netlink (podle toho, jestli je to skript nebo program v C, případně jiném jazyce). Ale to je samozřejmě výtka k distribučním nástrojům, ne k uživateli, kterému nezbývá než žít s tím, co (ne)udělali v distribuci (pokud to tam nechce opravit sám).

[k3dAR]

ifenslave nemusim rucne volat, ma sve if-pre/post/up skripty v ramci distribucniho balicku:

/etc/network/if-post-down.d/ifenslave
/etc/network/if-pre-up.d/ifenslave
/etc/network/if-up.d/ifenslave

nicmene, "aby to bylo persistent, to davass do rc.local? nebo v interfaces do pre-up/up?"

[Michal Kubeček]

Tak ho volá ten, kdo ty skripty interpretuje, o to nejde. Podstata mé připomínky byla ta, že ten, kdo v distribuci konfiguruje síť, ať už je to nějaká sada skriptů, NetworkManager, wicked, systemd-networkd nebo něco úplně jiného, by už nějaký pátek neměl k nakonfigurování bondu potřebovat příkaz ifenslave, stejně jako by neměly být potřeba např. ifconfig, route, brctl nebo vconfig.

aby to bylo persistent, to davass do rc.local? nebo v interfaces do pre-up/up

Nic takového dělat nemusím, v distribuci, kterou používám, se o to postará wicked - a ifenslave k tomu nepotřebuje.

[k3dAR]

jasne chapu, mas pravdu, odinstaloval sem ifenslave a po rebootu je bond pres /etc/network/interfaces nahozen ok, nevim proc mi to pretim neslo, asi to bylo necim jinym co mezi tim opravil... takze:

oprava predchoziho: v Ubuntu 18.04 je pro pouziti konfigurace pres /etc/network/interfaces potreba doinstalovat pouze balicek ifupdown

[k3dAR]

tak "opravu" beru zpet

oprava opravy: plati co sem psal puvodne: balicek ifupdown a ifenslave

[k3dAR]

predpokladam ze kdyz primarne 18.04 pouziva netplan, tak pro interfaces&ifupdown neudelali upravy o kterych si mluvil, aby se obeslo bez ifenslave... dal neresim, nainstaloval sem ifenslave a funguje to

[lertimir]

Rozumím snaze o automatizaci procesů, ale na druhou stranu někdy ruční práce není na škodu, protože uživatel má vše pod kontrolou. Kdysi jsem řešil podobný problém, chtěl jsem, aby v domáci síti mělo zařízení (notebooky) stejnou IP ať jsou na drátu nebo na wifi. A nakonec jsem zvolil nejjednodušší variantu, v DHCP je nastavena stejná IP na obě MAC adresy notebooků a stejně když je připojuji na drát dělám manuální akci a tak je součást té manuální akce "zapichnu konektor vypnu wifi". A naučil jsem to i rodinu.

[Peter Golis]

V notebookoch sa obvykle dá nastaviť prepínanie WiFi a kábla už priamo v UEFI firmware. Človek zapne WiFi tkačítkom, a odpojí mu to kábel. Alebo zasunie kábel, a vypne mu to WiFi. Funguje to až na drobné výpadky kým sa pripojí WiFi, alebo kým dorazí DHCP Response s adresou.

Ale neviem si predstaviť dôvod prečo by malo vadiť že je počítač naraz pripojený naraz cez WiFi a aj cez kábel. Teda okrem toho, že bude mať dve rôzne IP adresy z jedného rozsahu na dvoch rôznych rozhraniach. Ono, takáto vec v Linuxe funguje už niekoľko rokov, odkedy dali do jadra podporu pre "priority routing". Ja by som sa na to vykašlal a nechal si dve IPky, tak ako som to robil už dávno.

[lertimir]

Chápu. já jsem to řešil pro zálohování přes BackupPC, server se připojí přes ssh na klienta a pustí rsync. Při dvou IP by to byly jako by dvě stanice.

[Peter Golis]

Tak by boli. BackupPC by mal predsa využívať deduplikáciu, takže údaje by nemali byť uložené dvojmo. A dúfam že ani odosielané. I keď s jednou IPkou je to prehladnejšie, to je pravda.

[lertimir]

deduplikace je jen na ukládání. usuzuji z toho, že když jede úplná záloha, jede nekolikrát déle než když jedou inkrementální zálohy. používám schéma U123412341234U takže když by se zálohovala jedna stanice ze dvou IP tak jednak ji to bude otravovat na obou adresách při vypršení časového intervalu a jednak se bude porovnávat, jen to co prošlo konkrétním interfacem a proti tomu bude se dělat inkrementální záloha.

[Peter Golis]

Žeby mal BackupPC implementovaný len koncept Full/Diff/Incr záloh, a nazýval to deduplikáciou? To sa mi nezdá, to by bol veľmi lacný marketingový ťah. Deduplikácia je o tom že sa duplikátne dáta ukladajú len raz.

[lertimir]

Napsal jsem to nepřesně. BackupPC určite zálohy ukládá deduplikovaně. Primární struktura v kompresovaném poolu je uložena podle hashů souborů

ls cpool 
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

# root @ gondor in /var/lib/BackupPC [10:30:05] 
$ ls cpool/1
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

# root @ gondor in /var/lib/BackupPC [10:30:34] 
$ ls cpool/1/1
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

# root @ gondor in /var/lib/BackupPC [10:30:40] 
$ ls cpool/1/1/1
11100347054936b2382193b290542696  11145d2460f591f39532e2a1bc075930  111831b2927dfe659c0624574632ea66  111c3973d7f5852368c066ae732b218a
111005246ee3f0332229605272230663  11145d2cb66cefd4cba6a3947369e295  11184035cbd3b7d7c3ec3559cf487544  111c45125869eca56530f0ef97655bc1
1110076115861165ab0eb106c4749921  111465bc6d45ad2478e9472fc10c5e1b  11184666b47dcfd28ff3e3cf4cbf5b36  111c4519adcc172e75c124958055404a
11100ac010c841f63c12f8c81148280e  111469dbca61ad9bfce7831baf6f48e1  11184c3245c02786d8eab38965e80490  111c49c81da92d47433b6d39fcbc7056
11100e9ac705f37f9afe20cba7d03e6d  11146d6148cf8edcc12fffd4f50caf23  1118523a473b1d7cb074a062390c0800  111c49d8280fb7742427c4918250bcb8

(ten poslední výpis ls je mnoohem delší) A na ni jsou pak na hardlinkované jednotlivé zálohy jednotlivých pc.

ls pc/dnopytle         
791  867  874  881          LOCK          LOG.072018.z   RestoreInfo.1   RestoreLOG.1.z  restores.old   XferLOG.866.z  XferLOG.873.z  XferLOG.880.z
856  868  875  882          LOG.012019.z  LOG.082018.z   RestoreInfo.2   RestoreLOG.2.z  XferLOG.791.z  XferLOG.867.z  XferLOG.874.z  XferLOG.881.z
862  869  876  883          LOG.022019.z  LOG.092018.z   RestoreInfo.3   RestoreLOG.3.z  XferLOG.856.z  XferLOG.868.z  XferLOG.875.z  XferLOG.882.z
863  870  877  884          LOG.032019    LOG.102018.z   RestoreInfo.4   RestoreLOG.4.z  XferLOG.862.z  XferLOG.869.z  XferLOG.876.z  XferLOG.883.z
864  871  878  885          LOG.042018.z  LOG.112018.z   RestoreInfo.5   RestoreLOG.5.z  XferLOG.863.z  XferLOG.870.z  XferLOG.877.z  XferLOG.884.z
865  872  879  backups      LOG.052018.z  LOG.122018.z   RestoreInfo.6   RestoreLOG.6.z  XferLOG.864.z  XferLOG.871.z  XferLOG.878.z  XferLOG.885.z
866  873  880  backups.old  LOG.062018.z  RestoreInfo.0  RestoreLOG.0.z  restores        XferLOG.865.z  XferLOG.872.z  XferLOG.879.z  XferLOG.bad.z.old

# root @ gondor in /var/lib/BackupPC [10:51:27] 
$ ls pc/dnopytle/884     
attrib  backupInfo  f%2f  f%2fhome

# root @ gondor in /var/lib/BackupPC [10:52:20] 
$ ls pc/dnopytle/884/f%2f
attrib  fboot  fdev  fetc  fhome  fmnt  fopt  fproc  froot  frun  fsrv  fsys  fusr  fvar

# root @ gondor in /var/lib/BackupPC [10:52:25] 
$ ls pc/dnopytle/885/f%2f
attrib  fbin  fboot  fcrypto_keyfile.bin  fdev  fetc  fhome  flib  flib64  fmnt  fopt  fproc  froot  frun  fsbin  fsrv  fsys  fusr  fvar

Všimni, že v záloze 844 je v rootu toho méně než v 885, které je úplná záloha. Ale podle časů záloh

Backup Summary

Click on the backup number to browse and restore backup files.

Backup#	Type	Filled	Level	Start Date	Duration/mins	Age/days	Server Backup Path
791	full	yes	0	6/29 17:00	200.5	244.8	/var/lib/BackupPC//pc/dnopytle/791
856	full	yes	0	12/10 20:00	210.8	80.6	/var/lib/BackupPC//pc/dnopytle/856
862	full	yes	0	1/2 20:50	281.1	57.6	/var/lib/BackupPC//pc/dnopytle/862
863	incr	no	1	1/7 01:00	33.1	53.4	/var/lib/BackupPC//pc/dnopytle/863
864	incr	no	2	1/9 00:32	24.5	51.4	/var/lib/BackupPC//pc/dnopytle/864
865	incr	no	3	1/10 23:26	58.0	49.5	/var/lib/BackupPC//pc/dnopytle/865
866	incr	no	4	1/12 23:00	39.7	47.5	/var/lib/BackupPC//pc/dnopytle/866
867	incr	no	1	1/14 22:14	87.4	45.5	/var/lib/BackupPC//pc/dnopytle/867
868	incr	no	2	1/16 21:11	33.6	43.6	/var/lib/BackupPC//pc/dnopytle/868
869	full	yes	0	1/20 23:21	215.5	39.5	/var/lib/BackupPC//pc/dnopytle/869
870	incr	no	1	1/22 23:00	21.9	37.5	/var/lib/BackupPC//pc/dnopytle/870
871	incr	no	2	1/24 22:00	36.6	35.5	/var/lib/BackupPC//pc/dnopytle/871
872	incr	no	3	1/26 21:00	38.2	33.6	/var/lib/BackupPC//pc/dnopytle/872
873	incr	no	4	1/28 20:00	48.2	31.6	/var/lib/BackupPC//pc/dnopytle/873
874	incr	no	1	1/30 19:00	43.6	29.7	/var/lib/BackupPC//pc/dnopytle/874
875	incr	no	2	2/1 18:00	36.7	27.7	/var/lib/BackupPC//pc/dnopytle/875
876	full	yes	0	2/9 17:00	312.3	19.7	/var/lib/BackupPC//pc/dnopytle/876
877	incr	no	1	2/11 16:00	33.6	17.8	/var/lib/BackupPC//pc/dnopytle/877
878	incr	no	2	2/13 15:00	54.9	15.8	/var/lib/BackupPC//pc/dnopytle/878
879	incr	no	3	2/15 14:00	49.2	13.9	/var/lib/BackupPC//pc/dnopytle/879
880	incr	no	4	2/17 23:00	72.5	11.5	/var/lib/BackupPC//pc/dnopytle/880
881	incr	no	1	2/19 22:00	62.3	9.5	/var/lib/BackupPC//pc/dnopytle/881
882	incr	no	2	2/21 21:00	37.7	7.6	/var/lib/BackupPC//pc/dnopytle/882
883	incr	no	3	2/25 00:01	80.2	4.5	/var/lib/BackupPC//pc/dnopytle/883
884	incr	no	4	2/26 23:00	52.2	2.5	/var/lib/BackupPC//pc/dnopytle/884
885	full	yes	0	2/28 22:00	254.2	0.5	/var/lib/BackupPC//pc/dnopytle/885

je vidět že úplné zálohy jedou mnohem mnohem déle. a z hlediska toho kolik dat se za ten čas přenáší

File Size/Count Reuse Summary

Existing files are those already in the pool; new files are those added to the pool. Empty files and SMB errors aren't counted in the reuse and new counts.

		Totals			Existing Files		New Files
Backup#	Type	#Files	Size/MB	MB/sec	#Files	Size/MB	#Files	Size/MB
791	full	455358	125157.6	10.40	455087	111533.7	3118	13628.4
856	full	749021	134598.7	10.64	748550	127686.6	4086	6918.1
862	full	751402	137142.1	8.13	738566	129768.9	24091	7381.0
863	incr	18483	5518.0	2.78	14980	319.6	6150	5199.3
864	incr	16679	875.7	0.60	15433	270.5	2121	605.7
865	incr	52836	6488.1	1.86	46880	952.0	10000	5538.0
866	incr	5328	4905.8	2.06	4293	227.0	4435	4679.2
867	incr	181171	13424.7	2.56	167127	7139.1	26535	6290.6
868	incr	28882	5045.4	2.50	25898	383.4	8732	4663.3
869	full	602738	129623.0	10.02	599392	122849.3	10628	6782.2
870	incr	30969	1712.2	1.30	25099	489.5	12142	1224.0
871	incr	11101	5391.6	2.45	10267	1140.5	1550	4251.6
872	incr	228	3592.1	1.57	71	10.2	340	3582.0
873	incr	40094	7449.7	2.58	33274	1197.9	14734	6253.2
874	incr	79014	10312.4	3.94	73837	7067.1	11826	3246.4
875	incr	14668	4423.3	2.01	11338	202.2	7384	4221.8
876	full	606756	131431.9	7.01	609502	127386.8	11217	4052.7
877	incr	25641	3232.2	1.60	11372	257.4	17181	2976.1
878	incr	90338	5804.3	1.76	69833	1527.2	24685	4279.4
879	incr	24660	1815.8	0.61	19607	584.9	12074	1231.9
880	incr	15562	5379.2	1.24	12324	694.3	6249	4685.7
881	incr	139732	12515.7	3.35	139265	9533.6	872	2983.4
882	incr	49542	4014.9	1.77	48221	905.0	4776	3111.3
883	incr	37843	6551.3	1.36	29527	361.9	17745	6190.7
884	incr	71290	5644.6	1.80	64258	1063.5	15249	4583.2
885	full	625885	134813.8	8.84	624956	134041.4	5262	781.3

tak z toho pro mne plyne, že úplná záloha se přenáší přes síť celá, i když se pak třeba nakonec neuloží jinam díky deduplikaci.

[Peter Golis]

Pokiaľ je tam skutočne použitá deduplikácia, tak tie dáta nebudú zaberať miesto dva krát. A ak je deduplikácia už priamo na zdroji, tak sa nebudú ani odosielať dva krát.

Jediný problém mô%ze byť v tom, že si človek bude musieť pri Incr/Diff zálohe hľadať poslednú verziu zmeneného súboru cez akoby dve mašiny. Ale to pochopí každý.

[lertimir]

No já to mám vyřešené. dhcp dodá stejnou IP pro oba interfacy a zařízení jen jeden zapnutý. Chtěl jsem ti jen vysvětlit jak to BackupPC dělá

[Peter Golis]

Beriem že to teda BackupPC robí skutočnú deduplikáciu a neemuluje to konceptom Full+[Diff,Incr] alebo Incr forewer v ktorom môže byť trochu problém ak si človek nahrá starší súbor a backup ho môže nadosmrti alebo do následujúceho Full prehliadať.