date:20210312

Re: [vpp-dev] #vpp #vpp-dev

2021-03-12 Thread Mrityunjay Kumar

Hi Nikhil
Share me all CLI commands which you have triggered to vpp. I am sure you
forgot to set your interface to your IP table.

*"set interface ip table  "*

Use this and enjoy the weekend

*//MJ*







*Regards*,
Mrityunjay Kumar.
Mobile: +91 - 9731528504



On Thu, Mar 11, 2021 at 11:43 PM nikhil subhedar 
wrote:

> Hi All,
>
> Today i found a strange thing on my  POD on which VPP is running.  Can
> anyone please shed some light on this?
> Thanks.
> *Config:*
>
> 1) I created a loopback interface on VPP using confd CLI. on fib-index 1
> *loop2 (up):*
>
> *  L3 50.50.50.50/32  ip4 table-id 1 fib-idx 1*Also
> , on the top of this i  am having physical/ connected interface.
>
>
>
>
>
> *VirtualFuncEthernet0/6/0.900 (up):  L3 20.20.146.226/24
>  ip4 table-id 1 fib-idx 12) *On ubuntu VM i have
> created a loopback,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *lo:mobile: flags=73  mtu 65536inet
> 60.60.60.60  netmask 255.255.255.255loop  txqueuelen 1000  (Local
> Loopback)And i have a connected interface ens5.900:
> flags=4163  mtu 1500inet
> 20.20.146.216 route on VM.root@vmsrvrlnx-strongswan-216:~# route -nKernel
> IP routing tableDestination Gateway Genmask Flags
> Metric RefUse Iface0.0.0.0 10.163.64.1 0.0.0.0
> UG0  00 ens32.1.75.00.0.0.0 255.255.255.252
> U 0  00 gre110.163.64.0 0.0.0.0 255.255.224.0
> U 0  00 ens320.20.146.0 0.0.0.0 255.255.255.0
> U 0  00 ens5.90050.50.50.50 20.20.146.226
> 255.255.255.255 UGH   0  00 ens5.900*
> 3) I am  trying to ping from VM to vpp.
> using command
>
> * ping 50.50.50.50 -I  ens5.900.*4)  This icmp packet is reached to VPP
> on fib index 1, but when VPP is trying to send the echo-reply it is using
> fib index 0  and because of this icmp reply packet
> is not reaching to my VM.
> Below is o/p of show trace command.
>
> Packet 1
>
> 03:50:52:603829: dpdk-input
>   VirtualFuncEthernet0/6/0 rx queue 0
>   buffer 0x4c2f16: current data 0, length 102, 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 102
> buf_len 2176, data_len 102, ol_flags 0x180, data_off 128, phys_addr
> 0x7b0bc600
> packet_type 0x591 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_ICMP (0x0500) ICMP packet
>   IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 900
>   ICMP: 20.20.146.216 -> 50.50.50.50
> tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
> fragment id 0xf1d0, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x4303
> 03:50:52:603840: ethernet-input
>   frame: flags 0x3, hw-if-index 3, sw-if-index 3
>   IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 900
> 03:50:52:603847: ip4-input
>   ICMP: 20.20.146.216 -> 50.50.50.50
> tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
> fragment id 0xf1d0, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x4303
> 03:50:52:603853: ip4-lookup
>   *fib* 1 dpo-idx 22 flow hash: 0x
>   ICMP: 20.20.146.216 -> 50.50.50.50
> tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
> fragment id 0xf1d0, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x4303
> 03:50:52:603857: ip4-local
> ICMP: 20.20.146.216 -> 50.50.50.50
>   tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
>
>
>
>  ICMP echo_request checksum 0x4303
> 03:50:52:603859: ip4-icmp-input
>   ICMP: 20.20.146.216 -> 50.50.50.50
> tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
> fragment id 0xf1d0, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x4303
> 03:50:52:603860: ip4-icmp-echo-request
>   ICMP: 20.20.146.216 -> 50.50.50.50
> tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
> fragment id 0xf1d0, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x4303
> 03:50:52:603863: ip4-load-balance
>   *fib* 0 dpo-idx 9 flow hash: 0x
>   ICMP: 50.50.50.50 -> 20.20.146.216
> tos 0x00, ttl 64, length 84, checksum 0x246c dscp CS0 ecn NON_ECN
> fragment id 0x0aed, flags DONT_FRAGMENT
>   ICMP echo_reply checksum 0x4b03
> 03:50:52:603865: ip4-rewrite
>   tx_sw_if_index 11 dpo-idx 9 : ipv4 via 20.20.146.216
> VirtualFuncEthernet0/6/0.900: mtu:9000 next:9
> fa163e084c1dfa163e78ca96810003840800 flow hash: 0x00
> 00
>   :
> fa163e084c1dfa163e78ca968100038408

Re: [vpp-dev] Unexpected behavior of Classifier

2021-03-12 Thread Benoit Ganne (bganne) via lists.fd.io

Hi Jerome,

Could you share a packet trace of a packet that is being classified but not 
correctly redirected? Eg. if you use dpdk:
~# vppctl clear trace
~# vppctl trace add dpdk-input 10

~# vppctl show trace

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of
> jerome.bay...@student.uliege.be
> Sent: vendredi 12 mars 2021 12:12
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Unexpected behavior of Classifier
> 
> Hello all,
> 
> I think I found a bug/ an unexpected behavior of the classifier when I use
> it for IOAM encapsulation/decapsulation.
> 
> Indeed, I used the classifier to select packets for IOAM encapsulation or
> decapsulation, as it is done in the example described here :
> 
> https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/exampl
> e/simple-ip6
> 
> More precisely, here are the commands we are interested in, when it comes
> to decapsulation :
> 
> classify table miss-next ip6-node ip6-lookup mask l3 ip6 dst
> classify session acl-hit-next ip6-node ip6-lookup table-index 0 match l3
> ip6 dst db03::02 ioam-decap test1
> set int input acl intfc host-l_c2 ip6-table 0
> set int input acl intfc host-l_c1 ip6-table 0
> 
> This set of commands (more specifically the "classify session" one) is
> supposed to set the value of the "vnet_buffer (b0)-
> >l2_classify.opaque_index" that will be checked in the
> "vnet/ip/ip6_forward.c" file, in the "ip6_hop_by_hop_node" node (at line
> 2666 for single loop implementation). The issue is that the value of the
> "opaque_index" does not seem to be set anymore when the check occurs,
> leading to no redirection of the packet towards the
> "ip6_pop_hop_by_hop_node" so no decapsulation of IOAM data as it should.
> To find the origin of the problem, I tried to trace the value of this
> "opaque_index" as the packet traverses different VPP nodes and I noticed
> the following :
> 
> It seems that the classifier does its job correctly and sets the
> "opaque_index" to a value that will make true the condition at line 2666
> in "ip6_forward.c". However, as I said here above, when it arrives at this
> condition, the "opaque_index" appears to be equal to a null value...
> 
> I was not able to find why it behaves like this, can someone try to help
> me to solve this issue ?
> 
> Thanks,
> 
> Jérôme

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18910): https://lists.fd.io/g/vpp-dev/message/18910
Mute This Topic: https://lists.fd.io/mt/81276451/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] crypto_sw_scheduler questions

2021-03-12 Thread G. Paul Ziemba


I'm trying out VPP native crypto in async mode and ran into a few
issues. I am using 20.09, but the parts below haven't changed in master.

Have I misunderstood the code? I hope someone could comment:

1. The first issue was that processed operations were not being dequeued.
   In crypto_sw_scheduler/main.c crypto_sw_scheduler_dequeue_aead()
   there is (some parts omitted for clarity):

 vec_foreach_index (i, cm->per_thread_data)
   {
  ptd = cm->per_thread_data + i;
  q = ptd->queues[async_op_id];
  f = crypto_sw_scheduler_get_pending_frame (q);
  if (f)
break;
}
  
ptd = cm->per_thread_data + vm->thread_index;
  
if (f)
  {
while (n_elts--)
  {
crypto_sw_scheduler_convert_aead (vm, ptd, fe, fe - f->elts, bi[0],
  sync_op_id, aad_len, tag_len);
bi++;
fe++;
  }
  
process_ops (vm, f, ptd->crypto_ops, &state);
  
f->state = state;
*enqueue_thread_idx = f->enqueue_thread_index;
  }
  
return crypto_sw_scheduler_get_completed_frame (ptd->queues[async_op_id]);
  }
  
  
  It seems to me that the last line should be:
  
return crypto_sw_scheduler_get_completed_frame (q);
  
  because we want to dequeue from the queue of the originating thread.


2. I made the above change locally, which led to the second issue:

  vnet/crypto/node.c crypto_dequeue_frame() calls
  vnet_crypto_async_free_frame() in the context of the worker thread
  (not the original enqueueing thread) and tries to free the spent
  frame (returned by crypto_sw_scheduler_dequeue_aead() above) back
  to the wrong per-thread pool.

  It looks to me as if enqueue_thread_idx is ignored by
  crypto_dequeue_frame() when instead it should be used somehow to
  free the frame back to the correct pool.


3. While looking at all the above, I noticed that all of the loops
   involving crypto_sw_scheduler_queue_t * q look like this:

  u32 tail = q->tail;
  u32 head = q->head;

  for (i = tail; i < head; i++)
{
  f = q->jobs[i & CRYPTO_SW_SCHEDULER_QUEUE_MASK];
  [... do stuff ...]
}

   It seems to me that these loops will not work correctly when
   head wraps.

Thanks for your comments.
-- 
G. Paul Ziemba
FreeBSD unix:
 6:26AM  up 43 days, 35 mins, 16 users, load averages: 1.13, 1.18, 1.16

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

2021-03-12 Thread Damjan Marion via lists.fd.io


Thanks, let me polish it a bit and will submit for review….

> On 12.03.2021., at 10:32, Andrew 👽 Yourtchenko  wrote:
> 
> +1, great idea!
> 
> --a
> 
>> On 11 Mar 2021, at 15:36, Damjan Marion via lists.fd.io 
>>  wrote:
>> 
>> 
>> 
>> Guys,
>> 
>> I found that having both global and thread data in vlib_main_t  is confusing 
>> to many people and also bug prone.
>> 
>> I wonder if there is sense in. moving global data to new vlib_global_main_t?
>> 
>> I submitted RFC patch and would like to hear what people think about that….
>> 
>> https://gerrit.fd.io/r/c/vpp/+/31623
>> 
>> Thanks,
>> 
>> Damjan
>> 
>> 
>> 
>> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18908): https://lists.fd.io/g/vpp-dev/message/18908
Mute This Topic: https://lists.fd.io/mt/81253828/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Unexpected behavior of Classifier

2021-03-12 Thread jerome . bayaux

Hello all, 

I think I found a bug/ an unexpected behavior of the classifier when I use it 
for IOAM encapsulation/decapsulation. 

Indeed, I used the classifier to select packets for IOAM encapsulation or 
decapsulation , as it is done in the example described here : 

[ 
https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/example/simple-ip6
 | 
https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/example/simple-ip6
 ] 

More precisely, here are the commands we are interested in, when it comes to 
decapsulation : 

classify table miss-next ip6-node ip6-lookup mask l3 ip6 dst 
classify session acl-hit-next ip6-node ip6-lookup table-index 0 match l3 ip6 
dst db03::02 ioam-decap test1 
set int input acl intfc host-l_c2 ip6-table 0 
set int input acl intfc host-l_c1 ip6-table 0 

This set of commands (more specifically the " classify session " one) is 
supposed to set the value of the " vnet_buffer (b0)->l2_classify.opaque_index " 
that will be checked in the " vnet/ip/ip6_forward.c " file, in the " 
ip6_hop_by_hop_node " node (at line 2666 for single loop implementation). The 
issue is that the value of the " opaque_index " does not seem to be set anymore 
when the check occurs, leading to no redirection of the packet towards the " 
ip6_pop_hop_by_hop_node " so no decapsulation of IOAM data as it should. To 
find the origin of the problem, I tried to trace the value of this " 
opaque_index " as the packet traverses different VPP nodes and I noticed the 
following : 

It seems that the classifier does its job correctly and sets the " opaque_index 
" to a value that will make true the condition at line 2666 in " ip6_forward.c 
". However, as I said here above, when it arrives at this condition, the " 
opaque_index " appears to be equal to a null value... 

I was not able to find why it behaves like this, can someone try to help me to 
solve this issue ? 

Thanks, 

Jérôme 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18907): https://lists.fd.io/g/vpp-dev/message/18907
Mute This Topic: https://lists.fd.io/mt/81276451/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 with FRR Bring-up - tap interface enable causing crash

2021-03-12 Thread Mohsen Meamarian

Hi ashish ,
I saw an email from you that you wrote about a problem with 
vnet_arp_set_ip4_over_ ethernet in vppsb source code . Do you find any solution 
for this ?

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

2021-03-12 Thread Andrew Yourtchenko

+1, great idea!

--a

> On 11 Mar 2021, at 15:36, Damjan Marion via lists.fd.io 
>  wrote:
> 
> 
> 
> Guys,
> 
> I found that having both global and thread data in vlib_main_t  is confusing 
> to many people and also bug prone.
> 
> I wonder if there is sense in. moving global data to new vlib_global_main_t?
> 
> I submitted RFC patch and would like to hear what people think about that….
> 
> https://gerrit.fd.io/r/c/vpp/+/31623
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> 

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

2021-03-12 Thread Ole Troan

> I found that having both global and thread data in vlib_main_t  is confusing 
> to many people and also bug prone.
> 
> I wonder if there is sense in. moving global data to new vlib_global_main_t?
> 
> I submitted RFC patch and would like to hear what people think about that….
> 
> https://gerrit.fd.io/r/c/vpp/+/31623

It's definitely been bug prone. Good idea!

Cheers,
Ole


signature.asc
Description: Message signed with OpenPGP

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

Re: [vpp-dev] Unexpected behavior of Classifier

[vpp-dev] crypto_sw_scheduler questions

Re: [vpp-dev] RFC: vlib_global_main_t

[vpp-dev] Unexpected behavior of Classifier

Re: [vpp-dev] VPP with FRR Bring-up - tap interface enable causing crash

Re: [vpp-dev] RFC: vlib_global_main_t

Re: [vpp-dev] RFC: vlib_global_main_t

8 matches

Site Navigation

Mail list logo

Footer information