Thanks Ben. Got it. Will keep it in mind.At this point, I've decided not to
pursue this line of thought because I cannot fix allpossible scenarios.
SRC SFC DST
| | | | 1 2 3 4 OpenVswitch
If SFC is a bump-in-the-wire SFC, 1. By disabling learning on ports, I can
prevent the switch from getting confused when packetshit the NORMAL action.2.By
dropping multicast and broadcast packets on ports 2 and 3, I can prevent
broadcast and multicasts from looping.3.However, I cannot prevent unknown
unicast packets from looping. E.g: If SRC sends an unknown unicast, it will
flood to ports 2 and 3.
At this point, the only option I can think of is adding detailed flows for each
and every known MAC address and source port (similar to what OVN does).
Farhad.
On Monday, May 2, 2016 2:19 PM, Ben Pfaff <b...@ovn.org> wrote:
On Tue, Apr 19, 2016 at 05:30:21PM +0000, Farhad Sunavala wrote:
> >"normal" consists of a number of more or less independent steps:
> > * Drop certain malformed or invalid frames.
> > * Check VLAN.
> > * Check for other inadmissible frames.
> > * Learn source MAC.
> > * Decide on output interface(s).
> > * Output to each output interface.
> Yes, that sounds good too.Does a flow rule as shown below make sense ?
>
> table=20, actions=normal,no_learn_inport:4,no_learn_inport:5
> (If the packet hits table 20, do normal actions but no SRC MAC learning on OF
> ports 4 and 5).
That's not what I had in mind. The way you wrote it, it's like a set of
options to "normal". Instead, I suggest creating a collection of
actions, each of which performs one of the steps that makes up "normal".
Then you can use flow matching to decide, for example, that for packets
arrive with in_port=4 or in_port=5 one should not execute the action
that performs learning.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
