The OVS docs/code are still probably the best place to read about it, but just FYI, the POX manual's section on the subject has recently been expanded.
And forwarding.l2_nx demonstrates working with multiple tables. -- Murphy On Nov 5, 2013, at 3:18 PM, durga <c.vijaya.du...@gmail.com> wrote: > Thanks for the insight, Murphy! I think I will read about Nicira extensions > now > > > Cheers! > Durga > > > > On Tue, Nov 5, 2013 at 9:25 PM, Murphy McCauley <murphy.mccau...@gmail.com> > wrote: > On Nov 4, 2013, at 9:32 PM, durga <c.vijaya.du...@gmail.com> wrote: > >> Hello All, >> >> I tried to replicate vlan behaviour and succeeded to some extent(excl. >> Broadcasts). The procedure I followed is to maintain another vlanport table >> within the controller and map for vlanID to port ID based on simple >> calculation of even and odd ports. if both src and dest port are in same >> vlan , then controller inserts a flowtable entry , else drop the packet. I >> am yet to implement a Broadcast scenario within a single vlan. >> >> Now, >> 1.is there already a built in feature for implementing vlans? I understand, >> there is an action type vlan_vid to set the vlanID in flow tables, so does >> it mean that if a match exists in the Openflow switch, the switch is >> capable of figuring out if two ports belong to same vlan or not? > > It's not the action which helps with that. It's that ofp_match can match on > VLAN ID. The VLAN ID write action can then be used to handle switching > between access and trunk. Together, the two mean that you can interact with > existing VLANs. > >> 2.also can vlans be implemented as group tables? > > First off: not in POX, since these are an OpenFlow 1.1 feature, and POX > doesn't support 1.1 (yet?). > > Secondly: it depends what you mean. They certainly might be helpful. > > Thirdly: with Open vSwitch / Nicira extensions, I have found its multiple > table support useful for working with VLANs. These aren't 1.1 group tables; > just normal tables (which *are* supported by POX). A rough approximation of > the design involves four tables: > > Ingress table. This matches on input port and VLAN ID. It validates that > only trunked VLAN IDs for a port are allowed (others are dropped) and sets > the appropriate tag for untagged traffic on access ports. Then it jumps to > the forwarding table. > > Forwarding table. This actually does whatever your forwarding logic is > (e.g., L2 learning, IP prefixes, whatever). If outputting to a specific > port, it sets the output port in a meta register and jumps to the output > table. If flooding, it jumps to the flood table. > > Output table. This table matches on the output port set by the forwarding > table and the VLAN ID. For trunked VLANs, it doesn't do anything (a low > priority match-all just outputs the packet). For access ports, there's a > rule to strip the VLAN tag and then output. > > Flood table. Matches on the VLAN ID. Each entry outputs to each of the > trunk ports, then strips the tag and outputs to each of the access ports. > > -- Murphy >
