| 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
| ||
|
Message-ID: <F8810C2E-7791-43B8-AB64-6FC843431FEA@ciena.com>
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