[NETVIRT-38] match field in Broad cast flow need add inport Created: 29/Jun/16  Updated: 09/Mar/18  Resolved: 04/Nov/16

Status: Resolved
Project: netvirt
Component/s: None
Affects Version/s: Beryllium
Fix Version/s: None

Type: Bug
Reporter: wangqianyu Assignee: wangqianyu
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All

External issue ID: 6123

 Description   

Broad cast flow is like below
cookie=0x0, duration=3357.036s, table=110, n_packets=45, n_bytes=6050, priority=16383,reg0=0x1,tun_id=0x64,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:1,output:3,output:4,output:7

if the broadcast packet is come from port 1, it will also broadcast to port 1

this may cause the VIM which linked to port1 thinks that the network have a loop.

so, i think it should add an in_port in match field, and output port list shoud exclude the inport

 Comments   
Comment by Sam Hague [ 07/Jul/16 ]

Was this found as an issue or just a theory? Openflow dictates packets can not be sent out the received port unless the output action includes INPORT explictly. So adding the inport to the output list should ignore that port.

Comment by wangqianyu [ 08/Jul/16 ]

(In reply to Sam Hague from comment #1)
> Was this found as an issue or just a theory? Openflow dictates packets can
> not be sent out the received port unless the output action includes INPORT
> explictly. So adding the inport to the output list should ignore that port.

this problem is exist in theory, and i will prove it by catching packet in real scene.

in openflow1.3.3, the specifiction that packets can not be sent out the received port unless the output action includes INPORT can be found in section 5.6.1. the content is talk about group, not about action list. while in netvirt, the broadcast is implemented by action list.

Comment by Sam Hague [ 08/Jul/16 ]

(In reply to wangqianyu from comment #2)
> (In reply to Sam Hague from comment #1)
> > Was this found as an issue or just a theory? Openflow dictates packets can
> > not be sent out the received port unless the output action includes INPORT
> > explictly. So adding the inport to the output list should ignore that port.
>
> this problem is exist in theory, and i will prove it by catching packet in
> real scene.
>
> in openflow1.3.3, the specifiction that packets can not be sent out the
> received port unless the output action includes INPORT can be found in
> section 5.6.1. the content is talk about group, not about action list. while
> in netvirt, the broadcast is implemented by action list.

The group section is just a single example and clarification for groups that need to send out the ingress port and there must be an additional bucket with IN_PORT set. There are other sections is the spec indicating that IN_PORT is used with actions. Section B.6.3 is a good explanation on using it with an action list.

We use this same idea in other places like the vlan flood's. We simply add the ports to the list of outputs and OVS ensures the packets will not be sent out the received port - even if it was included in the output actions since IN_PORT was not explicitly included. We also use IN_PORT with ARP replies and SFC/NSH flows.

If you do find a switch sending out the ingress port without have IN_PORT on the flow, then that is a violation of the spec.

Comment by wangqianyu [ 11/Jul/16 ]

(In reply to Sam Hague from comment #3)
> (In reply to wangqianyu from comment #2)
> > (In reply to Sam Hague from comment #1)
> > > Was this found as an issue or just a theory? Openflow dictates packets can
> > > not be sent out the received port unless the output action includes INPORT
> > > explictly. So adding the inport to the output list should ignore that port.
> >
> > this problem is exist in theory, and i will prove it by catching packet in
> > real scene.
> >
> > in openflow1.3.3, the specifiction that packets can not be sent out the
> > received port unless the output action includes INPORT can be found in
> > section 5.6.1. the content is talk about group, not about action list. while
> > in netvirt, the broadcast is implemented by action list.
>
> The group section is just a single example and clarification for groups that
> need to send out the ingress port and there must be an additional bucket
> with IN_PORT set. There are other sections is the spec indicating that
> IN_PORT is used with actions. Section B.6.3 is a good explanation on using
> it with an action list.
>
> We use this same idea in other places like the vlan flood's. We simply add
> the ports to the list of outputs and OVS ensures the packets will not be
> sent out the received port - even if it was included in the output actions
> since IN_PORT was not explicitly included. We also use IN_PORT with ARP
> replies and SFC/NSH flows.
>
> If you do find a switch sending out the ingress port without have IN_PORT on
> the flow, then that is a violation of the spec.

In openflow spec, there is statement that IN_PORT can be used only as an output port, but there is no explicit statement that openflow switch will drop the packet if output port is same with input port.

OVS ensures the packets will not be sent out the received port, so there are some limitations when OVS used as tor switch.

I think, just for explicit, we should exclude the in port in output port list

Generated at Wed Feb 07 20:20:32 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.