Jon,
Do you have an api trace you could throw in my direction unicast ?
Macip_add_replace call was added later than most ACL plugins, (after realizing
the convenience of this approach in the policy ACLs vs the unapply/delete
acl/readd acl/reapply and for consistency), via commit
c29940c58de3e44c0c1dd5c4eda5e0268d963b14
That change modified the existing “macip_acl_add_list” routine to also get the
replace semantics, by deleting and then recreating the classifier tables anew.
This doesn’t work very well if the classifier tables are applied somewhere:
they are removed, but the new tables are not applied automatically. We need to
iterate the am->macip_acl_by_sw_if_index and for interfaces which have the acl
in question applied, reapply these new tables to these interfaces so the
already active macip acl remained active. This is a bug. Sorry for that.
Since there were also tests in that commit which ideally should have caught
this, i will also need to take a double check at what is going on there (my
guess missing negative tests), and fix it too, but not sure I can pull off
thumbtyping in a vi session, so I will add you to the changerequest with the
fix once I have it, hope in a day or so.
--a
>>> On 8 Dec 2017, at 17:28, Jon Loeliger <j...@netgate.com> wrote:
>>>
>>> On Fri, Dec 8, 2017 at 11:24 AM, Jon Loeliger <j...@netgate.com> wrote:
>>> On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger <j...@netgate.com> wrote:
>>>
>>> vpp# show acl-plugin macip acl
>>> MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
>>> ip4_table_index 0, ip6_table_index 0, l2_table_index 0
>>> rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
>>> 00:00:00:00:00:00
>>>
>>> Notice that the ip4_table_index has changed from 3 in the first two 'show'
>>> command outputs, while it is now 0 in the 3rd 'show' output.
>>>
>>> My guess is it should be a consistent value throughout, and I think it
>>> should
>>> be table 3, but I'm not certain yet.
>>>
>>> When I then go to remove the MACIP from the interface, I am told error -65,
>>> which is "No such table."
>>>
>>> Should it have copied the ip4_table_index 3 to the replaced MACIP as it
>>> stands
>>> after the macip_add_replace API call?
>>>
>>> Or should the original MACIP ACL have inherited the table number 0 from the
>>> interface when it was first bound there?
>
> Sorry. I also hate gmail. But I could digress acerbically.
>
> Anyway.
>
> I meant to say that I've read enough to know now that these are classifier
> table indices. Which means the 3rd, unlisted option is more likely here:
> As the ACL changed, update these table to use the _new_ classifier table
> indices. That should likely be table 4 unless the classifier can positively
> determine that there are no other users of tables 3 and can do it in place,
> in which case 3 is the correct answer.
>
> But not 0.
>
> Thanks,
> jdl
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
