On Nov 6, 2013, at 12:16 AM, durga <c.vijaya.du...@gmail.com> wrote:
> Are group tables used only for grouping up action buckets? My earlier thought > was that group tables group flows. > As of now, i am unable to think of a process to use group tables for vlans. Well, in my example, one of my four tables is a "flood table". This could be done with a group table, I think. > Thanks Murphy, i will take your lead about ovs docs and check out. > Also, You were right about vlan id be set as match criteria. I get it now! > > Wondering, how vlans can be cascaded when we have multiple switches in tree > topology.. The design I sketched should allow for this without difficulty. -- Murphy > On Wed, Nov 6, 2013 at 10:30 AM, Murphy McCauley <murphy.mccau...@gmail.com> > wrote: > 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 >> > >
