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@x10sdv-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@x10sdv-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@x10sdv-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@x10sdv-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@x10sdv-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?
