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] -=-=-=-=-=-=-=-=-=-=-=-