On Fri, Jan 22, 2016 at 7:06 AM, Numan Siddique <nusid...@redhat.com> wrote: > > Hi All, > > I am working on the port security feature in ovn and implementing as per the port security proposal defined here [1]. > > If a logical port has one mac and multiple IP addresses (both ipv4 and ipv6), as per this proposal, Logical_Port.port_security will be defined as > Logical_Port.port_security = ["MAC IP1 IP2 IP3 ..."] > > But Logical_Port.addresses column is stored as > Logical_Port.addresses = ["MAC IP1", "MAC IP2", "MAC IP3" ...] > > Is it a good idea to store Logical_Port.addresses also as ["MAC IP1 IP2 IP3 ...."] to be consistent with port security or it should be other way round ? > > > [1] - http://openvswitch.org/pipermail/dev/2015-July/057141.html > https://github.com/blp/ovs-reviews/blob/port-security/ovn/ovn-nb.xml#L210 > > > Thanks > Numan > > > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev
Numan, thanks for the proposal. I would suggest to have the format ["MAC1 IP1-1 IP1-2 IP1-3 ...", "MAC2 IP2-1 IP2-2 ...", ...] for both "port_security" and "addresses" columns. This would still provide the mapping between MAC and IPs (e.g. for ARP responder), at the same time avoid redundant data when one MAC maps to multiple IPs. One side-effect of the redundant data is the duplicated lflows generated against the same MAC address when there are multiple IPs but single MAC. A typical case is a port with both IPv4 and IPv6 addresses. The redundant flow will be detected and removed when generating physical flows in ovn-controller, but it would be better if the redundant data did not exist in the model in the first place. Regarding the functionality of port-security itself, I am not sure how would it be supported for ls_out_port_sec. If a dst MAC is not recognised in ls_in_l2_lkup stage, it is meaningless to have it allowed in ls_out_port_sec, because the packet would never reach the output port. Some thoughts: 1. For an individual MAC (not masked) in "port_security", if it doesn't exist in "addresses", we need to add a flow for it in ls_in_l2_lkup stage. 2. For a masked MAC in "port_security", we cannot add a flow in ls_in_l2_lkup, so it might be useful only if when we support "MAC learning" in the pipeline, and optionally enable it for lports (a new option needed) that need to send/recv packets using different MACs (e.g. a VM hosting containers but not using the child lport provided by OVN). -- Best regards, Han _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
