Neale, No worries. Enjoy your vacation !!!!
If the fix for issue 1 works where ACL and ABF can co-exist on an interface, we can configure ACL for all deny/drop scenarios and ABF only for the permit and forwarding traffic. So like you said, we will configure ABFs always with forwarding paths with a fix for the issue 1 works. thanks Venkat On Wed, Aug 12, 2020 at 10:05 AM Neale Ranns (nranns) <nra...@cisco.com> wrote: > Hi Venkat, > > No fix from me soon, I'm on leave. In the meantime, don't add policies > with no forwarding paths ;) > > /neale > > tpyed by my fat tumhbs > > ------------------------------ > *From:* Venkat <venkat.dabb...@gmail.com> > *Sent:* Wednesday, August 12, 2020 5:41:42 PM > *To:* Andrew đ˝ Yourtchenko <ayour...@gmail.com> > *Cc:* Neale Ranns (nranns) <nra...@cisco.com>; 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 > > Thank you Andrew for providing the fix. We will try the patch and let you > know how it holds. > Regarding the second issue, it appears to be some defensive check missing > for the forwarding paths. > The test scenario was to delete an ABF policy with no forwarding paths. > Create was successful. > > Will wait for Neale to comment on the backtrace provided and hopefully get > a fix from him soon. > > thanks > Venkat > > On Wed, Aug 12, 2020 at 1:47 AM Andrew đ˝ Yourtchenko <ayour...@gmail.com> > wrote: > > 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 <https://aka.ms/o0ukef> > ------------------------------ > *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 (#17210): https://lists.fd.io/g/vpp-dev/message/17210 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] -=-=-=-=-=-=-=-=-=-=-=-
