Dotaz: Bonding, VLAN a rozdil v chovani na strojich s ruznymi verzemi OS

[aldrtik]

Zdravim,

mam 2 stroje s OS Debian 9 a Debian 10.

Na obou strojich je stejna konfigurace site (az na ruzne IP adresy).

Na prvnim stroji vse chodi jak ma.

Zahada: na druhem stroji po upgrade OS se netvori prekladova ARP tabulka - neprojdou zpet arp odezvy.

Dusledek - nelze nikam ani ping, pouze v pripade, ze rucne dam do tabulky adresu brany a prislusnou adresu pomoci arp -s.

U prvniho stroje jsou arp zaznamy vzhledem k rozhrani br0.20 spravne. U druheho stroje se do arp tabulky vloudi zaznam z rozhrani bond0.20, coz je spatne a nejde ani odstranit pomoci arp -d

HW je v tom nevinne - overeno prohozenim OS mezi stroji.

Co se zmenilo mezi verzemi OS, ze jsem to nezachytil, nebo mam cosi viditelne spatne?

Diky za napady.

Vypis konfigurace rozhrani je nize.

cat /etc/network/interfaces

-----------
auto lo
iface lo inet loopback


allow-hotplug ens3f0
iface  ens3f0 inet manual

allow-hotplug ens3f1
iface ens3f1 inet manual


auto bond0
iface bond0 inet manual
        bond-slaves  ens3f0 ens3f1
        bond-mode 1 
	bond-primary ens3f1 
        bond-arp-validate all
	bond-miimon 500
    	bond-downdelay 500
    	bond-updelay 500
	bond-primary ens3f1
        bond-arp-interval 5000
        bond-arp-ip-target 10.5.75.1


auto bond0.20
iface bond0.20 inet manual

auto bond0.21
iface bond0.21 inet manual



auto br0.20
iface br0.20 inet static
	address 10.5.75.140
	netmask 255.255.255.0
	network 10.5.75.0
	broadcast 10.5.75.255
	gateway 10.5.75.1
	dns-nameservers 10.5.64.4 10.5.65.4
	dns-search domena.cz
	bridge_ports bond0.20
	#bridge_fd 0
	#bridge_maxwait 0
	#bridge_stp off

auto br0.21
iface br0.21 inet manual
        dns-nameservers 10.5.64.4 10.5.65.4
        dns-search domena.cz
        bridge_ports bond0.21


auto br0
iface br0 inet manual
	bridge_ports bond0
	bridge_fd 0
	bridge_maxwait 0
	bridge_stp off
	bridge_vlan_aware yes
----------

OK:
arp -n

Address                  HWtype  HWaddress           Flags Mask  Iface
10.5.75.1                ether   00:08:e3:ff:fd:90   C           br0.20
10.5.75.144              ether   92:95:da:8a:53:26   C           br0.20


spatne:
arp -n

Address                  HWtype  HWaddress           Flags Mask  Iface
10.5.75.140              ether   00:1b:21:da:0d:30   C           bond0.20
10.5.75.1                ether   00:08:e3:ff:fd:90   CM          br0.20

---

---

Odpovědi

[Michal Kubeček]

Spíš než ten konfigurační soubor by mne zajímal výstup "ip -d link show" a "ip addr show" (pokud máte dostatečně novou verzi iproute2, stačí "ip -d addr show"), protože ten konfigurační soubor he dost podivný: např. se podle všeho snaží nastavit současně MII i ARP monitoring, což určitě nejde a z hlavy si nepamatuju, jak přesně se jádro zachová (a je otázka, co mu vaše distribuční nástroje vůbec pošlou). A místo "arp -n" raději "ip neigh show".

[j]

Hele mozna nerozumim reci tvyho kmene, ale zkus sem nahodit neco jako ip li ls. Mam takovy podezreni, ze pouzivas ponekud hodne zastaraly zpusob nastavovani sitovani. Coz by i odpovidalo ty debiani odlezely mrtvole.

Zkus to nejak takhle (klidne z ruky)

# ip link add bond0 type bond
# ip link set bond0 type bond miimon 100 mode active-backup
# ip link set ens3f0 down
# ip link set ens3f0 master bond0
# ip link set ens3f1 down
# ip link set ens3f1 master bond0
# ip link set bond0 up

# ip link add link bond0 name mojeVlan type vlan id 100
# ip link set dev mojeVlan up
# ip addr add a.b.c.1/24 brd a.b.c.255 dev mojeVlan

Tam kde je ta mezera si samo muzes klidne priradit IPcko primo na ten bond, abys overil ze ti funguje, ale i bez toho bys mel videt arp.

Pochopitelne za predpokladu, ze se ty predvidatelny nazvy sitovek zcela nepredvidatelne zrovna nevygenerujou uplne jinak.

---

Dete s tim guuglem dopice!

[aldrtik]

Diky za reakce. Zadne *tables tam nejsou.

Patrne jsem udelal chybu v chapani:

- VLAN aware bridge - traditional bridge a VLANy

Debian 9 dle konf. v 1. prispevku:

root@blade4:~# ip neigh show
10.5.75.143 dev br0.20 lladdr 00:1b:21:db:32:34 STALE
10.5.75.138 dev br0.20 lladdr 00:1b:21:da:10:dc STALE
10.5.75.144 dev br0.20 lladdr 92:95:da:8a:53:26 STALE
10.5.75.142 dev br0.20 lladdr 00:1b:21:da:8e:28 STALE
10.5.75.1 dev br0.20 lladdr 00:08:e3:ff:fd:90 DELAY
10.5.75.139 dev br0.20 lladdr 00:1b:21:da:10:e0 STALE

root@blade4:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.5.75.143              ether   00:1b:21:db:32:34   C                     br0.20
10.5.75.138              ether   00:1b:21:da:10:dc   C                     br0.20
10.5.75.144              ether   92:95:da:8a:53:26   C                     br0.20
10.5.75.142              ether   00:1b:21:da:8e:28   C                     br0.20
10.5.75.1                ether   00:08:e3:ff:fd:90   C                     br0.20
10.5.75.139              ether   00:1b:21:da:10:e0   C                     br0.20

Funkcni konfigurace s Debian 10, (hodne zastaraly zpusob nastavovani sitovani):

root@blade7:~# cat /etc/network/interfaces

auto lo
iface lo inet loopback


allow-hotplug ens3f0
iface  ens3f0 inet manual

# The primary network interface
allow-hotplug ens3f1
iface ens3f1 inet manual


auto bond0
iface bond0 inet manual
        bond-slaves  ens3f0 ens3f1
        bond-mode 1 
	bond-primary ens3f1 
        bond-arp-validate all
# Specifies the MII link monitoring frequency in milliseconds. This determines how often the link state of each slave is inspected for link failures. 
#	bond-miimon 500
#    	bond-downdelay 500
# Specifies the time, in milliseconds, to wait before disabling a slave after a link failure has been detected.
#    	bond-updelay 500
	bond-primary ens3f1
        bond-arp-interval 5000
        bond-arp-ip-target 10.5.75.1



#auto bond0.20
#iface bond0.20 inet manual

#auto bond0.21
#iface bond0.21 inet manual



auto br0.20
iface br0.20 inet static
	address 10.5.75.144
	netmask 255.255.255.0
	network 10.5.75.0
	broadcast 10.5.75.255
	gateway 10.5.75.1
	dns-nameservers 10.5.64.4 10.5.65.4
	dns-search domena.org
	bridge_ports bond0
	bridge_fd 0
	bridge_maxwait 0
	bridge_stp off

auto br0.21
iface br0.21 inet manual
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 10.5.64.4 10.5.65.4
        dns-search domena.org
        bridge_ports bond0


auto br0
iface br0 inet manual
	bridge_ports bond0
	bridge_fd 0
	bridge_maxwait 0
	bridge_stp off
	bridge_vlan_aware yes



root@blade7:~# ip neigh show
10.5.75.140 dev br0.20 lladdr 00:1b:21:da:0d:30 REACHABLE
10.5.75.1 dev br0.20 lladdr 00:08:e3:ff:fd:90 REACHABLE
10.5.75.138 dev br0.20 lladdr 00:1b:21:da:10:dc REACHABLE


root@blade7:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.5.75.140              ether   00:1b:21:da:0d:30   C                     br0.20
10.5.75.1                ether   00:08:e3:ff:fd:90   C                     br0.20
10.5.75.138              ether   00:1b:21:da:10:dc   C                     br0.20

Takze konfigurace prevzata z Debian 9 na Debian 10 vygeneruje jina zarizeni.

Dal me prekvapilo, ze polozka u br0:

bridge_vlan_aware yes

muze byt aktivni nebo za # a zafunguje stejne, takze fakticky mam funkcni konfiguraci pro Debian 10, ale s pochopenim jsem zase na zacatku.

Vypis:

ip a sh

pro ilustraci vygenerovanych devices nejsem schopen sem dat, protoze vetsitka a mensitka to tady bere jako html znacky.

[Michal Kubeček]

Vypis "ip a sh" pro ilustraci vygenerovanych devices nejsem schopen sem dat, protoze vetsitka a mensitka to tady bere jako html znacky.

Tak ho prožeňte např. přes tenhle skript. Ale přidejte i výstup "ip -d link show", ten by měl být ještě důležitější.

Snažit se vytvářet vlan devices nad VLAN aware bridge určitě není dobrý nápad. Implementace VLAN aware bridge (IIRC od jádra 3.9 nebo 3.10) vznikla právě proto, aby se takové věci dělat nemusely a šlo s bridge device v linuxu pracovat podobně jako s VLAN aware switchem.

[aldrtik]

Po prohnani vypisu:

ip link sh, resp. ip a s, ip -d link show

pres doporuceny skript to zde stale pri nahledu komentare hlasi:

"Značka LOOPBACK,UP,LOWER_UP není povolena!"

Nejsem koder - existuje na to mistni trik, jak sem vypisy dostat, tak jak jsou?

[Michal Kubeček]

Chcete říct, že vám to nenahradí menšítka a většítka entitami "<" a ">"? Nekopíroval jste náhodou původní verzi z formuláře místo té konvertované pod ním?

[aldrtik]

Příloha:

• porovnani_konf_VLAN.txt (16392 bytů)

Delal jsem to v besu, takze platim za blba, jak pisete.

Vypisy posilam jako prilohu, protoze po konverzi se to kvuli zalamovani nedobre cte.

[Michal Kubeček]

Jestli dobře vidím, hlavní rozdíl je v tom, že na Debianu 9 je br0.20 (a analogicky br0.21) bridge, ve kterém je jako slave bond0.20 (vlan device pro VID 20 nad bond0), na Debianu 10 je to vlan device pro VID 20 nad br0 - ale ten bond0.20 je tam pořád taky.

Osobně bych doporučoval se na tenhle historický přístup úplně vykašlat a použít vlan filtering v rámci toho bridge, popis najdete např. tady.

[aldrtik]

Příloha:

• Debian10.interfaces (4498 bytů)

Pokud by nekoho zajimalo v cem byl problem - rozdil je pouze v konfiguracich /etc/network/interfaces v Debian 10 vuci verzi v Debian 9.

Funkcni verze pro Debian 10 je v priloze a vsechno chodi tak, jak ma.

[vencour]

Jedna věc je editovat příspěvek (nahradit "<" za (bez mezer) " & l t ; ", další možností je vložit to jako výpis v příloze.

[alkoholik]

Prejmenovane sitovky? Ebtables vs. nftables? Drivery sitovek podporuji offload, ktery v 9 nedelaly?

[alkoholik]

A muj oblibeny systemd.

[Peter Golis]

Release pre mipsel?

[alkoholik]

Njn, prvni link z google. Ty release notes jsou vsude stejne.

[Peter Golis]

By ma zaujímalo, prečo nevyhodili to vypnutie bondingu správcovia balíčkov keď o tom vedeli. Resp., by ma zaujímalo prečo to tam vôbec dali.

[Michal Kubeček]

Většinou je za tím snaha co nejméně se odlišovat od upstreamu a v případě systemd upstream na zpětnou kompatibilitu a nerozbíjení uživatelských systémů moc nehraje, často spíš naopak. Viz třeba ten odkaz, který jsem sem dával o něco dříve.

Na druhou stranu je fér přiznat si, že te historické chování bonding driveru (a některých dalších, třeba dummy), kdy se při natažení automaticky vytvoří jedno zařízení, je z dnešního pohledu jednoznačně historický omyl - který ale vzhledem k tomu, že politika jádra je diametrálně odlišná od systemd, nelze plně napravit. (Leda tak, že všichni uživatelé přejdou na teaming, ale to zatím taky moc reálně nevypadá.)

[Peter Golis]

Ten dôvod je napísaný v tom súbore, a je iný ako píšeš.

[Michal Kubeček]

To mi připomíná: tahle zákeřnost by taky mohla hrát roli.