lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 4 Jun 2018 11:17:58 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     AMG Zollner Robert <robert@...udmedia.eu>, ganeshgr@...lsio.com
Cc:     netdev@...r.kernel.org
Subject: Re: [bug] cxgb4: vrf stopped working with cxgb4 card

On 6/4/18 8:03 AM, AMG Zollner Robert wrote:
> I have noticed that vrf is not working with kernel v4.15.0 but was
> working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
> 
> Setup:
> Two metal servers with a T520-cr card each, directly connected without a
> switch in between.
> 
>        SVR1  only ipfwd                 SVR2     with vrf
> .----------------------------. .----------------------------------.
> |                            |         |             |
> |    192.168.8.1 [  ens2f4]--|---------|--[ens1f4] 192.168.8.2   |
> |    192.168.9.1 [ens2f4d1]--|---------|--<ens1f4d1> 192.168.9.2 VRF=10   |
> `----------------------------' `----------------------------------'
> 
> When vrf is not working there are no error messages (dmesg or iproute
> commands), tcpdump on the interface (SVR2.ens1f4d1) enslaved in vrf 10
> shows packets(arp req/reply) coming in and going out, but outgoing
> packets(arp reply) do not reach the other server SVR1.ens2f4d1
> 
> 
> Bisect:
> Found this commit to be the problem after doing a git bisect between
> v4.13..v4.15:
> 
> commit ba581f77df23c8ee70b372966e69cf10bc5453d8
> Author: Ganesh Goudar <ganeshgr@...lsio.com>
> Date:   Sat Sep 23 16:07:28 2017 +0530
> 
>     cxgb4: do DCB state reset in couple of places
> 
>     reset the driver's DCB state in couple of places
>     where it was missing.
> 
> 
> A bisect step was considered good when:
> - successful ping from SVR1 to SVR2.ens1f4d1 vrf interface
> - successful ping from SVR2 global to SVR2 vrf interface trough SVR1(l3
> forwarding) (this check was redundant,both tests fail or pass simultaneous)
> 
> The problem is still present on recent kernels also, checked v4.16.0 and
> v4.17.rc7
> 
> Disabling DCB for the card support fixes the problem ( Compiling kernel
> with "CONFIG_CHELSIO_T4_DCB=n")
> 

Are you doing the VRF enslave while it is up?

If so, does it work ok if you change the sequence:

ip li set ens1f4d1 down
ip li set ens1f4d1 master <VRF>
ip li set ens1f4d1 up

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ