<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>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.</div><div><br></div><div>And forwarding.l2_nx demonstrates working with multiple tables.</div><div><br></div><div>-- Murphy</div><br><div><div>On Nov 5, 2013, at 3:18 PM, durga <<a href="mailto:c.vijaya.durga@gmail.com">c.vijaya.durga@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#993300">Thanks for the insight, Murphy! I think I will read about Nicira extensions now </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#993300">
<br></div></div><div class="gmail_extra"><br clear="all"><div>Cheers!<br>Durga<br><br></div>
<br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 9:25 PM, Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">
<div style="word-wrap:break-word"><div class="im">On Nov 4, 2013, at 9:32 PM, durga <<a href="mailto:c.vijaya.durga@gmail.com" target="_blank">c.vijaya.durga@gmail.com</a>> wrote:<br></div><div><div class="im"><br>
<blockquote type="cite">
<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)">Hello All,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)">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.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)">Now, </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)"><a href="http://1.is/" target="_blank">1.is</a> 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?</div>
</div></blockquote><div><br></div></div><div>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.</div>
<div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:rgb(153,51,0)">2.also can vlans be implemented as group tables?</div></div>
</blockquote>
<div><br></div></div><div>First off: not in POX, since these are an OpenFlow 1.1 feature, and POX doesn't support 1.1 (yet?).</div><div><br></div><div>Secondly: it depends what you mean. They certainly might be helpful.</div>
<div><br></div><div>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:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div>
<br>
</div><div>-- Murphy</div></font></span></div></div></blockquote></div><br></div>
</blockquote></div><br></body></html>