[vpp-dev] No traffic to vhost-user after restart VPP and reconfigure

2017-03-31 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi all,

Does VPP support reconnect to existing qemu's vhost user socket?
I configured vhost-user interface on  VPP (client), I started qemu, I restarted 
VPP and reconfigured VPP.
Before restart packet was forwarded to the VM, after restart no packet received 
on the VM.

VPP config:
sw_interface_set_flags sw_if_index 1 admin-up
sw_interface_set_flags sw_if_index 2 admin-up
create_vhost_user_if socket /tmp/sock1
create_vhost_user_if socket /tmp/sock2
sw_interface_set_flags sw_if_index 5 admin-up
sw_interface_set_flags sw_if_index 6 admin-up
bridge_domain_add_del bd_id 101 flood 1 uu-flood 1 forward 1 learn 1 arp-term 0
bridge_domain_add_del bd_id 102 flood 1 uu-flood 1 forward 1 learn 1 arp-term 0
sw_interface_set_l2_bridge sw_if_index 5 bd_id 101 shg 0  enable
sw_interface_set_l2_bridge sw_if_index 6 bd_id 102 shg 0  enable
sw_interface_set_l2_bridge sw_if_index 1 bd_id 101 shg 0  enable
sw_interface_set_l2_bridge sw_if_index 2 bd_id 102 shg 0  enable


root@sut1:/home/cisco# /usr/bin/qemu-system-x86_64 -smp 
1,sockets=1,cores=1,threads=1 -object 
memory-backend-file,id=mem,size=512M,mem-path=/mnt/huge,share=on -m 512 -numa 
node,memdev=mem -net user,hostfwd=tcp::10022-:22 -cpu host -daemonize 
-enable-kvm -machine pc,accel=kvm,usb=off,mem-merge=off -net 
nic,macaddr=52:54:00:00:01:ff -balloon none -chardev 
socket,id=char1,path=/tmp/sock1,server -netdev 
vhost-user,id=vhost1,chardev=char1,queues=1 -device 
virtio-net-pci,netdev=vhost1,mac=52:54:00:00:01:01,mq=on,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off
 -chardev socket,id=char2,path=/tmp/sock2,server -netdev 
vhost-user,id=vhost2,chardev=char2,queues=1 -device 
virtio-net-pci,netdev=vhost2,mac=52:54:00:00:01:02,mq=on,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off
 -drive file=/var/lib/vm/vhost-nested.img,format=raw,cache=none,if=virtio -qmp 
unix:/tmp/qmp1.sock,server,nowait -chardev 
socket,host=127.0.0.1,port=4556,id=gnc0,server,nowait -device 
isa-serial,chardev=gnc0 -chardev 
socket,path=/tmp/qga1.sock,server,nowait,id=qga0 -device 
isa-serial,chardev=qga0 -monitor none -display none -vga none -pidfile 
/tmp/qemu1.pid
QEMU waiting for connection on: disconnected:unix:/tmp/sock1,server
QEMU waiting for connection on: disconnected:unix:/tmp/sock2,server
root@sut1:/home/cisco#


vpp# show vhost-user VirtualEthernet0/0/0
Virtio vhost-user interfaces
Global:
  coalesce frames 32 time 1e-3
Interface: VirtualEthernet0/0/0 (ifindex 5)
virtio_net_hdr_sz 10
features mask (0x):
features (0x5860):
   VIRTIO_NET_F_GUEST_ANNOUNCE (21)
   VIRTIO_NET_F_MQ (22)
   VIRTIO_F_ANY_LAYOUT (27)
   VIRTIO_F_INDIRECT_DESC (28)
   VHOST_USER_F_PROTOCOL_FEATURES (30)
  protocol features (0x3)
   VHOST_USER_PROTOCOL_F_MQ (0)
   VHOST_USER_PROTOCOL_F_LOG_SHMFD (1)

socket filename /tmp/sock1 type client errno "Success"

rx placement:
   thread 0 on vring 1
tx placement: lock-free
   thread 0 on vring 0

Memory regions (total 1)
region fdguest_phys_addrmemory_sizeuserspace_addr 
mmap_offsetmmap_addr
== = == == == 
== ==
  0 260x 0x2000 0x7f350320 
0x 0x7ff94480

Virtqueue 0 (TX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 256 used.flags 1 used.idx 0
  kickfd 27 callfd 28 errfd -1

Virtqueue 1 (RX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 22 callfd 29 errfd -1


root@sut1:/home/cisco# service vpp restart


vat# exec show vhost-user VirtualEthernet0/0/0
Virtio vhost-user interfaces
Global:
  coalesce frames 32 time 1e-3
Interface: VirtualEthernet0/0/0 (ifindex 5)
virtio_net_hdr_sz 0
features mask (0x):
features (0x0):
  protocol features (0x0)

socket filename /tmp/sock1 type client errno "Success"

rx placement:
tx placement: spin-lock
   thread 0 on vring 0

Memory regions (total 0)

vat#

vat# exec show ver
vpp v17.04-rc0~419-gdeee5ee~b4400 built by jenkins on 
ubuntu1604-basebuild-4c-4g-4199 at Sun Mar 12 23:22:32 UTC 2017
root@sut1:/home/cisco# qemu-system-x86_64 --version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.9), Copyright (c) 
2003-2008 Fabrice Bellard

Thanks,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Missing Network and Broadcast address in FIB for interface IP

2017-03-21 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi all,

I have configured on 2 VPP interfaces IP addresses:
set interface ip address GigabitEthernet0/9/0 10.0.0.2/24
set interface ip address GigabitEthernet0/a/0 192.168.0.126/26 (Network: 
192.168.0.64, Broadcast: 192.168.0.127)

When I send to GigabitEthernet0/9/0 interface packet with destination 
192.168.0.64 and 192.168.0.127, the GigabitEthernet0/a/0 interface sends an ARP 
request.
sendp(iface='eth2', x=Ether(src='02:00:00:00:00:02', 
dst='08:00:27:f3:be:f0')/IP(src='10.0.0.1', dst='192.168.0.64'))
sendp(iface='eth2', x=Ether(src='02:00:00:00:00:02', 
dst='08:00:27:f3:be:f0')/IP(src='10.0.0.1', dst='192.168.0.125'))
sendp(iface='eth2', x=Ether(src='02:00:00:00:00:02', 
dst='08:00:27:f3:be:f0')/IP(src='10.0.0.1', dst='192.168.0.126'))
sendp(iface='eth2', x=Ether(src='02:00:00:00:00:02', 
dst='08:00:27:f3:be:f0')/IP(src='10.0.0.1', dst='192.168.0.127'))
sendp(iface='eth2', x=Ether(src='02:00:00:00:00:02', 
dst='08:00:27:f3:be:f0')/IP(src='10.0.0.1', dst='192.168.0.128'))

vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

02:34:42:407061: dpdk-input
  GigabitEthernet0/9/0 rx queue 0
  buffer 0x4ccb: current data 14, length 46, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x79433300
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> 08:00:27:f3:be:f0
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.64
tos 0x00, ttl 64, length 20, checksum 0xb000
fragment id 0x0001
02:34:42:407085: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.64
tos 0x00, ttl 64, length 20, checksum 0xb000
fragment id 0x0001
02:34:42:407088: ip4-lookup
  fib 0 dpo-idx 1 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.64
tos 0x00, ttl 64, length 20, checksum 0xb000
fragment id 0x0001
02:34:42:407090: ip4-glean
IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.64
  tos 0x00, ttl 64, length 20, checksum 0xb000
  fragment id 0x0001
02:34:42:407093: GigabitEthernet0/a/0-output
  GigabitEthernet0/a/0
  ARP: 08:00:27:66:b8:57 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  08:00:27:66:b8:57/192.168.0.126 -> 00:00:00:00:00:00/192.168.0.64
02:34:42:407095: error-drop
  ip4-glean: ARP requests sent
02:34:42:407096: GigabitEthernet0/a/0-tx
  GigabitEthernet0/a/0 tx queue 0
  buffer 0x186c6: current data -14, length 42, free-list 0, trace 0x0
  ARP: 08:00:27:66:b8:57 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  08:00:27:66:b8:57/192.168.0.126 -> 00:00:00:00:00:00/192.168.0.64

Packet 2

02:34:42:410263: dpdk-input
  GigabitEthernet0/9/0 rx queue 0
  buffer 0x4ca4: current data 14, length 46, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x79432940
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> 08:00:27:f3:be:f0
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.125
tos 0x00, ttl 64, length 20, checksum 0xafc3
fragment id 0x0001
02:34:42:410282: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.125
tos 0x00, ttl 64, length 20, checksum 0xafc3
fragment id 0x0001
02:34:42:410285: ip4-lookup
  fib 0 dpo-idx 1 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.125
tos 0x00, ttl 64, length 20, checksum 0xafc3
fragment id 0x0001
02:34:42:410286: ip4-glean
IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.125
  tos 0x00, ttl 64, length 20, checksum 0xafc3
  fragment id 0x0001
02:34:42:410288: GigabitEthernet0/a/0-output
  GigabitEthernet0/a/0
  ARP: 08:00:27:66:b8:57 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  08:00:27:66:b8:57/192.168.0.126 -> 00:00:00:00:00:00/192.168.0.125
02:34:42:410291: error-drop
  ip4-glean: ARP requests sent
02:34:42:410291: GigabitEthernet0/a/0-tx
  GigabitEthernet0/a/0 tx queue 0
  buffer 0x186ed: current data -14, length 42, free-list 0, trace 0x1
  ARP: 08:00:27:66:b8:57 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  08:00:27:66:b8:57/192.168.0.126 -> 00:00:00:00:00:00/192.168.0.125

Packet 3

02:34:42:414134: dpdk-input
  GigabitEthernet0/9/0 rx queue 0
  buffer 0x4c7d: current data 14, length 46, free-list 0, totlen-nifb 0, trace 
0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x79431f80
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> 08:00:27:f3:be:f0
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.126
tos 0x00, ttl 64, length 20, checksum 0xafc2
fragment id 0x0001
02:34:42:414162: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.126
tos 0x00, ttl 64, length 20, checksum 0xafc2
fragment id 0x0001
02:34:42:414165: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 10.0.0.1 -> 192.168.0.126
tos 0x00, ttl 64, length 20, checksum 0xafc2

Re: [vpp-dev] Default setting for VLAN strip offload mode

2017-03-10 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi John,

You are right it is VIC, I miss that is off by default for all NICs except VICs.

Thanks,
  Matej

From: John Lo (loj)
Sent: 9. marca 2017 16:06
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com>; vpp-dev@lists.fd.io
Subject: RE: Default setting for VLAN strip offload mode

Hi Matej,

Do you know which NIC/DPDK-driver it is? I do know that ENIC driver by default 
is initialized with VLAN tag striped, because it is more efficient with the 
VNIC setup on the VIC NIC. Thus it needs to be explicitly disabled in startup 
config.

For other NIC/driver's, they are left as their default, which should mean VLAN 
tag is not stripped.

Regards,
John

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 09, 2017 5:12 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Default setting for VLAN strip offload mode

vppctl show ver
vpp v17.01-2~ge5bf04d~b31 built by jenkins on ubuntu1604-basebuild-4c-4g-4725 
at Fri Jan 27 01:10:30 UTC 2017

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: 9. marca 2017 10:54
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Default setting for VLAN strip offload mode

Hi vpp dev,

I've noticed /etc/vpp/startup.conf says
## VLAN strip offload mode for interface
## Default is off

But in /var/log/syslog after vpp starts is
vnet[22679]: dpdk_lib_init:788: VLAN strip enabled for interface

With
vlan-strip-offload off, in config file in dpdk dev default section, in the log 
is
vnet[22721]: dpdk_lib_init:776: VLAN strip disabled for interface

Regards,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Default setting for VLAN strip offload mode

2017-03-09 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
vppctl show ver
vpp v17.01-2~ge5bf04d~b31 built by jenkins on ubuntu1604-basebuild-4c-4g-4725 
at Fri Jan 27 01:10:30 UTC 2017

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Sent: 9. marca 2017 10:54
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Default setting for VLAN strip offload mode

Hi vpp dev,

I've noticed /etc/vpp/startup.conf says
## VLAN strip offload mode for interface
## Default is off

But in /var/log/syslog after vpp starts is
vnet[22679]: dpdk_lib_init:788: VLAN strip enabled for interface

With
vlan-strip-offload off, in config file in dpdk dev default section, in the log 
is
vnet[22721]: dpdk_lib_init:776: VLAN strip disabled for interface

Regards,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Default setting for VLAN strip offload mode

2017-03-09 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi vpp dev,

I've noticed /etc/vpp/startup.conf says
## VLAN strip offload mode for interface
## Default is off

But in /var/log/syslog after vpp starts is
vnet[22679]: dpdk_lib_init:788: VLAN strip enabled for interface

With
vlan-strip-offload off, in config file in dpdk dev default section, in the log 
is
vnet[22721]: dpdk_lib_init:776: VLAN strip disabled for interface

Regards,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

2017-03-09 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi John,

I put interface to promiscuous mode with command “exec set interface 
promiscuous on GigabitEthernet0/4/0”.  Does exist VAT equivalent for it?
The promiscuous mode explain why no packet is received if I use destination mac 
address 02:00:00:00:00:01, but in test I’m using destination mac address of the 
interface. Untagged packet are received.
In promisc mode the VPP shows in trace all 3 packet that I send. (MAC is 
different because of  different simulation)
vat# exec show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:24:42:044242: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ccb: current data 14, length 20, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x5329f180
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:7f:3d:9b
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:24:42:044252: ip4-input
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:24:42:044258: ip4-lookup
  fib 0 dpo-idx 0 flow hash: 0x
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:24:42:044260: ip4-drop
IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
  tos 0x00, ttl 64, length 20, checksum 0x7ce7
  fragment id 0x0001
00:24:42:044262: error-drop
  ip4-input: ip4 adjacency drop

Packet 2

00:24:42:056643: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4ca4: current data 0, length 38, free-list 0, totlen-nifb 0, trace 
0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x0, data_off 128, phys_addr 0x5329e7c0
packet_type 0x0
  IP4: 02:00:00:00:00:02 -> fa:16:3e:7f:3d:9b 802.1q vlan 10
  IP6_HOP_BY_HOP_OPTIONS: 127.0.0.1 -> 127.0.0.1
tos 0x00, ttl 64, length 20, checksum 0x7ce7
fragment id 0x0001
00:24:42:056646: ethernet-input
  IP4: 02:00:00:00:00:02 -> fa:16:3e:7f:3d:9b 802.1q vlan 10
00:24:42:056651: error-drop
  ethernet-input: unknown vlan

Packet 3

00:24:42:062241: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4c7d: current data 0, length 34, free-list 0, totlen-nifb 0, trace 
0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 34
buf_len 2176, data_len 34, ol_flags 0x0, data_off 128, phys_addr 0x5329de00
packet_type 0x0
  0x: 02:00:00:00:00:02 -> fa:16:3e:7f:3d:9b
00:24:42:062243: ethernet-input
  0x: 02:00:00:00:00:02 -> fa:16:3e:7f:3d:9b
00:24:42:062245: error-punt
  dpdk-input: no error


With e1000 driver I see tagged frames with promisc on or off.

Thanks,
  M.


From: John Lo (loj)
Sent: 9. marca 2017 4:26
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com>; vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: RE: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

If adding a sub-interface for VLAN 3 still does not work, try create another 
dummy sub-interface with, say VLAN 100, and put that sub-interface into a 
bridge domain. This will force the interface into promiscuous mode.  -John

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of John Lo (loj)
Sent: Wednesday, March 08, 2017 9:45 PM
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com<mailto:mklot...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Subject: Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

Hi Matej,

The difference between having an interface in L2 bridge/xconnect mode is that 
the interface is put into promiscuous mode. Thus the interface will receive all 
packets irrespective of its destination MAC address. When an interface is in L3 
mode, it will receive packets with DMAC matching that of its own MAC only. 
Also, in L3 mode, packets with VLAN must match a sub-interface which you did 
not setup. I wonder whether it is the case that the virtio driver is smart 
enough to not accept VLAN packets in non-promiscuous mode also. One way to test 
can be to create a sub-interface matching VLAN 3 and check how it behaves.

Regards,
John


From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, March 08, 2017 8:43 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Subject: Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio 
interface

Hi all,

I did some test in virl testbed. I sent following 3 frames to VPP interface 
from scapy:
sendp(

Re: [vpp-dev] [csit-dev] VPP receive no tagged packet on Virtio interface

2017-03-08 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
st fa:16:3e:d0:4a:66 src 02:00:00:00:00:02
00:00:28:962643: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:962644: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:962644: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:d0:4a:66 src 02:00:00:00:00:02 bd_index 1
00:00:28:962644: error-drop
  l2-flood: L2 replication complete


Does the sw_interface_set_l2_bridge command something with virtio driver which 
enable/disable the vlan tagged frame filtering?

Thanks,
  M.

From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On 
Behalf Of Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Sent: 7. marca 2017 12:35
To: Neale Ranns (nranns) <nra...@cisco.com>; vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: Re: [csit-dev] VPP receive no tagged packet on Virtio interface

Hi Neale,

I fixed the issue with the IP addresses, but the problem remains. In trace is
vat# --- Start of thread 0 vpp_main ---
No packets in trace buffer

The VIRL topology links are connected via linux bridges, and it seems like it 
doesn’t forward tagged frames.
It is probably not issue related to VPP.

Thanks,
  M.

From: Neale Ranns (nranns)
Sent: 6. marca 2017 17:07
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com<mailto:mklot...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Subject: Re: [csit-dev] VPP receive no tagged packet on Virtio interface


Hi Matej,

Your IP addresses are configured on the same interface; sw_if_index 6. 
Sw_if_index 5 thus will not accept IP packets.

/neale

From: <csit-dev-boun...@lists.fd.io<mailto:csit-dev-boun...@lists.fd.io>> on 
behalf of "Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)" 
<mklot...@cisco.com<mailto:mklot...@cisco.com>>
Date: Monday, 6 March 2017 at 14:58
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Cc: "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" 
<csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>>
Subject: [csit-dev] VPP receive no tagged packet on Virtio interface

Hi all,

In CSIT we are running VPP on a VM with virtio network device.
vppctl show hardware
  NameIdx   Link  Hardware
GigabitEthernet0/4/0   1 up   GigabitEthernet0/4/0
  Ethernet address fa:16:3e:0a:3e:3d
  Red Hat Virtio
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 256, tx queues 1, tx desc 256


The interface is configured with 2 Dot1Q subinterfaces, with ip address on each 
subinterface.
sw_interface_set_flags sw_if_index 1 admin-up
create_vlan_subif sw_if_index 1 vlan 10
sw_interface_set_flags sw_if_index 5 admin-up
create_vlan_subif sw_if_index 1 vlan 20
sw_interface_set_flags sw_if_index 6 admin-up
sw_interface_add_del_address sw_if_index 6 192.168.100.1/24
sw_interface_add_del_address sw_if_index 6 192.168.200.1/24
ip_neighbor_add_del sw_if_index 5 dst 192.168.100.2 mac fa:16:3e:b1:67:b7
ip_neighbor_add_del sw_if_index 6 dst 192.168.200.2 mac fa:16:3e:b1:67:b7


In a testcase I’m sending tagged frame with tag 20 and I’m expecting received 
packed with tag 10
###[ Ethernet ]###
  dst  = fa:16:3e:0a:3e:3d
  src   = fa:16:3e:b1:67:b7
  type  = n_802_1Q
###[ 802.1Q ]###
 prio  = 0L
 id= 0L
 vlan  = 10L
 type  = IPv4
###[ IP ]###
version   = 4L
ihl   = 5L
tos   = 0x0
len   = 28
id= 1
flags =
frag  = 0L
ttl   = 64
proto = icmp
chksum= 0xcd8a
src   = 192.168.100.2
dst   = 192.168.200.2
\options   \
###[ ICMP ]###
   type  = echo-request
   code  = 0
   chksum= 0xf7ff
   id= 0x0
   seq   = 0x0


But there is no packet received in vpp show trace
vat# --- Start of thread 0 vpp_main ---
No packets in trace buffer


The same testcase with e1000 driver instead virtio has in trace
Packet 1

00:00:18:038106: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x53935340
packet_type 0x0
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038164: ethernet-input
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
00:00:18:038174: ip4-input

Re: [vpp-dev] VPP receive no tagged packet on Virtio interface

2017-03-06 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi Dave,

Im sorry, I should write I'm sending tagged frame with tag 10 and I'm expecting 
received packed with tag 20.
The mac address in trace could mismatch, because I copyed from log.

Thanks,
  M.

From: Dave Barach (dbarach)
Sent: 6. marca 2017 16:06
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com>; vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io
Subject: RE: VPP receive no tagged packet on Virtio interface

I'm not sure if this is significant, but you wrote: "In a testcase I'm sending 
tagged frame with tag 20 and I'm expecting received packed with tag 10"

The packet tracer shows the reverse: a packet received on vlan 10 and sent on 
vlan 20.

00:00:18:038106: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x53935340
packet_type 0x0
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10

00:00:18:038194: GigabitEthernet0/4/0-tx
  GigabitEthernet0/4/0 tx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20


Thanks... Dave

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, March 6, 2017 9:59 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Subject: [vpp-dev] VPP receive no tagged packet on Virtio interface

Hi all,

In CSIT we are running VPP on a VM with virtio network device.
vppctl show hardware
  NameIdx   Link  Hardware
GigabitEthernet0/4/0   1 up   GigabitEthernet0/4/0
  Ethernet address fa:16:3e:0a:3e:3d
  Red Hat Virtio
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 256, tx queues 1, tx desc 256


The interface is configured with 2 Dot1Q subinterfaces, with ip address on each 
subinterface.
sw_interface_set_flags sw_if_index 1 admin-up
create_vlan_subif sw_if_index 1 vlan 10
sw_interface_set_flags sw_if_index 5 admin-up
create_vlan_subif sw_if_index 1 vlan 20
sw_interface_set_flags sw_if_index 6 admin-up
sw_interface_add_del_address sw_if_index 6 192.168.100.1/24
sw_interface_add_del_address sw_if_index 6 192.168.200.1/24
ip_neighbor_add_del sw_if_index 5 dst 192.168.100.2 mac fa:16:3e:b1:67:b7
ip_neighbor_add_del sw_if_index 6 dst 192.168.200.2 mac fa:16:3e:b1:67:b7


In a testcase I'm sending tagged frame with tag 20 and I'm expecting received 
packed with tag 10
###[ Ethernet ]###
  dst  = fa:16:3e:0a:3e:3d
  src   = fa:16:3e:b1:67:b7
  type  = n_802_1Q
###[ 802.1Q ]###
 prio  = 0L
 id= 0L
 vlan  = 10L
 type  = IPv4
###[ IP ]###
version   = 4L
ihl   = 5L
tos   = 0x0
len   = 28
id= 1
flags =
frag  = 0L
ttl   = 64
proto = icmp
chksum= 0xcd8a
src   = 192.168.100.2
dst   = 192.168.200.2
\options   \
###[ ICMP ]###
   type  = echo-request
   code  = 0
   chksum= 0xf7ff
   id= 0x0
   seq   = 0x0


But there is no packet received in vpp show trace
vat# --- Start of thread 0 vpp_main ---
No packets in trace buffer


The same testcase with e1000 driver instead virtio has in trace
Packet 1

00:00:18:038106: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x53935340
packet_type 0x0
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038164: ethernet-input
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
00:00:18:038174: ip4-input
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038179: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038185: ip4-rewrite
  tx_sw_if_index 6 dpo-idx 5 : ipv4 via 192.168.200.2 GigabitEthernet0/4/0.20: 
IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20 flow hash: 0x
  IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20
  ICMP: 192.168.100.2 -> 192.168.200.2
tos

[vpp-dev] VPP receive no tagged packet on Virtio interface

2017-03-06 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi all,

In CSIT we are running VPP on a VM with virtio network device.
vppctl show hardware
  NameIdx   Link  Hardware
GigabitEthernet0/4/0   1 up   GigabitEthernet0/4/0
  Ethernet address fa:16:3e:0a:3e:3d
  Red Hat Virtio
carrier up full duplex speed 1 mtu 9216
rx queues 1, rx desc 256, tx queues 1, tx desc 256


The interface is configured with 2 Dot1Q subinterfaces, with ip address on each 
subinterface.
sw_interface_set_flags sw_if_index 1 admin-up
create_vlan_subif sw_if_index 1 vlan 10
sw_interface_set_flags sw_if_index 5 admin-up
create_vlan_subif sw_if_index 1 vlan 20
sw_interface_set_flags sw_if_index 6 admin-up
sw_interface_add_del_address sw_if_index 6 192.168.100.1/24
sw_interface_add_del_address sw_if_index 6 192.168.200.1/24
ip_neighbor_add_del sw_if_index 5 dst 192.168.100.2 mac fa:16:3e:b1:67:b7
ip_neighbor_add_del sw_if_index 6 dst 192.168.200.2 mac fa:16:3e:b1:67:b7


In a testcase I'm sending tagged frame with tag 20 and I'm expecting received 
packed with tag 10
###[ Ethernet ]###
  dst  = fa:16:3e:0a:3e:3d
  src   = fa:16:3e:b1:67:b7
  type  = n_802_1Q
###[ 802.1Q ]###
 prio  = 0L
 id= 0L
 vlan  = 10L
 type  = IPv4
###[ IP ]###
version   = 4L
ihl   = 5L
tos   = 0x0
len   = 28
id= 1
flags =
frag  = 0L
ttl   = 64
proto = icmp
chksum= 0xcd8a
src   = 192.168.100.2
dst   = 192.168.200.2
\options   \
###[ ICMP ]###
   type  = echo-request
   code  = 0
   chksum= 0xf7ff
   id= 0x0
   seq   = 0x0


But there is no packet received in vpp show trace
vat# --- Start of thread 0 vpp_main ---
No packets in trace buffer


The same testcase with e1000 driver instead virtio has in trace
Packet 1

00:00:18:038106: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x53935340
packet_type 0x0
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038164: ethernet-input
  IP4: fa:16:3e:b1:67:b7 -> fa:16:3e:bc:bb:cd 802.1q vlan 10
00:00:18:038174: ip4-input
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038179: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 64, length 28, checksum 0xcd8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038185: ip4-rewrite
  tx_sw_if_index 6 dpo-idx 5 : ipv4 via 192.168.200.2 GigabitEthernet0/4/0.20: 
IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20 flow hash: 0x
  IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 63, length 28, checksum 0xce8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038188: GigabitEthernet0/4/0-output
  GigabitEthernet0/4/0.20
  IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 63, length 28, checksum 0xce8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:18:038194: GigabitEthernet0/4/0-tx
  GigabitEthernet0/4/0 tx queue 0
  buffer 0x4e51: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  IP4: fa:16:3e:bc:bb:cd -> fa:16:3e:b1:67:b7 802.1q vlan 20
  ICMP: 192.168.100.2 -> 192.168.200.2
tos 0x00, ttl 63, length 28, checksum 0xce8a
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff


Does anybody know if there is a problem in virtio driver with vlans?

Thanks,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] vpp csit functional test failures, not obviously related to the patches involved

2017-02-24 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hello Dave,
I've updated nested vm's disk driver because of deploying Centos testing.
I didn't realize when I update image in common directory it affect all Virl 
simulations without proper patches.
I rechecked the 5498 patch waiting a results

From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On 
Behalf Of Dave Barach (dbarach)
Sent: 23. februára 2017 21:10
To: csit-...@lists.fd.io
Cc: vpp-dev 
Subject: [csit-dev] vpp csit functional test failures, not obviously related to 
the patches involved

For example: https://gerrit.fd.io/r/#/c/5498

Thanks... Dave

13:54:14.203  TRACE   exec_command on ('10.30.51.236', 22): sudo -S rm -f 
/tmp/qga.sock
13:54:14.306  TRACE   exec_command on ('10.30.51.236', 22) took 
0.106814861298 seconds
13:54:14.306  TRACE   chan_recv/_stderr took 0.000247001647949 seconds
13:54:14.307  TRACE   return RC 0
13:54:14.307  TRACE   return STDOUT
13:54:14.307  TRACE   return STDERR
13:54:14.307  DEBUG  [chan 269] Max packet in: 32768 bytes
13:54:14.311  TRACE   exec_command on ('10.30.51.236', 22): sudo -S rm -f 
/tmp/sock1
13:54:14.413  TRACE   exec_command on ('10.30.51.236', 22) took 
0.106304168701 seconds
13:54:14.413  TRACE   chan_recv/_stderr took 0.000252962112427 seconds
13:54:14.414  TRACE   return RC 0
13:54:14.414  TRACE   return STDOUT
13:54:14.414  TRACE   return STDERR
13:54:14.414  DEBUG  [chan 270] Max packet in: 32768 bytes
13:54:14.418  TRACE   exec_command on ('10.30.51.236', 22): sudo -S rm -f 
/tmp/sock2
13:54:14.521  TRACE   exec_command on ('10.30.51.236', 22) took 
0.106459140778 seconds
13:54:14.521  TRACE   chan_recv/_stderr took 0.000211000442505 seconds
13:54:14.521  TRACE   return RC 0
13:54:14.521  TRACE   return STDOUT
13:54:14.521  TRACE   return STDERR
13:54:14.522  FAIL   SSHTimeout: Timeout exception.
Current contents of stdout buffer:
Current contents of stderr buffer:
13:54:14.522  DEBUG  Traceback (most recent call last):
  File 
"/w/workspace/vpp-csit-verify-virl-master/csit/resources/libraries/python/QemuUtils.py",
 line 521, in qemu_start
self._wait_until_vm_boot()
  File 
"/w/workspace/vpp-csit-verify-virl-master/csit/resources/libraries/python/QemuUtils.py",
 line 297, in _wait_until_vm_boot
out = self._qemu_qga_exec('guest-ping')
  File 
"/w/workspace/vpp-csit-verify-virl-master/csit/resources/libraries/python/QemuUtils.py",
 line 272, in _qemu_qga_exec
(ret_code, stdout, stderr) = self._ssh.exec_command(qga_cmd)
  File 
"/w/workspace/vpp-csit-verify-virl-master/csit/resources/libraries/python/ssh.py",
 line 156, in exec_command
.format(stdout.getvalue(), stderr.getvalue())
13:53:43.855  TRACE   Arguments: [ 'Qemu Start' ]
13:53:43.807  TRACE   Arguments: [ ${dut_node}={b'honeycomb': 
{b'netconf_port': 2831, b'passwd': b'admin', b'port': 8183, b'user': b'admin'},
b'host': b'10.30.51.236',
b'interfaces': {b'port1': {b'link': b'link1', b'mac_address': 
b'fa:16:3e:77:59:76', b'mtu': 9216, b'name': 'GigabitEthernet0/4/0', 
b'pci_address': b':00:04.0', b'vpp_sw_index': 1},
 b'port2': {b'link': b'link4', b'mac_address': 
b'fa:16:3e:11:d6:45', b'mtu': 9216, b'name': 'GigabitEthernet0/5/0', 
b'pci_address': b':00:05.0', b'vpp_sw_index': 2},
 b'port3': {b'link': b'link3', b'mac_address': 
b'fa:16:3e:e1:6f:29', b'mtu': 9216, b'name': 'GigabitEthernet0/6/0', 
b'pci_address': b':00:06.0', b'vpp_sw_index': 3},
 b'port4': {b'link': b'link6', b'mac_address': 
b'fa:16:3e:3b:47:19', b'mtu': 9216, b'name': 'GigabitEthernet0/7/0', 
b'pci_address': b':00:07.0', b'vpp_sw_index': 4}},
b'port': 22,
b'priv_key': b'-BEGIN RSA PRIVATE 

Re: [vpp-dev] [csit-dev] sporadically failing functional tests: L2BD and VXLANoIPv4oVLAN

2017-01-20 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
I marked testcase as non-critical in patches.

https://gerrit.fd.io/r/#/c/4803/
https://gerrit.fd.io/r/#/c/4804/
https://gerrit.fd.io/r/#/c/4805/


From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On 
Behalf Of Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
Sent: 17. januára 2017 16:27
To: Damjan Marion (damarion) <damar...@cisco.com>
Cc: csit-...@lists.fd.io; vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [csit-dev] [vpp-dev] sporadically failing functional tests: L2BD 
and VXLANoIPv4oVLAN

Unfortunately it failed again... :( It seems that packet has been correctly 
processed in DUT1 but didn't reach DUT2:

Packet trace form DUT1:

Packet 1

00:00:13:305429: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x4e03: current data 0, length 60, free-list 0, totlen-nifb 0, trace 
0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0x5ad33fc0
packet_type 0x0
  IP4: fa:16:3e:3d:5f:7c -> fa:16:3e:70:a8:34
  ICMP: 192.168.100.1 -> 192.168.100.2
tos 0x00, ttl 64, length 28, checksum 0x318c
fragment id 0x0001
  ICMP echo_request checksum 0xf7ff
00:00:13:305463: ethernet-input
  IP4: fa:16:3e:3d:5f:7c -> fa:16:3e:70:a8:34
00:00:13:305473: l2-input
  l2-input: sw_if_index 1 dst fa:16:3e:70:a8:34 src fa:16:3e:3d:5f:7c
00:00:13:305476: l2-learn
  l2-learn: sw_if_index 1 dst fa:16:3e:70:a8:34 src fa:16:3e:3d:5f:7c bd_index 1
00:00:13:305482: l2-fwd
  l2-fwd:   sw_if_index 1 dst fa:16:3e:70:a8:34 src fa:16:3e:3d:5f:7c bd_index 1
00:00:13:305485: l2-flood
  l2-flood: sw_if_index 1 dst fa:16:3e:70:a8:34 src fa:16:3e:3d:5f:7c bd_index 1
00:00:13:305486: l2-output
  l2-output: sw_if_index 6 dst fa:16:3e:70:a8:34 src fa:16:3e:3d:5f:7c
00:00:13:305508: vxlan4-encap
  VXLAN encap to vxlan_tunnel0 vni 23
00:00:13:305511: ip4-load-balance
  fib 6 dpo-idx 14 flow hash: 0x
  UDP: 172.16.0.1 -> 172.16.0.2
tos 0x00, ttl 254, length 96, checksum 0x6469
fragment id 0x
  UDP: 41828 -> 4789
length 76, checksum 0x
00:00:13:305516: ip4-rewrite
  tx_sw_if_index 5 dpo-idx 2 : ipv4 via 172.16.0.2 GigabitEthernet0/6/0.10: 
IP4: fa:16:3e:60:21:23 -> fa:16:3e:52:55:ca 802.1q vlan 10 flow hash: 0x
  IP4: fa:16:3e:60:21:23 -> fa:16:3e:52:55:ca 802.1q vlan 10
  UDP: 172.16.0.1 -> 172.16.0.2
tos 0x00, ttl 253, length 96, checksum 0x6569
fragment id 0x
  UDP: 41828 -> 4789
length 76, checksum 0x
00:00:13:305521: GigabitEthernet0/6/0-output
  GigabitEthernet0/6/0.10
  IP4: fa:16:3e:60:21:23 -> fa:16:3e:52:55:ca 802.1q vlan 10
  UDP: 172.16.0.1 -> 172.16.0.2
tos 0x00, ttl 253, length 96, checksum 0x6569
fragment id 0x
  UDP: 41828 -> 4789
length 76, checksum 0x
00:00:13:305524: GigabitEthernet0/6/0-tx
  GigabitEthernet0/6/0 tx queue 0
  buffer 0x4e03: current data -54, length 114, free-list 0, totlen-nifb 0, 
trace 0x0
  IP4: fa:16:3e:60:21:23 -> fa:16:3e:52:55:ca 802.1q vlan 10
  UDP: 172.16.0.1 -> 172.16.0.2
tos 0x00, ttl 253, length 96, checksum 0x6569
fragment id 0x
  UDP: 41828 -> 4789
length 76, checksum 0x

Packet trace form DUT2:

No packets in trace buffer


Anyway, it has passed with vpp build 17.04-rc0~64-gf952692~b1689_amd64 as well 
as vpp build 17.01-rc2~5-g257d5e2~b17_amd64.

I forced recheck with newer vpp build from the master: 
17.04-rc0~105-g5a3a6c0~b1730_amd64 for sure.

From: csit-dev-boun...@lists.fd.io<mailto:csit-dev-boun...@lists.fd.io> 
[mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Jan Gelety -X (jgelety - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, January 17, 2017 15:16
To: Damjan Marion (damarion) <damar...@cisco.com<mailto:damar...@cisco.com>>
Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>; vpp-dev 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [csit-dev] [vpp-dev] sporadically failing functional tests: L2BD 
and VXLANoIPv4oVLAN

Hello Damjan,

Needed fix has been merged to master and cherry-picked to csit branch 
oper-170108 that is currently used to verify vpp patch.

I did recheck on your commit https://gerrit.fd.io/r/#/c/4613/14 - it should 
pass now. We will keep our eyes on it.

Regards,
Jan

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, January 17, 2017 10:29
To: Damjan Marion (damarion) <damar...@cisco.com<mailto:damar...@cisco.com>>; 
csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Cc: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] [csit-dev] sporadically failing functional tests: L2BD 
and VXLANoIPv4oVLAN

I'll fix the test cases.

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Damja

Re: [vpp-dev] [csit-dev] sporadically failing functional tests: L2BD and VXLANoIPv4oVLAN

2017-01-17 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
I'll fix the test cases.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Damjan Marion (damarion)
Sent: 16. januára 2017 22:39
To: csit-...@lists.fd.io
Cc: vpp-dev 
Subject: Re: [vpp-dev] [csit-dev] sporadically failing functional tests: L2BD 
and VXLANoIPv4oVLAN


Can we please disable this test temporary as tests are failing?

Thanks,

Damjan


On 16 Jan 2017, at 17:12, Maciek Konstantynowicz (mkonstan) 
> wrote:

Hi, Got the report above are failing from time to time:

https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3316/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3316/robot/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3313/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3312/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3311/

Could someone have a look ?

-Maciek

___
csit-dev mailing list
csit-...@lists.fd.io
https://lists.fd.io/mailman/listinfo/csit-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Deleting VXLAN interface doesn't delete it from interface dump

2017-01-12 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
I've opened
https://jira.fd.io/browse/VPP-594
and
https://jira.fd.io/browse/VPP-595
https://jira.fd.io/browse/VPP-596



From: John Lo (loj)
Sent: 10. januára 2017 17:14
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com>; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Deleting VXLAN interface doesn't delete it from 
interface dump

Hi Matej,

The proper reuse of deleted VXLAN interface is to create a new one and put this 
newly created interface (which is actually reusing an old one, thus using the 
same sw_if_index) into a BD, etc. To bring a deleted interface state to up and 
into a BD is not the proper way to reuse it and thus will not work, since it is 
deleted and thus not setup to perform VXLAN function any more.

I suppose you should open a Jira to report the crash caused by this incorrect 
usage of a deleted VXLAN tunnel.

Regards,
John


From: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, January 10, 2017 10:00 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] Deleting VXLAN interface doesn't delete it from 
interface dump

Reusing removed VXLAN interfaces sounds good.
However I put deleted vxlan_tunnel interface UP, then assign it to a bridge 
domain and add pg interface to this bridge domain.
When I sent a traffic to pg interface VPP crashes with 
build-root/install-vpp_lite-native/vpp/bin/vpp[10393]: received signal SIGSEGV, 
PC 0x7f8e63b7744d, faulting address 0xfffc in /var/log/syslog

Regards,
  Matej

From: John Lo (loj)
Sent: 10. januára 2017 14:14
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com<mailto:mklot...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] Deleting VXLAN interface doesn't delete it from 
interface dump

Yes, this is the expected behavior. These deleted VXLAN tunnels in the down 
state are placed in a pool so that it can be reused when more VXLAN tunnels are 
created later. On creating a VXLAN tunnel, any of these deleted ones are reused 
first, before new interfaces are created for the VXLAN tunnel.

Regards,
John

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, January 10, 2017 3:45 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Deleting VXLAN interface doesn't delete it from interface 
dump

Hi,

I'm trying delete VXLAN tunnel interfaces and after they are deleted they are 
still in show interfaces but with down state.

vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 1
vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 2
vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 3
vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 2 del

vat# exec show vxlan tunnel
[0] src 172.16.1.1 dst 172.16.1.2 vni 1 sw_if_index 3 encap_fib_index 0 
fib_entry_index 19 decap_next l2
[2] src 172.16.1.1 dst 172.16.1.2 vni 3 sw_if_index 5 encap_fib_index 0 
fib_entry_index 19 decap_next l2

vat# exec show interface
  Name   Idx   State  Counter  Count
vxlan_tunnel0 3 up
vxlan_tunnel1 4down
vxlan_tunnel2 5 up

Is this expected behavior or should I open a Jira ticket?
Loopbacks and subinterfaces are deleted also from show interface.

Thanks,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] admin_up_down flag for loopback interface

2017-01-02 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi Neale, 

> Yes.
> The golden rule of FIB programming – do as you’re told and no more. The
> route will stay in the FIB until the control plane chooses to remove them –
> and this is the same control plane that has chosen to admin down the
> interface.

So the correct API calls, for disabling interface, should look like:
  sw_interface_set_flags(admin_up_down=0)
  then should I remove address from interface or  remove route from fib?

Thanks, 
  Matej

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] admin_up_down flag for loopback interface

2016-12-22 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi all,

I'm trying put Loopback interface to DOWN state with set admin_up_down=0 in 
sw_interface_set_flags api. The interface has IPv4 address configured with /32 
prefix.
Should the interface's address be in FIB when the admin_up_down flag is set to 
0?
Should VPP respond to ICMP echo requests to interface's IP when the 
admin_up_down flag is set to 0?

Thanks,
  Matej

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vxlan setup guidance

2016-12-09 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
https://jira.fd.io/browse/VPP-553

From: Dave Barach (dbarach)
Sent: 9. decembra 2016 15:09
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) 
<mklot...@cisco.com>
Subject: RE: [vpp-dev] vxlan setup guidance

Please do; assign it to John Lo...

Thanks... Dave

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Friday, December 9, 2016 9:03 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] vxlan setup guidance

Hi,

I've noticed, new scapy uses different flag value than older, it uses 0xc 
instead 0x8 which is required by VPP.

#define VXLAN_FLAGS_I 0x08

if (PREDICT_FALSE (vxlan0->flags != VXLAN_FLAGS_I))
{
  error0 = VXLAN_ERROR_BAD_FLAGS;
  next0 = VXLAN_INPUT_NEXT_DROP;
  goto trace0;
}

However RFC https://tools.ietf.org/html/rfc7348#section-5 says that received 
reserved bits must be ignored.

Should I open a Jira ticket for this issue?

Regards,
  Matej

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vxlan setup guidance

2016-12-09 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hi,

I've noticed, new scapy uses different flag value than older, it uses 0xc 
instead 0x8 which is required by VPP.

#define VXLAN_FLAGS_I 0x08

if (PREDICT_FALSE (vxlan0->flags != VXLAN_FLAGS_I))
{
  error0 = VXLAN_ERROR_BAD_FLAGS;
  next0 = VXLAN_INPUT_NEXT_DROP;
  goto trace0;
}

However RFC https://tools.ietf.org/html/rfc7348#section-5 says that received 
reserved bits must be ignored.

Should I open a Jira ticket for this issue?

Regards,
  Matej

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Configure same IP address without error message

2016-11-28 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
I've opened https://jira.fd.io/browse/VPP-539

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Sent: 28. novembra 2016 10:16
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Configure same IP address without error message

Hello dev team,

I tried to configure same IP address to different Loopback interfaces. The 
second command doesn't log error message and IP is not configured on second 
interface.
exec create loopback interface
exec create loopback interface
exec set interface state loop0 up
exec set interface state loop1 up
exec set interface ip address loop0 10.0.0.1/24
exec set interface ip address loop1 10.0.0.1/24
exec show interface address
local0 (dn):
loop0 (up):
  10.0.0.1/24
loop1 (up):

Should I open a Jira ticket for this?

Is in VPP supported configuring secondary IP address from same IP network?
exec set interface ip address loop0 10.0.0.1/24
exec set interface ip address loop0 10.0.0.2/24
vat# set interface ip address: failed to add 10.0.0.2/24 which conflicts with 
10.0.0.1/24 for interface loop0

but on different interface is not in conflict:

vat# exec set interface ip address loop1 10.0.0.2/24
vat# exec show interface address
local0 (dn):
loop0 (up):
  10.0.0.1/24
loop1 (dn):
  10.0.0.2/24


Thanks,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Configure same IP address without error message

2016-11-28 Thread Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
Hello dev team,

I tried to configure same IP address to different Loopback interfaces. The 
second command doesn't log error message and IP is not configured on second 
interface.
exec create loopback interface
exec create loopback interface
exec set interface state loop0 up
exec set interface state loop1 up
exec set interface ip address loop0 10.0.0.1/24
exec set interface ip address loop1 10.0.0.1/24
exec show interface address
local0 (dn):
loop0 (up):
  10.0.0.1/24
loop1 (up):

Should I open a Jira ticket for this?

Is in VPP supported configuring secondary IP address from same IP network?
exec set interface ip address loop0 10.0.0.1/24
exec set interface ip address loop0 10.0.0.2/24
vat# set interface ip address: failed to add 10.0.0.2/24 which conflicts with 
10.0.0.1/24 for interface loop0

but on different interface is not in conflict:

vat# exec set interface ip address loop1 10.0.0.2/24
vat# exec show interface address
local0 (dn):
loop0 (up):
  10.0.0.1/24
loop1 (dn):
  10.0.0.2/24


Thanks,
  Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev