On 6/15/17, Luke, Chris <chris_l...@comcast.com> wrote: > Iām mostly agnostic with 2; an alternate behavior might be to refuse to > delete an ACL if it is referenced anywhere. Iām more concerned with > consistency with this sort of operation across VPP which I feel is more > important, though no other examples spring to mind this early in the > morning!
Right... From what I see if e.g. I set the l2 classify lookup table # for the interface and then free the table itself, node function still goes into a given index, so I suspect the consequences of this move would be visible quite quickly.... So for now in the new bihash-based ACL lookup code I went ahead with this change of behaviour (I've added you to the draft so you can see it), and we can later align the linear lookup as well to match with this behaviour. --a > > Chris. > > On 6/15/17, 08:22, "Andrew š½ Yourtchenko" <ayour...@gmail.com> wrote: > > After a bit more thinking - there is a way that should take care of > both: > > 1) What Chris wrote: have consistent behaviour with non-existent ACL > as if the ACL matching fell off the end of the ACL: if an empty ACL is > referenced, treat it as if it had entries but none of them had > matched. Then we still hit the "default deny" if none of the applied > ACLs match, and drop the packets - so it will be logical. > > 2) What Marco wrote: when deleting an already referenced ACL, unapply > it from all the places where it is applied. > > It's a change in the behaviour in that the current behaviour is to > have the empty ACL act as if it was "deny any any", and block the > matching even if there is another ACL after it - but on the other hand > this would take both viewpoints in mind... > > What do you think ? > > --a > > On 6/9/17, Andrew š½ Yourtchenko <ayour...@gmail.com> wrote: > > Assuming the only change is to effectively have > > "unbind_acl_from_everywhere; delete_acl" instead of "delete_acl", > > maybe it would be best to tackle that post-17.07 with a separate API > > message acl_del_and_unbind or similar ? > > > > I feel a beet wary of adding more hidden state (even though the > > reflected sessions table does provide already plenty of it :) > > > > --a > > > > On 6/9/17, Luke, Chris <chris_l...@comcast.com> wrote: > >> Would it make sense to have a flag on the interface (or globally), > set > >> when > >> applying the ACL, that indicates the desired behavior when the ACL > is > >> empty > >> or non-existent? At the moment to me it seems logical that this is > the > >> same > >> behavior as when matching falls off the end of the ACL. > >> > >> Chris. > >> > >>> -----Original Message----- > >>> From: vpp-dev-boun...@lists.fd.io > [mailto:vpp-dev-boun...@lists.fd.io] > >>> On > >>> Behalf Of Andrew ?? Yourtchenko > >>> Sent: Friday, June 9, 2017 7:53 > >>> To: Marco Varlese <marco.varl...@suse.com> > >>> Cc: vpp-dev@lists.fd.io > >>> Subject: Re: [vpp-dev] Bind / Unbind of ACL > >>> > >>> Hi Marco, > >>> > >>> Yes, this works as expected, assuming after deletion *all* the > traffic > >>> is > >>> denied, rather than just the SSH traffic. > >>> > >>> If you apply to an interface the ACL# that does not exist, that is > the > >>> same as if > >>> there was an ACL with just the "deny all" semantics, to avoid the > >>> perception > >>> that a given policy is enforced when it isn't - so I erred on the > side > >>> of > >>> caution. > >>> > >>> The way to remove the ACL: you would ensure the ACL is not applied > to > >>> the > >>> interface(s) first, then remove the ACL (or replace it with a > different > >>> policy in- > >>> place). > >>> > >>> Alternatively, you can just replace the existing ACL in-place with > >>> "permit > >>> any" > >>> for IPv4 and IPv6 - this way you explicitly state that there is a > policy > >>> to permit > >>> all the traffic. > >>> > >>> I've been bitten myself and seen several times in my career when an > >>> applied > >>> but non-existent ACL caused problems later on, in the worst > possible > >>> moment. The current behaviour IMHO makes the config discrepancy > clear - > >>> what do you think ? > >>> > >>> --a > >>> > >>> On 6/9/17, Marco Varlese <marco.varl...@suse.com> wrote: > >>> > Hi, > >>> > > >>> > I am trying the ACL functionality and I found a "strange" > behaviour. > >>> > > >>> > The steps I follow to use an ACL are: > >>> > * I create an ACL to deny SSH traffic between VMs (via the > >>> 'acl_add_replace' > >>> > function) > >>> > * Set that ACL to the interfaces involved (via the > >>> > 'acl_interface_set_acl_list' > >>> > function) > >>> > > >>> > After performing the above steps the traffic was correctly being > >>> > blocked. > >>> > > >>> > However, when I decided to enable the SSH traffic again, I simply > >>> > deleted the ACL (via the 'acl_del' function) with the consequence > >>> > though that the traffic was still being denied. > >>> > > >>> > Is this behaviour correct? > >>> > If so what would be the right way to unset hence disable a given > ACL > >>> > from an interface (or multiple)? > >>> > > >>> > > >>> > Thanks, > >>> > Marco > >>> > > >>> > _______________________________________________ > >>> > 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 > >> > >> > > > > > _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
