# Quantum OVS tunneling - Why delete openflows on added port in bridge br-int ?

I looked the Quantum OVS plugin code and I block on a line https://github.com/openstack/quantum/blob/stable/folsom/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L388 (https://github.com/openstack/quantum/...)

This line is in the function 'port_bound' which called by OVS agent when a new port is added. And this line delete all openflows rules related to the new added port on bridge br-int.

Why it needs to delete this openflows and where they could be added ?

edit retag close merge delete

Sort by » oldest newest most voted

We don't add flow on VM's port.

more

Thanks Aaron.

more

Whoops sorry I was looking at master not stable/folsom......

If port_dead() is called which adds the flow entry: self.int_br.add_flow(priority=2, in_port=port.ofport, actions="drop") and then later the port shows up we delete this flow entry in port_bound()

The reason for the if int(port.ofport) != -1:

is because if the HV is rebooted the tap interfaces that connect to the vms will not persist the reboot but they will still be in OVSDB. The ovs agent will start up for the first time (after reboot) and detect this as a new port (since its the first time it's run ovs-vsctl list-ports br-int). Then it will enter port_bound() but since the tap interface doesn't exist on br-int port.ofport will == -1 and if it runs delete_flows with inport=-1 (which isn't a valid port as these must be non negative ) ovs-vsctl will return non 0 which causes an exception. This is the reason for the if statement. Sorry again about the confusion. Does this answer your question?

more

Ok, I understand. If we don't add flows on VM's port why add a delete flow command in the code ? Is it to do clean up in case of a rule is added ?

more

git blame on that line of code points to the following bug report that explains why https://bugs.launchpad.net/quantum/+b...

more

No this bug point to the line https://github.com/openstack/quantum/blob/stable/folsom/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L387 (https://github.com/openstack/quantum/...) This bug added the 'if' line to be sure the port exists before delete related flows.

The line I pointed is related to the blueprint https://blueprints.launchpad.net/quantum/+spec/quantum-ovs-tunnel-agent (https://blueprints.launchpad.net/quan...) https://review.openstack.org/#/c/4367/

It's what I understand, are you agree ?

more

Hi Edourard,

It was highlighs this line: if int(port.ofport) != -1: self.int_br.delete_flows(in_port=port.ofport) <--- Which is line 451 must be some chrome/linux issue.

checking...

more

So line 387 is:

    if lvm.network_type == constants.TYPE_GRE:
if self.enable_tunneling:
self.tun_br.delete_flows(tun_id=lvm.segmentation_id) <--- 387


lvm.segmentation_id is the gre_tunnel key that is used for a tenant's network. Once that tenants network is deleted (if that network_id existed on this HV) then the flow entry that was added to allow traffic to the vm on this tunnel matching this key needs to be deleted since it's no longer used. The flow entries that it is deleting was added here (line 315, 320)

    if network_type == constants.TYPE_GRE:
if self.enable_tunneling:
# outbound
dl_vlan=lvid,
actions="set_tunnel:%s,normal" %
segmentation_id)
# inbound bcast/mcast
priority=3,
tun_id=segmentation_id,
dl_dst="01:00:00:00:00:00/01:00:00:00:00:00",
actions="mod_vlan_vid:%s,output:%s" %
(lvid, self.patch_int_ofport))


Sorry for the confusion before.

more

Ok, it's clearer.

I didn't saw that when a port is dead we put it in the dead VLAN and add flow rule to drop all its traffic.

So if I understand, a port is dead when it is administratively down. An when it goes administratively up, we put it in the appropriate local VLAN and delete all drop flow rule (in port_bound())

more

# Get to know Ask OpenStack

Resources for moderators