>> Proposal:
>> We introduce the interface keyword "learn= no".
>> E.g. ovs-vsctl set interface foo learn=no
>>
>> This will instruct br-int NOT to do MAC learning on packets received on
>> interface foo.
>This seems less flexible than adding some kind of option to "normal", or
>breaking "normal" into sub-actions. Why do it this way?
Here's the typical scenario I have with SFC.
Typically, the flows matching the normal action are the most general flows.SRC
SF DST| | || | |4 5
6OpenvSwitch
The high priority flows match with the inport and the flow-classifier to
redirect traffic.In above example, the flows will be something as follows.
in_port=4, nw_src=SRC, nw_DST=DST, actions=mod_dl_dst:SF, output:5The traffic
from SF to DST follows the normal switching path along with many other traffic
flows.
If SF is a bump-in-the-wire SF and the last function in the chain, my idea was
to disablelearning on port 5 and let it pass through the normal path.
Can you elaborate more on your thoughts about breaking "normal" into
sub-actions ?
>> This cannot be applied to a bonded port with 2 or more interfaces.
>Why?
Just to make it simple for now. These are virtual appliances and unlikely
tosupport bonding anyway. Issues such as what happens if the bonded port has 3
interfaces and only oneof the interfaces has learning disabled. Do we disable
learning for the entire port?
Look forward to hearing your suggestion.
thanks,Farhad.
On Tuesday, April 19, 2016 8:07 AM, Ben Pfaff <[email protected]> wrote:
On Tue, Apr 19, 2016 at 08:08:46AM +0000, Farhad Sunavala wrote:
> Proposal:
> We introduce the interface keyword "learn= no".
> E.g. ovs-vsctl set interface foo learn=no
>
> This will instruct br-int NOT to do MAC learning on packets received on
> interface foo.
This seems less flexible than adding some kind of option to "normal", or
breaking "normal" into sub-actions. Why do it this way?
> This cannot be applied to a bonded port with 2 or more interfaces.
Why?
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
