Ask Your Question
0

untagging and tagging vlans

asked 2016-04-04 17:07:11 -0700

sterdnotshaken gravatar image

Here's a test flow where I'm trying to pop the vlan-id the frame arrives with and then tag it with a new vlan id before sending it back out another port:

<flow xmlns="urn:opendaylight:flow:inventory"> <id>1</id> <priority>50</priority> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <pop-vlan-action/> </action> <action> <order>3</order> <set-field> <vlan-match> <vlan-id> <vlan-id>2011</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </set-field> </action> <action> <order>2</order> <push-vlan-action> <ethernet-type>33024</ethernet-type> </push-vlan-action> </action> <action> <order>1</order> <set-field> <ethernet-match> <ethernet-destination>

00:19:38:9c:3d:00
</ethernet-destination> </ethernet-match> </set-field> </action> <action> <order>4</order> <output-action> <output-node-connector>1</output-node-connector> </output-action> </action> </apply-actions> </instruction> </instructions> <cookie>0</cookie> <idle-timeout>0</idle-timeout> <flags></flags> <hard-timeout>0</hard-timeout> <match> <in-port>openflow:100:3</in-port> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> </ethernet-match> <ipv4-source>10.0.10.11/32</ipv4-source> <ipv4-destination>10.0.10.12/32</ipv4-destination> </match> <table_id>0</table_id> </flow>


Problem is, it doesn't seem to be working... This flow won't actually install at all. If I remove the pop action, then it installs fine and matches traffic, but on the next network device the frames are double tagged...

Ideas?

Thanks!

edit retag flag offensive close merge delete

Comments

where is the flow install being rejected? at the switch, or is OpenDaylight rejecting it before even trying to send to the switch?

jamoluhrsen ( 2016-04-04 17:08:53 -0700 )edit

Great question! I'm actually not sure how to tell that... I try and install the flow while tailing log:tail in karaf with these log settings: opendaylight-user@root>log:list Logger | Level ---------------- ROOT | INFO openflow | DEBUG but no log entries are produced, so maybe its the switch

sterdnotshaken ( 2016-04-05 08:36:49 -0700 )edit

you can check the switch logs. Also, you can do a packet capture on your ODL system (e.g. "tcpdump -ni eth0 port 6633") and then check that communication. That might show you the switch rejecting it.

jamoluhrsen ( 2016-04-05 08:53:08 -0700 )edit

also, another gotcha. once you PUT the flow to ODL config-store if you want to try again, make sure you first DELETE that flow and then send your PUT again.

jamoluhrsen ( 2016-04-05 08:53:53 -0700 )edit

2 answers

Sort by ยป oldest newest most voted
0

answered 2016-04-06 11:45:58 -0700

jamoluhrsen gravatar image

This feels like a bug to me, but I am not totally sure. To be succinct, your flow has an order to first pop the vlan tag, then add a different tag after. The final result should be a packet with a single tag. You are seeing two tags.

Could you send this observation to this email address: openflowplugin-dev@lists.opendaylight...

That project should know if this is a bug, or maybe can be explained.

One workaround you might try is to have two flows. the first flow can be in table 0 to strip your vlan tag, with an action to goto table 1 where another flow will also match it and then add your new vlan tag. just a thought.

edit flag offensive delete publish link more

Comments

Really appreciate you taking the time to answer my inquiry Jamoluhrsen. I'll email that address as mentioned. Regarding your tables point, that would be AWESOME if it weren't for the fact that my Brocade MLXe's only support 1 lame table! I wish they supported more!

sterdnotshaken ( 2016-04-07 09:21:15 -0700 )edit

lets see if you can get some answers on the mailing list (I saw you already emailed). You know it could also be a bug on the switch side. Maybe you can try with another switch (e.g. OVS) to see what your results are?

jamoluhrsen ( 2016-04-07 10:43:27 -0700 )edit
0

answered 2016-04-05 16:37:11 -0700

sterdnotshaken gravatar image

updated 2016-04-05 16:48:33 -0700

Thanks for your help Jamoluhrsen,

Via packet captures, I see the switch responses with a OFPBACUNSUPPORTEDORDER error...

The order I have in this flow is

0 - change dest mac

1 - pop vlan:

<action> <order>1</order> <pop-vlan-action/> </action>

2 - push-vlan-action

3 - set-field (setting the desired vlan tag, although, as said before this ends up double-tagging the frame per the original frame tag not getting stripped)

4 - set output port

I have been able to remove tag's on other flows using the above syntax, but I've never tried to remove and then add another tag sequentially in the same flow before, so it almost seams like a relational issue of some sort between the actions...

Below is the flow I'm working with. Thoughts?

image description

edit flag offensive delete publish link more
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2016-04-04 17:07:11 -0700

Seen: 374 times

Last updated: Apr 06 '16