Dotaz: NIC bond a ping

[rastos]

Mám linuxový server na ktorom sú "eth0" a "eth1" spojené do "bond0" s IP 192.168.0.19. Z iného stroja v LAN robím ping na túto IP. A občas sa stane že nedostanem odpoveď. tcpudmp pustený na tom stroji s bond interface-om ukazuje, že ICMP echo request prišiel, ale žiadna ICMP echo reply odpoveď nebola poslaná.

a) má niekto podobnú skúsenosť?

b) má niekto nejaké možné vysvetlenie?

Odpovědi

[MP]

rate-limit? zastaraly sw?

[rastos]

rate-limit?

To, čo má v sebe štandardne UFW:

root@server:~# iptables-save  |grep -i limit
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
root@server:~#

Vo /var/log/syslog je kadečo od UFW, ale nič o "limit" ani "icmp".

root@server:~# grep -i -e  icmp -e limit /var/log/syslog 
root@server:~#

zastaraly sw?

22.04.3 LTS (GNU/Linux 5.15.0-91-generic x86_64)

[Peter Golis]

A podporujú ten typ bondingu použité switche?

[PetebLazar]

Pokud ICMP echo request na server dorazí a není "slyšet" odchozí ICMP echo reply na síťových rozhraních serveru tak bych si tipnul že to nebude o schopnostech switchů na cestě.

[rastos]

Myslím, že je tam buď "Cisco SG200-50", alebo "Dell PowerConnect 5324" (ešte zisťujem detaily). Toto (switche, cisco, ..) je mimo môj obor, ale zdá sa, že iné stroje v LAN nemajú taký problém (hoci tiež používajú bonding). Preto mám tendenciu súhlasiť s PetebLazar, že v switch-och to nebude.

[Peter Golis]

Kľudne to môže byť aj v tom. Zažil som keď switch podporoval LACP, ale len na polovicu.

Ale v tomto prípade by som sa pozrel na tie iné funkčné stroje či nemajú inak nastavenú sieť. Podobný zádrhel som zažil aj s Network Bridge (viem, je to opak bondingu), ešte že ten stroj nebol ďaleko.

[alkoholik]

Bond monitoring mas udelany pres MII nebo ARP?
Co nastaveni ARP filteru v kernelu?

[rastos]

Bond monitoring mas udelany pres MII nebo ARP?

/etc/network/interfaces:

auto eth0
iface eth0 inet manual
        bond-master bond0

auto eth1
iface eth1 inet manual
        bond-master bond0

auto bond0
iface bond0 inet static
...
        bond-slaves all
        bond-mode 6
        bond-miimon 100
        bond-downdelay 200
        bond-updelay 200

Co nastaveni ARP filteru v kernelu?

Neviem, čo máš presne na mysli, ale "arptables" neukazuje žiadne pravidlá.

[alkoholik]

Sorry, rp filter. ARP filter je neco jineho.
Cesty paketu jsou nevyzpytatelne.

[rastos]

$ cat /proc/sys/net/ipv4/conf/bond0/rp_filter 
2

rp_filter

Keď som sa s tým problémom začal zaoberať, tak som sa tiež dogooglil k "rp_filter". Ale tie stránky to nedávali do súvislosti s bondingom. Skôr pre situáciu, kedy má stroj viaceré NIC a nich rôzne IP rozsahy. Ale nechcel som navádzať na odpoveď. Preto som sa pýtal, či má niekto podobný setup, resp. podobnú skúsenosť. Meniť rp_filter som chcel príslušnému kolegovi navrhovať, až keď niekto povie, že by to mohlo byť užitočné.

[X]

Jses si jisty, ze to ma souvislost s tim bondem? Nejaka pocitadla na strane switche, nebo sitvych karet mozna nenapovi jinak je to dost tapani ve tme. Nejake ICMP testy jsi delal?

[rastos]

Jses si jisty, ze to ma souvislost s tim bondem?

Nie som. Ale je to asi jediná vec, ktorou sa ten stroj líši od hromady iných linuxových strojov, čo som kedy videl.

Nejaka pocitadla na strane switche

Tam nemám prístup. Zatiaľ. Navyše to vyzerá, že káble z jednotlivých sieťových kariet idú cez dva rôzne switche kvôli fault tolerance. (Tiež sa tieto veci dozvedám postupne a fyzicky je to celé 2000km ďaleko, takže sa nemôžem ísť pozrieť ).

, nebo sitvych karet mozna nenapovi jinak je to dost tapani ve tme.

Tiež tápem v tme. Neviem kam a na čo sa mám dívať.

Nejake ICMP testy jsi delal?

Začalo to ako ping problém hlásený z nagios-u. Potom som si to skúsil sám.Prihlásil som sa cez ssh na dva stroje, na jednom pustil "ping serrver", na druhom "tcpdump -i bond0 icmp". A vo výstupe z tcpdump som videl, že to občas funguje tak, ako má: príde echo request, odíde echo reply so zodpovedajúcim id a seq, ale občas príde echo request a echo reply neodíde. Aj 10 paketov po sebe. A potom to zasa nejaký čas funguje akoby sa nechumelilo.

[alkoholik]

Kdyz je zrovna vypadek, vidite MAC adresu zdroje v ARP tabulce na stroji, ktery neodpovida?

[rastos]

Áno.

[X]

Navyše to vyzerá, že káble z jednotlivých sieťových kariet idú cez dva rôzne switche kvôli fault tolerance.

To bude problem. Protoze podle dokumentace je zvoleny mod nevhodny. Presneji:

11.2 High Availability in a Multiple Switch Topology
----------------------------------------------------

	With multiple switches, the configuration of bonding and the
network changes dramatically.  In multiple switch topologies, there is
a trade off between network availability and usable bandwidth.

	Below is a sample network, configured to maximize the
availability of the network:

                |                                     |
                |port3                           port3|
          +-----+----+                          +-----+----+
          |          |port2       ISL      port2|          |
          | switch A +--------------------------+ switch B |
          |          |                          |          |
          +-----+----+                          +-----++---+
                |port1                           port1|
                |             +-------+               |
                +-------------+ host1 +---------------+
                         eth0 +-------+ eth1

	In this configuration, there is a link between the two
switches (ISL, or inter switch link), and multiple ports connecting to
the outside world ("port3" on each switch).  There is no technical
reason that this could not be extended to a third switch.

11.2.1 HA Bonding Mode Selection for Multiple Switch Topology
-------------------------------------------------------------

	In a topology such as the example above, the active-backup and
broadcast modes are the only useful bonding modes when optimizing for
availability; the other modes require all links to terminate on the
same peer for them to behave rationally.

[alkoholik]

Tcpdump nad bondem je o vrstvu vys nez sitovky.
Jestli vidi prichozi ICMP a ne odchozi, tak bud kernel zahodil prichodi paket - nejspis ve fw, ale muzou to byt i ruzne rp filtry - nebo neposle odpoved do bondu, protoze bud nesmi - zase fw - nebo nevi, ze ma jit odpoved tudy - problemy s routou nebo MAC/ARP.

[Vantomas]

Jaký Ethernet je v serveru? Občas má Linuxový bond driver problém s Intely, které umí HW akceleraci LACP a VLAN. Bonding v Linuxu si pak myslí, že je bonding aktivní, ale z Linuxu na switch neodchází LACP pakety a tak port switch vyřadí...

Logy ze switche, kernel log ze serveru, koukat do /proc/net/bonding/bond0, když se to děje, by mohlo napovědět víc.

[rastos]

Jaký Ethernet je v serveru?

Ethernet Connection X722 for 10GBASE-T

Občas má Linuxový bond driver problém s Intely, které umí HW akceleraci LACP a VLAN. Bonding v Linuxu si pak myslí, že je bonding aktivní, ale z Linuxu na switch neodchází LACP pakety a tak port switch vyřadí...

Ja ale nevidím na tom server-i, že by server odpoveď odoslal. Čo urobí (alebo by urobil) switch, to už je snáď fuk, nie?

Logy ze switche,

Viď vyššie. Keby som ten reply videl odísť a nedoraziť na toho, kto ten request poslal, tak by som hľadal problém v kábloch, switchoch, na strane klienta, ... ale keď ten reply podľa tcpdump ani neodíde, tak musí byť problém na tom serveri samotnom. Buď ten request paket niečo zožerie po tom, ako ho tcpdump uvidí prísť, alebo sa niečo rozhodne ten reply vôbec neposlať.

kernel log ze serveru,

V čase, keď je problém tak sa vo výstupe dmesg, ani vo /var/log/kern.log neobjaví vôbec nič.

koukat do /proc/net/bonding/bond0

Hmm!

$ cat /proc/net/bonding/bond0 
Ethernet Channel Bonding Driver: v5.15.0-91-generic

Bonding Mode: adaptive load balancing
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200
Peer Notification Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: ac:1f:6b:0c:88:20
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: ac:1f:6b:0c:88:21
Slave queue ID: 0

Prečo je tam "Link Failure Count: 1" pri eth0, to neviem. Ale tých zlyhaných pingov je mnoho a nie len jeden.

[Vantomas]

Aha, balance-alb, takže LACP se nepoužívá, v tom případě směřuju zcela mimo. S tímhle režimem nemám žádné zkušenosti, používám zásadně LACP, co jsem koukal do readme, tak v tomhle režimu ještě bonding driver unáší ARP replies a vyměňuje v nich MAC adresy pro různé hosty, příliš divoký a naprosto nedetermenistický pro mě.

Link Failure Count znamená, že někdy v minulosti se jednou shodil a nahodil link na tom portu, tedy třeba někdo vypojil a zapojil kabel, udělal se up/down interfacu přes "ip link", možná třeba vadný drát kvůli kterému vypadává link....

rp_filter by v tom hrát roli neměl, protože z pohledu L3 jede vše přes bond0 interface a tak rp_filter nemá co filtrovat.

Možná by mohlo hrát roli nastavení arp_announce a arp_proxy, v kombinaci s tím, že do toho sahá bonding driver by to něco způsobit mohlo.

Kouknul bych na "arp -n" na tom serveru odkud ten ping vypadává co tam je v době problému. V době problému zkusil "arp -d 192.168....", zda to hned nezačne odpovídat a pak hnedka zkontrolovat co je v "arp -n"...

Pro vyloučení toho, jestli to není něco v konfiguraci firewallu nebo něčeho jiného, tak pokud to situace dovoluje, na serveru úplně všechno vypnout, shodit všechny ostatní interfacy, nechat pouze ty v bondu, úplně vypnout a vyčistit firewall a koukat, zda se to pořád děje. Pak klidně klidně vyhodit druhý interface z bond a nechat pouze jeden, zkrátka to co nejvíc ořezat na dřeň a sledovat kdy se začne problém objevovat.

[Max]

Pokud se jedná o dva switche ve stacku, tak jediný smysl dává použití LACP (mode 4 = 802.3ad), protože pokud umožňují stackování, tak budou určitě umožňovat i LACP.
Pokud se jedná o dva různé switche, které nejsou ve stacku, tak se obávám, že režim active-active (bond-mode 6 = balance-alb) bude dělat problém. Bude problém s ARP na síti a budeš mít záhadné výpadky.
Pokud to před tím jelo a teď ne, tak je otázkou, zda nedošlo ke změně na infrastruktuře? Např. že tam původně byl jeden switch a někdo tam dal druhý a rozhodil kabely apod.
Jinak já osobně bych nikdy nepoužil bond-mode 6 = balance-alb. Pokud by mi to situace nedovolovala a nemohl jsem použít LACP, tak jedině režim active-backup, tj. mode 1.
Zdar Max

[trekker.dk]

Bude problém s ARP na síti a budeš mít záhadné výpadky.

Máte za to, že někdo ten mode 6 vymyslel s tím, že tam tohle nebude ošetřené?