netdev - Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge

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]

Message-ID: <439A44A3-F26C-42FC-9588-EC48842CFB94@ciena.com>
Date:   Fri, 20 Jul 2018 21:59:50 +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

The Linux kernel has kernel patches applied beyond 4.14.52 but aside from that it has no custom changes.
Currently don't have perf on the linux system, so will have to get back to you with the perf traces.

Meanwhile,  here's the ip outputs you requested.

root@...sdv-4c-tln4f:~# ip rule ls
0:	from all lookup local
1000:	from all lookup [l3mdev-table]
32766:	from all lookup main
32767:	from all lookup default

root@...sdv-4c-tln4f:~# ip route ls vrf mgmtvrf
default via 10.33.96.1 dev mgmtbr0
10.33.96.0/24 dev mgmtbr0 proto kernel scope link src 10.33.96.131

root@...sdv-4c-tln4f:~# ip link show vrf 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

Thanks,
Nelson

On 7/20/18, 12:11 PM, "David Ahern" <dsa@...ulusnetworks.com> wrote:

    On 7/20/18 1:03 PM, D'Souza, Nelson wrote:
    > 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? 
    
    It has always worked as far as I recall.
    
    > 
    > 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
    
    First, is this a modified kernel?
    
    What does the following show?
    $ ip ru ls
    $ ip route ls vrf mgmt
    $ ip li sh vrf mgmt
    
    Try perf:
        perf record -e fib:* -a -g -- sleep 3
        (run ping during record)
        perf script
    
    Look at the table used for lookups. Is the correct one for the mgmt vrf?