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
