I'm not sure I understand. As of now, there are no fully OF1.1
compliant switches -- the spec has just been released. What did you
compile? The "most complete" 1.1 switch is the openflow python switch
("ofps") that ships with oftest in the oft-1.1 branch, but even it is
missing significant functionality. Is this what you're using?
As for simple description of how to use it, I can point you to the
QinQ test cases in oftest's vlan tests, but the short short
description is that the standard OpenFlow match structure only matches
the outer tag and there are push and pop vlan instructions, so you
would insert flow_mods that express:
if dl_vlan_id = vlan1, then apply action push_vlan(ETHERTYPE_QinQ)
if dl_vlan_id = vlan2, then apply action pop_vlan()
The tests in the vlanact.py oftest file work through this in gory detail.
- Rob
.
On Tue, Mar 8, 2011 at 12:52 AM, Max Ott <[email protected]> wrote:
> Rob,
>
> Saeed has compiled the OF1.1 version and wants to experiment with QinQ. Is
> there a simple description on how to do this for a simple case?
>
> Cheers,
> -max
>
> On 08/03/2011, at 6:24 PM, Rob Sherwood wrote:
>
>> In OpenFlow version 1.0, the SET_VLAN action implicitly adds a vlan
>> tag if none exists, but a limitation of 1.0 is that you cannot manage
>> multiple vlan tags (e.g., QinQ). You can remove the vlan tag with the
>> STRIP_VLAN action.
>>
>> Multiple vlan tags are better handled in the recently released
>> OpenFlow 1.1 specification, that has explicit push and pop vlan
>> actions.
>>
>> Both specifications are available at http://www.openflow.org/wp/documents/
>>
>> Hope that helps,
>>
>> - Rob
>> .
>>
>>
>>
>> On Mon, Mar 7, 2011 at 5:35 PM, Saeed Attar <[email protected]> wrote:
>>> Hi
>>>
>>> I couldn't find any examples on how to use push/pull labels in openflow,
>>> Could any one point me to documentation or example code. in a simple
>>> word how can we add a VLAN tag for a packet entering one port and
>>> leaving through another.
>>>
>>> Thanks
>>> Saeed
>>>
>>> The information in this e-mail may be confidential and subject to legal
>>> professional privilege and/or copyright. National ICT Australia Limited
>>> accepts no liability for any damage caused by this email or its attachments.
>>> _______________________________________________
>>> openflow-discuss mailing list
>>> [email protected]
>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>>>
>> _______________________________________________
>> openflow-discuss mailing list
>> [email protected]
>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>
>
> The information in this e-mail may be confidential and subject to legal
> professional privilege and/or copyright. National ICT Australia Limited
> accepts no liability for any damage caused by this email or its attachments.
>
_______________________________________________
openflow-discuss mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
