QLogic 4x10GbE QL41134HLCU - NO-CARRIER
Pavel Kankovsky
peak na argo.troja.mff.cuni.cz
Sobota Červen 13 13:11:06 CEST 2020
On Sun, 7 Jun 2020, Zdeněk Janiš wrote:
>> Nejspíš nějak blbne firmware v té kartě a prostě to odfiltruje. [...]
>> Možná ho zkuste donutit, aby zrušil offloading filtrování vlanů, třeba
>> to pomůže.
>
> Chvilku jsem si hrál s ethtool, ale bez výsledku, protože jsem ani nevěděl co
> chci, co hledám.
V ethtoolu by to byly opšny mající v názvu "rx" (příjem) a "vlan", zejména
tedy asi tyto:
rx-vlan-offload: on [fixed]
rx-vlan-filter: on [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Ale jak jste sám vypozoroval, tak to má všechno "[fixed]", čili tam asi
nic přenastavit nejde.
Nicméně ten filtrovací offloading lze někdy donutit k vypnutí také tak, že
rozhraní dáte do promiskuitního módu a/nebo na něm nakfigurujete víc
vlanů, než hardware dokáže zpracovat. Ale podle toho, co píšete dál...
> Co jsem ještě dál laboroval, tak se zdá, že příchozí pakety projdou - vidím
> je v tcpdumpu. Ale problém je s odchozím provozem. Tam neprojde ani byte...
...asi není chyba na příjmu. Když se díváte na vysílaný provoz, vidíte ty
mizející pakety tcpdump-em aspoň přímo na stroji, který je má vysílat?
> Jedná se o problematický případ VLANy ve VLANě, a to nikoliv QinQ, ale
> "enp1s0f0 -> vlan45 -> vlan15 <- IP".
Bohužel nerozumím tomu, co přesně znamenají ty šipky. Co to znamená "VLANy
ve VLANě", když to není QinQ? Myslíte tím, že tam není S-tag a C-tag, ale
dva "normální" (= C-) tagy s TPID = 0x8100 za sebou?
--
Pavel Kankovsky aka Peak "Que sçay-je?"
Další informace o konferenci Linux