[vpp-dev] Possible missing build dependency on debian testing distributions?
Hi, vpp experts, I was building the latest vpp code on a debian testing based system. I hit the following errors when running: make install-ext-deps Package libelf was not found in the pkg-config search path. Perhaps you should add the directory containing `libelf.pc' to the PKG_CONFIG_PATH environment variable No package 'libelf' found btf.c:17:10: fatal error: gelf.h: No such file or directory 17 | #include | ^~~~ compilation terminated. I have to install a missing package before I can build successfully. sudo apt-get install libelf-dev Does this mean vpp makefile shall be updated so that libelf-dev is installed by default for all debian distributions? https://github.com/FDio/vpp/blob/master/Makefile#L98 If so, can someone update the makefile? Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17516): https://lists.fd.io/g/vpp-dev/message/17516 Mute This Topic: https://lists.fd.io/mt/77082190/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Does intel x710 under vpp has the same lldp dropping behavior by default like in kernel?
Hi, vpp experts, It is known that intel x710 nic in the kernel will drop lldp pkts by default. https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e00LJEFCA4 Does anyone know it is also true on vpp? If vpp/dpdk drops, is there a workaround to disable this feature like in kernel? Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16998): https://lists.fd.io/g/vpp-dev/message/16998 Mute This Topic: https://lists.fd.io/mt/75617352/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vpp crashes when running "ip punt redirect rx via "
Thanks. The fix works. On Thu, Jul 2, 2020 at 2:01 AM Mohsin Kazmi (sykazmi) wrote: > Hi Chuan, > > > > Please find the following fix for it. > > > > https://gerrit.fd.io/r/c/vpp/+/27760 > > > > It seems that order is issue. > > > > -br > > Mohsin > > > > *From: * on behalf of "Chuan Han via lists.fd.io" > > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, July 2, 2020 at 12:57 AM > *To: *vpp-dev > *Subject: *[vpp-dev] vpp crashes when running "ip punt redirect rx > via " > > > > It seems this commit causes the issue. > > > > https://gerrit.fd.io/r/c/vpp/+/27675 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16877): https://lists.fd.io/g/vpp-dev/message/16877 Mute This Topic: https://lists.fd.io/mt/75247302/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vpp crashes when running "ip punt redirect rx via "
It seems this commit causes the issue. https://gerrit.fd.io/r/c/vpp/+/27675 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16864): https://lists.fd.io/g/vpp-dev/message/16864 Mute This Topic: https://lists.fd.io/mt/75247302/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vppctl is broken on master head
Yes. It fixes the issue. On Fri, May 15, 2020 at 4:28 PM Florin Coras wrote: > Hi Chuan, > > Does this [1] fix the issue? > > Regards, > Florin > > [1] https://gerrit.fd.io/r/c/vpp/+/27103 > > On May 15, 2020, at 4:24 PM, Chuan Han via lists.fd.io < > chuanhan=google@lists.fd.io> wrote: > > The following patch is very suspicious. > > * a58be82dd vlib: fix unix cli commands crash without session > > vppctl works fine at: * 0ef915398 (HEAD) ikev2: use u32 in unformat > > > On Fri, May 15, 2020 at 4:07 PM Chuan Han via lists.fd.io google@lists.fd.io> wrote: > >> Hi, vpp team, >> >> It seems vppctl is broken on the master head: 18a86c6e6 g2: fix the g2 >> build for Ubuntu 20.04 >> >> The broken functionality is vppctl single command mode: sudo vppctl > command> >> >> host# vppctl >> srv-2-vpp# sh ver >> vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 >> srv-2-vpp# quit >> host# >> host# vppctl sh ver >> vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 >> *quit: invalid for non-interactive sessions* >> ^C >> >> vppctl hangs here. The command does not return. I have to do ctrl+c to >> break it. >> >> ** 18a86c6e6 g2: fix the g2 build for Ubuntu 20.04* >> * 4362baa33 ikev2: add support for NAT traversal >> * 17b5c3d6a tcp: fix bogus time update due to missing cast >> * 1ce60463a nat: unhide tests >> * d0e646f68 vcl svm: fix rx event loss >> * 219fbb228 nat: "users" dump for ED-NAT >> >> Can this be fixed? >> >> Thanks. >> Chuan >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16420): https://lists.fd.io/g/vpp-dev/message/16420 Mute This Topic: https://lists.fd.io/mt/74239178/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] vppctl is broken on master head
The following patch is very suspicious. * a58be82dd vlib: fix unix cli commands crash without session vppctl works fine at: * 0ef915398 (HEAD) ikev2: use u32 in unformat On Fri, May 15, 2020 at 4:07 PM Chuan Han via lists.fd.io wrote: > Hi, vpp team, > > It seems vppctl is broken on the master head: 18a86c6e6 g2: fix the g2 > build for Ubuntu 20.04 > > The broken functionality is vppctl single command mode: sudo vppctl command> > > host# vppctl > srv-2-vpp# sh ver > vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 > srv-2-vpp# quit > host# > host# vppctl sh ver > vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 > *quit: invalid for non-interactive sessions* > ^C > > vppctl hangs here. The command does not return. I have to do ctrl+c to > break it. > > ** 18a86c6e6 g2: fix the g2 build for Ubuntu 20.04* > * 4362baa33 ikev2: add support for NAT traversal > * 17b5c3d6a tcp: fix bogus time update due to missing cast > * 1ce60463a nat: unhide tests > * d0e646f68 vcl svm: fix rx event loss > * 219fbb228 nat: "users" dump for ED-NAT > > Can this be fixed? > > Thanks. > Chuan > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16418): https://lists.fd.io/g/vpp-dev/message/16418 Mute This Topic: https://lists.fd.io/mt/74239178/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vppctl is broken on master head
Hi, vpp team, It seems vppctl is broken on the master head: 18a86c6e6 g2: fix the g2 build for Ubuntu 20.04 The broken functionality is vppctl single command mode: sudo vppctl host# vppctl srv-2-vpp# sh ver vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 srv-2-vpp# quit host# host# vppctl sh ver vpp v20.09-rc0~15-g18a86c6e6 built by root on host at 2020-05-15T15:31:41 *quit: invalid for non-interactive sessions* ^C vppctl hangs here. The command does not return. I have to do ctrl+c to break it. ** 18a86c6e6 g2: fix the g2 build for Ubuntu 20.04* * 4362baa33 ikev2: add support for NAT traversal * 17b5c3d6a tcp: fix bogus time update due to missing cast * 1ce60463a nat: unhide tests * d0e646f68 vcl svm: fix rx event loss * 219fbb228 nat: "users" dump for ED-NAT Can this be fixed? Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16416): https://lists.fd.io/g/vpp-dev/message/16416 Mute This Topic: https://lists.fd.io/mt/74239178/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Use OSS-Fuzz, and get upto 20K USD reward
Hi, vpp developers, I think someone may be interested in the following. If you have an ideal integration of google's OSS-Fuzz with vpp, you will get upto $20,000 for an ideal integration. See more details, and how to get started: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16286): https://lists.fd.io/g/vpp-dev/message/16286 Mute This Topic: https://lists.fd.io/mt/74079776/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP Plugins build errors from IPSec module
I am also interested in frr integration with vpp. Could you please share detailed steps once you figure it out? On Tue, Feb 25, 2020, 11:34 PM Ray Kinsella wrote: > > > I am not sure how accurate / current the information from the wiki is. > > However looks like you are missing the Intel Multi-buffer Crypto Library. > Try a `make install-ext-deps`, then wipe and rebuild. > > Ray K > > On 25/02/2020 22:34, Majumdar, Kausik wrote: > > Hi folks, > > > > > > > > I am trying to build VPP netlink and router plugins based on vpp branch > v20.01 to integrate and run with routing control plane FRR. I am following > the guidelines based on > https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP > > > > > > > > I am finding issues while trying to compile the IPSec plugin code, it is > exiting with the below error. I have tried with latest VPP master branch, > the result is pretty much same. Is there any resolution to this issue or am > I missing something? If I try to use VPP v18.10 branch then I hit other > netlink issue which I think discussed in this thread in the past. Hence > moved to latest VPP code base, tried to link VPPSB and build the > netlink-install and router-install plugins, hitting IPSec build failures. > Any recommendation would be helpful. > > > > > > > > I am running Centos 7.4 machine. > > > > > > > > [root@localhost build-root]# git branch > > > > * (detached from v20.01) > > > > master > > > > > > > > [root@localhost build-root]# *make V=0 PLATFORM=vpp TAG=vpp_debug > netlink-install router-install* > > > > Arch for platform 'vpp' is native > > > > Finding source for external > > > > Makefile fragment found in /root/vpp/build-data/packages/ > external.mk > > > > Source found in /root/vpp/build > > > > Arch for platform 'vpp' is native > > > > Finding source for vpp > > > > Makefile fragment found in /root/vpp/build-data/packages/vpp.mk > > > > > Source found in /root/vpp/src > > > > Arch for platform 'vpp' is native > > > > Finding source for netlink > > > > Makefile fragment found in /root/vpp/build-data/packages/netlink.mk > > > > > Source found in /root/vpp/netlink > > > > Configuring external: nothing to do > > > > Building external: nothing to do > > > > Installing external: nothing to do > > > > Configuring vpp: nothing to do > > > > Building vpp in /root/vpp/build-root/build-vpp_debug-native/vpp > > > > [1/660] Building C object > plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o > > > > FAILED: > plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o > > > > /opt/rh/devtoolset-7/root/bin/cc -Dcrypto_ipsecmb_plugin_EXPORTS > -I/root/vpp/src -I. -Iinclude -I/root/vpp/src/plugins -Iplugins > -I/opt/vpp/external/x86_64/include -Wno-address-of-packed-member -g -fPIC > -Werror -Wall -march=corei7 -mtune=corei7-avx -O0 -DCLIB_DEBUG > -fstack-protector -DFORTIFY_SOURCE=2 -fno-common -fPIC -march=silvermont > -maes -MD -MT > plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o -MF > plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o.d > -o plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o > -c /root/vpp/src/plugins/crypto_ipsecmb/ipsecmb.c > > > > /root/vpp/src/plugins/crypto_ipsecmb/ipsecmb.c:20:10: fatal error: > intel-ipsec-mb.h: No such file or directory > > > > #include > > > > ^~ > > > > compilation terminated. > > > > [4/660] Building C object > plugins/ct6/CMakeFiles/ct6_test_plugin.dir/ct6_test.c.o > > > > ninja: build stopped: subcommand failed. > > > > make: *** [vpp-build] Error 1 > > > > [root@localhost build-root]# > > > > > > > > Thanks, > > > > Kausik > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15551): https://lists.fd.io/g/vpp-dev/message/15551 Mute This Topic: https://lists.fd.io/mt/71543494/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Did anything ever make vpp's native ipsec stack (ia32) work with dpdk/phy nic?
Hi, Damjan, It worked! Thanks for helping! I can see native ipsec stack works with aes-gcm-256 now. 00:44:05:465769: ip4-input-no-checksum IPSEC_ESP: 10.10.10.11 -> 10.10.10.10 tos 0x00, ttl 253, length 540, checksum 0x9387 fragment id 0x 00:44:05:465770: ipsec4-input-feature IPSEC_ESP: sa_id 2 spd 1 policy 0 spi 255128 (0x0003e498) seq 3478582380 00:44:05:465770: *esp4-decrypt* esp: crypto *aes-gcm-256* integrity none pkt-seq -816384916 sa-seq 0 sa-seq-hi 0 vpp# sh ver vpp v20.01-rc0~735-gbfd7d294d built by root on esdn-lab at Wed Nov 27 19:34:36 UTC 2019 vpp# sh dpdk ver DPDK Version: DPDK 19.08.0 DPDK EAL init args: -c 5554 -n 4 --in-memory --log-level debug --file-prefix vpp -w :1b:10.1 -w :19:00.1 --master-lcore 2 vpp# 8.5Gbps udp/tcp ixia traffic is happy now. However, I did not see any performance improvement, i.e., still the same 8.5Gbps. Probably, native stack is more stable and well tested as you mentioned before. Thanks. Chuan On Thu, Dec 5, 2019 at 4:11 PM Damjan Marion wrote: > > Hi Chuan, > > You need to specify salt for GCM to work in static config. > > i.e. > ipsec sa add 1 spi 255129 esp crypto-key > 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg > aes-gcm-256 salt 0x12345678 > > LMK if this helps... > > -- > Damjan > > > On 27 Nov 2019, at 15:16, Chuan Han wrote: > > I switched cipher from aes-gcm to aes-cbc. native stack works. it seems > the issue is related to aes-gcm cipher support in native stack? > Probably some integration bug between aes-gcm and native stack? > > On Tue, Nov 19, 2019 at 10:42 AM Chuan Han via Lists.Fd.Io > <http://lists.fd.io/> wrote: > >> Hi, Damjan, >> >> See attachment for detailed logs. no.vdev.xxx files contain the log for >> the case where vdev is commented out. v.dev.xxx files contain logs for the >> case where vdev is enabled. >> >> I pinged srv-1 from srv-2, i.e., 172.16.2.2 -> 172.16.1.2. >> >> When vdev is removed, the srv-1 cannot decrypt the esp pkts. When vdev is >> enabled, I can see srv-1 decrypted esp pkts and ping worked fine. >> >> Thanks. >> Chuan >> >> >> On Tue, Nov 19, 2019 at 2:08 AM Damjan Marion wrote: >> >>> Hi Chuan, >>> >>> Please note that we have daily run of IPSec performance tests in CSIT >>> with VPP running on the physical NIC with DPDK drivers. >>> Also please note that every VPP patch is passing unit tests with IETF >>> and NIST test encryption vectors. >>> >>> Other comments inline…. >>> >>> >>> > On 18 Nov 2019, at 23:48, Chuan Han via Lists.Fd.Io >>> <http://lists.fd.io/> wrote: >>> > >>> > Hi, vpp experts, >>> > >>> > I was told that vpp's native ipsec stack is stabler and more >>> performant. We can enable it by commenting out the vdev line in dpdk >>> stanza. >>> > >>> > However, when I did so, ipsec decryption failed. >>> > >>> > Ex: >>> > # commenting out this line makes decryption fail. >>> > vdev crypto_aesni_mb0,socket_id=0 >>> >>> Have you validated that in your working case, packets are decrypted >>> correctly? >>> Can you share packet trace for both cases? >>> >>> > >>> > Did anyone ever make native ipsec stack, i.e., ia32 work with dpdk/phy >>> nic? >>> >>> yes, it is tested and working on the daily basis. >>> > >>> > The interesting thing is no matter whether I comment out the vdev line >>> or not, ia32 is shown as the active crypto handler for aes-gcm-256. Does >>> this mean ia32 is used by both cases? >>> > >>> > vpp# sh crypto engines >>> > NamePrioDescription >>> > ia32100 Intel IA32 ISA Optimized Crypto >>> > ipsecmb 80 Intel(R) Multi-Buffer Crypto for IPsec >>> Library 0.52.0 >>> > openssl 50 OpenSSL >>> > vpp# sh crypto handlers >>> > AlgoTypeActive Candidates >>> > (nil) >>> > des-cbc encrypt openssl openssl >>> > decrypt openssl openssl >>> > 3des-cbcencrypt openssl openssl >>> > decrypt openssl openssl >>> > aes-128-cbc encrypt ia32ia32 >>> ipsecmb
Re: [vpp-dev] Did anything ever make vpp's native ipsec stack (ia32) work with dpdk/phy nic?
I switched cipher from aes-gcm to aes-cbc. native stack works. it seems the issue is related to aes-gcm cipher support in native stack? Probably some integration bug between aes-gcm and native stack? On Tue, Nov 19, 2019 at 10:42 AM Chuan Han via Lists.Fd.Io wrote: > Hi, Damjan, > > See attachment for detailed logs. no.vdev.xxx files contain the log for > the case where vdev is commented out. v.dev.xxx files contain logs for the > case where vdev is enabled. > > I pinged srv-1 from srv-2, i.e., 172.16.2.2 -> 172.16.1.2. > > When vdev is removed, the srv-1 cannot decrypt the esp pkts. When vdev is > enabled, I can see srv-1 decrypted esp pkts and ping worked fine. > > Thanks. > Chuan > > > On Tue, Nov 19, 2019 at 2:08 AM Damjan Marion wrote: > >> Hi Chuan, >> >> Please note that we have daily run of IPSec performance tests in CSIT >> with VPP running on the physical NIC with DPDK drivers. >> Also please note that every VPP patch is passing unit tests with IETF and >> NIST test encryption vectors. >> >> Other comments inline…. >> >> >> > On 18 Nov 2019, at 23:48, Chuan Han via Lists.Fd.Io > google@lists.fd.io> wrote: >> > >> > Hi, vpp experts, >> > >> > I was told that vpp's native ipsec stack is stabler and more >> performant. We can enable it by commenting out the vdev line in dpdk >> stanza. >> > >> > However, when I did so, ipsec decryption failed. >> > >> > Ex: >> > # commenting out this line makes decryption fail. >> > vdev crypto_aesni_mb0,socket_id=0 >> >> Have you validated that in your working case, packets are decrypted >> correctly? >> Can you share packet trace for both cases? >> >> > >> > Did anyone ever make native ipsec stack, i.e., ia32 work with dpdk/phy >> nic? >> >> yes, it is tested and working on the daily basis. >> > >> > The interesting thing is no matter whether I comment out the vdev line >> or not, ia32 is shown as the active crypto handler for aes-gcm-256. Does >> this mean ia32 is used by both cases? >> > >> > vpp# sh crypto engines >> > NamePrioDescription >> > ia32100 Intel IA32 ISA Optimized Crypto >> > ipsecmb 80 Intel(R) Multi-Buffer Crypto for IPsec >> Library 0.52.0 >> > openssl 50 OpenSSL >> > vpp# sh crypto handlers >> > AlgoTypeActive Candidates >> > (nil) >> > des-cbc encrypt openssl openssl >> > decrypt openssl openssl >> > 3des-cbcencrypt openssl openssl >> > decrypt openssl openssl >> > aes-128-cbc encrypt ia32ia32 >> ipsecmb openssl >> > decrypt ia32ia32 >> ipsecmb openssl >> > aes-192-cbc encrypt ia32ia32 >> ipsecmb openssl >> > decrypt ia32ia32 >> ipsecmb openssl >> > aes-256-cbc encrypt ia32ia32 >> ipsecmb openssl >> > decrypt ia32ia32 >> ipsecmb openssl >> > aes-128-ctr encrypt openssl openssl >> > decrypt openssl openssl >> > aes-192-ctr encrypt openssl openssl >> > decrypt openssl openssl >> > aes-256-ctr encrypt openssl openssl >> > decrypt openssl openssl >> > aes-128-gcm aead-encryptia32ia32 >> ipsecmb openssl >> > aead-decryptia32ia32 >> ipsecmb openssl >> > aes-192-gcm aead-encryptia32ia32 >> ipsecmb openssl >> > aead-decryptia32ia32 >> ipsecmb openssl >> > aes-256-gcm aead-encryptia32ia32 >> ipsecmb openssl >> > aead-decryptia32ia32 >> ipsecmb openssl >> > hmac-md5hmacopenssl openssl >> > hmac-sha-1 hmacipsecmb
[vpp-dev] Did anything ever make vpp's native ipsec stack (ia32) work with dpdk/phy nic?
Hi, vpp experts, I was told that vpp's native ipsec stack is stabler and more performant. We can enable it by commenting out the vdev line in dpdk stanza. However, when I did so, ipsec decryption failed. Ex: # commenting out this line makes decryption fail. vdev crypto_aesni_mb0,socket_id=0 Did anyone ever make native ipsec stack, i.e., ia32 work with dpdk/phy nic? The interesting thing is no matter whether I comment out the vdev line or not, ia32 is shown as the active crypto handler for aes-gcm-256. Does this mean ia32 is used by both cases? vpp# sh crypto engines NamePrioDescription ia32100 Intel IA32 ISA Optimized Crypto ipsecmb 80 Intel(R) Multi-Buffer Crypto for IPsec Library 0.52.0 openssl 50 OpenSSL vpp# sh crypto handlers AlgoTypeActive Candidates (nil) des-cbc encrypt openssl openssl decrypt openssl openssl 3des-cbcencrypt openssl openssl decrypt openssl openssl aes-128-cbc encrypt ia32ia32 ipsecmb openssl decrypt ia32ia32 ipsecmb openssl aes-192-cbc encrypt ia32ia32 ipsecmb openssl decrypt ia32ia32 ipsecmb openssl aes-256-cbc encrypt ia32ia32 ipsecmb openssl decrypt ia32ia32 ipsecmb openssl aes-128-ctr encrypt openssl openssl decrypt openssl openssl aes-192-ctr encrypt openssl openssl decrypt openssl openssl aes-256-ctr encrypt openssl openssl decrypt openssl openssl aes-128-gcm aead-encryptia32ia32 ipsecmb openssl aead-decryptia32ia32 ipsecmb openssl aes-192-gcm aead-encryptia32ia32 ipsecmb openssl aead-decryptia32ia32 ipsecmb openssl aes-256-gcm aead-encryptia32ia32 ipsecmb openssl aead-decryptia32ia32 ipsecmb openssl hmac-md5hmacopenssl openssl hmac-sha-1 hmacipsecmb ipsecmb openssl hmac-sha-224hmacipsecmb ipsecmb openssl hmac-sha-256hmacipsecmb ipsecmb openssl hmac-sha-384hmacipsecmb ipsecmb openssl hmac-sha-512hmacipsecmb ipsecmb openssl vpp# I attached the two servers' startup conf files and topology diagram. Any input/comments are welcome. Thanks. Chuan vpp testbed - iperf3.pdf Description: Adobe PDF document srv-2 vpp startup.conf Description: Binary data srv-1 vpp switch startup.cfg Description: Binary data srv-1 vpp startup.conf Description: Binary data srv-2 vpp switch startup.cfg Description: Binary data -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14619): https://lists.fd.io/g/vpp-dev/message/14619 Mute This Topic: https://lists.fd.io/mt/60327762/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
Ah... I see. That explains everything!
Thanks for catching this.
It will be more helpful to let vpp print more meaningful logs or have
better documentation.
On Thu, Nov 14, 2019 at 7:17 AM Benoit Ganne (bganne)
wrote:
> Hi Chuan,
>
> I took a deeper look at your conf and actually realized that the dpdk
> 'workers' stanza does not refer to core number but to worker id.
> So, when you say "cpu { corelist-workers 4,6,8,10,12,14,16,18,20,22 }" you
> define 10 workers with id from 0 to 9 and pin them to specific cores (4,6
> etc.).
> Then, with "dpdk { ... dev ... { workers 4,6,8,10,12 } ..." you refer to
> the *workers id*, numbered from 0 to 9, not to cores.
> So the correct dpdk stanzas should be "workers 0,1,2,3,4" and "workers
> 5,6,7,8,9" instead (note: you can also use "workers 0-4" and "workers 5-9").
> What is confusing is the dpdk will happily parse inexistent workers id,
> and then when assigning queues to workers, it will respect the conf for
> known ones (4,6,8) and do round-robin assignment for the unknown ones
> ignoring already set manual assignment.
>
> Best
> Ben
>
> > -Original Message-
> > From: Chuan Han
> > Sent: lundi 11 novembre 2019 23:23
> > To: Benoit Ganne (bganne)
> > Cc: Dave Barach (dbarach) ; vpp-dev > d...@lists.fd.io>
> > Subject: Re: [vpp-dev] Is there a limit when assigning corelist-workers
> in
> > vpp?
> >
> > If I do not manually assign cores to nic, and let vpp assign cores, vpp
> > only assign one core per nic queue. If I also assign number of queues to
> > 10, all cores are used. Otherwise, only core 4 and 6 are assigned to each
> > nic, which has only one queue.
> >
> > Probably, there is some smart logic adaptively assigning cores to nics?
> > Anyway, a single core per nic is good enough to us for now.
> >
> > Without specifying number of rx queues per nic, only core 4 and 6 are
> > assigned.
> >
> > vpp# sh threads
> > ID NameTypeLWP Sched Policy (Priority)
> > lcore Core Socket State
> > 0 vpp_main16886 other (0)2
> > 0 0
> > 1 vpp_wk_0workers 16888 other (0)4
> > 1 0
> > 2 vpp_wk_1workers 16889 other (0)6
> > 4 0
> > 3 vpp_wk_2workers 16890 other (0)8
> > 2 0
> > 4 vpp_wk_3workers 16891 other (0)
> 10
> > 3 0
> > 5 vpp_wk_4workers 16892 other (0)
> 12
> > 8 0
> > 6 vpp_wk_5workers 16893 other (0)
> 14
> > 13 0
> > 7 vpp_wk_6workers 16894 other (0)
> 16
> > 9 0
> > 8 vpp_wk_7workers 16895 other (0)
> 18
> > 12 0
> > 9 vpp_wk_8workers 16896 other (0)
> 20
> > 10 0
> > 10 vpp_wk_9workers 16897 other (0)
> 22
> > 11 0
> > vpp# sh interface rx-placement
> > Thread 1 (vpp_wk_0):
> > node dpdk-input:
> > eth1 queue 0 (polling)
> > Thread 2 (vpp_wk_1):
> > node dpdk-input:
> > eth0 queue 0 (polling)
> > vpp#
> >
> >
> > cpu {
> > main-core 2
> > corelist-workers 4,6,8,10,12,14,16,18,20,22
> > }
> >
> > dpdk {
> > socket-mem 2048,0
> > log-level debug
> > no-tx-checksum-offload
> > dev default{
> > num-tx-desc 512
> > num-rx-desc 512
> > }
> > dev :1a:00.0 {
> > name eth0
> > }
> > dev :19:00.1 {
> > name eth1
> > }
> > # Use aesni mb lib.
> > vdev crypto_aesni_mb0,socket_id=0
> > no-multi-seg
> > }
> >
> >
> > When specifying number of queues per nic, all cores are used.
> >
> > vpp# sh int rx-placement
> > Thread 1 (vpp_wk_0):
> > node dpdk-input:
> > eth1 queue 0 (polling)
> > eth0 queue 0 (polling)
> > Thread 2 (vpp_wk_1):
> > node dpdk-input:
> > eth1 queue 1 (polling)
> > eth0 queue 1 (polling)
> > Thread 3 (vpp_wk_2):
> > node dpdk-input:
> > eth1 queue 2 (polling)
> > eth0 queue 2 (polling)
> > Thread 4 (vpp_wk_3):
> > node dpdk-input:
> > eth1 queue 3 (polling)
> > eth0 queue 3 (polling)
> > Thread 5 (vpp_wk_4):
> > node dpdk-input:
> > eth1 queue 4 (polling)
> > eth0 queue 4 (polling)
> > Thread 6 (vpp_wk_5):
> > node dpdk-input:
> > eth1 queue 5 (polling)
> > eth0 queue 5 (polling)
> > Thread 7 (vpp_wk_6):
> > node dpdk-input:
> > eth1 queue 6 (polling)
> > eth0 queue 6 (polling)
> > Thread 8 (vpp_wk_7):
> > node dpdk-input:
> > eth1 queue 7 (polling)
> > eth0 queue 7 (polling)
> > Thread 9 (vpp_wk_8):
> > node dpdk-input:
> > eth1 queue 8 (polling)
> > eth0 queue 8 (polling)
> > Thread 10 (vpp_wk_9):
> > node dpdk-input:
> > eth1 queue 9 (polling)
> > eth0 queue 9 (polling)
> > vpp# sh threads
> > ID NameTypeLWP Sched Policy (Priority)
> > lcore Core Socket State
> > 0 vpp_main16905 other (0)2
> > 0
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
If I do not manually assign cores to nic, and let vpp assign cores, vpp
only assign one core per nic queue. If I also assign number of queues to
10, all cores are used. Otherwise, only core 4 and 6 are assigned to each
nic, which has only one queue.
Probably, there is some smart logic adaptively assigning cores to nics?
Anyway, a single core per nic is good enough to us for now.
Without specifying number of rx queues per nic, only core 4 and 6 are
assigned.
vpp# sh threads
ID NameTypeLWP Sched Policy (Priority)
lcore Core Socket State
0 vpp_main16886 other (0)2
0 0
1 vpp_wk_0workers 16888 other (0)4
1 0
2 vpp_wk_1workers 16889 other (0)6
4 0
3 vpp_wk_2workers 16890 other (0)8
2 0
4 vpp_wk_3workers 16891 other (0)10
3 0
5 vpp_wk_4workers 16892 other (0)12
8 0
6 vpp_wk_5workers 16893 other (0)14
13 0
7 vpp_wk_6workers 16894 other (0)16
9 0
8 vpp_wk_7workers 16895 other (0)18
12 0
9 vpp_wk_8workers 16896 other (0)20
10 0
10 vpp_wk_9workers 16897 other (0)22
11 0
vpp# sh interface rx-placement
Thread 1 (vpp_wk_0):
node dpdk-input:
eth1 queue 0 (polling)
Thread 2 (vpp_wk_1):
node dpdk-input:
eth0 queue 0 (polling)
vpp#
cpu {
main-core 2
corelist-workers 4,6,8,10,12,14,16,18,20,22
}
dpdk {
socket-mem 2048,0
log-level debug
no-tx-checksum-offload
dev default{
num-tx-desc 512
num-rx-desc 512
}
dev :1a:00.0 {
name eth0
}
dev :19:00.1 {
name eth1
}
# Use aesni mb lib.
vdev crypto_aesni_mb0,socket_id=0
no-multi-seg
}
When specifying number of queues per nic, all cores are used.
vpp# sh int rx-placement
Thread 1 (vpp_wk_0):
node dpdk-input:
eth1 queue 0 (polling)
eth0 queue 0 (polling)
Thread 2 (vpp_wk_1):
node dpdk-input:
eth1 queue 1 (polling)
eth0 queue 1 (polling)
Thread 3 (vpp_wk_2):
node dpdk-input:
eth1 queue 2 (polling)
eth0 queue 2 (polling)
Thread 4 (vpp_wk_3):
node dpdk-input:
eth1 queue 3 (polling)
eth0 queue 3 (polling)
Thread 5 (vpp_wk_4):
node dpdk-input:
eth1 queue 4 (polling)
eth0 queue 4 (polling)
Thread 6 (vpp_wk_5):
node dpdk-input:
eth1 queue 5 (polling)
eth0 queue 5 (polling)
Thread 7 (vpp_wk_6):
node dpdk-input:
eth1 queue 6 (polling)
eth0 queue 6 (polling)
Thread 8 (vpp_wk_7):
node dpdk-input:
eth1 queue 7 (polling)
eth0 queue 7 (polling)
Thread 9 (vpp_wk_8):
node dpdk-input:
eth1 queue 8 (polling)
eth0 queue 8 (polling)
Thread 10 (vpp_wk_9):
node dpdk-input:
eth1 queue 9 (polling)
eth0 queue 9 (polling)
vpp# sh threads
ID NameTypeLWP Sched Policy (Priority)
lcore Core Socket State
0 vpp_main16905 other (0)2
0 0
1 vpp_wk_0workers 16907 other (0)4
1 0
2 vpp_wk_1workers 16908 other (0)6
4 0
3 vpp_wk_2workers 16909 other (0)8
2 0
4 vpp_wk_3workers 16910 other (0)10
3 0
5 vpp_wk_4workers 16911 other (0)12
8 0
6 vpp_wk_5workers 16912 other (0)14
13 0
7 vpp_wk_6workers 16913 other (0)16
9 0
8 vpp_wk_7workers 16914 other (0)18
12 0
9 vpp_wk_8workers 16915 other (0)20
10 0
10 vpp_wk_9workers 16916 other (0)22
11 0
vpp#
cpu {
main-core 2
corelist-workers 4,6,8,10,12,14,16,18,20,22
}
dpdk {
socket-mem 2048,0
log-level debug
no-tx-checksum-offload
dev default{
num-tx-desc 512
num-rx-desc 512
num-rx-queues 10
}
dev :1a:00.0 {
name eth0
}
dev :19:00.1 {
name eth1
}
# Use aesni mb lib.
vdev crypto_aesni_mb0,socket_id=0
no-multi-seg
}
On Fri, Nov 8, 2019 at 12:54 AM Benoit Ganne (bganne) via Lists.Fd.Io
wrote:
> Hi Chuan,
>
> > The weird thing is that when I reduced the number of workers
> > everything worked fine. I did send 8.5Gbps udp/tcp traffic over the two
> > machines. I also saw encryption/decryption happening. How could this be
> > possible without crypto engine?
>
> Hmm that should not have happened :)
> Frankly I have no idea, but maybe there was other difference in
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
gt; > >
>> > >
>> > > Not sure how to get all symbols. Can someone share
>> > some steps?
>> > >
>> > > (gdb) list
>> > > 46 in ../sysdeps/unix/sysv/linux/raise.c
>> > > (gdb) bt full
>> > > #0 __GI_raise (sig=sig@entry=6) at
>> > > ../sysdeps/unix/sysv/linux/raise.c:51
>> > > set = {__val = {1024, 140192549297216,
>> > > 140191458925760, 94479452800528, 140191458925744,
>> > 14738652586040953856,
>> > > 12, 94479452800528, 0, 14738652586040953856, 12, 1,
>> 94479452800528,
>> > 1, 12,
>> > > 140192554943764}}
>> > > pid =
>> > > tid =
>> > > ret =
>> > > #1 0x7f811edf2801 in __GI_abort () at
>> > abort.c:79
>> > > save_stage = 1
>> > > act = {__sigaction_handler = {sa_handler =
>> > 0x0,
>> > > sa_sigaction = 0x0}, sa_mask = {__val = {140192549484596,
>> > 140192549745376,
>> > > 140192549484596, 140192554638615, 140192554894358,
>> 140192549484596,
>> > > 140191451682880, 4294967295, 4, 1024, 140191451683548,
>> > 140191451691708,
>> > > 14738652586040953856,
>> > > 140191436101232, 8, 8}}, sa_flags =
>> > 853347328,
>> > > sa_restorer = 0x7f80de1c1ef0}
>> > > sigs = {__val = {32, 0 > times>}}
>> > > __cnt =
>> > > __set =
>> > > __cnt =
>> > > __set =
>> > > #2 0x55edb4f0ad44 in os_exit ()
>> > > No symbol table info available.
>> > > #3 0x7f811f6f53d9 in ?? () from
>> > /usr/lib/x86_64-linux-
>> > > gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #4
>> > > No locals.
>> > > #5 0x7f811f6db793 in ?? () from
>> > /usr/lib/x86_64-linux-
>> > > gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #6 0x7f811f6df4d9 in ?? () from
>> > /usr/lib/x86_64-linux-
>> > > gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #7 0x7f811f6a4eee in
>> > vlib_call_init_exit_functions ()
>> > > from /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #8 0x7f811f6b5d17 in vlib_main () from
>> > /usr/lib/x86_64-
>> > > linux-gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #9 0x7f811f6f4416 in ?? () from
>> > /usr/lib/x86_64-linux-
>> > > gnu/libvlib.so.19.08.1
>> > > No symbol table info available.
>> > > #10 0x7f811f1cb834 in clib_calljmp () from
>> > > /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
>> > > No symbol table info available.
>> > > #11 0x7ffe3cb01770 in ?? ()
>> > > No symbol table info available.
>> > > #12 0x7f811f6f586f in vlib_unix_main () from
>> > > /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> > >
>> > >
>> > > On Mon, Nov 4, 2019 at 10:45 AM Chuan Han via
>> > Lists.Fd.Io <http://Lists.Fd.Io>
>> > > <http://Lists.Fd.Io> > > <mailto:google@lists.fd.io>
>> > > <mailto:google@lists.fd.io <mailto:google@lists.fd.io>
>> > >
>> > wrote:
>> > >
>> > >
>> > > Here is the gdb vpp core output
>> > &g
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
t; >
> > >
> > > More details.
> > >
> > > warning: core file may not match specified executable file.
> > > [New LWP 10851]
> > > [New LWP 10855]
> > > [New LWP 10853]
> > > [New LWP 10854]
> > > [New LWP 10856]
> > > [New LWP 10857]
> > > [New LWP 10858]
> > > [New LWP 10852]
> > > [New LWP 10859]
> > > [New LWP 10860]
> > > [New LWP 10861]
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib/x86_64-linux-
> > > gnu/libthread_db.so.1".
> > > Core was generated by `vpp -c vpp_startup/startup.conf'.
> > > Program terminated with signal SIGABRT, Aborted.
> > > #0 __GI_raise (sig=sig@entry=6) at
> > > ../sysdeps/unix/sysv/linux/raise.c:51
> > > 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or
> > > directory.
> > > [Current thread is 1 (Thread 0x7f8120c00780 (LWP 10851))]
> > > (gdb)
> > >
> > >
> > > On Mon, Nov 4, 2019 at 10:46 AM Chuan Han
> > mailto:chuan...@google.com>
> > > <mailto:chuan...@google.com <mailto:chuan...@google.com> > >
> > wrote:
> > >
> > >
> > > Not sure how to get all symbols. Can someone share
> > some steps?
> > >
> > > (gdb) list
> > > 46 in ../sysdeps/unix/sysv/linux/raise.c
> > > (gdb) bt full
> > > #0 __GI_raise (sig=sig@entry=6) at
> > > ../sysdeps/unix/sysv/linux/raise.c:51
> > > set = {__val = {1024, 140192549297216,
> > > 140191458925760, 94479452800528, 140191458925744,
> > 14738652586040953856,
> > > 12, 94479452800528, 0, 14738652586040953856, 12, 1,
> 94479452800528,
> > 1, 12,
> > > 140192554943764}}
> > > pid =
> > > tid =
> > > ret =
> > > #1 0x7f811edf2801 in __GI_abort () at
> > abort.c:79
> > > save_stage = 1
> > > act = {__sigaction_handler = {sa_handler =
> > 0x0,
> > > sa_sigaction = 0x0}, sa_mask = {__val = {140192549484596,
> > 140192549745376,
> > > 140192549484596, 140192554638615, 140192554894358,
> 140192549484596,
> > > 140191451682880, 4294967295, 4, 1024, 140191451683548,
> > 140191451691708,
> > > 14738652586040953856,
> > > 140191436101232, 8, 8}}, sa_flags =
> > 853347328,
> > > sa_restorer = 0x7f80de1c1ef0}
> > > sigs = {__val = {32, 0 }}
> > > __cnt =
> > > __set =
> > > __cnt =
> > > __set =
> > > #2 0x55edb4f0ad44 in os_exit ()
> > > No symbol table info available.
> > > #3 0x7f811f6f53d9 in ?? () from
> > /usr/lib/x86_64-linux-
> > > gnu/libvlib.so.19.08.1
> > > No symbol table info available.
> > > #4
> > > No locals.
> > > #5 0x7f811f6db793 in ?? () from
> > /usr/lib/x86_64-linux-
> > > gnu/libvlib.so.19.08.1
> > > No symbol table info available.
> > > #6 0x7f811f6df4d9 in ?? () from
> > /usr/lib/x86_64-linux-
> > > gnu/libvlib.so.19.08.1
> > > No symbol table info available.
> > > #7 0x7f811f6a4eee in
> > vlib_call_init_exit_functions ()
> > > from /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> > > No symbol table info available.
> > > #8 0x7f811f6b5d17 in vlib_main () from
> > /usr/lib/x86_64-
> > > linux-gnu/libvlib.so.19.08.1
> > > No symbol table info available.
> > >
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
locals. > > #5 0x7f811f6db793 in ?? () from /usr/lib/x86_64-linux- > > gnu/libvlib.so.19.08.1 > > No symbol table info available. > > #6 0x7f811f6df4d9 in ?? () from /usr/lib/x86_64-linux- > > gnu/libvlib.so.19.08.1 > > No symbol table info available. > > #7 0x7f811f6a4eee in vlib_call_init_exit_functions () > > from /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1 > > No symbol table info available. > > #8 0x7f811f6b5d17 in vlib_main () from > /usr/lib/x86_64- > > linux-gnu/libvlib.so.19.08.1 > > No symbol table info available. > > #9 0x7f811f6f4416 in ?? () from /usr/lib/x86_64-linux- > > gnu/libvlib.so.19.08.1 > > No symbol table info available. > > #10 0x7f811f1cb834 in clib_calljmp () from > > /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1 > > No symbol table info available. > > #11 0x7ffe3cb01770 in ?? () > > No symbol table info available. > > #12 0x7f811f6f586f in vlib_unix_main () from > > /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1 > > > > > > On Mon, Nov 4, 2019 at 10:45 AM Chuan Han via Lists.Fd.Io > > <http://Lists.Fd.Io> > <mailto:google@lists.fd.io> > wrote: > > > > > > Here is the gdb vpp core output > > > > (gdb) f > > #0 __GI_raise (sig=sig@entry=6) at > > ../sysdeps/unix/sysv/linux/raise.c:51 > > 51 in ../sysdeps/unix/sysv/linux/raise.c > > (gdb) bt > > #0 __GI_raise (sig=sig@entry=6) at > > ../sysdeps/unix/sysv/linux/raise.c:51 > > #1 0x7f811edf2801 in __GI_abort () at > abort.c:79 > > #2 0x55edb4f0ad44 in os_exit () > > #3 0x7f811f6f53d9 in ?? () from > /usr/lib/x86_64- > > linux-gnu/libvlib.so.19.08.1 > > #4 > > #5 0x7f811f6db793 in ?? () from > /usr/lib/x86_64- > > linux-gnu/libvlib.so.19.08.1 > > #6 0x7f811f6df4d9 in ?? () from > /usr/lib/x86_64- > > linux-gnu/libvlib.so.19.08.1 > > #7 0x7f811f6a4eee in > vlib_call_init_exit_functions > > () from /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1 > > #8 0x7f811f6b5d17 in vlib_main () from > > /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1 > > #9 0x7f811f6f4416 in ?? () from > /usr/lib/x86_64- > > linux-gnu/libvlib.so.19.08.1 > > #10 0x7f811f1cb834 in clib_calljmp () from > > /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1 > > #11 0x7ffe3cb01770 in ?? () > > #12 0x7f811f6f586f in vlib_unix_main () from > > /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1 > > #13 0x3de8f6310400 in ?? () > > #14 0x8100458b49ffd49d in ?? () > > #15 0x8b480100f868 in ?? () > > #16 0x6d8141fb6085 in ?? () > > #17 0x408b48010008 in ?? () > > #18 0x4800c740 in ?? () > > > > > > let me know more specific steps to pinpoint the > issues. > > > > On Mon, Nov 4, 2019 at 10:13 AM Damjan Marion > > mailto:dmar...@me.com> > wrote: > > > > > > i remember doing corelist-workers with > > 50 > > cores….. > > > > If you paste traceback we may have better > clue > > what is wrong… > > > > — > > Damjan > > > > > > > > > > On 4 Nov 2019, at 18:51, Chuan Han > via > > Lists.Fd.Io <http://Lists.Fd.Io> > <mailto:chuanhan=google@lists.fd.io> > wrote: > > > > All even number cores are on numa > 0, which > > also hosts all nics. > > > > It seems corelist-workers can only > take > > maximum 8 cores. > > > > On Mon, Nov 4, 2019 at 9:45 AM > Tkachuk, > > Georgii mailto:georgii.tkac...@intel.co
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
Hi, Damjan,
I downloaded the glibc source file. Now, I can see the symbols. See
attachment for all details. Hope they help fix the issue.
Thanks.
Chuan
On Mon, Nov 4, 2019 at 11:00 AM Chuan Han wrote:
> More details.
>
> warning: core file may not match specified executable file.
> [New LWP 10851]
> [New LWP 10855]
> [New LWP 10853]
> [New LWP 10854]
> [New LWP 10856]
> [New LWP 10857]
> [New LWP 10858]
> [New LWP 10852]
> [New LWP 10859]
> [New LWP 10860]
> [New LWP 10861]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `vpp -c vpp_startup/startup.conf'.
> Program terminated with signal SIGABRT, Aborted.
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> [Current thread is 1 (Thread 0x7f8120c00780 (LWP 10851))]
> (gdb)
>
> On Mon, Nov 4, 2019 at 10:46 AM Chuan Han wrote:
>
>> Not sure how to get all symbols. Can someone share some steps?
>>
>> (gdb) list
>>
>>
>>
>> 46 in ../sysdeps/unix/sysv/linux/raise.c
>>
>>
>>
>> (gdb) bt full
>>
>>
>>
>> #0 __GI_raise (sig=sig@entry=6) at
>> ../sysdeps/unix/sysv/linux/raise.c:51
>>
>>
>>
>> set = {__val = {1024, 140192549297216, 140191458925760,
>> 94479452800528, 140191458925744, 14738652586040953856, 12, 94479452800528,
>> 0, 14738652586040953856, 12, 1, 94479452800528, 1, 12, 140192554943764}}
>> pid =
>> tid =
>> ret =
>> #1 0x7f811edf2801 in __GI_abort () at abort.c:79
>> save_stage = 1
>> act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction =
>> 0x0}, sa_mask = {__val = {140192549484596, 140192549745376,
>> 140192549484596, 140192554638615, 140192554894358, 140192549484596,
>> 140191451682880, 4294967295, 4, 1024, 140191451683548, 140191451691708,
>> 14738652586040953856,
>> 140191436101232, 8, 8}}, sa_flags = 853347328, sa_restorer
>> = 0x7f80de1c1ef0}
>> sigs = {__val = {32, 0 }}
>> __cnt =
>> __set =
>> __cnt =
>> __set =
>> #2 0x55edb4f0ad44 in os_exit ()
>> No symbol table info available.
>> #3 0x7f811f6f53d9 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #4
>> No locals.
>> #5 0x7f811f6db793 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #6 0x7f811f6df4d9 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #8 0x7f811f6b5d17 in vlib_main () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #9 0x7f811f6f4416 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> No symbol table info available.
>> #10 0x7f811f1cb834 in clib_calljmp () from
>> /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
>> No symbol table info available.
>> #11 0x7ffe3cb01770 in ?? ()
>> No symbol table info available.
>> #12 0x7f811f6f586f in vlib_unix_main () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>>
>> On Mon, Nov 4, 2019 at 10:45 AM Chuan Han via Lists.Fd.Io > google@lists.fd.io> wrote:
>>
>>> Here is the gdb vpp core output
>>>
>>> (gdb) f
>>>
>>>
>>>
>>> #0 __GI_raise (sig=sig@entry=6) at
>>> ../sysdeps/unix/sysv/linux/raise.c:51
>>>
>>>
>>>
>>> 51 in ../sysdeps/unix/sysv/linux/raise.c
>>>
>>>
>>>
>>> (gdb) bt
>>>
>>>
>>>
>>> #0 __GI_raise (sig=sig@entry=6) at
>>> ../sysdeps/unix/sysv/linux/raise.c:51
>>>
>>>
>>>
>>> #1 0x7f811edf2801 in __GI_abort () at abort.c:79
>>> #2 0x55edb4f0ad44 in os_exit ()
>>> #3 0x7f811f6f53d9 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>>> #4
>>> #5 0x7f811f6db793 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>>> #6 0x7f811f6df4d9 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>>> #7 0x7f811f6a4eee in vlib_ca
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
More details.
warning: core file may not match specified executable file.
[New LWP 10851]
[New LWP 10855]
[New LWP 10853]
[New LWP 10854]
[New LWP 10856]
[New LWP 10857]
[New LWP 10858]
[New LWP 10852]
[New LWP 10859]
[New LWP 10860]
[New LWP 10861]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `vpp -c vpp_startup/startup.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f8120c00780 (LWP 10851))]
(gdb)
On Mon, Nov 4, 2019 at 10:46 AM Chuan Han wrote:
> Not sure how to get all symbols. Can someone share some steps?
>
> (gdb) list
>
>
>
> 46 in ../sysdeps/unix/sysv/linux/raise.c
>
>
>
> (gdb) bt full
>
>
>
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
>
>
> set = {__val = {1024, 140192549297216, 140191458925760,
> 94479452800528, 140191458925744, 14738652586040953856, 12, 94479452800528,
> 0, 14738652586040953856, 12, 1, 94479452800528, 1, 12, 140192554943764}}
> pid =
> tid =
> ret =
> #1 0x7f811edf2801 in __GI_abort () at abort.c:79
> save_stage = 1
> act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction =
> 0x0}, sa_mask = {__val = {140192549484596, 140192549745376,
> 140192549484596, 140192554638615, 140192554894358, 140192549484596,
> 140191451682880, 4294967295, 4, 1024, 140191451683548, 140191451691708,
> 14738652586040953856,
> 140191436101232, 8, 8}}, sa_flags = 853347328, sa_restorer =
> 0x7f80de1c1ef0}
> sigs = {__val = {32, 0 }}
> __cnt =
> __set =
> __cnt =
> __set =
> #2 0x55edb4f0ad44 in os_exit ()
> No symbol table info available.
> #3 0x7f811f6f53d9 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #4
> No locals.
> #5 0x7f811f6db793 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #6 0x7f811f6df4d9 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #8 0x7f811f6b5d17 in vlib_main () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #9 0x7f811f6f4416 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> No symbol table info available.
> #10 0x7f811f1cb834 in clib_calljmp () from
> /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
> No symbol table info available.
> #11 0x00007ffe3cb01770 in ?? ()
> No symbol table info available.
> #12 0x7f811f6f586f in vlib_unix_main () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>
> On Mon, Nov 4, 2019 at 10:45 AM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote:
>
>> Here is the gdb vpp core output
>>
>> (gdb) f
>>
>>
>>
>> #0 __GI_raise (sig=sig@entry=6) at
>> ../sysdeps/unix/sysv/linux/raise.c:51
>>
>>
>>
>> 51 in ../sysdeps/unix/sysv/linux/raise.c
>>
>>
>>
>> (gdb) bt
>>
>>
>>
>> #0 __GI_raise (sig=sig@entry=6) at
>> ../sysdeps/unix/sysv/linux/raise.c:51
>>
>>
>>
>> #1 0x7f811edf2801 in __GI_abort () at abort.c:79
>> #2 0x55edb4f0ad44 in os_exit ()
>> #3 0x7f811f6f53d9 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #4
>> #5 0x7f811f6db793 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #6 0x7f811f6df4d9 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #8 0x7f811f6b5d17 in vlib_main () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #9 0x7f811f6f4416 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #10 0x7f811f1cb834 in clib_calljmp () from
>> /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
>> #11 0x7ffe3cb01770 in ?? ()
>> #12 0x7f811f6f586f in vlib_unix_main () from
>> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
>> #13 0x3de8f6310400 in ?? ()
>> #14 0x8100458b49ffd49d in ?? ()
>> #15 0x8b480100f868 in ?? ()
>> #16 0x6d8141fb6085 in ?? ()
>> #17 0x408b480100
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
Not sure how to get all symbols. Can someone share some steps?
(gdb) list
46 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) bt full
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
set = {__val = {1024, 140192549297216, 140191458925760,
94479452800528, 140191458925744, 14738652586040953856, 12, 94479452800528,
0, 14738652586040953856, 12, 1, 94479452800528, 1, 12, 140192554943764}}
pid =
tid =
ret =
#1 0x7f811edf2801 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction =
0x0}, sa_mask = {__val = {140192549484596, 140192549745376,
140192549484596, 140192554638615, 140192554894358, 140192549484596,
140191451682880, 4294967295, 4, 1024, 140191451683548, 140191451691708,
14738652586040953856,
140191436101232, 8, 8}}, sa_flags = 853347328, sa_restorer =
0x7f80de1c1ef0}
sigs = {__val = {32, 0 }}
__cnt =
__set =
__cnt =
__set =
#2 0x55edb4f0ad44 in os_exit ()
No symbol table info available.
#3 0x7f811f6f53d9 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#4
No locals.
#5 0x7f811f6db793 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#6 0x7f811f6df4d9 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#8 0x7f811f6b5d17 in vlib_main () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#9 0x7f811f6f4416 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
No symbol table info available.
#10 0x7f811f1cb834 in clib_calljmp () from
/usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
No symbol table info available.
#11 0x7ffe3cb01770 in ?? ()
No symbol table info available.
#12 0x7f811f6f586f in vlib_unix_main () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
On Mon, Nov 4, 2019 at 10:45 AM Chuan Han via Lists.Fd.Io wrote:
> Here is the gdb vpp core output
>
> (gdb) f
>
>
>
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
>
>
> 51 in ../sysdeps/unix/sysv/linux/raise.c
>
>
>
> (gdb) bt
>
>
>
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
>
>
> #1 0x7f811edf2801 in __GI_abort () at abort.c:79
> #2 0x55edb4f0ad44 in os_exit ()
> #3 0x7f811f6f53d9 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #4
> #5 0x7f811f6db793 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #6 0x7f811f6df4d9 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #8 0x7f811f6b5d17 in vlib_main () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #9 0x7f811f6f4416 in ?? () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #10 0x7f811f1cb834 in clib_calljmp () from
> /usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
> #11 0x7ffe3cb01770 in ?? ()
> #12 0x7f811f6f586f in vlib_unix_main () from
> /usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
> #13 0x3de8f6310400 in ?? ()
> #14 0x8100458b49ffd49d in ?? ()
> #15 0x8b480100f868 in ?? ()
> #16 0x6d8141fb6085 in ?? ()
> #17 0x408b48010008 in ?? ()
> #18 0x4800c740 in ?? ()
>
> let me know more specific steps to pinpoint the issues.
>
> On Mon, Nov 4, 2019 at 10:13 AM Damjan Marion wrote:
>
>> i remember doing corelist-workers with > 50 cores…..
>>
>> If you paste traceback we may have better clue what is wrong…
>>
>> —
>> Damjan
>>
>>
>>
>> On 4 Nov 2019, at 18:51, Chuan Han via Lists.Fd.Io <
>> chuanhan=google@lists.fd.io> wrote:
>>
>> All even number cores are on numa 0, which also hosts all nics.
>>
>> It seems corelist-workers can only take maximum 8 cores.
>>
>> On Mon, Nov 4, 2019 at 9:45 AM Tkachuk, Georgii <
>> georgii.tkac...@intel.com> wrote:
>>
>>> Hi Chuan, are cores 20 and 22 on socket0 or socket1? If they are on
>>> socket1, the application is crashing because the aesni_mb driver is
>>> pointing to socket0: vdev crypto_aesni_mb0,socket_id=0.
>>>
>>>
>>>
>>> George
>>>
>>>
>>>
>>> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chuan
>>> Han via Lists.Fd.Io <http://lists.fd.io/>
>>> *Sent:* Monday, November 04, 2019 10:27 AM
>>> *To:* vpp-dev
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
Here is the gdb vpp core output
(gdb) f
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 in ../sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7f811edf2801 in __GI_abort () at abort.c:79
#2 0x55edb4f0ad44 in os_exit ()
#3 0x7f811f6f53d9 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#4
#5 0x7f811f6db793 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#6 0x7f811f6df4d9 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#7 0x7f811f6a4eee in vlib_call_init_exit_functions () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#8 0x7f811f6b5d17 in vlib_main () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#9 0x7f811f6f4416 in ?? () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#10 0x7f811f1cb834 in clib_calljmp () from
/usr/lib/x86_64-linux-gnu/libvppinfra.so.19.08.1
#11 0x7ffe3cb01770 in ?? ()
#12 0x7f811f6f586f in vlib_unix_main () from
/usr/lib/x86_64-linux-gnu/libvlib.so.19.08.1
#13 0x3de8f6310400 in ?? ()
#14 0x8100458b49ffd49d in ?? ()
#15 0x8b480100f868 in ?? ()
#16 0x6d8141fb6085 in ?? ()
#17 0x408b48010008 in ?? ()
#18 0x4800c740 in ?? ()
let me know more specific steps to pinpoint the issues.
On Mon, Nov 4, 2019 at 10:13 AM Damjan Marion wrote:
> i remember doing corelist-workers with > 50 cores…..
>
> If you paste traceback we may have better clue what is wrong…
>
> —
> Damjan
>
>
>
> On 4 Nov 2019, at 18:51, Chuan Han via Lists.Fd.Io <
> chuanhan=google@lists.fd.io> wrote:
>
> All even number cores are on numa 0, which also hosts all nics.
>
> It seems corelist-workers can only take maximum 8 cores.
>
> On Mon, Nov 4, 2019 at 9:45 AM Tkachuk, Georgii
> wrote:
>
>> Hi Chuan, are cores 20 and 22 on socket0 or socket1? If they are on
>> socket1, the application is crashing because the aesni_mb driver is
>> pointing to socket0: vdev crypto_aesni_mb0,socket_id=0.
>>
>>
>>
>> George
>>
>>
>>
>> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chuan
>> Han via Lists.Fd.Io <http://lists.fd.io/>
>> *Sent:* Monday, November 04, 2019 10:27 AM
>> *To:* vpp-dev
>> *Cc:* vpp-dev@lists.fd.io
>> *Subject:* [vpp-dev] Is there a limit when assigning corelist-workers in
>> vpp?
>>
>>
>>
>> Hi, vpp experts,
>>
>>
>>
>> I am trying to allocate more cores to a phy nic. I want to allocate cores
>> 4,6,8,10 to eth0, and cores 12,14,16,18 to eth1.
>>
>>
>>
>> cpu {
>> main-core 2
>> * # corelist-workers 4,6,8,10,12,14,16,18,20,22 <== This does not
>> work. vpp crashes when starting. *
>> corelist-workers 4,6,8,10,12,14,16,18
>> }
>>
>> dpdk {
>> socket-mem 2048,0
>> log-level debug
>> no-tx-checksum-offload
>> dev default{
>> num-tx-desc 512
>> num-rx-desc 512
>> }
>> dev :1a:00.0 {
>> # workers 4,6,8,10,12
>> workers 4,6,8,10
>> name eth0
>> }
>> dev :19:00.1 {
>> # workers 14,16,18,20,22
>> workers 12,14,16,18
>> name eth1
>> }
>> # Use aesni mb lib.
>> vdev crypto_aesni_mb0,socket_id=0
>> # Use qat VF pcie addresses.
>> # dev :3d:01.0
>> no-multi-seg
>> }
>>
>>
>>
>> Afte vpp starts, I can see eth1 got 4 cores but eth0 only got 3 cores.
>>
>>
>>
>> vpp# sh thread
>> ID NameTypeLWP Sched Policy (Priority)
>> lcore Core Socket State
>> 0 vpp_main10653 other (0)2
>> 0 0
>> 1 vpp_wk_0workers 10655 other (0)4
>> 1 0
>> 2 vpp_wk_1workers 10656 other (0)6
>> 4 0
>> 3 vpp_wk_2workers 10657 other (0)8
>> 2 0
>> 4 vpp_wk_3workers 10658 other (0)
>> 10 3 0
>> 5 vpp_wk_4workers 10659 other (0)
>> 12 8 0
>> 6 vpp_wk_5workers 10660 other (0)
>> 14 13 0
>> 7 vpp_wk_6workers 10661 other (0)
>> 16 9 0
>> *8 vpp_wk_7workers 10662 other (0)
>> 18 12 0 <=== core 18 is not used by eth0.*
>> vpp# sh interface rx-placement
>> Thread 1 (vpp_wk_0):
>> node dpdk-input:
>> eth1 queue 0 (polling)
>> Thr
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
I was able to manually fix the nic queue assignment by issuing this command.
set interface rx-placement eth0 queue 2 worker 7
vpp# sh interface rx-placement
Thread 1 (vpp_wk_0):
node dpdk-input:
eth1 queue 0 (polling)
Thread 2 (vpp_wk_1):
node dpdk-input:
eth1 queue 1 (polling)
Thread 3 (vpp_wk_2):
node dpdk-input:
eth1 queue 2 (polling)
Thread 4 (vpp_wk_3):
node dpdk-input:
eth1 queue 3 (polling)
*Thread 5 (vpp_wk_4): <=== not sure why this thread got two queues.
node dpdk-input:eth0 queue 0 (polling)eth0 queue 2 (polling)*
Thread 6 (vpp_wk_5):
node dpdk-input:
eth0 queue 3 (polling)
Thread 7 (vpp_wk_6):
node dpdk-input:
eth0 queue 1 (polling)
vpp# set interface p
promiscuous proxy-arp
vpp# set interface rx
rx-mode rx-placement
vpp# set interface rx-placement eth0 queue 2 thread 8
set interface rx-placement: parse error: 'thread 8'
vpp# set interface rx-placement eth0 queue 2 thread 7
set interface rx-placement: parse error: 'thread 7'
vpp# set interface rx-placement eth0 queue 2 ?
set interface rx-placement: parse error: '?'
vpp# set interface rx-placement ?
set interface rx-placement set interface rx-placement
[queue ] [worker | main]
vpp# set interface rx-placement eth0 queue 2 worker 7
vpp# sh interface rx-placement
Thread 1 (vpp_wk_0):
node dpdk-input:
eth1 queue 0 (polling)
Thread 2 (vpp_wk_1):
node dpdk-input:
eth1 queue 1 (polling)
Thread 3 (vpp_wk_2):
node dpdk-input:
eth1 queue 2 (polling)
Thread 4 (vpp_wk_3):
node dpdk-input:
eth1 queue 3 (polling)
Thread 5 (vpp_wk_4):
node dpdk-input:
eth0 queue 0 (polling)
Thread 6 (vpp_wk_5):
node dpdk-input:
eth0 queue 3 (polling)
Thread 7 (vpp_wk_6):
node dpdk-input:
eth0 queue 1 (polling)
Thread 8 (vpp_wk_7):
node dpdk-input:
eth0 queue 2 (polling)
On Mon, Nov 4, 2019 at 10:13 AM Damjan Marion wrote:
> i remember doing corelist-workers with > 50 cores…..
>
> If you paste traceback we may have better clue what is wrong…
>
> —
> Damjan
>
>
>
> On 4 Nov 2019, at 18:51, Chuan Han via Lists.Fd.Io <
> chuanhan=google@lists.fd.io> wrote:
>
> All even number cores are on numa 0, which also hosts all nics.
>
> It seems corelist-workers can only take maximum 8 cores.
>
> On Mon, Nov 4, 2019 at 9:45 AM Tkachuk, Georgii
> wrote:
>
>> Hi Chuan, are cores 20 and 22 on socket0 or socket1? If they are on
>> socket1, the application is crashing because the aesni_mb driver is
>> pointing to socket0: vdev crypto_aesni_mb0,socket_id=0.
>>
>>
>>
>> George
>>
>>
>>
>> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chuan
>> Han via Lists.Fd.Io <http://lists.fd.io/>
>> *Sent:* Monday, November 04, 2019 10:27 AM
>> *To:* vpp-dev
>> *Cc:* vpp-dev@lists.fd.io
>> *Subject:* [vpp-dev] Is there a limit when assigning corelist-workers in
>> vpp?
>>
>>
>>
>> Hi, vpp experts,
>>
>>
>>
>> I am trying to allocate more cores to a phy nic. I want to allocate cores
>> 4,6,8,10 to eth0, and cores 12,14,16,18 to eth1.
>>
>>
>>
>> cpu {
>> main-core 2
>> * # corelist-workers 4,6,8,10,12,14,16,18,20,22 <== This does not
>> work. vpp crashes when starting. *
>> corelist-workers 4,6,8,10,12,14,16,18
>> }
>>
>> dpdk {
>> socket-mem 2048,0
>> log-level debug
>> no-tx-checksum-offload
>> dev default{
>> num-tx-desc 512
>> num-rx-desc 512
>> }
>> dev :1a:00.0 {
>> # workers 4,6,8,10,12
>> workers 4,6,8,10
>> name eth0
>> }
>> dev :19:00.1 {
>> # workers 14,16,18,20,22
>> workers 12,14,16,18
>> name eth1
>> }
>> # Use aesni mb lib.
>> vdev crypto_aesni_mb0,socket_id=0
>> # Use qat VF pcie addresses.
>> # dev :3d:01.0
>> no-multi-seg
>> }
>>
>>
>>
>> Afte vpp starts, I can see eth1 got 4 cores but eth0 only got 3 cores.
>>
>>
>>
>> vpp# sh thread
>> ID NameTypeLWP Sched Policy (Priority)
>> lcore Core Socket State
>> 0 vpp_main10653 other (0)2
>> 0 0
>> 1 vpp_wk_0workers 10655 other (0)4
>> 1 0
>> 2 vpp_wk_1workers 10656 other (0)6
>> 4 0
>> 3 vpp_wk_2workers 10657 other (0)8
>> 2 0
>> 4 vpp_wk_3workers 10658 other (0)
>> 10 3 0
>> 5 vpp
Re: [vpp-dev] Is there a limit when assigning corelist-workers in vpp?
All even number cores are on numa 0, which also hosts all nics.
It seems corelist-workers can only take maximum 8 cores.
On Mon, Nov 4, 2019 at 9:45 AM Tkachuk, Georgii
wrote:
> Hi Chuan, are cores 20 and 22 on socket0 or socket1? If they are on
> socket1, the application is crashing because the aesni_mb driver is
> pointing to socket0: vdev crypto_aesni_mb0,socket_id=0.
>
>
>
> George
>
>
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chuan
> Han via Lists.Fd.Io
> *Sent:* Monday, November 04, 2019 10:27 AM
> *To:* vpp-dev
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] Is there a limit when assigning corelist-workers in
> vpp?
>
>
>
> Hi, vpp experts,
>
>
>
> I am trying to allocate more cores to a phy nic. I want to allocate cores
> 4,6,8,10 to eth0, and cores 12,14,16,18 to eth1.
>
>
>
> cpu {
> main-core 2
> * # corelist-workers 4,6,8,10,12,14,16,18,20,22 <== This does not work.
> vpp crashes when starting. *
> corelist-workers 4,6,8,10,12,14,16,18
> }
>
> dpdk {
> socket-mem 2048,0
> log-level debug
> no-tx-checksum-offload
> dev default{
> num-tx-desc 512
> num-rx-desc 512
> }
> dev :1a:00.0 {
> # workers 4,6,8,10,12
> workers 4,6,8,10
> name eth0
> }
> dev :19:00.1 {
> # workers 14,16,18,20,22
> workers 12,14,16,18
> name eth1
> }
> # Use aesni mb lib.
> vdev crypto_aesni_mb0,socket_id=0
> # Use qat VF pcie addresses.
> # dev :3d:01.0
> no-multi-seg
> }
>
>
>
> Afte vpp starts, I can see eth1 got 4 cores but eth0 only got 3 cores.
>
>
>
> vpp# sh thread
> ID NameTypeLWP Sched Policy (Priority)
> lcore Core Socket State
> 0 vpp_main10653 other (0)2
> 0 0
> 1 vpp_wk_0workers 10655 other (0)4
> 1 0
> 2 vpp_wk_1workers 10656 other (0)6
> 4 0
> 3 vpp_wk_2workers 10657 other (0)8
> 2 0
> 4 vpp_wk_3workers 10658 other (0)10
> 3 0
> 5 vpp_wk_4workers 10659 other (0)12
> 8 0
> 6 vpp_wk_5workers 10660 other (0)14
> 13 0
> 7 vpp_wk_6workers 10661 other (0)16
> 9 0
> *8 vpp_wk_7workers 10662 other (0)
> 18 12 0 <=== core 18 is not used by eth0.*
> vpp# sh interface rx-placement
> Thread 1 (vpp_wk_0):
> node dpdk-input:
> eth1 queue 0 (polling)
> Thread 2 (vpp_wk_1):
> node dpdk-input:
> eth1 queue 1 (polling)
> Thread 3 (vpp_wk_2):
> node dpdk-input:
> eth1 queue 2 (polling)
> Thread 4 (vpp_wk_3):
> node dpdk-input:
> eth1 queue 3 (polling)
>
>
>
> *Thread 5 (vpp_wk_4): node dpdk-input: eth0 queue 0 (polling)
> eth0 queue 2 (polling)*
> Thread 6 (vpp_wk_5):
> node dpdk-input:
> eth0 queue 3 (polling)
> Thread 7 (vpp_wk_6):
> node dpdk-input:
> eth0 queue 1 (polling)
> vpp#
>
>
>
> It seems there is a limitation on assigning cores to nic.
>
> 1. I cannot allocate cores after 20 to corelist-workers.
>
> 2. Cores after 18 cannot be allocated to nic.
>
>
>
> Is this some bug? Or, some undocumented limitation?
>
>
>
> Thanks.
>
> Chuan
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14491): https://lists.fd.io/g/vpp-dev/message/14491
Mute This Topic: https://lists.fd.io/mt/41334952/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Is there a limit when assigning corelist-workers in vpp?
Hi, vpp experts,
I am trying to allocate more cores to a phy nic. I want to allocate cores
4,6,8,10 to eth0, and cores 12,14,16,18 to eth1.
cpu {
main-core 2
* # corelist-workers 4,6,8,10,12,14,16,18,20,22 <== This does not work.
vpp crashes when starting. *
corelist-workers 4,6,8,10,12,14,16,18
}
dpdk {
socket-mem 2048,0
log-level debug
no-tx-checksum-offload
dev default{
num-tx-desc 512
num-rx-desc 512
}
dev :1a:00.0 {
# workers 4,6,8,10,12
workers 4,6,8,10
name eth0
}
dev :19:00.1 {
# workers 14,16,18,20,22
workers 12,14,16,18
name eth1
}
# Use aesni mb lib.
vdev crypto_aesni_mb0,socket_id=0
# Use qat VF pcie addresses.
# dev :3d:01.0
no-multi-seg
}
Afte vpp starts, I can see eth1 got 4 cores but eth0 only got 3 cores.
vpp# sh thread
ID NameTypeLWP Sched Policy (Priority)
lcore Core Socket State
0 vpp_main10653 other (0)2
0 0
1 vpp_wk_0workers 10655 other (0)4
1 0
2 vpp_wk_1workers 10656 other (0)6
4 0
3 vpp_wk_2workers 10657 other (0)8
2 0
4 vpp_wk_3workers 10658 other (0)10
3 0
5 vpp_wk_4workers 10659 other (0)12
8 0
6 vpp_wk_5workers 10660 other (0)14
13 0
7 vpp_wk_6workers 10661 other (0)16
9 0
*8 vpp_wk_7workers 10662 other (0)18
12 0 <=== core 18 is not used by eth0.*
vpp# sh interface rx-placement
Thread 1 (vpp_wk_0):
node dpdk-input:
eth1 queue 0 (polling)
Thread 2 (vpp_wk_1):
node dpdk-input:
eth1 queue 1 (polling)
Thread 3 (vpp_wk_2):
node dpdk-input:
eth1 queue 2 (polling)
Thread 4 (vpp_wk_3):
node dpdk-input:
eth1 queue 3 (polling)
*Thread 5 (vpp_wk_4): node dpdk-input:eth0 queue 0 (polling)eth0
queue 2 (polling)*
Thread 6 (vpp_wk_5):
node dpdk-input:
eth0 queue 3 (polling)
Thread 7 (vpp_wk_6):
node dpdk-input:
eth0 queue 1 (polling)
vpp#
It seems there is a limitation on assigning cores to nic.
1. I cannot allocate cores after 20 to corelist-workers.
2. Cores after 18 cannot be allocated to nic.
Is this some bug? Or, some undocumented limitation?
Thanks.
Chuan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14489): https://lists.fd.io/g/vpp-dev/message/14489
Mute This Topic: https://lists.fd.io/mt/41334952/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Basic l2 bridging does not work
Just for record purposes, we did not continue trying this R740-R230 setup. We moved to R740-R740 setup. We did not see this phy nic down issue. It seems some compatibility bug within R230 + some nic. On Sun, Oct 20, 2019 at 9:37 PM Balaji Venkatraman via Lists.Fd.Io wrote: > I see in the log of “ethtool enp6s0f1“ on R230: > > > > root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 > > > > Supported ports: [ *FIBRE* ] <<<<<<<<<<<<<<<< > > Supported link modes: 1baseT/Full > > Supports auto-negotiation: No > > Advertised link modes: 1baseT/Full <<<<< > > Speed: 1Mb/s > > Port: Direct Attach Copper > > *Auto-negotiation: off* > > > > > > While on R 230: > > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 > Settings for eno3: > Supported ports: [ *TP* ]. <<<<<<<<<<<<<<<<< > > > *Supported link modes: 100baseT/Full > 1000baseT/Full 1baseT/Full *<<<<< > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Twisted Pair* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: on* > MDI-X: Unknown > > > > > > The supported ports seem mismatched at either end with AutoNeg disabled at > one, I doubt the parameters are exchanged to get the transmissions going. > Some expert in the ethernet might want to comment if this could be an issue. > > Regards, > > Balaji. > > > > > > *From: * on behalf of "steven luong via Lists.Fd.Io" > > *Reply-To: *"Steven Luong (sluong)" > *Date: *Friday, October 18, 2019 at 10:06 PM > *To: *"vpp-dev@lists.fd.io" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Can you reduce your rx and tx queues to 1 and try again? > > > > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > > > Steven > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Friday, October 18, 2019 at 4:05 PM > *To: *Chuan Han > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Hi, Damjan, > > > > It seems the bug is in vpp. > > > > On R230, vpp shows eth0 is down. > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > > > * Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down* > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > extended stats: > mac local errors 318 > vpp# > > > > However, the testpmd tool shows it is up. > > > > testpmd> show port summary 1 > Number of available ports: 2 > Port MAC Address Name Driver Status Link > *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* > testpmd> > > > &g
Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
Just for record purposes, here are the configs I figured out on l2 gretap + ipsec transport mode. The other party config is similar with proper changes in ip, mac address and spi. Make sure spi matches. Otherwise, pkt will be punted on the receiving side. set int state eth0 up set int ip address eth0 10.10.10.11/24 set int promiscuous on eth0 set ip arp eth0 10.10.10.10 24:6e:96:b4:b2:07 set int state eth1 up set int promiscuous on eth1 create gre tunnel src 10.10.10.11 dst 10.10.10.10 teb set int state gre0 up create bridge-domain 1 set interface l2 bridge gre0 1 set interface l2 bridge eth1 1 ipsec spd add 1 set interface ipsec spd eth0 1 ipsec sa add 1 spi 255128 esp crypto-key 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg aes-gcm-256 ipsec sa add 2 spi 255129 esp crypto-key 0123456789012345678901234567890101234567890123456789012345678901 crypto-alg aes-gcm-256 ipsec policy add spd 1 priority 90 inbound action protect sa 2 local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range 10.10.10.10-10.10.10.10 ipsec policy add spd 1 priority 90 outbound action protect sa 1 local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range 10.10.10.10-10.10.10.10 trace add dpdk-input 10 On Tue, Oct 8, 2019 at 3:23 PM Chuan Han via Lists.Fd.Io wrote: > Hi, Neale/vpp experts, > > Can you help check why the receiving side drops all the incoming pkts > because of unknown ip protocol? > > I looked at TestIpsecGreTebIfEsp, but had no clue how it is mapped to cli > commands. > > I am new to vpp. > > Thanks. > Chuan > > On Fri, Oct 4, 2019 at 11:41 AM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > >> Thanks for helping. >> >> I removed spd configs on both sides, but still no luck. I am pinging from >> r230 side. >> >> It seems r230 is able to sending ping pkts over dpdk interface. However, >> on r740 side, gre0 interface drops all of them. See the attached updated >> cfg files and log files for more details. >> >> IPSec: remote:10.10.10.11 spi:255129 (0x0003e499) seq 418 >> 00:06:52:367944: esp4-decrypt-tun >> esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 418 sa-seq 0 >> sa-seq-hi 0 >> 00:06:52:367948: ip4-input-no-checksum >> GRE: 10.10.10.11 -> 10.10.10.10 >> tos 0x00, ttl 254, length 66, checksum 0x9464 >> fragment id 0x >> GRE teb >> 00:06:52:367948: ip4-not-enabled >> GRE: 10.10.10.11 -> 10.10.10.10 >> tos 0x00, ttl 254, length 66, checksum 0x9464 >> fragment id 0x >> GRE teb >> 00:06:52:367948: error-drop >> rx:gre0 >> 00:06:52:367949: drop >> ip4-input: unknown ip protocol >> >> >> On Fri, Oct 4, 2019 at 8:39 AM Neale Ranns (nranns) >> wrote: >> >>> >>> >>> Hi Chuan, >>> >>> >>> >>> Please remove the SPD config. For tunnels all packets that >>> ingress/egress the tunnel are decrypted/encrypted, so no policy is >>> required. The presence of the SPD on the ingress eth0 link could be why >>> it’s not working. >>> >>> Please provide packet traces when you are reporting packet loss >>> problems, it helps us debug. >>> >>> >>> >>> For reference the setup for GRE TEB IPSec can be found in the python UT >>> TestIpsecGreTebIfEsp. >>> >>> >>> >>> Regards, >>> >>> neale >>> >>> >>> >>> >>> >>> *From: * on behalf of "Chuan Han via Lists.Fd.Io" >>> >>> *Reply to: *"chuan...@google.com" >>> *Date: *Friday 4 October 2019 at 02:15 >>> *To: *"John Lo (loj)" >>> *Cc: *"vpp-dev@lists.fd.io" >>> *Subject: *Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 >>> >>> >>> >>> Hi, >>> >>> >>> >>> Thanks for information. >>> >>> >>> >>> I am trying to configure l2 gre over ipsec transport mode. >>> >>> >>> >>> Here are my startup.cfg files. Can you help check if my configuration is >>> correct or not? >>> >>> >>> >>> r230 and r740 are two servers which are directly connected. >>> >>> >>> >>> eth0 is the phy nic. host-veth1 is one endpoint of veth pair. the other >>> end is connected to a network namespace with ip address 172.16.1.2. >>> >>> >>> >>> From the network namespace, I cannot ping the other end 172.16.1.1. >>> >>> >>>
Re: [vpp-dev] Basic l2 bridging does not work
The same problem still exists. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 *carrier down * flags: admin-up promisc pmd rx-ip4-cksum *rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)tx: queues 1 (max 64), desc 512 (min 32 max 4096 align 8)* pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec vpp# testpmd shows that interface is up. testpmd> show port summary 1 Number of available ports: 2 Port MAC Address Name Driver Status Link *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* testpmd> On Fri, Oct 18, 2019 at 8:16 PM Steven Luong (sluong) wrote: > Can you reduce your rx and tx queues to 1 and try again? > > > > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > > Steven > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Friday, October 18, 2019 at 4:05 PM > *To: *Chuan Han > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Hi, Damjan, > > > > It seems the bug is in vpp. > > > > On R230, vpp shows eth0 is down. > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > > > * Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down* > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > extended stats: > mac local errors 318 > vpp# > > > > However, the testpmd tool shows it is up. > > > > testpmd> show port summary 1 > Number of available ports: 2 > Port MAC Address Name Driver Status Link > *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* > testpmd> > > > > Does this prove something wrong on vpp side? > > > > Thanks. > > Chuan > > > > On Fri, Oct 18, 2019 at 3:06 PM Chuan Han wrote: > > I built testpmd binary on both r740 and r230, and ran the test. I did see > testpmd reports some link status change on r230 server. testpmd report on > r740 is stabler. no status change reported. > > > > r230 log > > ==== > > Press enter to exit > > Port 0: link state change event > > Port 1: link state change event > > Port 1: link state change event > > r740 log > > > > Press enter to exitx0 - TX RS bit threshold=32 > > If it is a dpdk bug, what shall I do? Report to dpdk mailing list? > > > > On Fri, Oct 18, 2019 at 11:55 AM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > > So, it is
Re: [vpp-dev] Basic l2 bridging does not work
Hi, Damjan, It seems the bug is in vpp. On R230, vpp shows eth0 is down. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown * Ethernet address b4:96:91:23:1e:d6 Intel 82599carrier down* flags: admin-up promisc pmd rx-ip4-cksum rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec extended stats: mac local errors 318 vpp# However, the testpmd tool shows it is up. testpmd> show port summary 1 Number of available ports: 2 Port MAC Address Name Driver Status Link *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* testpmd> Does this prove something wrong on vpp side? Thanks. Chuan On Fri, Oct 18, 2019 at 3:06 PM Chuan Han wrote: > I built testpmd binary on both r740 and r230, and ran the test. I did see > testpmd reports some link status change on r230 server. testpmd report on > r740 is stabler. no status change reported. > > r230 log > > Press enter to exit > > Port 0: link state change event > > Port 1: link state change event > > Port 1: link state change event > > r740 log > > Press enter to exitx0 - TX RS bit threshold=32 > > If it is a dpdk bug, what shall I do? Report to dpdk mailing list? > > On Fri, Oct 18, 2019 at 11:55 AM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > >> So, it is a dpdk bug? >> >> I am new to dpdk/vpp. >> >> How do I run dpdk testpmd? Shall I install dpdk separately on the r230 >> server? Are there any steps to follow? >> >> On Fri, Oct 18, 2019 at 10:30 AM Damjan Marion wrote: >> >>> In this case we are purely relying on link state provided by DPDK. >>> Have you tried to check if same problem exists with DPDK testpmd app? >>> >>> >>> On 18 Oct 2019, at 10:26, Chuan Han via Lists.Fd.Io < >>> chuanhan=google@lists.fd.io> wrote: >>> >>> I cleaned up startup config a bit. I can still see eth0 down. >>> >>> See attachment for config file and log. There are some errors in log, >>> but I am not sure they are worrisome or not. >>> >>> On Thu, Oct 17, 2019 at 5:22 PM Florin Coras >>> wrote: >>> >>>> This looks like a DPDK issue, but I’ll let Damjan be the judge of that. >>>> >>>> To see if this is a config issues, could you simplify your startup >>>> config by >>>> - removing “workers 0” from the two nics and adding “num-rx-queues 2” >>>> to the nics or to the default stanza, if you’re running with 2 workers >>>> - comment out the cryptodev config >>>> >>>> If the two nics don’t come up, check if there’s any obvious dpdk error >>>> in “show log”. >>>> >>>> Florin >>>> >>>> On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io >>>> <http://lists.fd.io/> wrote: >>>> >>>> I tried disabling autoneg on R740 side. It is not allowed too. If vpp >>>> cannot allow two nics to be successfully added to the same vpp instance, it >>>> seems to be a bug. Is it something which can be easily spotted in the code >>>> base? >>>> >>>> It is also not possible to enforce symmetricity on internet. The other >>>> party can do anything as long as basic ping works. >>>> >>>> On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: >>>> >>>>> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it >>>>> is up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems >>>>> something is wron
Re: [vpp-dev] Basic l2 bridging does not work
I built testpmd binary on both r740 and r230, and ran the test. I did see testpmd reports some link status change on r230 server. testpmd report on r740 is stabler. no status change reported. r230 log Press enter to exit Port 0: link state change event Port 1: link state change event Port 1: link state change event r740 log Press enter to exitx0 - TX RS bit threshold=32 If it is a dpdk bug, what shall I do? Report to dpdk mailing list? On Fri, Oct 18, 2019 at 11:55 AM Chuan Han via Lists.Fd.Io wrote: > So, it is a dpdk bug? > > I am new to dpdk/vpp. > > How do I run dpdk testpmd? Shall I install dpdk separately on the r230 > server? Are there any steps to follow? > > On Fri, Oct 18, 2019 at 10:30 AM Damjan Marion wrote: > >> In this case we are purely relying on link state provided by DPDK. >> Have you tried to check if same problem exists with DPDK testpmd app? >> >> >> On 18 Oct 2019, at 10:26, Chuan Han via Lists.Fd.Io < >> chuanhan=google@lists.fd.io> wrote: >> >> I cleaned up startup config a bit. I can still see eth0 down. >> >> See attachment for config file and log. There are some errors in log, but >> I am not sure they are worrisome or not. >> >> On Thu, Oct 17, 2019 at 5:22 PM Florin Coras >> wrote: >> >>> This looks like a DPDK issue, but I’ll let Damjan be the judge of that. >>> >>> To see if this is a config issues, could you simplify your startup >>> config by >>> - removing “workers 0” from the two nics and adding “num-rx-queues 2” to >>> the nics or to the default stanza, if you’re running with 2 workers >>> - comment out the cryptodev config >>> >>> If the two nics don’t come up, check if there’s any obvious dpdk error >>> in “show log”. >>> >>> Florin >>> >>> On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io >>> <http://lists.fd.io/> wrote: >>> >>> I tried disabling autoneg on R740 side. It is not allowed too. If vpp >>> cannot allow two nics to be successfully added to the same vpp instance, it >>> seems to be a bug. Is it something which can be easily spotted in the code >>> base? >>> >>> It is also not possible to enforce symmetricity on internet. The other >>> party can do anything as long as basic ping works. >>> >>> On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: >>> >>>> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it >>>> is up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems >>>> something is wrong with the nic or vpp does not support this type of >>>> hardware? >>>> >>>> We tried enabling autoneg on R230. It is not allowed. To avoid >>>> asymmetric settings, disabling autoneg on R740 will help? >>>> >>>> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < >>>> bala...@cisco.com> wrote: >>>> >>>>> It plays a role if it is asymmetric at both ends. You could enable it >>>>> at both ends and check. >>>>> >>>>> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >>>>> >>>>> >>>>> I rebooted the r230 machine and found the phy nic corresponding to eth >>>>> has autoneg off. >>>>> >>>>> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >>>>> Settings for enp6s0f1: >>>>> Supported ports: [ FIBRE ] >>>>> Supported link modes: 1baseT/Full >>>>> Supported pause frame use: Symmetric >>>>> Supports auto-negotiation: No >>>>> Supported FEC modes: Not reported >>>>> Advertised link modes: 1baseT/Full >>>>> Advertised pause frame use: Symmetric >>>>> Advertised auto-negotiation: No >>>>> Advertised FEC modes: Not reported >>>>> Speed: 1Mb/s >>>>> Duplex: Full >>>>> *Port: Direct Attach Copper* >>>>> PHYAD: 0 >>>>> Transceiver: internal >>>>> *Auto-negotiation: off* >>>>> Supports Wake-on: d >>>>> Wake-on: d >>>>> Current message level: 0x0007 (7) >>>>>drv probe link >>>>>
Re: [vpp-dev] Basic l2 bridging does not work
So, it is a dpdk bug? I am new to dpdk/vpp. How do I run dpdk testpmd? Shall I install dpdk separately on the r230 server? Are there any steps to follow? On Fri, Oct 18, 2019 at 10:30 AM Damjan Marion wrote: > In this case we are purely relying on link state provided by DPDK. > Have you tried to check if same problem exists with DPDK testpmd app? > > > On 18 Oct 2019, at 10:26, Chuan Han via Lists.Fd.Io < > chuanhan=google@lists.fd.io> wrote: > > I cleaned up startup config a bit. I can still see eth0 down. > > See attachment for config file and log. There are some errors in log, but > I am not sure they are worrisome or not. > > On Thu, Oct 17, 2019 at 5:22 PM Florin Coras > wrote: > >> This looks like a DPDK issue, but I’ll let Damjan be the judge of that. >> >> To see if this is a config issues, could you simplify your startup config >> by >> - removing “workers 0” from the two nics and adding “num-rx-queues 2” to >> the nics or to the default stanza, if you’re running with 2 workers >> - comment out the cryptodev config >> >> If the two nics don’t come up, check if there’s any obvious dpdk error in >> “show log”. >> >> Florin >> >> On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io >> <http://lists.fd.io/> wrote: >> >> I tried disabling autoneg on R740 side. It is not allowed too. If vpp >> cannot allow two nics to be successfully added to the same vpp instance, it >> seems to be a bug. Is it something which can be easily spotted in the code >> base? >> >> It is also not possible to enforce symmetricity on internet. The other >> party can do anything as long as basic ping works. >> >> On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: >> >>> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is >>> up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems >>> something is wrong with the nic or vpp does not support this type of >>> hardware? >>> >>> We tried enabling autoneg on R230. It is not allowed. To avoid >>> asymmetric settings, disabling autoneg on R740 will help? >>> >>> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < >>> bala...@cisco.com> wrote: >>> >>>> It plays a role if it is asymmetric at both ends. You could enable it >>>> at both ends and check. >>>> >>>> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >>>> >>>> >>>> I rebooted the r230 machine and found the phy nic corresponding to eth >>>> has autoneg off. >>>> >>>> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >>>> Settings for enp6s0f1: >>>> Supported ports: [ FIBRE ] >>>> Supported link modes: 1baseT/Full >>>> Supported pause frame use: Symmetric >>>> Supports auto-negotiation: No >>>> Supported FEC modes: Not reported >>>> Advertised link modes: 1baseT/Full >>>> Advertised pause frame use: Symmetric >>>> Advertised auto-negotiation: No >>>> Advertised FEC modes: Not reported >>>> Speed: 1Mb/s >>>> Duplex: Full >>>> *Port: Direct Attach Copper* >>>> PHYAD: 0 >>>> Transceiver: internal >>>> *Auto-negotiation: off* >>>> Supports Wake-on: d >>>> Wake-on: d >>>> Current message level: 0x0007 (7) >>>>drv probe link >>>> Link detected: yes >>>> root@esdn-relay:~/gnxi/perf_testing/r230# >>>> >>>> On r740, autoneg is on. It is copper. >>>> >>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >>>> Settings for eno3: >>>> Supported ports: [ TP ] >>>> Supported link modes: 100baseT/Full >>>> 1000baseT/Full >>>> 1baseT/Full >>>> Supported pause frame use: Symmetric >>>> Supports auto-negotiation: Yes >>>> Supported FEC modes: Not reported >>>> Advertised link modes: 100baseT/Full >>>> 1000baseT/Full >>>> 1baseT/Full >>>> Advertised pause frame use: Symmetric >>>>
Re: [vpp-dev] Basic l2 bridging does not work
I cleaned up startup config a bit. I can still see eth0 down. See attachment for config file and log. There are some errors in log, but I am not sure they are worrisome or not. On Thu, Oct 17, 2019 at 5:22 PM Florin Coras wrote: > This looks like a DPDK issue, but I’ll let Damjan be the judge of that. > > To see if this is a config issues, could you simplify your startup config > by > - removing “workers 0” from the two nics and adding “num-rx-queues 2” to > the nics or to the default stanza, if you’re running with 2 workers > - comment out the cryptodev config > > If the two nics don’t come up, check if there’s any obvious dpdk error in > “show log”. > > Florin > > On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io < > chuanhan=google@lists.fd.io> wrote: > > I tried disabling autoneg on R740 side. It is not allowed too. If vpp > cannot allow two nics to be successfully added to the same vpp instance, it > seems to be a bug. Is it something which can be easily spotted in the code > base? > > It is also not possible to enforce symmetricity on internet. The other > party can do anything as long as basic ping works. > > On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: > >> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is >> up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems >> something is wrong with the nic or vpp does not support this type of >> hardware? >> >> We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric >> settings, disabling autoneg on R740 will help? >> >> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < >> bala...@cisco.com> wrote: >> >>> It plays a role if it is asymmetric at both ends. You could enable it at >>> both ends and check. >>> >>> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >>> >>> >>> I rebooted the r230 machine and found the phy nic corresponding to eth >>> has autoneg off. >>> >>> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >>> Settings for enp6s0f1: >>> Supported ports: [ FIBRE ] >>> Supported link modes: 1baseT/Full >>> Supported pause frame use: Symmetric >>> Supports auto-negotiation: No >>> Supported FEC modes: Not reported >>> Advertised link modes: 1baseT/Full >>> Advertised pause frame use: Symmetric >>> Advertised auto-negotiation: No >>> Advertised FEC modes: Not reported >>> Speed: 1Mb/s >>> Duplex: Full >>> *Port: Direct Attach Copper* >>> PHYAD: 0 >>> Transceiver: internal >>> *Auto-negotiation: off* >>> Supports Wake-on: d >>> Wake-on: d >>> Current message level: 0x0007 (7) >>>drv probe link >>> Link detected: yes >>> root@esdn-relay:~/gnxi/perf_testing/r230# >>> >>> On r740, autoneg is on. It is copper. >>> >>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >>> Settings for eno3: >>> Supported ports: [ TP ] >>> Supported link modes: 100baseT/Full >>> 1000baseT/Full >>> 1baseT/Full >>> Supported pause frame use: Symmetric >>> Supports auto-negotiation: Yes >>> Supported FEC modes: Not reported >>> Advertised link modes: 100baseT/Full >>> 1000baseT/Full >>> 1baseT/Full >>> Advertised pause frame use: Symmetric >>> Advertised auto-negotiation: Yes >>> Advertised FEC modes: Not reported >>> Speed: 1Mb/s >>> Duplex: Full >>> *Port: Twisted Pair* >>> PHYAD: 0 >>> Transceiver: internal >>> *Auto-negotiation: on* >>> MDI-X: Unknown >>> Supports Wake-on: umbg >>> Wake-on: g >>> Current message level: 0x0007 (7) >>>drv probe link >>> Link detected: yes >>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >>> >>> not clear if this plays a role or not. >>> >>> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >>> <http://lists.fd.io/> wrote: >&
Re: [vpp-dev] Basic l2 bridging does not work
I tried disabling autoneg on R740 side. It is not allowed too. If vpp cannot allow two nics to be successfully added to the same vpp instance, it seems to be a bug. Is it something which can be easily spotted in the code base? It is also not possible to enforce symmetricity on internet. The other party can do anything as long as basic ping works. On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: > If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is > up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems > something is wrong with the nic or vpp does not support this type of > hardware? > > We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric > settings, disabling autoneg on R740 will help? > > On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > >> It plays a role if it is asymmetric at both ends. You could enable it at >> both ends and check. >> >> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >> >> >> I rebooted the r230 machine and found the phy nic corresponding to eth >> has autoneg off. >> >> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >> Settings for enp6s0f1: >> Supported ports: [ FIBRE ] >> Supported link modes: 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: No >> Supported FEC modes: Not reported >> Advertised link modes: 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: No >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> *Port: Direct Attach Copper* >> PHYAD: 0 >> Transceiver: internal >> *Auto-negotiation: off* >> Supports Wake-on: d >> Wake-on: d >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-relay:~/gnxi/perf_testing/r230# >> >> On r740, autoneg is on. It is copper. >> >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >> Settings for eno3: >> Supported ports: [ TP ] >> Supported link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: Yes >> Supported FEC modes: Not reported >> Advertised link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: Yes >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> *Port: Twisted Pair* >> PHYAD: 0 >> Transceiver: internal >> *Auto-negotiation: on* >> MDI-X: Unknown >> Supports Wake-on: umbg >> Wake-on: g >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >> >> not clear if this plays a role or not. >> >> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io > google@lists.fd.io> wrote: >> >>> Restarting ixia controller does not help. We ended up with both ixia >>> ports having '!'. >>> >>> We are not sure how ixia port plays a role here. eth0 interfaces are the >>> interfaces connecting two servers, not to ixia. >>> >>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>> bala...@cisco.com> wrote: >>> >>>> Hi Chuan, >>>> >>>> >>>> >>>> Could you please try to reset the ixia controller connected to port 4? >>>> >>>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is >>>> down, I suspect the ixia port. >>>> >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Balaji. >>>> >>>> >>>> >>>> >>>> >>>> *From: *Chuan Han >>>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>>> *To: *"Balaji Venkatraman (balajiv)" >>>> *Cc: *"vpp-dev@lists.fd.io&
Re: [vpp-dev] Basic l2 bridging does not work
If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems something is wrong with the nic or vpp does not support this type of hardware? We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric settings, disabling autoneg on R740 will help? On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < bala...@cisco.com> wrote: > It plays a role if it is asymmetric at both ends. You could enable it at > both ends and check. > > On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: > > > I rebooted the r230 machine and found the phy nic corresponding to eth has > autoneg off. > > root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 > Settings for enp6s0f1: > Supported ports: [ FIBRE ] > Supported link modes: 1baseT/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: No > Supported FEC modes: Not reported > Advertised link modes: 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: No > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Direct Attach Copper* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: off* > Supports Wake-on: d > Wake-on: d > Current message level: 0x0007 (7) >drv probe link > Link detected: yes > root@esdn-relay:~/gnxi/perf_testing/r230# > > On r740, autoneg is on. It is copper. > > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 > Settings for eno3: > Supported ports: [ TP ] > Supported link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Twisted Pair* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: on* > MDI-X: Unknown > Supports Wake-on: umbg > Wake-on: g > Current message level: 0x0007 (7) > drv probe link > Link detected: yes > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# > > not clear if this plays a role or not. > > On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > >> Restarting ixia controller does not help. We ended up with both ixia >> ports having '!'. >> >> We are not sure how ixia port plays a role here. eth0 interfaces are the >> interfaces connecting two servers, not to ixia. >> >> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >> bala...@cisco.com> wrote: >> >>> Hi Chuan, >>> >>> >>> >>> Could you please try to reset the ixia controller connected to port 4? >>> >>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, >>> I suspect the ixia port. >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Balaji. >>> >>> >>> >>> >>> >>> *From: *Chuan Han >>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>> *To: *"Balaji Venkatraman (balajiv)" >>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi >>> Appachi gounder , Jerry Cen >>> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >>> >>> >>> >>> Yes. It is unidirectional stream from port 1 to port 4. >>> >>> >>> >>> Another engineer, Nambi, configured ixia. What he showed me yesterday is >>> that xia port connected to port 1 is green and good. ixia port connected to >>> port 4 is green but has a red exclamation mark, which means ping does not >>> work. >>> >>> >>> >>> We also found eth0 on R230 is down shown by "show hardware eth0" >>> command. However "show int" shows it is up. >>> >>> >>> >>> >>> >>> vpp# sh hardware-interfaces et
Re: [vpp-dev] Basic l2 bridging does not work
ksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > rx frames ok 33278 > rx bytes ok 3960082 > extended stats: > rx good packets 33278 > rx good bytes 3960082 > rx q0packets 33278 > rx q0bytes 3960082 > rx size 65 to 127 packets33278 > rx multicast packets 33278 > rx total packets 33278 > rx total bytes 3960082 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 33279 > rx > bytes 3960201 > drops > 5 > punt > 1 > > tx-error 33274 > eth1 1 up 9000/0/0/0 rx > packets 33274 > rx > bytes 3959606 > tx > packets 33273 > tx > bytes 3959487 > drops > 33274 > > tx-error 3 > local00 down 0/0/0/0 > vpp# > > On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > > Hi Chuan, > > I assume u have unidirectional stream ? ixia->1->2->3->4->ixia? > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 30920 <<< packets are received on port 3 > rx > bytes 3679480 > tx > packets 30919 > tx > bytes 3679361 > drops > 30920 <<< all dropped at port 3 > > tx-error 3 > local00 down 0/0/0/0 > > On sh error logs on R 230 we see > > 1 ethernet-input l3 mac mismatch <<<< > 3 eth1-output interface is down > 30922 eth0-output interface is down > > > Do u see the arp getting resolved on ixia? The mac on ixia at port with > 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at > both ends? > > > -- > Regards, > Balaji. > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io > <http://lists.fd.io/>" > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, October 17, 2019 at 9:59 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > It seems R740 vpp works fine. All packets coming from port 1 go to port 2. > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Co
Re: [vpp-dev] Basic l2 bridging does not work
9000/0/0/0 rx > packets 33274 > rx > bytes 3959606 > tx > packets 33273 > tx > bytes 3959487 > drops > 33274 > > tx-error 3 > local00 down 0/0/0/0 > vpp# > > > > On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > > Hi Chuan, > > > > I assume u have unidirectional stream ? ixia->1->2->3->4->ixia? > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 30920 <<< packets are received on port 3 > rx > bytes 3679480 > tx > packets 30919 > tx > bytes 3679361 > drops > 30920 <<< all dropped at port 3 > > tx-error 3 > local00 down 0/0/0/0 > > > > On sh error logs on R 230 we see > > 1 ethernet-input l3 mac mismatch <<<< > 3 eth1-output interface is down > 30922 eth0-output interface is down > > > > > > Do u see the arp getting resolved on ixia? The mac on ixia at port with > 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at > both ends? > > > > > > -- > > Regards, > > Balaji. > > > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, October 17, 2019 at 9:59 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > It seems R740 vpp works fine. All packets coming from port 1 go to port > 2. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > > > The dro
Re: [vpp-dev] Basic l2 bridging does not work
I rebooted the r230 machine and found the phy nic corresponding to eth has autoneg off. root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 Settings for enp6s0f1: Supported ports: [ FIBRE ] Supported link modes: 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full *Port: Direct Attach Copper* PHYAD: 0 Transceiver: internal *Auto-negotiation: off* Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-relay:~/gnxi/perf_testing/r230# On r740, autoneg is on. It is copper. root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 Settings for eno3: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full *Port: Twisted Pair* PHYAD: 0 Transceiver: internal *Auto-negotiation: on* MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-lab:~/gnxi/perf_testing/r740/vpp# not clear if this plays a role or not. On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io wrote: > Restarting ixia controller does not help. We ended up with both ixia ports > having '!'. > > We are not sure how ixia port plays a role here. eth0 interfaces are the > interfaces connecting two servers, not to ixia. > > On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > >> Hi Chuan, >> >> >> >> Could you please try to reset the ixia controller connected to port 4? >> >> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, >> I suspect the ixia port. >> >> >> >> -- >> >> Regards, >> >> Balaji. >> >> >> >> >> >> *From: *Chuan Han >> *Date: *Thursday, October 17, 2019 at 11:09 AM >> *To: *"Balaji Venkatraman (balajiv)" >> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi >> gounder , Jerry Cen >> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >> >> >> >> Yes. It is unidirectional stream from port 1 to port 4. >> >> >> >> Another engineer, Nambi, configured ixia. What he showed me yesterday is >> that xia port connected to port 1 is green and good. ixia port connected to >> port 4 is green but has a red exclamation mark, which means ping does not >> work. >> >> >> >> We also found eth0 on R230 is down shown by "show hardware eth0" command. >> However "show int" shows it is up. >> >> >> >> >> >> vpp# sh hardware-interfaces eth0 >> NameIdx Link Hardware >> eth0 2down eth0 >> Link speed: unknown >> Ethernet address b4:96:91:23:1e:d6 >> Intel 82599 >> carrier down >> flags: admin-up promisc pmd rx-ip4-cksum >> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) >> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) >> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 >> max rx packet len: 15872 >> promiscuous: unicast on all-multicast on >> vlan offload: strip off filter off qinq off >> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >>macsec-strip vlan-filter vlan-extend jumbo-frame >> scatter >>security keep-crc >> rx offload active: ipv4-cksum >> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >> sctp-cksum >>tcp-tso macsec-insert multi-segs security >> tx offload active: none >> rss avail:
Re: [vpp-dev] Basic l2 bridging does not work
>2->3->4->ixia? > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 30920 <<< packets are received on port 3 > rx > bytes 3679480 > tx > packets 30919 > tx > bytes 3679361 > drops > 30920 <<< all dropped at port 3 > > tx-error 3 > local0 0 down 0/0/0/0 > > > > On sh error logs on R 230 we see > > 1 ethernet-input l3 mac mismatch <<<< > 3 eth1-output interface is down > 30922 eth0-output interface is down > > > > > > Do u see the arp getting resolved on ixia? The mac on ixia at port with > 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at > both ends? > > > > > > -- > > Regards, > > Balaji. > > > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, October 17, 2019 at 9:59 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > It seems R740 vpp works fine. All packets coming from port 1 go to port > 2. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about > down interface. However, show command shows interfaces are up. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 3
Re: [vpp-dev] Basic l2 bridging does not work
/0/0/0 > > > > On sh error logs on R 230 we see > > 1 ethernet-input l3 mac mismatch <<<< > 3 eth1-output interface is down > 30922 eth0-output interface is down > > > > > > Do u see the arp getting resolved on ixia? The mac on ixia at port with > 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at > both ends? > > > > > > -- > > Regards, > > Balaji. > > > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, October 17, 2019 at 9:59 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > It seems R740 vpp works fine. All packets coming from port 1 go to port > 2. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about > down interface. However, show command shows interfaces are up. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 30920 > rx > bytes 3679480 > tx > packets 30919 > tx > bytes 3679361 > drops > 30920 > > tx-error 3 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 2llc-input unknown llc ssap/dsap > 61846l2-output L2 output packets > 61846l2-learnL2 learn packets > 2l2-learnL2 learn misses > 61846l2-inputL2 input packets > 61846l2-floodL2 flood packets > 1 ethernet-input l3 mac mismatch > 3 eth1-output interface is down > 30922 eth0-output interface is down > vpp# > > > > Not sure how to check mac issues. Can you explain a bit more? He
Re: [vpp-dev] Basic l2 bridging does not work
On R230, we have the following. Not sure why eth0 is down. I used the same setup for L3 routing measurement. Everything worked fine. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 *carrier down <= How can this be done? * flags: admin-up promisc pmd rx-ip4-cksum rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec rx frames ok 32770 rx bytes ok 3899630 extended stats: rx good packets 32770 rx good bytes 3899630 rx q0packets 32770 rx q0bytes 3899630 rx size 65 to 127 packets32770 rx multicast packets 32770 rx total packets 32770 rx total bytes 3899630 vpp# On Thu, Oct 17, 2019 at 10:47 AM Damjan Marion wrote: > > > On 17 Oct 2019, at 09:59, Chuan Han wrote: > > It seems R740 vpp works fine. All packets coming from port 1 go to port 2. > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about > down interface. However, show command shows interfaces are up. > > > Can you capture "show hardware eth0" ? > > -- > Damjan > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14205): https://lists.fd.io/g/vpp-dev/message/14205 Mute This Topic: https://lists.fd.io/mt/34655826/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Basic l2 bridging does not work
IXIA | > > | | > > | | > > +---^-+ > > |172.16.1.1/24 | > 172.16.1.2/24 > > | | > > | | > > |eth0 | eth0 > > +---v-+++---+ > > | 1 ||4 | > > | ||| > > | ||| > > | ||| > > | |eth1 eth1 || > > |VPP1 2 +> 3VPP 2 | > > | ||| > > | ||| > > | ||| > > | ||| > > +-+++ > > R 740 R 230 > > > > > > Might help if you could check if the packet counts at ingress (port 1) & > egress (port 2) match. Similarly 3 & 4. And the mac entries seen on both > vpp(s). ARP req/rep tracing might also help. > > > > > > /- > > Balaji > > > > > > > > > > *From: * on behalf of "Damjan Marion via Lists.Fd.Io" > > *Reply-To: *"dmar...@me.com" > *Date: *Wednesday, October 16, 2019 at 5:12 PM > *To: *"chuan...@google.com" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > > > On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io < > chuanhan=google@lists.fd.io> wrote: > > > > Hi, vpp experts, > > > > We are trying to make basic l2 bridge works within vpp. > > > > We have two servers: r230 and r740, each of which has two phy nics. Two > servers are connected via cable. On each server, we bring these two nics > into the same vpp instance and put them into the same l2 bridge. We tried > sending traffic using ixia. However, ixia shows ping does not work. > > > > I attached the topology, vpp conf files, startup conf file, and logs. > > > > Please advise where we could make it wrong. > > > > Thanks. > > Chuan > > startup.cfg> bridge.pdf>-=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189 > Mute This Topic: https://lists.fd.io/mt/34655826/675642 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com] > -=-=-=-=-=-=-=-=-=-=-=- > > > > On the 1st look everything look ok including the packet trace. > > Can you try to clear counters* and enable packet trace on both instances. > > Then send known number of packets and find put where drop happens by > looking into same outputs you already shared. > > > > * "clear int", "clear run", "clear trace" > > > > -- > Damjan > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14202): https://lists.fd.io/g/vpp-dev/message/14202 Mute This Topic: https://lists.fd.io/mt/34655826/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Basic l2 bridging does not work
Hi, vpp experts, We are trying to make basic l2 bridge works within vpp. We have two servers: r230 and r740, each of which has two phy nics. Two servers are connected via cable. On each server, we bring these two nics into the same vpp instance and put them into the same l2 bridge. We tried sending traffic using ixia. However, ixia shows ping does not work. I attached the topology, vpp conf files, startup conf file, and logs. Please advise where we could make it wrong. Thanks. Chuan r230 vpp.conf Description: Binary data r740 vpp.conf Description: Binary data r230 vpp startup.cfg Description: Binary data r740 vpp startup.cfg Description: Binary data vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 624 rx bytes 73430 tx packets10 tx bytes1190 eth1 1 up 9000/0/0/0 rx packets10 rx bytes1190 tx packets 624 tx bytes 73430 local00 down 0/0/0/0 vpp# sh error CountNode Reason 636l2-output L2 output packets 636l2-learnL2 learn packets
Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
Hi, Neale/vpp experts, Can you help check why the receiving side drops all the incoming pkts because of unknown ip protocol? I looked at TestIpsecGreTebIfEsp, but had no clue how it is mapped to cli commands. I am new to vpp. Thanks. Chuan On Fri, Oct 4, 2019 at 11:41 AM Chuan Han via Lists.Fd.Io wrote: > Thanks for helping. > > I removed spd configs on both sides, but still no luck. I am pinging from > r230 side. > > It seems r230 is able to sending ping pkts over dpdk interface. However, > on r740 side, gre0 interface drops all of them. See the attached updated > cfg files and log files for more details. > > IPSec: remote:10.10.10.11 spi:255129 (0x0003e499) seq 418 > 00:06:52:367944: esp4-decrypt-tun > esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 418 sa-seq 0 sa-seq-hi > 0 > 00:06:52:367948: ip4-input-no-checksum > GRE: 10.10.10.11 -> 10.10.10.10 > tos 0x00, ttl 254, length 66, checksum 0x9464 > fragment id 0x > GRE teb > 00:06:52:367948: ip4-not-enabled > GRE: 10.10.10.11 -> 10.10.10.10 > tos 0x00, ttl 254, length 66, checksum 0x9464 > fragment id 0x > GRE teb > 00:06:52:367948: error-drop > rx:gre0 > 00:06:52:367949: drop > ip4-input: unknown ip protocol > > > On Fri, Oct 4, 2019 at 8:39 AM Neale Ranns (nranns) > wrote: > >> >> >> Hi Chuan, >> >> >> >> Please remove the SPD config. For tunnels all packets that ingress/egress >> the tunnel are decrypted/encrypted, so no policy is required. The presence >> of the SPD on the ingress eth0 link could be why it’s not working. >> >> Please provide packet traces when you are reporting packet loss problems, >> it helps us debug. >> >> >> >> For reference the setup for GRE TEB IPSec can be found in the python UT >> TestIpsecGreTebIfEsp. >> >> >> >> Regards, >> >> neale >> >> >> >> >> >> *From: * on behalf of "Chuan Han via Lists.Fd.Io" >> >> *Reply to: *"chuan...@google.com" >> *Date: *Friday 4 October 2019 at 02:15 >> *To: *"John Lo (loj)" >> *Cc: *"vpp-dev@lists.fd.io" >> *Subject: *Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 >> >> >> >> Hi, >> >> >> >> Thanks for information. >> >> >> >> I am trying to configure l2 gre over ipsec transport mode. >> >> >> >> Here are my startup.cfg files. Can you help check if my configuration is >> correct or not? >> >> >> >> r230 and r740 are two servers which are directly connected. >> >> >> >> eth0 is the phy nic. host-veth1 is one endpoint of veth pair. the other >> end is connected to a network namespace with ip address 172.16.1.2. >> >> >> >> From the network namespace, I cannot ping the other end 172.16.1.1. >> >> >> >> On r230, I can see unknown ip protocol errors. >> >> vpp# sh errors >>CountNode Reason >> 5null-node blackholed packets >> 5 ipsec4-output-feature IPSec policy (no match) >> 1esp4-decrypt-tunESP pkts received >> 1ipsec4-tun-inputgood packets received >> 1 ipsec4-input-feature IPSEC pkts received >> 1ip4-input unknown ip protocol >>592gre-encap GRE output packets >> encapsulated >>592 ipsec4-output-feature IPSec policy bypass >>592esp4-encrypt-tunESP pkts received >>592l2-output L2 output packets >>592l2-learnL2 learn packets >> 1l2-learnL2 learn misses >>592l2-inputL2 input packets >>592l2-floodL2 flood packets >> vpp# sh int >> Name IdxState MTU (L3/IP4/IP6/MPLS) >> Counter Count >> eth0 1 up 9000/0/0/0 rx >> packets 1 >> rx >> bytes 166 >> tx >> packets 592 >>
Re: [vpp-dev] How to configure 256 bit crypto algorithm for ipsec
A11E51E5B111 is from one of the online examples for gcm 256. 2b7e151628aed2a6abf7158809cf4f3d2b7e151628aed2a6abf7158809cf4f3d works. Thanks for catching the mistakes. On Sun, Oct 6, 2019 at 6:28 PM Christian Hopps wrote: > So you had: crypto-key 2b7e151628aed2a6abf7158809cf4f3d > Now you "doubled" it and got: crypto-key A11E51E5B111 > > ? :) > > Try crypto-key > 2b7e151628aed2a6abf7158809cf4f3d2b7e151628aed2a6abf7158809cf4f3d > > A 128 bit algorithm needs a 16 byte key (128b=16B) a 265 bit algorithm > needs a 32B key (256b=32B) > > Thanks, > Chris. > > > On Oct 6, 2019, at 6:57 PM, Chuan Han wrote: > > > > double key size does not work. > > > > ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst > 10.10.10.11 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 > > ipsec sa add 2 spi 255129 esp tunnel-src 10.10.10.11 tunnel-dst > 10.10.10.10 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 > > > > I got the following errors: > > > > 000:41:02.7 --master-lcore 2 > > host-veth1 > > ipsec sa: failed > > > > The full config is as follows: > > > > set int state eth0 up > > set int ip address eth0 10.10.10.10/24 > > > > set int promiscuous on eth0 > > > > set ip arp eth0 10.10.10.11 b4:96:91:23:1e:d6 > > > > create host-interface name veth1 > > set int state host-veth1 up > > set int ip address host-veth1 172.16.1.1/24 > > set ip arp host-veth1 172.16.1.2 d6:4b:87:30:6a:60 > > > > > > ip route add 172.16.2.2/24 via 10.10.10.11 eth0 > > > > > > ipsec spd add 1 > > set interface ipsec spd eth0 1 > > > > ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst > 10.10.10.11 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 > > ipsec sa add 2 spi 255129 esp tunnel-src 10.10.10.11 tunnel-dst > 10.10.10.10 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 > > > > ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass > local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range > 0.0.0.0-255.255.255.255 > > ipsec policy add spd 1 inbound priority 90 protocol 50 action bypass > local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range > 0.0.0.0-255.255.255.255 > > > > ipsec policy add spd 1 priority 10 inbound action protect sa 2 > local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range > 172.16.2.1-172.16.2.255 > > ipsec policy add spd 1 priority 10 outbound action protect sa 1 > local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range > 172.16.2.1-172.16.2.255 > > > > On Fri, Oct 4, 2019 at 7:52 PM Christian Hopps > wrote: > > Double your key length. Probably better to switch to GCM (aes-gcm-256) > and drop the separate integrity algorithm too. > > > > Thanks, > > Chris. > > > > > On Oct 4, 2019, at 7:23 PM, Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > > > > > > Hi, > > > > > > I want to use 256 bit crypto algorithm in my ipsec config. > > > > > > I have something like this: > > > ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst > 10.10.10.11 crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg > aes-cbc-256 integ-key 6867666568676665686766656867666568676669 integ-alg > sha1-96 > > > > > > However, it gives me an error when I start vpp. > > > > > > ipsec sa: failed > > > > > > ipsec is not configured after the failure. > > > > > > vpp# sh ipsec all > > > spd 1 > > > ip4-outbound: > > > ip6-outbound: > > > ip4-inbound-protect: > > > ip6-inbound-protect: > > > ip4-inbound-bypass: > > > ip6-inbound-bypass: > > > SPD Bindings: > > > 1 -> eth0 > > > Tunnel interfaces > > > vpp# > > > > > > When I change 256 to 128, everything works fine. Does this mean vpp > ipsec only supports 128 ciphers? Or, I made some stupid mistakes? > > > > > > If I want to configure 256 bit ciphers, what shall I do? > > > > > > I attached the bad cfg file with 256 bit cipher, and good cfg file > with 128 bit cipher. > > > > > > Thanks. > > > Chuan > > > -=-=-=-=-=-=-=-=-=-=-=- > > > Links: You receive all messages sent to this group. > > > > > > View/Reply Online (#14124): > https://lists.fd.io/g/vpp-dev/message/14124 > > > Mute This Topic: https://lists.fd.io/mt/34400077/1826170 > > > Group Owner: vpp-dev+ow...@lists.fd.io > > > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org] > > > -=-=-=-=-=-=-=-=-=-=-=- > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14129): https://lists.fd.io/g/vpp-dev/message/14129 Mute This Topic: https://lists.fd.io/mt/34400077/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] How to configure 256 bit crypto algorithm for ipsec
double key size does not work. ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst 10.10.10.11 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 ipsec sa add 2 spi 255129 esp tunnel-src 10.10.10.11 tunnel-dst 10.10.10.10 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 I got the following errors: 000:41:02.7 --master-lcore 2 host-veth1 ipsec sa: failed The full config is as follows: set int state eth0 up set int ip address eth0 10.10.10.10/24 set int promiscuous on eth0 set ip arp eth0 10.10.10.11 b4:96:91:23:1e:d6 create host-interface name veth1 set int state host-veth1 up set int ip address host-veth1 172.16.1.1/24 set ip arp host-veth1 172.16.1.2 d6:4b:87:30:6a:60 ip route add 172.16.2.2/24 via 10.10.10.11 eth0 ipsec spd add 1 set interface ipsec spd eth0 1 ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst 10.10.10.11 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 ipsec sa add 2 spi 255129 esp tunnel-src 10.10.10.11 tunnel-dst 10.10.10.10 crypto-key A11E51E5B111 crypto-alg aes-gcm-256 ipsec policy add spd 1 outbound priority 90 protocol 50 action bypass local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range 0.0.0.0-255.255.255.255 ipsec policy add spd 1 inbound priority 90 protocol 50 action bypass local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range 0.0.0.0-255.255.255.255 ipsec policy add spd 1 priority 10 inbound action protect sa 2 local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range 172.16.2.1-172.16.2.255 ipsec policy add spd 1 priority 10 outbound action protect sa 1 local-ip-range 0.0.0.0-255.255.255.255 remote-ip-range 172.16.2.1-172.16.2.255 On Fri, Oct 4, 2019 at 7:52 PM Christian Hopps wrote: > Double your key length. Probably better to switch to GCM (aes-gcm-256) and > drop the separate integrity algorithm too. > > Thanks, > Chris. > > > On Oct 4, 2019, at 7:23 PM, Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > > > > Hi, > > > > I want to use 256 bit crypto algorithm in my ipsec config. > > > > I have something like this: > > ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst > 10.10.10.11 crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg > aes-cbc-256 integ-key 6867666568676665686766656867666568676669 integ-alg > sha1-96 > > > > However, it gives me an error when I start vpp. > > > > ipsec sa: failed > > > > ipsec is not configured after the failure. > > > > vpp# sh ipsec all > > spd 1 > > ip4-outbound: > > ip6-outbound: > > ip4-inbound-protect: > > ip6-inbound-protect: > > ip4-inbound-bypass: > > ip6-inbound-bypass: > > SPD Bindings: > > 1 -> eth0 > > Tunnel interfaces > > vpp# > > > > When I change 256 to 128, everything works fine. Does this mean vpp > ipsec only supports 128 ciphers? Or, I made some stupid mistakes? > > > > If I want to configure 256 bit ciphers, what shall I do? > > > > I attached the bad cfg file with 256 bit cipher, and good cfg file with > 128 bit cipher. > > > > Thanks. > > Chuan > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > > > View/Reply Online (#14124): https://lists.fd.io/g/vpp-dev/message/14124 > > Mute This Topic: https://lists.fd.io/mt/34400077/1826170 > > Group Owner: vpp-dev+ow...@lists.fd.io > > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org] > > -=-=-=-=-=-=-=-=-=-=-=- > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14127): https://lists.fd.io/g/vpp-dev/message/14127 Mute This Topic: https://lists.fd.io/mt/34400077/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] How to configure 256 bit crypto algorithm for ipsec
Hi, I want to use 256 bit crypto algorithm in my ipsec config. I have something like this: ipsec sa add 1 spi 255128 esp tunnel-src 10.10.10.10 tunnel-dst 10.10.10.11 crypto-key 2b7e151628aed2a6abf7158809cf4f3d crypto-alg aes-cbc-256 integ-key 6867666568676665686766656867666568676669 integ-alg sha1-96 However, it gives me an error when I start vpp. ipsec sa: failed ipsec is not configured after the failure. vpp# sh ipsec all spd 1 ip4-outbound: ip6-outbound: ip4-inbound-protect: ip6-inbound-protect: ip4-inbound-bypass: ip6-inbound-bypass: SPD Bindings: 1 -> eth0 Tunnel interfaces vpp# When I change 256 to 128, everything works fine. Does this mean vpp ipsec only supports 128 ciphers? Or, I made some stupid mistakes? If I want to configure 256 bit ciphers, what shall I do? I attached the bad cfg file with 256 bit cipher, and good cfg file with 128 bit cipher. Thanks. Chuan bad.cfg Description: Binary data good.cfg Description: Binary data -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14124): https://lists.fd.io/g/vpp-dev/message/14124 Mute This Topic: https://lists.fd.io/mt/34400077/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
Thanks for helping. I removed spd configs on both sides, but still no luck. I am pinging from r230 side. It seems r230 is able to sending ping pkts over dpdk interface. However, on r740 side, gre0 interface drops all of them. See the attached updated cfg files and log files for more details. IPSec: remote:10.10.10.11 spi:255129 (0x0003e499) seq 418 00:06:52:367944: esp4-decrypt-tun esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 418 sa-seq 0 sa-seq-hi 0 00:06:52:367948: ip4-input-no-checksum GRE: 10.10.10.11 -> 10.10.10.10 tos 0x00, ttl 254, length 66, checksum 0x9464 fragment id 0x GRE teb 00:06:52:367948: ip4-not-enabled GRE: 10.10.10.11 -> 10.10.10.10 tos 0x00, ttl 254, length 66, checksum 0x9464 fragment id 0x GRE teb 00:06:52:367948: error-drop rx:gre0 00:06:52:367949: drop ip4-input: unknown ip protocol On Fri, Oct 4, 2019 at 8:39 AM Neale Ranns (nranns) wrote: > > > Hi Chuan, > > > > Please remove the SPD config. For tunnels all packets that ingress/egress > the tunnel are decrypted/encrypted, so no policy is required. The presence > of the SPD on the ingress eth0 link could be why it’s not working. > > Please provide packet traces when you are reporting packet loss problems, > it helps us debug. > > > > For reference the setup for GRE TEB IPSec can be found in the python UT > TestIpsecGreTebIfEsp. > > > > Regards, > > neale > > > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply to: *"chuan...@google.com" > *Date: *Friday 4 October 2019 at 02:15 > *To: *"John Lo (loj)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 > > > > Hi, > > > > Thanks for information. > > > > I am trying to configure l2 gre over ipsec transport mode. > > > > Here are my startup.cfg files. Can you help check if my configuration is > correct or not? > > > > r230 and r740 are two servers which are directly connected. > > > > eth0 is the phy nic. host-veth1 is one endpoint of veth pair. the other > end is connected to a network namespace with ip address 172.16.1.2. > > > > From the network namespace, I cannot ping the other end 172.16.1.1. > > > > On r230, I can see unknown ip protocol errors. > > vpp# sh errors >CountNode Reason > 5null-node blackholed packets > 5 ipsec4-output-feature IPSec policy (no match) > 1esp4-decrypt-tunESP pkts received > 1ipsec4-tun-inputgood packets received > 1 ipsec4-input-feature IPSEC pkts received > 1ip4-input unknown ip protocol >592gre-encap GRE output packets > encapsulated >592 ipsec4-output-feature IPSec policy bypass >592esp4-encrypt-tunESP pkts received >592l2-output L2 output packets >592l2-learnL2 learn packets > 1l2-learnL2 learn misses >592l2-inputL2 input packets >592l2-floodL2 flood packets > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 1 up 9000/0/0/0 rx > packets 1 > rx > bytes 166 > tx > packets 592 > tx > bytes 88816 > drops > 5 > ip4 > 1 > > rx-error 1 > gre0 3 up 9000/0/0/0 drops > 1 > ip4 > 1 > host-veth12 up 9000/0/0/0 rx > packets 592 > rx > bytes 24892 > local00 down 0/0/0/0 > vpp# sh errors >
Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
592esp4-decrypt-tunESP pkts received 592ipsec4-tun-inputgood packets received 592 ipsec4-input-feature IPSEC pkts received 592ip4-input unknown ip protocol 1gre-encap GRE output packets encapsulated 1 ipsec4-output-feature IPSec policy bypass 1esp4-encrypt-tunESP pkts received 1l2-output L2 output packets 1l2-learnL2 learn packets 1l2-learnL2 learn misses 1l2-inputL2 input packets 1l2-floodL2 flood packets vpp# On Wed, Oct 2, 2019 at 9:13 AM John Lo (loj) wrote: > To create GRE tunnel in L2 mode, you can add “teb” keyword in the create > CLI which makes the GRE tunnel work in transparent ethernet bridging mode: > > > > vpp# create gre ? > > create gre tunnelcreate gre tunnel src > dst [instance ] [outer-fib-id ] [*teb* | erspan > ] [del] > > > > In theory, a GRE tunnel can be configured with IPSec, as described by > Neale, irrespective of it being in teb mode or not. Neale, please correct > me if it is not the case. > > > > Regards, > > John > > > > *From:* vpp-dev@lists.fd.io *On Behalf Of *Chuan > Han via Lists.Fd.Io > *Sent:* Wednesday, October 02, 2019 11:32 AM > *To:* Neale Ranns (nranns) > *Cc:* vpp-dev@lists.fd.io > *Subject:* Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 > > > > Gre is l3 in this case. Right? This limits the possible use cases. > > > > Is there any plan to support l2 gre over ipsec transport mode? It seems > vpp 17 support s this feature. Not sure why it is dropped in 19. > > > > On Wed, Oct 2, 2019, 12:18 AM Neale Ranns (nranns) > wrote: > > > Hi Chuan, > > IPSec and GRE is supported using the tunnel protection mechanism : > https://wiki.fd.io/view/VPP/IPSec > > GRE over IPSec is only support when the SA is in tunnel mode. This means > there is a double encap of the IP header ; once by the SA (in tunnel mode) > and once by the tunnel itself. (Which has always been the case in VPP). > > Example config follows : > > DBGvpp# ipsec sa add 20 spi 200 crypto-key > 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src > 10.10.10.10 tunnel-dst 10.10.10.11 > DBGvpp# ipsec sa add 30 spi 300 crypto-key > 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src > 10.10.10.11 tunnel-dst 10.10.10.10 > DBGvpp# create gre tunnel src 10.10.10.10 dst 10.10.10.11 > gre0 > DBGvpp# ipsec tunnel protect gre0 sa-in 20 sa-out 30 > DBGvpp# sh ipsec protect > gre0 >output-sa: > [1] sa 30 (0x1e) spi 300 (0x012c) protocol:esp flags:[tunnel ] >input-sa: > [0] sa 20 (0x14) spi 200 (0x00c8) protocol:esp flags:[tunnel > Protect ] > > Regards, > neale > > > From: on behalf of "Chuan Han via Lists.Fd.Io" > > Reply to: "chuan...@google.com" > Date: Wednesday 2 October 2019 at 02:08 > To: "vpp-dev@lists.fd.io" > Cc: "vpp-dev@lists.fd.io" > Subject: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 > > Hi, vpp experts, > > I am trying to configure l2 gre over ipsec. I followed the steps here: > https://docs.fd.io/vpp/16.12/ipsec_gre_doc.html > > I hit the following error: > create ipsec: unknown input `gre tunnel src 10.10.10.10 dst...' > > My vpp version is v19.08.1-release > > It seems on this version the "create ipsec gre tunnel" command does not > work. If so, is there any other way of configuring l2 gre over ipsec in > 19.08? > > Please advise. > > Thanks. > Chuan > > r740.cfg Description: Binary data r230.cfg Description: Binary data -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14112): https://lists.fd.io/g/vpp-dev/message/14112 Mute This Topic: https://lists.fd.io/mt/34364734/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
Gre is l3 in this case. Right? This limits the possible use cases. Is there any plan to support l2 gre over ipsec transport mode? It seems vpp 17 support s this feature. Not sure why it is dropped in 19. On Wed, Oct 2, 2019, 12:18 AM Neale Ranns (nranns) wrote: > > Hi Chuan, > > IPSec and GRE is supported using the tunnel protection mechanism : > https://wiki.fd.io/view/VPP/IPSec > > GRE over IPSec is only support when the SA is in tunnel mode. This means > there is a double encap of the IP header ; once by the SA (in tunnel mode) > and once by the tunnel itself. (Which has always been the case in VPP). > > Example config follows : > > DBGvpp# ipsec sa add 20 spi 200 crypto-key > 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src > 10.10.10.10 tunnel-dst 10.10.10.11 > DBGvpp# ipsec sa add 30 spi 300 crypto-key > 6541686776336961656264656f6f6579 crypto-alg aes-cbc-128 tunnel-src > 10.10.10.11 tunnel-dst 10.10.10.10 > DBGvpp# create gre tunnel src 10.10.10.10 dst 10.10.10.11 > gre0 > DBGvpp# ipsec tunnel protect gre0 sa-in 20 sa-out 30 > DBGvpp# sh ipsec protect > gre0 >output-sa: > [1] sa 30 (0x1e) spi 300 (0x012c) protocol:esp flags:[tunnel ] >input-sa: > [0] sa 20 (0x14) spi 200 (0x00c8) protocol:esp flags:[tunnel > Protect ] > > Regards, > neale > > > From: on behalf of "Chuan Han via Lists.Fd.Io" > > Reply to: "chuan...@google.com" > Date: Wednesday 2 October 2019 at 02:08 > To: "vpp-dev@lists.fd.io" > Cc: "vpp-dev@lists.fd.io" > Subject: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08 > > Hi, vpp experts, > > I am trying to configure l2 gre over ipsec. I followed the steps here: > https://docs.fd.io/vpp/16.12/ipsec_gre_doc.html > > I hit the following error: > create ipsec: unknown input `gre tunnel src 10.10.10.10 dst...' > > My vpp version is v19.08.1-release > > It seems on this version the "create ipsec gre tunnel" command does not > work. If so, is there any other way of configuring l2 gre over ipsec in > 19.08? > > Please advise. > > Thanks. > Chuan > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14099): https://lists.fd.io/g/vpp-dev/message/14099 Mute This Topic: https://lists.fd.io/mt/34364734/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
Hi, vpp experts, I am trying to configure l2 gre over ipsec. I followed the steps here: https://docs.fd.io/vpp/16.12/ipsec_gre_doc.html I hit the following error: create ipsec: unknown input `gre tunnel src 10.10.10.10 dst...' My vpp version is v19.08.1-release It seems on this version the "create ipsec gre tunnel" command does not work. If so, is there any other way of configuring l2 gre over ipsec in 19.08? Please advise. Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14097): https://lists.fd.io/g/vpp-dev/message/14097 Mute This Topic: https://lists.fd.io/mt/34364734/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
