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

asked 2013-03-05 16:58:19 -0600

ethuleau gravatar image

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 flag offensive close merge delete

9 answers

Sort by ยป oldest newest most voted

answered 2013-03-06 01:19:02 -0600

gongysh gravatar image

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

edit flag offensive delete link more

answered 2013-03-06 14:04:06 -0600

ethuleau gravatar image

Thanks Aaron.

edit flag offensive delete link more

answered 2013-03-06 09:54:13 -0600

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?

edit flag offensive delete link more

answered 2013-03-06 08:34:12 -0600

ethuleau gravatar image

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 ?

edit flag offensive delete link more

answered 2013-03-06 08:40:38 -0600

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

edit flag offensive delete link more

answered 2013-03-06 08:55:46 -0600

ethuleau gravatar image

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 ?

edit flag offensive delete link more

answered 2013-03-06 09:17:56 -0600

Hi Edourard,

Sorry about this. When I click on this link https://github.com/openstack/quantum/...

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.


edit flag offensive delete link more

answered 2013-03-06 09:28:28 -0600

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
            self.tun_br.add_flow(priority=4, in_port=self.patch_int_ofport,      <--- 
                                 actions="set_tunnel:%s,normal" %
            # inbound bcast/mcast
            self.tun_br.add_flow(           <--- 
                actions="mod_vlan_vid:%s,output:%s" %
                (lvid, self.patch_int_ofport))

Sorry for the confusion before.

edit flag offensive delete link more

answered 2013-03-06 14:03:33 -0600

ethuleau gravatar image

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())

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2013-03-05 16:58:19 -0600

Seen: 114 times

Last updated: Mar 06 '13