Hi Venkat,

Cool, thanks a lot! 

So the first issue is acl-related,
you can try out the https://gerrit.fd.io/r/c/vpp/+/28251

ACL plugin uses its own heap to get better isolation 
from the rest of the world, but the lookup 
contexts are sitting in the global heap -
 and accidentally it was being  created in the wrong heap,
thus tripping up the assertion later on.  (This is why you 
saw the unintended “either-or” behavior).

The second issue seems to me to be purely in ABF code, 
so Neale will need to take a look.

--a

>> On 12 Aug 2020, at 02:39, Venkat <venkat.dabb...@gmail.com> wrote:
> 
> Andrew/Neale, 
> 
> We spent some more time today trying to root cause the issues. The following 
> are the VPP backtraces for the respective issues. We tried this on VPP 
> version 20.05
> Hope this gives some clues towards fixing the issue. 
> 
> Issue 1 Test Scenario:  ABF and ACL attached to the same interface
> 
> it is getting stuck at the spin_acquire_lock()
>
>  Thread 1 (Thread 0x7ffff7fe0c40 (LWP 28339)):
>  #0  0x00007ffff43cff37 in sched_yield () at 
> ../sysdeps/unix/syscall-template.S:78
>  #1  0x00007ffff51beb87 in spin_acquire_lock (sl=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:468
>  #2  mspace_malloc (msp=0x7fffb42bc010, bytes=92) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4371
>  #3  0x00007ffff51beaa9 in mspace_get_aligned (msp=0x7fffb42bc010, 
> n_user_data_bytes=92, align=16, 
>      align_offset=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4254
>  #4  0x00007ffff521cd57 in clib_mem_alloc_aligned_at_offset (size=72, 
> align=8, align_offset=8, os_out_of_memory_on_failure=1)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:142
>  #5  vec_resize_allocate_memory (v=<optimized out>, length_increment=64, 
> data_bytes=72, header_bytes=<optimized out>, 
>      data_align=8, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67
>  #6  0x00007ffff51fb670 in _vec_resize_inline (v=0x0, 
> length_increment=<optimized out>, data_bytes=<optimized out>, 
>      header_bytes=<optimized out>, data_align=<optimized out>, 
> numa_id=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>  #7  serialize_vector_write (m=<optimized out>, s=0x7fffb5809980)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:903
>  #8  0x00007ffff51fb2b7 in serialize_write_not_inline (m=0x7fffb5809920, 
> s=0x7fffb5809980, n_bytes_to_write=4, 
>      flags=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:729
>  #9  0x00007ffff7bc77dc in serialize_stream_read_write 
> (header=0x7fffb5809920, s=<optimized out>, n_bytes=4, flags=2)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:140
>  #10 serialize_get (m=0x7fffb5809920, n_bytes=4) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:180
>  #11 serialize_integer (m=0x7fffb5809920, n_bytes=4, x=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:187
>  #12 vl_api_serialize_message_table (am=0x7ffff7dd3c28 <api_global_main>, 
> vector=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:212
>  #13 0x00007ffff7bc7cb6 in vl_msg_api_trace_save (am=0x7fffb42bc010, 
> which=<optimized out>, fp=0x555555986b80)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:261
>  #14 0x00007ffff7bc989d in vl_msg_api_post_mortem_dump ()
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:944
>  #15 0x000055555555c756 in os_panic () at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:364
>  #16 0x00007ffff51c0afb in mspace_free (msp=0x7fffb42bc010, mem=<optimized 
> out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4548
>  #17 0x00007ffff521cf0b in clib_mem_free (p=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:224
>  #18 vec_resize_allocate_memory (v=<optimized out>, 
> length_increment=<optimized out>, data_bytes=<optimized out>, 
>      header_bytes=56, data_align=<optimized out>, numa_id=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:119
>  #19 0x00007fffb3e1f4e0 in _vec_resize_inline (v=<optimized out>, 
> length_increment=1, data_bytes=24, header_bytes=48, 
>      data_align=8, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>  #20 acl_plugin_get_lookup_context_index (acl_user_id=1, val1=1, val2=0)
>      at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/acl/lookup_context.c:112
>  #21 0x00007fffb40b4ab5 in abf_itf_attach (fproto=FIB_PROTOCOL_IP4, 
> policy_id=<optimized out>, priority=0, 
>      sw_if_index=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:227
>  #22 0x00007fffb40b7327 in abf_itf_attach_cmd (vm=<optimized out>, 
> input=<optimized out>, cmd=<optimized out>)
>      at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:397
>  #23 0x00007ffff5d6f752 in vlib_cli_dispatch_sub_commands (vm=0x7ffff6012500 
> <vlib_global_main>, cm=<optimized out>, 
>      input=0x7fffb5809f60, parent_command_index=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:568
>  #24 0x00007ffff5d6f669 in vlib_cli_dispatch_sub_commands (vm=0x7ffff6012500 
> <vlib_global_main>, 
>      cm=0x7ffff6012730 <vlib_global_main+560>, input=0x7fffb5809f60, 
> parent_command_index=<optimized out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:528
>  #25 0x00007ffff5d6edd0 in vlib_cli_input (vm=0x7ffff6012500 
> <vlib_global_main>, input=0x7fffb5809f60, 
>      function=<optimized out>, function_arg=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:667
>  #26 0x00007ffff5de8a3b in unix_cli_process_input (cm=<optimized out>, 
> cli_file_index=1)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2575
>  #27 unix_cli_process (vm=<optimized out>, rt=0x7fffb57c9000, f=<optimized 
> out>)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2691
>  #28 0x00007ffff5d98cb7 in vlib_process_bootstrap (_a=<optimized out>)
>  ---Type <return> to continue, or q <return> to quit---
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1502
>  #29 0x00007ffff51de3e4 in clib_calljmp () from 
> /usr/lib/x86_64-linux-gnu/libvppinfra.so.20.05
>  #30 0x00007fffb49102a0 in ?? ()
>  #31 0x00007ffff5d90934 in vlib_process_startup (vm=0x7ffff6012500 
> <vlib_global_main>, p=0x7fffb57c9000, f=0x0)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1524
>  #32 dispatch_process (vm=0x7ffff6012500 <vlib_global_main>, 
> p=0x7fffb57c9000, f=0x0, last_time_stamp=0)
>      at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1569
> 
> 
> For Issue 2 Test Scenario: Delete ABF Policy that doesn’t have forwarding Path
> 
> Thread 1 "vpp_main" received signal SIGABRT, Aborted.
> __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.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007ffff430c8b1 in __GI_abort () at abort.c:79
> #2  0x000055555555c760 in os_panic () at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:366
> #3  0x00007ffff521f163 in clib_mem_alloc_aligned_at_offset (size=17179869192, 
> align=8, align_offset=<optimized out>, 
>     os_out_of_memory_on_failure=1) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:147
> #4  vec_resize_allocate_memory (v=<optimized out>, 
> length_increment=4294967296, data_bytes=17179869192, 
>     header_bytes=<optimized out>, data_align=8, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67
> #5  0x00007ffff779a16e in _vec_resize_inline (v=<optimized out>, 
> length_increment=4294967296, data_bytes=<optimized out>, 
>     header_bytes=0, data_align=4, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
> #6  fib_path_list_copy_and_path_remove (orig_path_list_index=<optimized out>, 
> flags=<optimized out>, rpaths=0x0)
>     at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vnet/fib/fib_path_list.c:1112
> #7  0x00007fffb40b7b71 in abf_policy_delete (policy_id=<optimized out>, 
> rpaths=0x0)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_policy.c:209
> #8  0x00007fffb40b8121 in abf_policy_cmd (vm=0x7ffff6012500 
> <vlib_global_main>, main_input=<optimized out>, 
>     cmd=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_policy.c:304
> #9  0x00007ffff5d6f752 in vlib_cli_dispatch_sub_commands (vm=0x7ffff6012500 
> <vlib_global_main>, cm=<optimized out>, 
>     input=0x7fffb57b4f60, parent_command_index=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:568
> #10 0x00007ffff5d6f669 in vlib_cli_dispatch_sub_commands (vm=0x7ffff6012500 
> <vlib_global_main>, 
>     cm=0x7ffff6012730 <vlib_global_main+560>, input=0x7fffb57b4f60, 
> parent_command_index=<optimized out>)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:528
> #11 0x00007ffff5d6edd0 in vlib_cli_input (vm=0x7ffff6012500 
> <vlib_global_main>, input=0x7fffb57b4f60, 
>     function=<optimized out>, function_arg=<optimized out>) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:667
> #12 0x00007ffff5de8a3b in unix_cli_process_input (cm=<optimized out>, 
> cli_file_index=0)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2575
> #13 unix_cli_process (vm=<optimized out>, rt=0x7fffb5774000, f=<optimized 
> out>)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/unix/cli.c:2691
> #14 0x00007ffff5d98cb7 in vlib_process_bootstrap (_a=<optimized out>)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1502
> #15 0x00007ffff51de3e4 in clib_calljmp () from 
> /usr/lib/x86_64-linux-gnu/libvppinfra.so.20.05
> #16 0x00007fffb49102a0 in ?? ()
> #17 0x00007ffff5d90934 in vlib_process_startup (vm=0x7ffff6012500 
> <vlib_global_main>, p=0x7fffb5774000, f=0x0)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1524
> #18 dispatch_process (vm=0x7ffff6012500 <vlib_global_main>, p=0x7fffb5774000, 
> f=0x0, last_time_stamp=0)
>     at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/main.c:1569
> 
> 
> 
>> On Tue, Aug 11, 2020 at 9:46 AM Venkat via lists.fd.io 
>> <venkat.dabbara=gmail....@lists.fd.io> wrote:
>> Andres/Neale,
>> 
>> I confirm to see the same behavior when using ligato etcd proto models which 
>> I believe eventually calls APIs in vpp. 
>> Please let me know if you want me to do any further tests that would help 
>> you fix the issues.
>> 
>>> IMO it's reasonable to use ACL and ABF on the same interface as they 
>>> provide independent functions, especially when they are matching against 
>>> different criteria.
>> 
>> +1. Those two are orthogonal functions. ABF uses the acl as a service infra 
>> to select which traffic it deals with - but that’s it.
>> 
>> 
>> +1  [ VENKAT] I expected the same behavior but it doesn't look like it. 
>> 
>>> On Tue, Aug 11, 2020 at 9:33 AM Andrew 👽 Yourtchenko <ayour...@gmail.com> 
>>> wrote:
>>> 
>>> 
>>>>> On 11 Aug 2020, at 17:30, Neale Ranns (nranns) <nra...@cisco.com> wrote:
>>>> 
>>>> 
>>>> IMO it's reasonable to use ACL and ABF on the same interface as they 
>>>> provide independent functions, especially when they are matching against 
>>>> different criteria.
>>> 
>>> +1. Those two are orthogonal functions. ABF uses the acl as a service infra 
>>> to select which traffic it deals with - but that’s it.
>>> 
>>>> Re the debug CLI, it's often not robust to garbage input. If the API has 
>>>> the same problem though, I'll fix it.
>>> 
>>> BTW - I did mark ABF APIs as “in-progress”, as we discussed a few months 
>>> ago, so they are subject to changes. 
>>> 
>>> —a
>>> 
>>>> 
>>>> Neale
>>>> 
>>>> tpyed by my fat tumhbs
>>>> 
>>>> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Balaji 
>>>> Venkatraman via lists.fd.io <balajiv=cisco....@lists.fd.io>
>>>> Sent: Tuesday, August 11, 2020 4:08:56 PM
>>>> To: Venkat <venkat.dabb...@gmail.com>; Andrew 👽 Yourtchenko 
>>>> <ayour...@gmail.com>
>>>> Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
>>>> Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface
>>>>
>>>> Hi Venkat,
>>>> Ideally, we should not let ABF be configured if the interface is already 
>>>> tied to an ACL. Conversely, an ACL should be honored when the interface is 
>>>> tied to an ABF. Right? 
>>>> You might want to confirm how we handle the behavior from experts here.
>>>> BTW, the second scenario you seeing the crash..
>>>> Issue 2: Delete ABF Policy that doesn’t have forwarding Path
>>>> 
>>>> That is an interesting scenario. Shouldn’t ABF mandatorily have an 
>>>> underlying ACL with a forwarding path?
>>>> 
>>>> 
>>>> Thanks!
>>>> —
>>>> Regards,
>>>> Balaji.
>>>> 
>>>> Get Outlook for iOS
>>>> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Venkat 
>>>> <venkat.dabb...@gmail.com>
>>>> Sent: Monday, August 10, 2020 11:52:46 PM
>>>> To: Andrew 👽 Yourtchenko <ayour...@gmail.com>
>>>> Cc: Balaji Venkatraman (balajiv) <bala...@cisco.com>; vpp-dev@lists.fd.io 
>>>> <vpp-dev@lists.fd.io>
>>>> Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface
>>>>
>>>> Hi Andrew, 
>>>> 
>>>> Here are a couple of test scenarios where I observed vpp crash while 
>>>> experimenting with ABF configuration. 
>>>> I will find time to translate them to make test cases soon. 
>>>> Meanwhile here are the steps to reproduce the issues.
>>>> 
>>>>  Issues
>>>>  1: ABF and ACL attached to the same interface
>>>> 
>>>> 
>>>> In vpp VAT shell
>>>>  and configure bunch of ACL rules in a group
>>>> 
>>>> 
>>>> vat#
>>>>  acl_add_replace  ipv4 permit src 30.30.30.1/32 dst
>>>> 40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect src
>>>> 10.10.10.0/24, ipv4 permit+reflect src 
>>>> 20.20.20.0/24
>>>> vl_api_acl_add_replace_reply_t_handler:109:
>>>>  ACL index: 0
>>>> 
>>>> 
>>>> Attach ACL Group
>>>>  create above to lan interface
>>>> 
>>>> 
>>>> vat#
>>>>  acl_interface_set_acl_list sw_if_index 1 input 0
>>>> 
>>>> 
>>>> Following will be
>>>>  the state in vpp
>>>> 
>>>> 
>>>> DBGvpp#
>>>>  show version 
>>>> vpp
>>>>  v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
>>>> 21:10:49 UTC 2020
>>>> DBGvpp#
>>>> 
>>>> DBGvpp#
>>>>  show hardware-interfaces brief
>>>>               Name 
>>>>                Idx   Link  Hardware
>>>> lan 
>>>>                                1     up   lan
>>>>   Link
>>>>  speed: 10 Gbps
>>>> local0
>>>>                              0    down  local0
>>>>   Link
>>>>  speed: unknown
>>>> loop0 
>>>>                              3     up   loop0
>>>>   Link
>>>>  speed: unknown
>>>> loop1 
>>>>                              5     up   loop1
>>>>   Link
>>>>  speed: unknown
>>>> tap0
>>>>                                4     up   tap0
>>>>   Link
>>>>  speed: unknown
>>>> wan 
>>>>                                2     up   wan
>>>>   Link
>>>>  speed: 1 Gbps
>>>> 
>>>> DBGvpp#
>>>>  show acl-plugin acl 
>>>> acl-index
>>>>  0 count 3 tag {}
>>>>           0:
>>>>  ipv4 permit src 30.30.30.1/32 dst 
>>>> 40.40.40.1/32 proto 0 sport 1000 dport 1000
>>>>           1:
>>>>  ipv4 permit+reflect src 10.10.10.0/24 dst 
>>>> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>>>>           2:
>>>>  ipv4 permit+reflect src 20.20.20.0/24 dst 
>>>> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>>>>   applied
>>>>  inbound on sw_if_index: 1
>>>>   used
>>>>  in lookup context index: 0
>>>> 
>>>> DBGvpp#
>>>>  show acl-plugin interface 
>>>> sw_if_index
>>>>  0:
>>>> sw_if_index
>>>>  1:
>>>>   input
>>>>  acl(s): 0
>>>> DBGvpp#
>>>> 
>>>> 
>>>> Create another ACL
>>>>  for ABF configuration
>>>> 
>>>> 
>>>> vat#
>>>>  acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 17
>>>> vl_api_acl_add_replace_reply_t_handler:109:
>>>>  ACL index: 1
>>>> 
>>>> DBGvpp#
>>>>  show acl-plugin acl 
>>>> acl-index
>>>>  0 count 3 tag {}
>>>>           0:
>>>>  ipv4 permit src 30.30.30.1/32 dst 
>>>> 40.40.40.1/32 proto 0 sport 1000 dport 1000
>>>>           1:
>>>>  ipv4 permit+reflect src 10.10.10.0/24 dst 
>>>> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>>>>           2:
>>>>  ipv4 permit+reflect src 20.20.20.0/24 dst 
>>>> 0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535
>>>>   applied
>>>>  inbound on sw_if_index: 1
>>>>   used
>>>>  in lookup context index: 0
>>>> acl-index
>>>>  1 count 1 tag {}
>>>>           0:
>>>>  ipv4 permit src 11.11.11.0/24 dst 
>>>> 0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535
>>>> DBGvpp#
>>>> 
>>>> 
>>>> Configure ABF Policy
>>>>  referring to the above created ACL
>>>> 
>>>> 
>>>> DBGvpp#
>>>>  abf policy add id 100 acl 1 via 10.39.27.227 wan
>>>> 
>>>> DBGvpp#
>>>>  show abf policy 
>>>> abf:[0]:
>>>>  policy:100 acl:1
>>>>      path-list:[47]
>>>>  locks:1 flags:shared,no-uRPF, uRPF-list: None
>>>>       path:[47]
>>>>  pl-index:47 ip4 weight=1 pref=0 attached-nexthop:  oper-flags:resolved,
>>>>         10.39.27.227
>>>>  wan
>>>>       [@0]:
>>>>  ipv4 via 10.39.27.227 wan: mtu:9000 b496915808e1b49691591f610800
>>>> DBGvpp#
>>>>  show abf attach lan
>>>> DBGvpp#
>>>> 
>>>> 
>>>> Attach ABF Policy
>>>>  to the same interface as ACL Group 0 was attached. This will result in a 
>>>> vpp crash. 
>>>> 
>>>> 
>>>> DBGvpp#
>>>>  abf attach ip4 policy 100 priority 100 lan
>>>> 
>>>> 
>>>> 
>>>> Issue
>>>>  2: Delete ABF Policy that doesn’t have forwarding Path
>>>> 
>>>> 
>>>> Create another ACL
>>>>  for ABF configuration
>>>> 
>>>> 
>>>> vat#
>>>>  acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 17
>>>> vl_api_acl_add_replace_reply_t_handler:109:
>>>>  ACL index: 0
>>>> 
>>>> DBGvpp#
>>>>  show acl-plugin acl 
>>>> acl-index
>>>>  0 count 1 tag {}
>>>>           0:
>>>>  ipv4 permit src 11.11.11.0/24 dst 
>>>> 0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535
>>>> 
>>>> 
>>>> Configure ABF Policy
>>>>  referring to the above created ACL with no forwarding path
>>>> 
>>>> 
>>>> DBGvpp#
>>>>  abf policy add id 100 acl 0
>>>> DBGvpp#
>>>>  show abf policy 
>>>> abf:[0]:
>>>>  policy:100 acl:0
>>>>      path-list:[47]
>>>>  locks:1 flags:shared,no-uRPF, uRPF-list: None
>>>> 
>>>> 
>>>> Delete ABF Policy
>>>>  and this results in a VPP crash
>>>> 
>>>> 
>>>> DBGvpp#
>>>>  abf policy del id 100 acl 0
>>>> 
>>>> 
>>>> On Fri, Aug 7, 2020 at 5:36 PM Andrew 👽 Yourtchenko <ayour...@gmail.com> 
>>>> wrote:
>>>> 
>>>> 
>>>>> 
>>>>> On 8 Aug 2020, at 01:40, Venkat <venkat.dabb...@gmail.com> wrote:
>>>>> 
>>>>> Thank you Andrew for the response. Will invest time to put together the 
>>>>> test cases. Could you please point me to sample test scripts for vpp for 
>>>>> reference? 
>>>> 
>>>> You can look in the “test” subdirectories of the ABF and acl plug-ins for 
>>>> the inspiration, hopefully should be a simple tweak to combine the two...
>>>> 
>>>>> Or shall I compile a list of test cases I am executing using vpp dbg 
>>>>> shell CLI commands? 
>>>>> 
>>>>> Also, do you think there are significant changes between 1908 vs 2001 or 
>>>>> 2005 VPP stable branches for ABF plugin code making a case to upgrade 
>>>>> vpp? 
>>>> 
>>>> ACLs didn’t change for quite a while - not sure about the ABF...
>>>> 
>>>> You can do git log —oneline | egrep “acl|abf” on master branch to see what 
>>>> changes were there...
>>>> 
>>>> —a
>>>> 
>>>>> Please advise. 
>>>>> 
>>>>> thanks
>>>>> Venkat
>>>>> 
>>>>> 
>>>>> On Fri, Aug 7, 2020 at 4:25 PM Andrew 👽 Yourtchenko <ayour...@gmail.com> 
>>>>> wrote:
>>>>> Sure. Neither me nor Neale have k8s or ligato.
>>>>> 
>>>>> If you invest some effort into building a small “make test” script(s) 
>>>>> that show the issues then:
>>>>> 1) it will be possible for at least one of us to take a look at them
>>>>> 2) they won’t resurface again.
>>>>> 
>>>>> Does this make sense?
>>>>> 
>>>>> Also, probably ligato folks have some testing as well - have you 
>>>>> discussed with them what kind of scenarios they tested ?
>>>>> 
>>>>> --a
>>>>> 
>>>>>> On 7 Aug 2020, at 21:35, Venkat <venkat.dabb...@gmail.com> wrote:
>>>>>> 
>>>>>> Just to give more context on my test environment... I am using contiv 
>>>>>> vpp  Kubernetes environment and configuring ABFs via etcdctl. 
>>>>>> 
>>>>>> eg. 
>>>>>> / # etcdctl --endpoints=10.43.255.42:12379 put 
>>>>>> /vnf-agent/eos-branch-1/config/vpp/abfs/v2/abf/4 
>>>>>> '{"index":4,"acl_name":"023-sjcf
>>>>>> w-icmp-deny","attached_interfaces":[{"input_interface":"lan","priority":5}],"forwarding_paths":[{"interface_name":"sjc-blr-tunne
>>>>>> l"}]}'
>>>>>> 
>>>>>> Just wondering of ABF feature is mature enough in vpp. I am facing a 
>>>>>> good number of issues as I try to experiment with various scenarios. 
>>>>>> I seeing issues when NAT is enabled on the interface, then ABF is not 
>>>>>> exercised. 
>>>>>> I am not sure how to setup deny rules on the interface, if we cannot 
>>>>>> have ABF and ACL co-exist on the interface. 
>>>>>> Observing crashes in VPP while performing some of these tests. 
>>>>>> 
>>>>>> DBGvpp# show version 
>>>>>> vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
>>>>>> 21:10:49 UTC 2020
>>>>>> DBGvpp#
>>>>>> 
>>>>>> thanks
>>>>>> Venkat
>>>>>> 
>>>>>> On Fri, Aug 7, 2020 at 10:27 AM Andrew 👽 Yourtchenko 
>>>>>> <ayour...@gmail.com> wrote:
>>>>>> A contribution to “make test” that covers this scenario would be very 
>>>>>> much appreciated...
>>>>>> 
>>>>>> --a
>>>>>> 
>>>>>>> On 7 Aug 2020, at 19:07, Venkat <venkat.dabb...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Thank you for the response Balaji. 
>>>>>>> I have noticed VPP crashes when I configure an ABF on the interface 
>>>>>>> that already has an non-abf ACL attached to the interface. 
>>>>>>> And when I don't have non-abf ACL, then I am able to install ABF rule. 
>>>>>>> Hence was wondering if it's a misconfiguration to have both ABF and 
>>>>>>> non-abf ACL on the same interface. I agree, in any case, it should not 
>>>>>>> result in a crash. 
>>>>>>> 
>>>>>>> thanks
>>>>>>> Venkat
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Aug 7, 2020 at 9:59 AM Balaji Venkatraman via lists.fd.io 
>>>>>>> <balajiv=cisco....@lists.fd.io> wrote:
>>>>>>> Hi Venkat,
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>> Underlying the ABF is another ACL. When we attach an ABF to the 
>>>>>>> interface, the ACL it inherits gets applied to the interface. Not sure 
>>>>>>> if another ACL independent of the above can be attached to the same 
>>>>>>> interface. But, in any case, it should not crash 😊
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Balaji. 
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>> From: <vpp-dev@lists.fd.io> on behalf of "vdabb...@infoblox.com" 
>>>>>>> <vdabb...@infoblox.com>
>>>>>>> Date: Friday, August 7, 2020 at 9:36 AM
>>>>>>> To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
>>>>>>> Subject: [vpp-dev] ABF and ACL co-existence on an Interface
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>> Hello,
>>>>>>> Experimenting ABF in VPP. Had a question regarding the co-existence of 
>>>>>>> ABF and ACL on an interface. 
>>>>>>> Seems like we can either attach ABF or ACL to an interface and not 
>>>>>>> both. 
>>>>>>> Is this the behavior or am I missing anything?
>>>>>>> When I try to install ABF rule on an interface that already has ACL 
>>>>>>> attached, I see vpp resulting in a crash. 
>>>>>>> Please confirm.
>>>>>>> thanks
>>>>>>> Venkat
>>>>>>> 
>>>>>>> 
>> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17193): https://lists.fd.io/g/vpp-dev/message/17193
Mute This Topic: https://lists.fd.io/mt/76052836/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to