[ovs-discuss] OVN - Opaque metadata on logical switch ports to simplify network policies

Dumitru Ceara dceara at redhat.com
Thu Apr 2 11:30:29 UTC 2020


Hi all,

I'd like to bring up to discussion the following feature request that
would make the life of some CMSs easier when implementing network
policies with OVN ACLs.

If OVN would allow a CMS to attach an opaque metadata value to logical
switch ports (e.g., a 32-bit integer) and also support defining ACLs
that match on a specific value of that opaque metadata then the
following type of policies would result in less openflow entries and
would also be easier to configure.

Let's assume the logical topology:

Logical_Switch LS1 --- Logical_Router LR --- Logical_Switch LS2
   |         |                                  |         |
   |         |                                  |         |
  VM1.1     VM1.2                              VM2.1     VM2.2

And a default, drop-all-traffic, policy:

PortGroup:
- name: "pg_drop_all"
- ports: VM1.1, VM1.2, VM2.1, VM2.2

ACL:
- priority: 1000
- direction: to-lport
- match: "outport == @pg_drop_all && ipv4"
- action: "drop"
- applied on PortGroup "pg_drop_all".

With the current OVN implementation, if we want to allow traffic between
VM1.1 and VM2.1, for example, for TCP port 80 we have to add something like:

PortGroup:
- name: "pg_allow"
- ports: VM1.1, VM2.1

AddressSet:
- name: "as_allow"
- IPs: IP-VM1.1, IP-VM2.1

ACL:
- priority: 2000
- direction: to-lport
- match: "ipv4.src == @as_allow && outport == @pg_allow && tcp.dest == 80"
- action: "allow"/"allow-related"
- applied on PortGroup "pg_allow"

Assuming that we could attach some opaque metadata to traffic received
on specific logical switch ports, e.g. value 42:

ovn-nbctl set-lsp-metadata VM1.1 42
ovn-nbctl set-lsp-metadata VM2.1 42

The configuration required to enforce the same type of allow network
policy would change to:

ACL:
- priority: 2000
- direction: to-lport
- match "lsp-metadata == 42 && outport == @pg_allow && tcp.dest == 80"
- action: "allow"/"allow-related"
- applied on PortGroup "pg_allow"

This would generate 50% less openflow entries because we don't need to
validate that traffic comes from IPs in AddressSet "as_allow" as that's
implicitly done by matching on the "lsp-metadata" value.

>From an implementation perspective as far as I see we'd need to:
- in openflow table 0: store the lsp-metadata value in an unused 32 bit
register (e.g., REG7). This is either passed through tunnel header
fields or read from the port_binding associated with the ingress logical
switch port.
- in openflow table 34: when moving the packet to the egress pipeline,
skip clearing the register used to store lsp-metadata (e.g., REG7)
- in openflow table 32: when packets need to be tunneled to a remote
hypervisor, put_encapsulation() should also encode the lsp-metadata.

Do you think there would be any major problems with such an approach?

Thanks,
Dumitru



More information about the discuss mailing list