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:   Fri, 20 Jul 2018 19:03:49 +0000
From:   "D'Souza, Nelson" <ndsouza@...na.com>
To:     David Ahern <dsa@...ulusnetworks.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge

Hi Dave,

It is good to know that this works in your case. However, I'm not able to pinpoint what the issue is and looking for a way to narrow down to the root cause.
Do you know if this has been an issue in the past and resolved in Linux kernel versions after 4.14.52? 

I have the same setup as you and tcpdump works at all levels (eth, bridge, vrf).

Setup is as follows:

ethUSB(ingress port) -> mgmtbr0 (bridge) -> mgmtvrf (vrf)

Logs from my setup:

b) ethUSB is enslaved to mgmtbr0 (bridge)

root@...sdv-4c-tln4f:~# ip link show master mgmtbr0
6: ethUSB: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master mgmtbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether c0:56:27:90:4f:75 brd ff:ff:ff:ff:ff:ff

b) mgmtbr0 bridge is enslaved to mgmtvrf  (vrf)

root@...sdv-4c-tln4f:~# ip link show master mgmtvrf
16: mgmtbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master mgmtvrf state UP mode DEFAULT group default qlen 1000
    link/ether c0:56:27:90:4f:75 brd ff:ff:ff:ff:ff:ff

c) ip address configured on mgmtbr0

root@...sdv-4c-tln4f:~# ip addr show dev mgmtbr0
16: mgmtbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master mgmtvrf state UP group default qlen 1000
    link/ether c0:56:27:90:4f:75 brd ff:ff:ff:ff:ff:ff
    inet 10.33.96.131/24 brd 10.33.96.255 scope global mgmtbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::c256:27ff:fe90:4f75/64 scope link
       valid_lft forever preferred_lft forever

d) tcpdump on ethUSB successful, but ping fails
root@...sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c1 -w1
PING 10.32.8.135 (10.32.8.135): 56 data bytes
--- 10.32.8.135 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

root@...sdv-4c-tln4f:~# tcpdump -i ethUSB icmp 
11:38:37.169678 IP 10.33.96.131 > 10.32.8.135: ICMP echo request, id 62312, seq 0, length 64
11:38:37.170906 IP 10.32.8.135 > 10.33.96.131: ICMP echo reply, id 62312, seq 0, length 64

e) tcpdump on mgmtbr0 successful, but ping fails

root@...sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c1 -w1
PING 10.32.8.135 (10.32.8.135): 56 data bytes
--- 10.32.8.135 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

root@...sdv-4c-tln4f:~# tcpdump -i mgmtbr0 icmp
11:46:21.566739 IP 10.33.96.131 > 10.32.8.135: ICMP echo request, id 617, seq 0, length 64
11:46:21.567982 IP 10.32.8.135 > 10.33.96.131: ICMP echo reply, id 617, seq 0, length 64

f) tcpdump on mgmtvrf successful, but ping fails
root@...sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c1 -w1
PING 10.32.8.135 (10.32.8.135): 56 data bytes
--- 10.32.8.135 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

root@...sdv-4c-tln4f:~# tcpdump -i mgmtvrf icmp
11:50:24.155706 IP 10.33.96.131 > 10.32.8.135: ICMP echo request, id 2153, seq 0, length 64
11:50:24.156977 IP 10.32.8.135 > 10.33.96.131: ICMP echo reply, id 2153, seq 0, length 64

f) Netfilter prerouting rules added to the raw table, only sees packets ingressing on mgmtbr0, not mgmtvrf. 

root@...sdv-4c-tln4f:~# iptables -t raw -nvL PREROUTING
Chain PREROUTING (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   252 LOG        all  --  mgmtbr0 *       10.32.8.135          0.0.0.0/0            LOG flags 0 level 4
    0     0 LOG        all  --  mgmtvrf *       10.32.8.135          0.0.0.0/0            LOG flags 0 level 4

It's strange that while the tcpdump works at the mgmtvrf level, netfilter prerouting rules do not match on the mgmtvrf level.

Appreciate the help, please let me know if you need additional logs.

Thanks,
Nelson

On 7/19/18, 8:37 PM, "David Ahern" <dsa@...ulusnetworks.com> wrote:

    On 7/19/18 8:19 PM, D'Souza, Nelson wrote:
    > Hi,
    > 
    >  
    > 
    > I'm seeing the following issue on a system running a 4.14.52 Linux kernel.
    > 
    >  
    > 
    > With an eth interface enslaved to a VRF device, pings sent out on the
    > VRF to an neighboring host are successful. But, with an eth interface
    > enslaved to a L3 enabled bridge (mgmtbr0), and the bridge enslaved to a
    > l3mdev VRF (mgmtvrf), the pings sent out on the VRF are not received
    > back at the application level.
    
    you mean this setup:
        eth1 (ingress port) -> br0 (bridge) -> red (vrf)
    
    IP address on br0:
    
    9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master
    red state UP group default qlen 1000
        link/ether 02:e0:f9:1c:00:37 brd ff:ff:ff:ff:ff:ff
        inet 10.100.1.4/24 scope global br0
           valid_lft forever preferred_lft forever
        inet6 fe80::e0:f9ff:fe1c:37/64 scope link
           valid_lft forever preferred_lft forever
    
    And then ping a neighbor:
    
    # ping -I red -c1 -w1 10.100.1.254
    ping: Warning: source address might be selected on device other than red.
    PING 10.100.1.254 (10.100.1.254) from 10.100.1.4 red: 56(84) bytes of data.
    64 bytes from 10.100.1.254: icmp_seq=1 ttl=64 time=0.810 ms
    
    --- 10.100.1.254 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.810/0.810/0.810/0.000 ms
    
    > 
    >  
    > 
    > ICMP Echo requests are successfully sent out on the mgmtvrf device to a
    > neighboring host. However, ICMP echo replies that are received back from
    > the neighboring host via the eth and mgmtbr0 interfaces are not seen at
    > the vrf device level and therefore fail to be delivered locally to the
    > ping application.
    
    Does tcpdump on each level show the response? tcpdump on eth, tcpdump on
    bridge and tcpdump on the vrf device?
    
    > 
    >  
    > 
    > The following LOG rules were added to the raw table, prerouting chain
    > and the filter table, OUTPUT chains:
    > 
    >  
    > 
    > root@...sdv-4c-tln4f:~# iptables -t raw -S PREROUTING
    > 
    > -P PREROUTING ACCEPT
    > 
    > -A PREROUTING -s 10.32.8.135/32 -i mgmtbr0 -j LOG
    > 
    > -A PREROUTING -s 10.32.8.135/32 -i mgmtvrf -j LOG
    > 
    >  
    > 
    > root@...sdv-4c-tln4f:~# iptables -S OUTPUT
    > 
    > -P OUTPUT ACCEPT
    > 
    > -A OUTPUT -o mgmtvrf -j LOG
    > 
    > -A OUTPUT -o mgmtbr0 -j LOG
    > 
    >  
    > 
    > Pings are sent on the management VRF to a neighboring host (10.32.8.135)
    > and the netfilter logs included below:
    > 
    > Note, that in the logs, ICMP echo requests are sent out on the mgmtvrf
    > and match the output rules for mgmvrf and mgmtbr0, but the ICMP echo
    > replies are only seen on mgmtbr0, not on mgmtvrf
    > 
    >  
    > 
    > root@...sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c 1
    > 
    > PING 10.32.8.135  (10.32.8.135):
    > 
    > 56 data bytes
    > 
    > [ 2679.683027] IN= OUT=mgmtvrf SRC=10.33.96.131 DST=10.32.8.135 LEN=84
    > TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
    > SEQ=0   <<< ICMP echo sent on mgmtvrf
    > 
    > [ 2679.697560] IN= OUT=mgmtbr0 SRC=10.33.96.131 DST=10.32.8.135 LEN=84
    > TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
    > SEQ=0   <<< ICMP echo sent on mgmtbr0
    > 
    > [ 2679.713312] IN=mgmtbr0 OUT= PHYSIN=ethUSB
    > MAC=c0:56:27:90:4f:75:c4:7d:4f:bb:02:e7:08:00 SRC=10.32.8.135
    > DST=10.33.96.131 LEN=84 TOS=0x00 PREC=0x00 TTL=62 ID=64949 PROTO=ICMP
    > TYPE=0 CODE=0 ID=32610 SEQ=0     <<< ICMP echo reply rcvd on mgmtbr0,
    > but not on mgmtvrf
    > 
    >  
    > 
    > --- 10.32.8.135 ping statistics ---
    > 
    > 1 packets transmitted, 0 packets received, 100% packet loss     <<<<
    > ping failed
    > 
    >  
    > 
    > I’d like to know if this is an outstanding/resolved issue.
    > 
    
    This one works (see above), so I suspect it is something with your setup.
    

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ