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.
Re the debug CLI, it's often not robust to garbage input. If the API has the same problem though, I'll fix it. 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<http://30.30.30.1/32> dst 40.40.40.1/32<http://40.40.40.1/32> sport 1000 dport 1000, ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24>, ipv4 permit+reflect src 20.20.20.0/24<http://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<http://30.30.30.1/32> dst 40.40.40.1/32<http://40.40.40.1/32> proto 0 sport 1000 dport 1000 1: ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24> dst 0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535 2: ipv4 permit+reflect src 20.20.20.0/24<http://20.20.20.0/24> dst 0.0.0.0/0<http://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<http://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<http://30.30.30.1/32> dst 40.40.40.1/32<http://40.40.40.1/32> proto 0 sport 1000 dport 1000 1: ipv4 permit+reflect src 10.10.10.0/24<http://10.10.10.0/24> dst 0.0.0.0/0<http://0.0.0.0/0> proto 0 sport 0-65535 dport 0-65535 2: ipv4 permit+reflect src 20.20.20.0/24<http://20.20.20.0/24> dst 0.0.0.0/0<http://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<http://11.11.11.0/24> dst 0.0.0.0/0<http://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<http://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<http://11.11.11.0/24> dst 0.0.0.0/0<http://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<mailto:ayour...@gmail.com>> wrote: On 8 Aug 2020, at 01:40, Venkat <venkat.dabb...@gmail.com<mailto: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<mailto: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<mailto: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<http://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<mailto: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<mailto: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<http://lists.fd.io> <balajiv=cisco....@lists.fd.io<mailto: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<mailto:vpp-dev@lists.fd.io>> on behalf of "vdabb...@infoblox.com<mailto:vdabb...@infoblox.com>" <vdabb...@infoblox.com<mailto:vdabb...@infoblox.com>> Date: Friday, August 7, 2020 at 9:36 AM To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto: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 (#17187): https://lists.fd.io/g/vpp-dev/message/17187 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] -=-=-=-=-=-=-=-=-=-=-=-
