Re: [vpp-dev] change vhost-user queue size

[steven luong]

Yuliang,

Queue size is controlled by the driver, not the device which VPP is running as. 
When you launch the VM via Qemu, at the end of virtio-net-pci, specify 
rx_queue_size=xxx and/or tx_queue_size=xxx, where xxx is 512 or 1024.

You need Qemu-2.8.0 to specify rx_queue_size. You need to get Qemu-2.10.0 for 
both rx_queue_size and/or tx_queue_size support.

Steven

From:  on behalf of Yuliang Li 
Date: Wednesday, May 16, 2018 at 9:09 PM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] change vhost-user queue size

Hi all,

When vpp sends packets to a VM via a vhost-user interface, it will put the 
packet in a queue (called `rxvq` in the code). It seems the default queue size 
is 256 descriptors (I print rxvq->qsz_mask+1, and get 256). Is it possible to 
increase the queue size, and how?

I followed the steps 
here
 to setup the vhost-user interfaces and VM.

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University

Re: [vpp-dev] router_plugin

[Demian Pecile]

Hi Wang trying last version.
I have cannot find -lrtnl error.

Any idea ?

its working with last versions ?

 Arch for platform 'vpp' is native 
 Finding source for router 
 Makefile fragment found in /vpp/build-data/packages/router.mk 
 Source found in /vpp/router 
 Configuring router: nothing to do 
 Building router in /vpp/build-root/build-vpp-native/router 
make[1]: Entering directory '/vpp/build-root/build-vpp-native/router'
  CC   router/tap_inject_netlink.lo
  CCLD router.la
/usr/bin/ld: cannot find -lrtnl
collect2: error: ld returned 1 exit status
Makefile:444: recipe for target 'router.la' failed
make[1]: *** [router.la] Error 1
make[1]: Leaving directory '/vpp/build-root/build-vpp-native/router'
Makefile:691: recipe for target 'router-build' failed
make: *** [router-build] Error 2



> El 4 mar. 2018, a las 23:38, Wang  escribió:
> 
> HI Gulakh,
> 
> From my experience, VPP and VPPSB are compatible with the latest versions. 
> What sequence of command lines did you use?
> 
> 2018-03-04 4:58 GMT-05:00 Gulakh  >:
> Hi,
> I am using vppsb router plugin with vpp. there is a problem when I use 
> tap-inject.
> The problem is that after I enable tap-inject and set interfaces' and taps' 
> IP address, I want to make taps' state up but at this point vpp crashes and 
> everything rolls back to its first state (No tap, No IP address, ...)
> 
> Q1) What is the problem??
> 
> Q2) I have heard that VPP and VPPSB are not compatible in some versions ... 
> To which versions Should checkout both source code so that they can work 
> correctly??
> 
> Thanks in advance
> 
> 
> 
> 
> 

--
Demian Pecile
Siete Capas S.R.L.
Periodistas Neuquinos 136
Piso 4 - Dpto. A - 8300 Neuquen
Argentina
Tel +54-299-4479172 
Cel. +549-299-5833500

[vpp-dev] change vhost-user queue size

[Yuliang Li]

Hi all,

When vpp sends packets to a VM via a vhost-user interface, it will put the
packet in a queue (called `rxvq` in the code). It seems the default queue
size is 256 descriptors (I print rxvq->qsz_mask+1, and get 256). Is it
possible to increase the queue size, and how?

I followed the steps here

to setup the vhost-user interfaces and VM.

Thanks,
-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University

Re: [vpp-dev] problem in xcrw testing

[John Lo (loj)]

Hi Xyxue,

I have not used xcrw before to know how it is supposed to work, to cross 
connect a layer 2 interface to a layer 3 stack.  My suggestion was based on the 
error shown by the packet trace you provided, that l2-output node found GRE 
tunnel not to be set to L2 mode.  If a GRE tunnel is created in TEB mode, it is 
an L2 interface and thus can be put into L2 mode to work with L2 xconnect.  If 
you have a “normal” L2 xconnect config like the following I would expect it to 
work:

set interface l2 xconnect host-eth5 gre0
set interface l2 xconnect gre0 host-eth5

BTW, in older version of VPP, GRE tunnel in TEB mode has the name pattern 
teb-greN while with later version just greN, where N is the tunnel instance 
number.

I don’t know what are your intended usage or expectation of xcrw is and hoping 
someone with proper knowledge of xcrw can help.

Regards,
John


From: 薛欣颖 
Sent: Wednesday, May 16, 2018 8:07 AM
To: John Lo (loj) ; Neale Ranns (nranns) ; 
vpp-dev 
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John，

I changed my configuration to that shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface l3 host-eth1
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next gre-output  rw 
4558fd2fa5720b0101020b0101016558
create bridge-domain 1
set interface l2 bridge teb-gre0 1
set interface l2 bridge xcrw0 1

There is an assert :
Program received signal SIGSEGV, Segmentation fault.
0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
366   hw = vnet_get_hw_interface (vnm, sw->hw_if_index);
(gdb) bt
#0  0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
#1  0x76f3126b in gre_interface_tx (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:412
#2  0x7769b2aa in dispatch_node (vm=0x7791d1a0 , 
node=0x7fffb6c87600, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING,
frame=0x7fffb676fbc0, last_time_stamp=35926090675277) at 
/home/vpp/build-data/../src/vlib/main.c:1010
#3  0x7769b88d in dispatch_pending_node (vm=0x7791d1a0 
, pending_frame_index=4, last_time_stamp=35926090675277)
at /home/vpp/build-data/../src/vlib/main.c:1160
#4  0x7769daa4 in vlib_main_or_worker_loop (vm=0x7791d1a0 
, is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1630
#5  0x7769db53 in vlib_main_loop (vm=0x7791d1a0 ) 
at /home/vpp/build-data/../src/vlib/main.c:1649
#6  0x7769e2ad in vlib_main (vm=0x7791d1a0 , 
input=0x7fffb5704fb0) at /home/vpp/build-data/../src/vlib/main.c:1806
#7  0x776e0d64 in thread0 (arg=140737346916768) at 
/home/vpp/build-data/../src/vlib/unix/main.c:617
#8  0x76927560 in clib_calljmp () at 
/home/vpp/build-data/../src/vppinfra/longjmp.S:128
#9  0x7fffd350 in ?? ()
#10 0x776e1223 in vlib_unix_main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vlib/unix/main.c:682
#11 0x00406202 in main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vpp/vnet/main.c:241
(gdb)

Is there any examples about xcrw ? Is there any configuration I missed？

Thanks，
Xyxue
From: John Lo (loj)
Date: 2018-05-16 16:02
To: 薛欣颖; Neale Ranns 
(nranns); vpp-dev
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,

The L2 cross connect CLI via either xconnect or xcrw would put the source/input 
interface into L2 mode and setup an one-directional cross connect to the 
specified peer/output interface.  The expectation is there should be a 
xcrw/cross connect CLI for the other direction specifying the other interface 
as source/input so it will also be in L2 mode.

Hope this help, with regards,
John

From: 薛欣颖 >
Sent: Wednesday, May 16, 2018 3:46 AM
To: John Lo (loj) >; Neale Ranns (nranns) 
>; vpp-dev 
>
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John,

The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?



Thanks,
Xyxue


From: John Lo (loj)
Date: 2018-05-15 20:32
To: 薛欣颖; Neale 

Re: [EXT] [vpp-dev] Marvell's AI from last call

[Damjan Marion]

Hi Natalie,

Who requested that? 

Thanks,

-- 
Damjan

> On 16 May 2018, at 15:33, Natalie Samsonov  wrote:
> 
> Dear Damjan,
>
> As I understood, it was a request to use DPDK plugin with all platforms and I 
> was asked to upstream Marvell DPDK plugin.
>
> Best Regards,
> Natalie
>
> From: Damjan Marion [mailto:dmarion.li...@gmail.com 
> ] 
> Sent: Wednesday, May 16, 2018 16:03
> To: Natalie Samsonov >
> Cc: Tina Tsou >; 
> vpp-dev@lists.fd.io ; Maen Suleiman 
> >
> Subject: [EXT] Re: [vpp-dev] Marvell's AI from last call
>
> External Email
>
> Dear Natalie,
>
> What is the point of using DPDK marvel driver (which is actually just a 
> wrapper around musdk) if we already have native musdk support in vpp?
> -- 
> Damjan
> 
> 
> On 15 May 2018, at 08:48, Natalie Samsonov  > wrote:
>
> Hi,
>
> 1.   We are working now on upstreaming Marvell’s PMD support in VPP DPDK 
> plugin.
> I’m attaching the patch as well in case you want play with it.
> 2.   Regarding the L3FWD performance difference between MUSDK and DPDK, 
> currently we don’t have numbers with VPP L3FW.
> We only have  the numbers with two different applications. One is our own 
> L3FW application running on top of MUSDK and other is a standard DPDL L3FWD 
> application, so it’s not a fair comparison.
>
> Best Regards,
> Natalie Samsonov
>
>
> 
> <0001-plugins-dpdk-Add-support-for-net_mrvl-dpdk-driver.patch>

[vpp-dev] tap-inject for BGP Kill traffic

[Demian Pecile]

Hi 
I am running VPP jut to route traffic between vlans, no routing 
protocol involved.
I compiled the tap-inject plugin.
When I enable the plugin, I see I receive packets, but no packets go 
out.

RX packets go up, nut no TX packets.

So 2 questions, is this behavior normal ?
Its possible to restrict tap0inject just to 1 interface ?

Thanks

--
Demian Pecile
Siete Capas S.R.L.
Periodistas Neuquinos 136
Piso 4 - Dpto. A - 8300 Neuquen
Argentina
Tel +54-299-4479172 
Cel. +549-299-5833500

Re: [vpp-dev] [infra-steering] NOTIFICATION: FD.io Maintenance

[Vanessa Valderrama]

I apologize, Sonar maintenance has been rescheduled to 2018-05-17 due to
conflicts.

Thank you,

Vanessa


On 05/16/2018 09:12 AM, Vanessa Valderrama wrote:
>
> Reminder of Sonar maintenance today
>
>
> On 04/26/2018 10:02 AM, Vanessa Valderrama wrote:
>>
>> *Sonar 2018-05-16 - **2100 UTC to 0100 UTC*
>>
>> Sonar will be unavailable for approximately 2-3 hours depending on
>> data transfer.
>>
>
> 

Re: [vpp-dev] NOTIFICATION: FD.io Maintenance

[Vanessa Valderrama]

Reminder of Sonar maintenance today


On 04/26/2018 10:02 AM, Vanessa Valderrama wrote:
>
> *Sonar 2018-05-16 - **2100 UTC to 0100 UTC*
>
> Sonar will be unavailable for approximately 2-3 hours depending on
> data transfer.
>

Re: [EXT] Re: [vpp-dev] Marvell's AI from last call

[Natalie Samsonov]

Dear Damjan,

As I understood, it was a request to use DPDK plugin with all platforms and I 
was asked to upstream Marvell DPDK plugin.

Best Regards,
Natalie

From: Damjan Marion [mailto:dmarion.li...@gmail.com]
Sent: Wednesday, May 16, 2018 16:03
To: Natalie Samsonov 
Cc: Tina Tsou ; vpp-dev@lists.fd.io; Maen Suleiman 

Subject: [EXT] Re: [vpp-dev] Marvell's AI from last call

External Email


Dear Natalie,

What is the point of using DPDK marvel driver (which is actually just a wrapper 
around musdk) if we already have native musdk support in vpp?
--
Damjan


On 15 May 2018, at 08:48, Natalie Samsonov 
> wrote:

Hi,

1.   We are working now on upstreaming Marvell’s PMD support in VPP DPDK 
plugin.
I’m attaching the patch as well in case you want play with it.
2.   Regarding the L3FWD performance difference between MUSDK and DPDK, 
currently we don’t have numbers with VPP L3FW.
We only have  the numbers with two different applications. One is our own L3FW 
application running on top of MUSDK and other is a standard DPDL L3FWD 
application, so it’s not a fair comparison.

Best Regards,
Natalie Samsonov



<0001-plugins-dpdk-Add-support-for-net_mrvl-dpdk-driver.patch>

Re: [vpp-dev] Marvell's AI from last call

[Damjan Marion]

Dear Natalie,

What is the point of using DPDK marvel driver (which is actually just a wrapper 
around musdk) if we already have native musdk support in vpp?
-- 
Damjan

> On 15 May 2018, at 08:48, Natalie Samsonov  wrote:
> 
> Hi,
>
> We are working now on upstreaming Marvell’s PMD support in VPP DPDK plugin.
> I’m attaching the patch as well in case you want play with it.
> Regarding the L3FWD performance difference between MUSDK and DPDK, currently 
> we don’t have numbers with VPP L3FW.
> We only have  the numbers with two different applications. One is our own 
> L3FW application running on top of MUSDK and other is a standard DPDL L3FWD 
> application, so it’s not a fair comparison.
>
> Best Regards,
> Natalie Samsonov
>
>
> 
> <0001-plugins-dpdk-Add-support-for-net_mrvl-dpdk-driver.patch>

Re: [vpp-dev] problem in xcrw testing

[xyxue]

Hi John，

I changed my configuration to that shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface l3 host-eth1
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next gre-output  rw 
4558fd2fa5720b0101020b0101016558
create bridge-domain 1
set interface l2 bridge teb-gre0 1
set interface l2 bridge xcrw0 1

There is an assert :
Program received signal SIGSEGV, Segmentation fault.
0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
366   hw = vnet_get_hw_interface (vnm, sw->hw_if_index);
(gdb) bt
#0  0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
#1  0x76f3126b in gre_interface_tx (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:412
#2  0x7769b2aa in dispatch_node (vm=0x7791d1a0 , 
node=0x7fffb6c87600, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, 
frame=0x7fffb676fbc0, last_time_stamp=35926090675277) at 
/home/vpp/build-data/../src/vlib/main.c:1010
#3  0x7769b88d in dispatch_pending_node (vm=0x7791d1a0 
, pending_frame_index=4, last_time_stamp=35926090675277)
at /home/vpp/build-data/../src/vlib/main.c:1160
#4  0x7769daa4 in vlib_main_or_worker_loop (vm=0x7791d1a0 
, is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1630
#5  0x7769db53 in vlib_main_loop (vm=0x7791d1a0 ) 
at /home/vpp/build-data/../src/vlib/main.c:1649
#6  0x7769e2ad in vlib_main (vm=0x7791d1a0 , 
input=0x7fffb5704fb0) at /home/vpp/build-data/../src/vlib/main.c:1806
#7  0x776e0d64 in thread0 (arg=140737346916768) at 
/home/vpp/build-data/../src/vlib/unix/main.c:617
#8  0x76927560 in clib_calljmp () at 
/home/vpp/build-data/../src/vppinfra/longjmp.S:128
#9  0x7fffd350 in ?? ()
#10 0x776e1223 in vlib_unix_main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vlib/unix/main.c:682
#11 0x00406202 in main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vpp/vnet/main.c:241
(gdb) 

Is there any examples about xcrw ? Is there any configuration I missed？

Thanks，
Xyxue
From: John Lo (loj)
Date: 2018-05-16 16:02
To: 薛欣颖; Neale Ranns (nranns); vpp-dev
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,
 
The L2 cross connect CLI via either xconnect or xcrw would put the source/input 
interface into L2 mode and setup an one-directional cross connect to the 
specified peer/output interface.  The expectation is there should be a 
xcrw/cross connect CLI for the other direction specifying the other interface 
as source/input so it will also be in L2 mode.  
 
Hope this help, with regards,
John
 
From: 薛欣颖  
Sent: Wednesday, May 16, 2018 3:46 AM
To: John Lo (loj) ; Neale Ranns (nranns) ; 
vpp-dev 
Subject: Re: Re: [vpp-dev] problem in xcrw testing
 
Hi John,
 
The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?


Thanks,
Xyxue


 
From: John Lo (loj)
Date: 2018-05-15 20:32
To: 薛欣颖; Neale Ranns (nranns); vpp-dev
Subject: Re: [vpp-dev] problem in xcrw testing
The GRE tunnel needs to be put in L2 mode so it can be a valid l2-output 
interface. You can do that by putting the GRE tunnel into a bridge domain, or 
xconnect it to peer interface:
 
vpp# set int l2  bri ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]
vpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 
 
Regards,
John
 
From: vpp-dev@lists.fd.io  On Behalf Of xyxue
Sent: Tuesday, May 15, 2018 8:10 AM
To: Neale Ranns (nranns) ; vpp-dev 
Subject: Re: [vpp-dev] problem in xcrw testing
 
 
Hi Neale，
 
After I changed my configuration (the configuration and the trace info is shown 
below) 
 
create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next teb-gre0-output rw 
4558fd2fa5720b0101020b0101016558



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

00:01:18:847131: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5afaa73c nsec 

Re: [vpp-dev] problem in xcrw testing

[John Lo (loj)]

Hi Xyxue,

The L2 cross connect CLI via either xconnect or xcrw would put the source/input 
interface into L2 mode and setup an one-directional cross connect to the 
specified peer/output interface.  The expectation is there should be a 
xcrw/cross connect CLI for the other direction specifying the other interface 
as source/input so it will also be in L2 mode.

Hope this help, with regards,
John

From: 薛欣颖 
Sent: Wednesday, May 16, 2018 3:46 AM
To: John Lo (loj) ; Neale Ranns (nranns) ; 
vpp-dev 
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John,

The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?


Thanks,
Xyxue


From: John Lo (loj)
Date: 2018-05-15 20:32
To: 薛欣颖; Neale Ranns 
(nranns); vpp-dev
Subject: Re: [vpp-dev] problem in xcrw testing
The GRE tunnel needs to be put in L2 mode so it can be a valid l2-output 
interface. You can do that by putting the GRE tunnel into a bridge domain, or 
xconnect it to peer interface:

vpp# set int l2  bri ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]
vpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

Regards,
John

From: vpp-dev@lists.fd.io 
> On Behalf Of xyxue
Sent: Tuesday, May 15, 2018 8:10 AM
To: Neale Ranns (nranns) >; vpp-dev 
>
Subject: Re: [vpp-dev] problem in xcrw testing


Hi Neale，

After I changed my configuration (the configuration and the trace info is shown 
below)

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next teb-gre0-output rw 
4558fd2fa5720b0101020b0101016558



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

00:01:18:847131: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5afaa73c nsec 0x2c4032d7 vlan 0
00:01:18:847197: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:c0:00:04
00:01:18:847305: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05
00:01:18:847323: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:01:18:847336: error-drop
  l2-output: L2 Output interface not valid



It doesn't seem to be in effect. Is there something I missed?



Thanks,
Xyxue


From: Neale Ranns
Date: 2018-05-15 15:58
To: 薛欣颖; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,

The GRE tunnel needs to be in L2 mode, which in the case of GRE is known as 
‘transparent ethernet bridging’. So:
  create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb

/neale





From: > on behalf of xyxue 
>
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io" 
>
Subject: [vpp-dev] problem in xcrw testing


Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

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

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 

Re: [vpp-dev] problem in xcrw testing

[xyxue]

Hi John,

The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?

Thanks,
Xyxue


 
From: John Lo (loj)
Date: 2018-05-15 20:32
To: 薛欣颖; Neale Ranns (nranns); vpp-dev
Subject: Re: [vpp-dev] problem in xcrw testing
The GRE tunnel needs to be put in L2 mode so it can be a valid l2-output 
interface. You can do that by putting the GRE tunnel into a bridge domain, or 
xconnect it to peer interface:
 
vpp# set int l2  bri ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]
vpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 
 
Regards,
John
 
From: vpp-dev@lists.fd.io  On Behalf Of xyxue
Sent: Tuesday, May 15, 2018 8:10 AM
To: Neale Ranns (nranns) ; vpp-dev 
Subject: Re: [vpp-dev] problem in xcrw testing
 
 
Hi Neale，
 
After I changed my configuration (the configuration and the trace info is shown 
below) 
 
create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next teb-gre0-output rw 
4558fd2fa5720b0101020b0101016558


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

00:01:18:847131: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5afaa73c nsec 0x2c4032d7 vlan 0
00:01:18:847197: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:c0:00:04
00:01:18:847305: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05
00:01:18:847323: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:01:18:847336: error-drop
  l2-output: L2 Output interface not valid


It doesn't seem to be in effect. Is there something I missed?


Thanks,
Xyxue


 
From: Neale Ranns
Date: 2018-05-15 15:58
To: 薛欣颖; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,
 
The GRE tunnel needs to be in L2 mode, which in the case of GRE is known as 
‘transparent ethernet bridging’. So:
  create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
 
/neale


 
 
From:  on behalf of xyxue 
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] problem in xcrw testing
 
 
Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

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

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 tx_fib_index -1
00:00:22:692753: gre4-input
  GRE: tunnel 0 len 88 src 11.1.1.2 dst 11.1.1.1
00:00:22:692771: error-drop
  gre4-input: GRE input packets dropped due to missing tunnel
  
Is there any problem in my configuration?
  
Thanks，
Xyxue