https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETVIRT-38 netvirt <p>Broad cast flow is like below<br/> 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</p> <p>if the broadcast packet is come from port 1, it will also broadcast to port 1 </p> <p>this may cause the VIM which linked to port1 thinks that the network have a loop.</p> <p>so, i think it should add an in_port in match field, and output port list shoud exclude the inport</p> <p>Operating System: Linux<br/> Platform: All</p> NETVIRT-38

match field in Broad cast flow need add inport

Bug Resolved Won't Do wangqianyu wangqianyu Wed, 29 Jun 2016 07:35:21 +0000 Fri, 9 Mar 2018 18:21:30 +0000 Fri, 4 Nov 2016 20:09:23 +0000 Beryllium 0 1 <p>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.</p> <p>(In reply to Sam Hague from comment #1)<br/> &gt; Was this found as an issue or just a theory? Openflow dictates packets can<br/> &gt; not be sent out the received port unless the output action includes INPORT<br/> &gt; explictly. So adding the inport to the output list should ignore that port.</p> <p>this problem is exist in theory, and i will prove it by catching packet in real scene.</p> <p>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.</p> <p>(In reply to wangqianyu from comment #2)<br/> &gt; (In reply to Sam Hague from comment #1)<br/> &gt; &gt; Was this found as an issue or just a theory? Openflow dictates packets can<br/> &gt; &gt; not be sent out the received port unless the output action includes INPORT<br/> &gt; &gt; explictly. So adding the inport to the output list should ignore that port.<br/> &gt; <br/> &gt; this problem is exist in theory, and i will prove it by catching packet in<br/> &gt; real scene.<br/> &gt; <br/> &gt; in openflow1.3.3, the specifiction that packets can not be sent out the<br/> &gt; received port unless the output action includes INPORT can be found in<br/> &gt; section 5.6.1. the content is talk about group, not about action list. while<br/> &gt; in netvirt, the broadcast is implemented by action list.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>(In reply to Sam Hague from comment #3)<br/> &gt; (In reply to wangqianyu from comment #2)<br/> &gt; &gt; (In reply to Sam Hague from comment #1)<br/> &gt; &gt; &gt; Was this found as an issue or just a theory? Openflow dictates packets can<br/> &gt; &gt; &gt; not be sent out the received port unless the output action includes INPORT<br/> &gt; &gt; &gt; explictly. So adding the inport to the output list should ignore that port.<br/> &gt; &gt; <br/> &gt; &gt; this problem is exist in theory, and i will prove it by catching packet in<br/> &gt; &gt; real scene.<br/> &gt; &gt; <br/> &gt; &gt; in openflow1.3.3, the specifiction that packets can not be sent out the<br/> &gt; &gt; received port unless the output action includes INPORT can be found in<br/> &gt; &gt; section 5.6.1. the content is talk about group, not about action list. while<br/> &gt; &gt; in netvirt, the broadcast is implemented by action list.<br/> &gt; <br/> &gt; The group section is just a single example and clarification for groups that<br/> &gt; need to send out the ingress port and there must be an additional bucket<br/> &gt; with IN_PORT set. There are other sections is the spec indicating that<br/> &gt; IN_PORT is used with actions. Section B.6.3 is a good explanation on using<br/> &gt; it with an action list.<br/> &gt; <br/> &gt; We use this same idea in other places like the vlan flood's. We simply add<br/> &gt; the ports to the list of outputs and OVS ensures the packets will not be<br/> &gt; sent out the received port - even if it was included in the output actions<br/> &gt; since IN_PORT was not explicitly included. We also use IN_PORT with ARP<br/> &gt; replies and SFC/NSH flows.<br/> &gt; <br/> &gt; If you do find a switch sending out the ingress port without have IN_PORT on<br/> &gt; the flow, then that is a violation of the spec.</p> <p>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.</p> <p>OVS ensures the packets will not be sent out the received port, so there are some limitations when OVS used as tor switch. </p> <p>I think, just for explicit, we should exclude the in port in output port list</p> Development External issue ID 6123 External issue URL Issue Type Rank 0|i01pbz: