[pox-dev] implementing vlans

[durga]

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.

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..


Cheers!
Durga



On Wed, Nov 6, 2013 at 10:30 AM, Murphy McCauley
<murphy.mccauley at 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.durga at 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.mccauley at gmail.com
> > wrote:
>
>> On Nov 4, 2013, at 9:32 PM, durga <c.vijaya.durga at 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20131106/a6a50670/attachment-0002.htm>