[vpp-dev] VPP is not coming up

2021-03-22 Thread Vijay Kumar
Hi,

I was running VPP on my VM without any issues. But recently due to a lab
maintenance, the VM was powered off. But now I am not able to bring it up.
Getting the error "unknown input dpdk  dev :0b:00.0"

-- I have ensured the ethernet interface is set to DOWN so that VPP takes
control of it.
-- As shown below, I have ensured the ethernet port number/PCI number is
listed in the startup.conf file so that dpdk can start using the port


*dpdk {  dev :0b:00.0}*
-- I have also ensured the line having "*gid vpp"* is commented out in the
startup.conf. What else could I be missing.

root@ubuntu-10-37-3-75
:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin# ./vpp -c
../etc/vpp/startup.conf
vlib_call_all_config_functions: unknown input `dpdk  dev :0b:00.0 '



Regards

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18985): https://lists.fd.io/g/vpp-dev/message/18985
Mute This Topic: https://lists.fd.io/mt/81519523/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 is not coming up

2021-03-22 Thread chetan bhasin
Hi Vijay,

Have you modprobe uio and uio_pci_generic ?

kindly confirm the pci address of your nic again using ethtool -i

Please share what else is coming on the console.

Thanks,
Chetan

On Mon, Mar 22, 2021 at 1:58 PM Vijay Kumar  wrote:

> Hi,
>
> I was running VPP on my VM without any issues. But recently due to a lab
> maintenance, the VM was powered off. But now I am not able to bring it up.
> Getting the error "unknown input dpdk  dev :0b:00.0"
>
> -- I have ensured the ethernet interface is set to DOWN so that VPP takes
> control of it.
> -- As shown below, I have ensured the ethernet port number/PCI number is
> listed in the startup.conf file so that dpdk can start using the port
>
>
> *dpdk {  dev :0b:00.0}*
> -- I have also ensured the line having "*gid vpp"* is commented out in
> the startup.conf. What else could I be missing.
>
> root@ubuntu-10-37-3-75
> :~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin# ./vpp -c
> ../etc/vpp/startup.conf
> vlib_call_all_config_functions: unknown input `dpdk  dev :0b:00.0 '
>
>
>
> Regards
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18986): https://lists.fd.io/g/vpp-dev/message/18986
Mute This Topic: https://lists.fd.io/mt/81519523/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 is not coming up

2021-03-22 Thread Vijay Kumar
Hi Chetan,

I added the PCI address into the whitelist configuration of the startup.conf
Yes I did load both kernel modules: uio and pci_generic
Pls find the output that you asked for.

root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
lsmod | grep uio
igb_uio20480  0
uio_pci_generic16384  0
uio20480  2 igb_uio,uio_pci_generic

root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
ethtool -i ens192
driver: vmxnet3
version: 1.5.0.0-k-NAPI
firmware-version:
expansion-rom-version:
bus-info: :0b:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

On Mon, Mar 22, 2021 at 2:25 PM chetan bhasin 
wrote:

> Hi Vijay,
>
> Have you modprobe uio and uio_pci_generic ?
>
> kindly confirm the pci address of your nic again using ethtool -i
> 
> Please share what else is coming on the console.
>
> Thanks,
> Chetan
>
> On Mon, Mar 22, 2021 at 1:58 PM Vijay Kumar  wrote:
>
>> Hi,
>>
>> I was running VPP on my VM without any issues. But recently due to a lab
>> maintenance, the VM was powered off. But now I am not able to bring it up.
>> Getting the error "unknown input dpdk  dev :0b:00.0"
>>
>> -- I have ensured the ethernet interface is set to DOWN so that VPP takes
>> control of it.
>> -- As shown below, I have ensured the ethernet port number/PCI number is
>> listed in the startup.conf file so that dpdk can start using the port
>>
>>
>> *dpdk {  dev :0b:00.0}*
>> -- I have also ensured the line having "*gid vpp"* is commented out in
>> the startup.conf. What else could I be missing.
>>
>> root@ubuntu-10-37-3-75
>> :~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin# ./vpp -c
>> ../etc/vpp/startup.conf
>> vlib_call_all_config_functions: unknown input `dpdk  dev :0b:00.0 '
>>
>>
>>
>> Regards
>>
>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18987): https://lists.fd.io/g/vpp-dev/message/18987
Mute This Topic: https://lists.fd.io/mt/81519523/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 is not coming up

2021-03-22 Thread Nathan Skrzypczak
Hi Vijay,

Usually the `unknown input dpdk` comes from the dpdk plugin not being
loaded at startup. So either there is a
`plugins { plugin dpdk_plugin.so { disable } }` stanza that was added to
you config file - but VM restart wouldn't explain this.
Or vpp-ext-deps / e-build containing dpdk got out of sync with your vpp
build.

Anyway 'show log' would give more details on what's happening.
And you can try `dpkg -r vpp-ext-deps ; make install-ext-deps ; make
rebuild` to get a clean build

Cheers
-Nathan



Le lun. 22 mars 2021 à 11:09, Vijay Kumar  a écrit :

> Hi Chetan,
>
> I added the PCI address into the whitelist configuration of the
> startup.conf
> Yes I did load both kernel modules: uio and pci_generic
> Pls find the output that you asked for.
>
> root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
> lsmod | grep uio
> igb_uio20480  0
> uio_pci_generic16384  0
> uio20480  2 igb_uio,uio_pci_generic
>
> root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
> ethtool -i ens192
> driver: vmxnet3
> version: 1.5.0.0-k-NAPI
> firmware-version:
> expansion-rom-version:
> bus-info: :0b:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
> On Mon, Mar 22, 2021 at 2:25 PM chetan bhasin 
> wrote:
>
>> Hi Vijay,
>>
>> Have you modprobe uio and uio_pci_generic ?
>>
>> kindly confirm the pci address of your nic again using ethtool -i
>> 
>> Please share what else is coming on the console.
>>
>> Thanks,
>> Chetan
>>
>> On Mon, Mar 22, 2021 at 1:58 PM Vijay Kumar 
>> wrote:
>>
>>> Hi,
>>>
>>> I was running VPP on my VM without any issues. But recently due to a lab
>>> maintenance, the VM was powered off. But now I am not able to bring it up.
>>> Getting the error "unknown input dpdk  dev :0b:00.0"
>>>
>>> -- I have ensured the ethernet interface is set to DOWN so that VPP
>>> takes control of it.
>>> -- As shown below, I have ensured the ethernet port number/PCI number is
>>> listed in the startup.conf file so that dpdk can start using the port
>>>
>>>
>>> *dpdk {  dev :0b:00.0}*
>>> -- I have also ensured the line having "*gid vpp"* is commented out in
>>> the startup.conf. What else could I be missing.
>>>
>>> root@ubuntu-10-37-3-75
>>> :~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin# ./vpp -c
>>> ../etc/vpp/startup.conf
>>> vlib_call_all_config_functions: unknown input `dpdk  dev :0b:00.0 '
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18988): https://lists.fd.io/g/vpp-dev/message/18988
Mute This Topic: https://lists.fd.io/mt/81519523/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] Update VPP IPsec examples

2021-03-22 Thread Benoit Ganne (bganne) via lists.fd.io
Also, Filip recently added more ikev2 docs (no GRE though): 
https://gerrit.fd.io/r/c/vpp/+/31414 see for example how to connect strongSwan 
"client" (initiator) to VPP: 
https://gerrit.fd.io/r/c/vpp/+/31414/2/docs/usecases/vpp_resp_sswan_init.md
It will show up in https://fd.io/docs/vpp/master/usecases/ next time it is 
rebuilt.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Andrew
> Yourtchenko
> Sent: vendredi 19 mars 2021 16:23
> To: Bjørn Vegard Larsen 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Update VPP IPsec examples
> 
> Hi Bjørn,
> 
> You can click on the top-right corner link “log in/register with Linux
> foundation ID”.
> 
> Once you have logged in, the wiki will become editable, so you can then do
> the adjustments to the content.
> 
> 
> --a
> 
> 
>   On 19 Mar 2021, at 09:22, Bjørn Vegard Larsen 
> wrote:
> 
> 
> 
>   
>   Hi,
> 
>   Could you add a Strongswan - VPP GRE over IPSec example on the wiki
> pages https://wiki.fd.io/view/VPP/IPSec_and_IKEv2#Prerequisite_2
> 
>   Note, Ubuntu 20.04 don´t support ipsec-tools, so Strongswan should
> use /etc/ipsec.conf and /etc/ipsec.secrets.
> 
>   Please also make examples with PSK and certificates.
> 
>   Best regards
>   Bjørn Vegard Larsen
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18989): https://lists.fd.io/g/vpp-dev/message/18989
Mute This Topic: https://lists.fd.io/mt/81450756/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] 40G Mellanox NIC not working

2021-03-22 Thread Benoit Ganne (bganne) via lists.fd.io
Hi,

If possible, the preferred way of using Mellanox NICs with VPP is with the 
native rdma driver instead of DPDK: 
https://docs.fd.io/vpp/21.06/df/d0e/rdma_doc.html
Otherwise you can always try to rebuild DPDK with mlx5 support, see 
https://git.fd.io/vpp/tree/build/external/packages/dpdk.mk#n18
The instructions you refer to is out-of-date.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of  ??
> Sent: vendredi 19 mars 2021 15:25
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] 40G Mellanox NIC not working
> 
> Hi,
> 
> VPP doesn't see mellanox 40G card.
> I've try to compile based on summary instruction
> https://lists.fd.io/g/vpp-dev/message/16211
> But after recompilation it doesn't see NIC in show interface
> 
> The main problem that there is no message in log like for intel card
> /usr/bin/vpp[394111]: pci: Skipping PCI device :02:00.0 as host
> interface eno1 is up
> 
> 
> $ cat /etc/os-release
> NAME="Ubuntu"
> VERSION="20.04.2 LTS (Focal Fossa)
> 
> # lshw -c network -businfo
> Bus info  Device Class  Description
> ===
> pci@:01:00.0  enp1s0f0   networkMT27700 Family [ConnectX-4]
> pci@:01:00.1  enp1s0f1   networkMT27700 Family [ConnectX-4]
> 
> # lsmod | grep mlx
> mlx5_ib   331776  0
> ib_uverbs 147456  1 mlx5_ib
> ib_core   352256  2 ib_uverbs,mlx5_ib
> mlx5_core1105920  1 mlx5_ib
> pci_hyperv_intf16384  1 mlx5_core
> mlxfw  32768  1 mlx5_core
> tls90112  1 mlx5_core
> 
> Building:
> 
> # git clone https://gerrit.fd.io/r/vpp
> # make install-dep
> 
> 
> After building vpp, I try to run
> $ sudo ifconfig enp1s0f1 down
> $ sudo LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/login/origin/build-
> root/install-vpp_debug-native/external/lib/ ./build-root/build-vpp_debug-
> native/vpp/bin/vpp -c
> ./build-root/install-vpp_debug-native/vpp/etc/vpp/startup.conf
> 
> Then go to console
> $ sudo LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/login/origin/build-
> root/install-vpp_debug-native/external/lib/ ./build-root/build-vpp_debug-
> native/vpp/bin/vppctl
> DBGvpp# show interface
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> local00 down  0/0/0/0
> DBGvpp# show pci
> Address  Sock VID:PID Link SpeedDriver  Product Name
> Vital Product Data
> :01:00.0   0  15b3:1013   8.0 GT/s x8   mlx5_core   CX414A -
> ConnectX-4 QSFP28  PN: MCX414A-GCAT
> 
> EC: AG
> 
> SN: MT2002X14876
> 
> V0: 0x 50 43 49 65 47 65 6e 33 ...
> 
> RV: 0x 28 00 00
> :01:00.1   0  15b3:1013   8.0 GT/s x8   mlx5_core   CX414A -
> ConnectX-4 QSFP28  PN: MCX414A-GCAT
> 
> EC: AG
> 
> SN: MT2002X14876
> 
> V0: 0x 50 43 49 65 47 65 6e 33 ...
> 
> RV: 0x 28 00 00
> As you can see there is no 40G interface in VPP.
> Maybe be there is some specific prerequisites, OS or driver version?


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18990): https://lists.fd.io/g/vpp-dev/message/18990
Mute This Topic: https://lists.fd.io/mt/81456458/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] IPSec proposal to improve "ipsec4-output-feature" node performance

2021-03-22 Thread Govindarajan Mohandoss
Hi Neale,
   I have completed the flow cache implementation for SPD lookup in IPv4/IPSec 
outbound direction.  Performance numbers are good with null encryption on 
single core/64B @ MRR. Please provide your comments.
https://gerrit.fd.io/r/c/vpp/+/31694

  Summary of flow cache implementation:

  1.  Based on Bihash without collision handling. This will avoid the overhead 
to recycle/age out old entries in flow cache. Whenever collision occurs, the 
old entry will be overwritten by new entry in data plane.
  2.  Size of flow cache is fixed. Currently set to handle 1 million flows. 
This can be made configurable as a next step.
  3.  Whenever an SPD rule is added/deleted from the control plane, flow cache 
entries are flushed from control plane. Before flushing, the data plane is put 
in fall back mode to bypass flow cache and do linear lookup. Flushing is done 
only after the inflight packets are sent out from all the worker cores.

Thanks
Govind

From: vpp-dev@lists.fd.io  On Behalf Of Govindarajan 
Mohandoss via lists.fd.io
Sent: Wednesday, March 3, 2021 7:55 PM
To: Neale Ranns ; vpp-dev 
Cc: nd ; nd 
Subject: Re: [vpp-dev] IPSec proposal to improve "ipsec4-output-feature" node 
performance

Hi Neale,
  Thank you for your comments. I know you would have thought about it already. 
I can work with you to implement the right solution to improve performance.
  Please see my response inline.

Thanks
Govind

From: Neale Ranns mailto:ne...@graphiant.com>>
Sent: Wednesday, March 3, 2021 8:45 AM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: nd mailto:n...@arm.com>>
Subject: Re: [vpp-dev] IPSec proposal to improve "ipsec4-output-feature" node 
performance


Hi Govind,

Flow caches always perform well, but they are more difficult to use than they 
first appear. Consider asking yourself these questions:
1 - how many entries can the cache contain?
>> This can be made configurable as per the system need. By default, we can 
>> allocate the hash table size to hold 10K entries.

2 - what do you do when the cache is full? How do you age or recycle old flows?
>> If the flow cache is implemented using a hash table without collision 
>> handling, then age out mechanism is not needed. Whenever a collision occurs,
old entry can be overwritten with new entry. Worst case will be 255 overwrites, 
if all the 256 packets per batch result in same hash value.

3 - how do you flush the cache when the policy set changes?
>> Whenever an SPD rule is deleted, the flow cache will be flushed completely 
>> in the control plane. An IPSec module level flag will be introduced and set 
>> by the
control plane to put the data plane in fall back mode to use linear search. 
This flag will be reset once the control plane flush the flow cache and delete 
the
SPD rule from SPD table. Also, data plane will not add new entry into the flow 
cache during SPD rule deletion.
I have added this logic in my prototype. Please find the changes attached.

In general, what is the rate at which an SPD rule will be deleted by the 
application ? If the deletion rate is low, then we can take the hit of flushing 
the flow cache in control plane.

I had considered in the past changing an SPD definition to use IP subnets 
(rather than IP ranges) and then re-use the tuple-sort/merge algorithm used by 
ACLs. This approach would not need you to answer the awkward questions about a 
cache and it would break the linear dependent lookup (it has other 
dependencies, but they are much better). Two reasons I didn't do this 1) no 
time 2) ipsec is a vnet component and ACL is a plugin, a vnet -> plugin 
dependency is a no-no. If you're lucky some-one might volunteer to make IPsec a 
plugin and this will go away...
>> Please correct my understanding.
In this method, the mask have to be created for every SPD rule and stored in an 
array. On every packet arrival, the mask will be picked up in linear fashion 
and hash will
be computed based on mask and packet header fields. Then bihash will be looked 
up with that hash value. This reduces the overhead of comparing the ranges 
during
linear search. But the mask lookup is still linear. I agree that there will be 
a performance improvement because the range comparison is avoided for every SPD 
entry.
Is there a way to implement it without creating IPSec plugin and without 
depending on ACL plugin ?


/neale


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Govindarajan 
Mohandoss via lists.fd.io 
mailto:Govindarajan.mohandoss=arm@lists.fd.io>>
Date: Wednesday, 3 March 2021 at 06:57
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: nd mailto:n...@arm.com>>
Subject: [vpp-dev] IPSec proposal to improve "ipsec4-output-feature" node 
performance
Hi Neale,
   I am working on optimizing "ipsec4-output-feature" node on ARM based 
systems. Towards that, I saw an opportunity to supplement SPD table lookup 
(linear search) with Bihash 

[vpp-dev] GRE-over-IPSec fails

2021-03-22 Thread Vijay Kumar
Hi,

I am trying a test case where-in I have an GRE P2MP (mGRE) tunnel on the
VPP. The GRE peer is a strongswan VM that hosts both the GRE tunnel and
IPSec SA. When I started ping traffic from SS, the traffic is dropped at
esp4-decrypt-tun graph node due to integrity check failure.

Has any one tested GRE-over-IPSec recently? If so can you pls share me a
working config. If not please review the below config and let me know if I
missed something

*NOTE: -*
If I have run only GRE test case, traffic is fine (no IPSec enabled). If I
have only IPSec configured but no GRE then also traffic is fine.

I am facing this issue only when both GRE and IPSec are enabled at the same
time.

Topology and config at SS and VPP
==
Strongswan VM (20.20.99.215, gre peer 2.2.2.1, loopback 7.7.7.7)
<=>VPP cluster (20.20.99.99, gre peer 2.2.2.2, loopback
8.8.8.8)
IPSec SA Traffic Selector (7.7.7.7/32 to 8.8.8.8/32)
ike=aes256-sha256-modp2048!
esp=aes256-sha1-noesn!


Below is the VPP trace

03:20:34:670201: dpdk-input
  VirtualFuncEthernet0/7/0 rx queue 0
  buffer 0x4c6b91: current data 0, length 170, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x100
   ext-hdr-valid
   l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 170
buf_len 2176, data_len 170, ol_flags 0x180, data_off 128, phys_addr
0xa3dae4c0
packet_type 0x691 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without
extension headers
  RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet
  IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
  IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
fragment id 0xef9e, flags DONT_FRAGMENT
03:20:34:670208: ethernet-input
  frame: flags 0x3, hw-if-index 3, sw-if-index 3
  IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
03:20:34:670214: ip4-input
  IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
fragment id 0xef9e, flags DONT_FRAGMENT
03:20:34:670218: ip4-lookup
  fib 1 dpo-idx 21 flow hash: 0x
  IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
fragment id 0xef9e, flags DONT_FRAGMENT
03:20:34:670220: ip4-local
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
  tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
  fragment id 0xef9e, flags DONT_FRAGMENT
03:20:34:670222: ipsec4-tun-input
  IPSec: remote:20.20.99.215 spi:305419897 (0x12345679) seq 40 sa 1
03:20:34:670225: esp4-decrypt-tun
  esp: crypto aes-cbc-256 integrity sha1-96 pkt-seq 40 sa-seq 0 sa-seq-hi 0
03:20:34:670241: ip4-drop
IP6_NONXT: 242.163.36.86 -> 70.168.225.19
  version 1, header length 8
  tos 0x34, ttl 245, length 22137, checksum 0x5156 (should be 0x972a)
dscp unknown ecn NON_ECN
  fragment id 0x offset 320
03:20:34:670243: error-drop
  rx:ipip0
03:20:34:670244: drop
  esp4-decrypt-tun: Integrity check failed


vpp# show node counters
   CountNode  Reason
25esp4-encrypt-tunESP pkts received
   213   memif-input  not ip packet
 3   dpdk-input   no error
   136arp-reply   ARP replies sent
 3arp-reply   IP4 source address not
local to subnet
 1   gre4-input   no error
   213 ip4-udp-lookup No error
42esp4-decrypt-tunESP pkts received
42esp4-decrypt-tunIntegrity check failed
25esp4-encrypt-tunESP pkts received
42ipsec4-tun-inputgood packets received
11ip4-local   ip4 source lookup miss
 3ip4-local   unknown ip protocol
 3 ethernet-input unknown vlan
vpp#

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18992): https://lists.fd.io/g/vpp-dev/message/18992
Mute This Topic: https://lists.fd.io/mt/81531694/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 is not coming up

2021-03-22 Thread Vijay Kumar
Hi Nathan,

Even with the rebuild based on the steps you provided, the result is same.



Regards.


On Mon, 22 Mar 2021, 19:01 Nathan Skrzypczak, 
wrote:

> Hi Vijay,
>
> Usually the `unknown input dpdk` comes from the dpdk plugin not being
> loaded at startup. So either there is a
> `plugins { plugin dpdk_plugin.so { disable } }` stanza that was added to
> you config file - but VM restart wouldn't explain this.
> Or vpp-ext-deps / e-build containing dpdk got out of sync with your vpp
> build.
>
> Anyway 'show log' would give more details on what's happening.
> And you can try `dpkg -r vpp-ext-deps ; make install-ext-deps ; make
> rebuild` to get a clean build
>
> Cheers
> -Nathan
>
>
>
> Le lun. 22 mars 2021 à 11:09, Vijay Kumar  a
> écrit :
>
>> Hi Chetan,
>>
>> I added the PCI address into the whitelist configuration of the
>> startup.conf
>> Yes I did load both kernel modules: uio and pci_generic
>> Pls find the output that you asked for.
>>
>> root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
>> lsmod | grep uio
>> igb_uio20480  0
>> uio_pci_generic16384  0
>> uio20480  2 igb_uio,uio_pci_generic
>>
>> root@ubuntu-10-37-3-75:~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin#
>> ethtool -i ens192
>> driver: vmxnet3
>> version: 1.5.0.0-k-NAPI
>> firmware-version:
>> expansion-rom-version:
>> bus-info: :0b:00.0
>> supports-statistics: yes
>> supports-test: no
>> supports-eeprom-access: no
>> supports-register-dump: yes
>> supports-priv-flags: no
>>
>> On Mon, Mar 22, 2021 at 2:25 PM chetan bhasin 
>> wrote:
>>
>>> Hi Vijay,
>>>
>>> Have you modprobe uio and uio_pci_generic ?
>>>
>>> kindly confirm the pci address of your nic again using ethtool -i
>>> 
>>> Please share what else is coming on the console.
>>>
>>> Thanks,
>>> Chetan
>>>
>>> On Mon, Mar 22, 2021 at 1:58 PM Vijay Kumar 
>>> wrote:
>>>
 Hi,

 I was running VPP on my VM without any issues. But recently due to a
 lab maintenance, the VM was powered off. But now I am not able to bring it
 up.
 Getting the error "unknown input dpdk  dev :0b:00.0"

 -- I have ensured the ethernet interface is set to DOWN so that VPP
 takes control of it.
 -- As shown below, I have ensured the ethernet port number/PCI number
 is listed in the startup.conf file so that dpdk can start using the port


 *dpdk {  dev :0b:00.0}*
 -- I have also ensured the line having "*gid vpp"* is commented out in
 the startup.conf. What else could I be missing.

 root@ubuntu-10-37-3-75
 :~/VPP-NEW/vpp/build-root/install-vpp_debug-native/vpp/bin# ./vpp -c
 ../etc/vpp/startup.conf
 vlib_call_all_config_functions: unknown input `dpdk  dev :0b:00.0 '



 Regards




>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18993): https://lists.fd.io/g/vpp-dev/message/18993
Mute This Topic: https://lists.fd.io/mt/81519523/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] GRE-over-IPSec fails

2021-03-22 Thread Vijay Kumar
Hi Neale,

Could you let me know if you faced the mentioned problem anytime?

For me only IPSec works fine, Only GRE also works fine. But when I
configure GRE-over-IPSec, the traffic is dropped at *esp4-decrypt-tun* due
to integrity check failure.
As there are two logical interfaces created at VPP (ipip0 and gre0) for the
peer, do I need to take care of something specially? As far as I know, I
haven't missed any config.


Regards,
Vijay Kumar N

On Mon, Mar 22, 2021 at 11:31 PM Vijay Kumar via lists.fd.io  wrote:

> Hi,
>
> I am trying a test case where-in I have an GRE P2MP (mGRE) tunnel on the
> VPP. The GRE peer is a strongswan VM that hosts both the GRE tunnel and
> IPSec SA. When I started ping traffic from SS, the traffic is dropped at
> esp4-decrypt-tun graph node due to integrity check failure.
>
> Has any one tested GRE-over-IPSec recently? If so can you pls share me a
> working config. If not please review the below config and let me know if I
> missed something
>
> *NOTE: -*
> If I have run only GRE test case, traffic is fine (no IPSec enabled). If I
> have only IPSec configured but no GRE then also traffic is fine.
>
> I am facing this issue only when both GRE and IPSec are enabled at the
> same time.
>
> Topology and config at SS and VPP
> ==
> Strongswan VM (20.20.99.215, gre peer 2.2.2.1, loopback 7.7.7.7)
> <=>VPP cluster (20.20.99.99, gre peer 2.2.2.2, loopback
> 8.8.8.8)
> IPSec SA Traffic Selector (7.7.7.7/32 to 8.8.8.8/32)
> ike=aes256-sha256-modp2048!
> esp=aes256-sha1-noesn!
>
>
> Below is the VPP trace
> 
> 03:20:34:670201: dpdk-input
>   VirtualFuncEthernet0/7/0 rx queue 0
>   buffer 0x4c6b91: current data 0, length 170, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x100
>ext-hdr-valid
>l4-cksum-computed l4-cksum-correct
>   PKT MBUF: port 0, nb_segs 1, pkt_len 170
> buf_len 2176, data_len 170, ol_flags 0x180, data_off 128, phys_addr
> 0xa3dae4c0
> packet_type 0x691 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without
> extension headers
>   RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet
>   IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
>   IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670208: ethernet-input
>   frame: flags 0x3, hw-if-index 3, sw-if-index 3
>   IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
> 03:20:34:670214: ip4-input
>   IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670218: ip4-lookup
>   fib 1 dpo-idx 21 flow hash: 0x
>   IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
> tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
> fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670220: ip4-local
> IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
>   tos 0x00, ttl 64, length 152, checksum 0x5b33 dscp CS0 ecn NON_ECN
>   fragment id 0xef9e, flags DONT_FRAGMENT
> 03:20:34:670222: ipsec4-tun-input
>   IPSec: remote:20.20.99.215 spi:305419897 (0x12345679) seq 40 sa 1
> 03:20:34:670225: esp4-decrypt-tun
>   esp: crypto aes-cbc-256 integrity sha1-96 pkt-seq 40 sa-seq 0 sa-seq-hi 0
> 03:20:34:670241: ip4-drop
> IP6_NONXT: 242.163.36.86 -> 70.168.225.19
>   version 1, header length 8
>   tos 0x34, ttl 245, length 22137, checksum 0x5156 (should be 0x972a)
> dscp unknown ecn NON_ECN
>   fragment id 0x offset 320
> 03:20:34:670243: error-drop
>   rx:ipip0
> 03:20:34:670244: drop
>   esp4-decrypt-tun: Integrity check failed
>
>
> vpp# show node counters
>CountNode  Reason
> 25esp4-encrypt-tunESP pkts received
>213   memif-input  not ip packet
>  3   dpdk-input   no error
>136arp-reply   ARP replies sent
>  3arp-reply   IP4 source address not
> local to subnet
>  1   gre4-input   no error
>213 ip4-udp-lookup No error
> 42esp4-decrypt-tunESP pkts received
> 42esp4-decrypt-tunIntegrity check failed
> 25esp4-encrypt-tunESP pkts received
> 42ipsec4-tun-inputgood packets received
> 11ip4-

Re: [vpp-dev] GRE-over-IPSec fails

2021-03-22 Thread Vijay Kumar
Hi Xingyeping,

My customer use case if gre-over-ipsec but we want to use mGRE only because
we don't want to create too many GRE tunnels which is the case if there are
too many peers connecting with VPP (for a GRE p2p case)

I saw your example, it looks like you are using GRE with manually keyed
IPSec (ipsec sad and spd are manually chosen). But in our case we are
using IKEv2 stack which creates SA.

Did you test GRE-over-IPSec using IKEv2 way of SA creation and not manual
IPSec SA?




On Tue, Mar 23, 2021 at 11:49 AM xingyep...@163.com 
wrote:

> Hi:
> I use Gre over IPsec(not mgre),it's ok。There is only gre tunnel, no ipip
> tunnel:
> vpp1 :
>
> set interface state GigabitEthernet0/b/0 up
>
> set interface ip address GigabitEthernet0/b/0 10.1.1.3/24
>
> create gre tunnel src 10.1.1.3 dst 10.1.1.4
>
> set interface state gre0 up
>
> set interface unnumbered gre0 use GigabitEthernet0/b/0
>
>
>
> create host-interface name vpp1out
>
> set interface state host-vpp1out up
>
> set interface ip address host-vpp1out 10.10.1.2/24
>
> ip route add 10.10.2.0/24 via gre0
>
>
>
> ipsec sa add 10 spi 2001 esp crypto-alg aes-cbc-128 crypto-key
> 4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key
> 4339314b55523947594d6d3547666b45764e6a58
>
> ipsec tunnel protect gre0 sa-in 10 sa-out 10
>
>
> vpp2:
>
> create host-interface name vpp2out
>
> set interface state host-vpp2out up
>
> set interface ip address host-vpp2out 10.10.2.2/24
>
>
>
> set interface state GigabitEthernet0/b/0 up
>
> set interface ip address GigabitEthernet0/b/0 10.1.1.4/24
>
> create gre tunnel src 10.1.1.4 dst 10.1.1.3
>
> set interface state gre0 up
>
> set interface unnumbered gre0 use GigabitEthernet0/b/0
>
> ip route add 10.10.1.0/24 via gre0
>
>
>
> ipsec sa add 10 spi 2001 esp crypto-alg aes-cbc-128 crypto-key
> 4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key
> 4339314b55523947594d6d3547666b45764e6a58
>
> ipsec tunnel protect gre0 sa-in 10 sa-out 10
>
> *Router-A Trace:*
>
>
>
>
>
> DBGvpp# trace add af-packet-input 10
>
>
> DBGvpp# show trace
>
> --- Start of thread 0 vpp_main ---
>
> No packets in trace buffer
>
> --- Start of thread 1 vpp_wk_0 ---
>
> No packets in trace buffer
>
> --- Start of thread 2 vpp_wk_1 ---
>
> Packet 1
>
>
>
> 00:33:03:857975: af-packet-input
>
>   af_packet: hw_if_index 5 next-index 4
>
> tpacket2_hdr:
>
>   status 0x2001 len 98 snaplen 98 mac 66 net 80
>
>   sec 0x60137ac5 nsec 0x230ab2d4 vlan 0 vlan_tpid 0
>
> 00:33:03:858004: ethernet-input
>
>   IP4: 6a:2a:e7:05:19:8e -> 02:fe:ec:52:c8:c8
>
> 00:33:03:858012: ip4-input
>
>   ICMP: 10.10.1.1 -> 10.10.2.1
>
> tos 0x00, ttl 64, length 84, checksum 0xb6b9 dscp CS0 ecn NON_ECN
>
> fragment id 0x6cda, flags DONT_FRAGMENT
>
>   ICMP echo_request checksum 0x9bb3
>
> 00:33:03:858024: ip4-lookup
>
>   fib 0 dpo-idx 7 flow hash: 0x
>
>   ICMP: 10.10.1.1 -> 10.10.2.1
>
> tos 0x00, ttl 64, length 84, checksum 0xb6b9 dscp CS0 ecn NON_ECN
>
> fragment id 0x6cda, flags DONT_FRAGMENT
>
>   ICMP echo_request checksum 0x9bb3
>
> 00:33:03:858055: ip4-midchain
>
>   tx_sw_if_index 4 dpo-idx 7 : ipv4 via 0.0.0.0 gre0: mtu:9000 next:7
> 4500fe2fa6c60a0101030a0101040800
>
>   stacked-on entry:21:
>
> [@2]: ipv4 via 10.1.1.4 GigabitEthernet0/b/0: mtu:9000 next:4
> 525400280679525400b1983f0800 flow hash: 0x
>
>   :
> 456cfe2fa65a0a0101030a010104080045546cda4000
>
>   0020:
> 3f01b7b90a0a01010a0a020108009bb37da50001c57a13603ef80800
>
>   0040:
> 101112131415161718191a1b1c1d1e1f202122232425262728292a2b
>
>   0060:
> 2c2d2e2f3031323334353637
>
>   0080:
> 
>
>   00a0:
> 
>
>   00c0:
> 
>
>   00e0: 
>
> 00:33:03:858064: esp4-encrypt-tun
>
>   esp: sa-index 0 spi 2001 (0x07d1) seq 4 sa-seq-hi 0 crypto
> aes-cbc-128 integrity sha1-96
>
> 00:33:03:858088: adj-midchain-tx
>
>   adj-midchain:[7]:ipv4 via 0.0.0.0 gre0: mtu:9000 next:7
> 4500fe2fa6c60a0101030a0101040800
>
>   stacked-on entry:21:
>
> [@2]: ipv4 via 10.1.1.4 GigabitEthernet0/b/0: mtu:9000 next:4
> 525400280679525400b1983f0800
>
> 00:33:03:858090: ip4-rewrite
>
>   tx_sw_if_index 3 dpo-idx 4 : ipv4 via 10.1.1.4 GigabitEthernet0/b/0:
> mtu:9000 next:4 525400280679525400b1983f0800 flow hash: 0x
>
>   :
> 525400280679525400b1983f08004598fd32a72b0a0101030a01
>
>   0020:
> 010407d1000499d0d3e1eb5b77d7d723d0fd448e8023ee2ab5786d20
>
>   0040:
> de9c788457480384ca18cf23a242192a9d83c87be32f1ddefad5e74b1fa5c08f
>
>   0060:
> 6f9fa089