Hi, >Why tie together two plugins with potentially very different use cases ?
I didn't mean to tie these two plugins together. I just have this in mind that both these plugins have common function of connection tracking. For example, why they do not use the one common code for this functionality? Appearently there was a reason not to do so. May you describe that? In fact I have no idea about their different use cases. Because this part of connection tracking and taking record of connections seem to be common, even management of connections. >The mental model of acl-plugin is small per-interface "firewall", independent from other interfaces. Do you have any plan to extend this per-interface firewall to have this stateful functionality over multiple interfaces(the other interfaces I mean)? Regards, Ehsan Shahrokhi On Sun, Jul 9, 2017 at 10:14 PM, Andrew Yourtchenko <[email protected]> wrote: > > > > On 9 Jul 2017, at 07:31, Ehsan Shahrokhi <[email protected]> wrote: > > > > Hi, > > > > I have two questions about stateful. > > First, why stateful implementation of NAT and ACL are independent? Was > there any logic behind this? As it is expected that both ACL and NAT > plugins use the same connection tracking code base or platform. > > Why tie together two plugins with potentially very different use cases ? > > > > > Second, Should we define an acl in both directions even if we are > configuring stateful acl using "permit+reflect"? Or if I have a > "permit+reflect" acl in one direction, can I expect the response packets to > be also permitted? > > The mental model of acl-plugin is small per-interface "firewall", > independent from other interfaces. > > If you don't have an acl applied, then the packers are permitted. > > From this - if you want a firewall like behavior on an interface, you need > permit+reflect in one direction, and deny in the other direction on that > interface. > > If you only have permit+reflect on one interface and no acl in the other > direction, it will still work by for a different reason. > > --a > > > > > Regards, > > _______________________________________________ > > vpp-dev mailing list > > [email protected] > > https://lists.fd.io/mailman/listinfo/vpp-dev >
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
