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