Hello,

we are facing to following issue: test with VLAN tagged packets between two VIRL hosts fail.

There was done a lot fo observation by Carsten Koester:

Summary:
In VIRL testing with the following VPP build (and, I understand, every build thereafter?), test with VLAN tagged packets between two VIRL hosts fail:

root@sut2:~# vppctl sh ver verbose
Version: v1.0.0-343~gc02f02d
Compiled by: jenkins
Compile host: ubnt-trusty-58f
Compile date: Wed Apr 20 11:28:36 UTC 2016
Compile location: /w/workspace/vpp-merge-master-ubuntu1404
Compiler: GCC 4.8.4
CPU model name: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
CPU microarchitecture: Haswell (Haswell-E)
DPDK Version: RTE 2.2.0
DPDK EAL init args: -c 1 -n 4 --huge-dir /run/vpp/hugepages --file-prefix vpp -b 0000:00:03.0 --master-lcore 0 --socket-mem 1024

Testing with SUT1 -> SUT2 traffic.

SUT1:
GigabitEthernet0/6/0 7 up tx packets 19

tx bytes 874
GigabitEthernet0/6/0.10 9 up tx packets 19

tx bytes 874
GigabitEthernet0/6/0.10 (up):
172.16.0.1/24

SUT2:
GigabitEthernet0/6/0 7 up tx packets 6

tx bytes 276
GigabitEthernet0/6/0.10 9 up tx packets 6

tx bytes 276
GigabitEthernet0/6/0.10 (up):
172.16.0.2/24

Symptom:
ARP ("vppctl ip probe-neighbor GigabitEthernet0/6/0.10 172.16.0.2 retry 3", executed on SUT1) fails.. and vice versa.

Observations:

a.) As per sniffer trace on VIRL host (OVS tap interface facing SUT2), packets are being delivered to SUT2:

virl@tb4-virl:~$ sudo tcpdump -enni tap63dc0f83-0f
listening on tap63dc0f83-0f, link-type EN10MB (Ethernet), capture size 65535 bytes
11:55:43.739179 fa:16:3e:d2:10:c9 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 172.16.0.2 tell 172.16.0.1, length 28
11:55:44.737202 fa:16:3e:d2:10:c9 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 172.16.0.2 tell 172.16.0.1, length 28
11:55:45.735271 fa:16:3e:d2:10:c9 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 172.16.0.2 tell 172.16.0.1, length 28

b.) If NOT running VPP on SUT2, a tcpdump on SUT2 itself "sees" the incoming packets.

c.) "vppctl trace add dpdk-input 100", "vppctl sh trace" shows no input packets.

root@sut2:~# sudo vppctl sh trace
------------------- Start of thread 0 vpp_main -------------------
No packets in trace buffer
root@sut2:~#

d.) "vppctl sh int" shows no rx- packets.

root@sut2:~# sudo vppctl sh int
Name Idx State Counter Count
GigabitEthernet0/4/0 5 down
GigabitEthernet0/5/0 6 down
GigabitEthernet0/6/0 7 up
GigabitEthernet0/6/0.10 9 up
GigabitEthernet0/7/0 8 down

e.) "sh error" shows no errors.
root@sut2:~# sudo vppctl sh err
Count Node Reason
root@sut2:~#

f.) "sh run" shows no input vectors:

root@sut2:~# sudo vppctl sh run
Time 11.0, average vectors/node 0.00, last 128 main loops 0.00 per node 0.00
vector rates in 0.0000e0, out 0.0000e0, drop 0.0000e0, punt 0.0000e0
Name State Calls Vectors Suspends Clocks Vectors/Call
api-rx-from-ring active 0 0 15 4.53e4 0.00
cdp-process any wait 0 0 9 8.54e2 0.00
dpdk-input polling 37776575 0 0 1.53e2 0.00
dpdk-process any wait 0 0 4 1.02e5 0.00
gmon-process time wait 0 0 2 3.13e3 0.00
ip6-icmp-neighbor-discovery-ev any wait 0 0 11 4.76e3 0.00
unix-epoll-input polling 37771455 0 0 4.48e2 0.00
vpe-oam-process any wait 0 0 6 3.16e3 0.00

For more information, please, see attached e-mail.