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=
[email protected]> 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 <[email protected]>
> wrote:
>
>>
>>
>> On 11 Aug 2020, at 17:30, Neale Ranns (nranns) <[email protected]> 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:* [email protected] <[email protected]> on behalf of Balaji
>> Venkatraman via lists.fd.io <[email protected]>
>> *Sent:* Tuesday, August 11, 2020 4:08:56 PM
>> *To:* Venkat <[email protected]>; Andrew 👽 Yourtchenko <
>> [email protected]>
>> *Cc:* [email protected] <[email protected]>
>> *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:* [email protected] <[email protected]> on behalf of Venkat <
>> [email protected]>
>> *Sent:* Monday, August 10, 2020 11:52:46 PM
>> *To:* Andrew 👽 Yourtchenko <[email protected]>
>> *Cc:* Balaji Venkatraman (balajiv) <[email protected]>;
>> [email protected] <[email protected]>
>> *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 <[email protected]>
>> wrote:
>>
>>
>>
>>
>> On 8 Aug 2020, at 01:40, Venkat <[email protected]> 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 <[email protected]>
>> 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 <[email protected]> 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 <[email protected]>
>> wrote:
>>
>> A contribution to “make test” that covers this scenario would be very
>> much appreciated...
>>
>> --a
>>
>> On 7 Aug 2020, at 19:07, Venkat <[email protected]> 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
>> <[email protected]> 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: *<[email protected]> on behalf of "[email protected]" <
>> [email protected]>
>> *Date: *Friday, August 7, 2020 at 9:36 AM
>> *To: *"[email protected]" <[email protected]>
>> *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 (#17192): https://lists.fd.io/g/vpp-dev/message/17192
Mute This Topic: https://lists.fd.io/mt/76052836/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to