[pox-dev] implementing vlans

[durga]

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/4c818e31/attachment-0002.htm>