Hello Ben, Jean,
Thank you for your reply.
As for my example of configuration:
port 1: trunks 100, 110, 120 (connected to tenant networks)
port 2: trunks 100, 110, 120 (connected to tenant networks)
port 3: trunks 200, 210, 220 (connected to tenant networks)
port 4: trunks 200, 210, 220 (connected to tenant networks)
port 5: trunks 300, 310, 320 (connected to tenant networks)
port 6: trunks 300, 310, 320 (connected to tenant networks)
port 7: trunk (connected to provider networks)
port 8: trunk (connected to provider networks)
For implementing it if I use Egress Tables,
I understand that I should use following table.
Is my understanding correct?
First egress == 200
table 200:
actset_output=1,actions=goto_table:201
actset_output=2,actions=goto_table:201
actset_output=3,actions=goto_table:202
actset_output=4,actions=goto_table:202
actset_output=3,actions=goto_table:203
actset_output=4,actions=goto_table:203
actset_output=7,actions=
actset_output=8,actions=
table 201:
actset_output=*,vlan_id=100,actions=
actset_output=*,vlan_id=110,actions=
actset_output=*,vlan_id=120,actions=
actset_output=*,actions=clear_actions
table 202:
actset_output=*,vlan_id=200,actions=
actset_output=*,vlan_id=210,actions=
actset_output=*,vlan_id=220,actions=
actset_output=*,actions=clear_actions
table 203:
actset_output=*,vlan_id=300,actions=
actset_output=*,vlan_id=310,actions=
actset_output=*,vlan_id=320,actions=
actset_output=*,actions=clear_actions
On Fri, 6 Mar 2015 11:04:03 -0800,
j...@hpl.hp.com wrote
in E-mail "Re: Hybrid VLAN capability":
> On Fri, Mar 06, 2015 at 10:27:22AM -0800, Ben Pfaff wrote:
> >
> > Another possibility is to use the "conjunctive match" feature in
> > (upcoming) OVS 2.4. With this feature, you can effectively construct
> > flows that say,
> >
> > (in_port in {set_A}) and (vlan_id in {set_B}),actions=...
> >
> > by adding n_A + n_B + 1 flows to the flow table, where n_A is the
> > number of elements in {set_A} and n_B is the number in {set_B}. But I
> > doubt that that feature maps well to hardware.
>
> I believe this will only help for ingress filtering. I think
> ingress filtering is easy, you can just do it with two tables :
>
> table 0:
> in_port=1,actions=goto_table:1
> in_port=2,actions=goto_table:1
> in_port=3,actions=goto_table:1
> in_port=4,actions=goto_table:1
> in_port=7,actions=goto_table:2
>
> table 1:
> in_port=*,vlan_id=100,actions=goto_table:2
> in_port=*,vlan_id=110,actions=goto_table:2
> in_port=*,vlan_id=120,actions=goto_table:2
> in_port=*,drop
>
> table 2:
> in_port=1,actions=output:2,output:7,output:8
> in_port=2,actions=output:1,output:7,output:8
> in_port=3,actions=output:4,output:7,output:8
> in_port=4,actions=output:3,output:7,output:8
> in_port=7,actions=output:8
>
> It is clear that "conjunctive match" would help to collapse
> the first two tables into one, but there may be other way to do that,
> such as using bitmasks on the VLAN or just wildcarding input port.
> In term of what would be more efficient in the datapath,
> I guess that would depend on the traffic pattern and how forwarding
> rules look like. What is clear to me is that having all collapsed into
> one megaflow lookup would beat having an additional specialised VLAN
> lookup in the port itself.
>
> Where "conjunctive match" does not help is with egress
> filtering. Obviously, actset_output would help, but it's tricky to use
> in ingress tables and is non-transparent to the forwarding rules.
>
> With Egress Tables :
>
> table 0:
> in_port=1,actions=goto_table:1
> in_port=2,actions=goto_table:1
> in_port=3,actions=goto_table:1
> in_port=4,actions=goto_table:1
> in_port=7,actions=goto_table:2
> in_port=8,actions=goto_table:2
>
> table 1:
> in_port=*,vlan_id=100,actions=goto_table:2
> in_port=*,vlan_id=110,actions=goto_table:2
> in_port=*,vlan_id=120,actions=goto_table:2
> in_port=*,drop
>
> table 2:
> in_port=1,actions=output:2,output:7,output:8
> in_port=2,actions=output:1,output:7,output:8
> in_port=3,actions=output:4,output:7,output:8
> in_port=4,actions=output:3,output:7,output:8
> in_port=7,actions=output:8
>
> First egress == 200
>
> table 200:
> actset_output=1,actions=goto_table:201
> actset_output=2,actions=goto_table:201
> actset_output=3,actions=goto_table:201
> actset_output=4,actions=goto_table:201
> actset_output=7,actions=
> actset_output=8,actions=
>
> table 201:
> actset_output=*,vlan_id=100,actions=
> actset_output=*,vlan_id=110,actions=
> actset_output=*,vlan_id=120,actions=
> actset_output=*,actions=clear_actions
>
> How do that look like ? Clean enough ?
> Again, "conjunctive match" would allow you to collapse table
> 200 and 201. But that's only an optimisation ;-)
> But to me the main issue is avoiding an extra lookup in the
> output port. I personally believe that you won't have any trouble
> folding egress tables into a single megaflow lookup without needing
> recirculation in most cases. Recirculation is probably needed only
> when using OFPP_ALL, group of type all or multiple output actions.
>
> Regards,
>
> Jean
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
