OpenFlow Pushing/Popping/Rewriting VLANs Support

[phpHavok]

This is going to be a bit of an overloaded question, so please bear with me.

There is a table listed at http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/K-KA-KB/15-18/5998_8148_sww_admin_guide/content/ch05s03.html#v32701554 which is prefixed by "HP switches running OpenFlow do not support Push and Pop VLANs." However, the table seems to indicate that there is some level of support for popping VLANs. For the first part of my question, could someone please explain the details regarding the support of these operations on HP switches? Is there or is there not support, and is it based on module version, switch version, firmware version, VAN version, etc.?

Second, I am very confused about how the standard pipeline processes packets with or without VLAN tags and when OpenFlow takes over. Through testing, I have observed many confusing results including:

1. Popping a VLAN before outputting on a port resulting in the packet being dropped.

2. A packet arrives on an untagged port. I set the VLAN ID (what VLAN ID? it shouldn't have one. is there internal tagging?). I output the (now somehow tagged) packet on another untagged port. It successfully travels across the wire and arrives on the other side. Though the other side is configured as an access port, the tag containing the same VLAN as the native/untagged VLAN of the access port is automatically popped from the packet.

Could someone please explain, in as much detail as possible, the details of the OpenFlow pipeline with respect to VLANs. I will likely have follow up questions, as this has caused numurous problems and confusion for me.

Thanks for your time!

[Vince-Whirlwind]

For starters, I think HP would be doing us a favour if they broke down their description of what is going on by differentiating between Layer2 and Layer3 datagrams. When Openflow talks at a high level about "packets" they are kind of ignoring what is going on at Layer2, where a switch is dealing with frames. The frame remains a frame unless it is routed, in which case it is re-framed before being forwarded.

The switch has to tag frames internally - otherwise how would it differentiate between untagged frames received on ports that are configured as Access ports in VLAN10 and untagged frames received on ports that are configured as Access ports in VLAN20?
Packets aren't tagged, frames are.
If a switchport is a layer2 switchport (ie no IP address on it) then it doesn't deal with packets, it deals with frames. A frame that arrives on a switch has a destination MAC.
If that destination MAC is a local Layer3 interface, then the packet it contains will be routed to the correct network segment, then re-framed.
Otherwise, the destination MAC will be in the MAC-address table which will direct it to a switchport for output.
(If it's not in the MAC-address table, it will be "flooded" by being sent out all ports in the network segment).
When a frame is output on a switchport, it will tag/untag it depending on how that switchport is configured.
Normally, a switchport receiving a frame tagged in a VLAN it isn't configured for will drop the frame. Untag/tag mismatches should also see the frame dropped.

[ShaunWackerly]

Hi phpHavok,

The OFPAT_PUSH_VLAN and OFPAT_POP_VLAN actions are supported on HP/HPE Aruba switches running firmware 15.17 or greater. You should be able to verify this by looking at the output of the following command. As you can see it includes "Push VLAN" and "Pop VLAN" under the "Table Instructions" output:

HP2920# show open inst X flow-table 100 table-capability

 OpenFlow Flow Table Properties

 Table Match Capabilities:
   Incoming Port                      Ethernet Source
   Ethernet Type                      VLAN ID
   VLAN PCP                           IP DSCP
   IP Protocol                        IPv4 Source Address
   IPv4 Destination Address           TCP Source Port
   TCP Destination Port               UDP Source Port
   UDP Destination Port               ICMP Type
   ICMP Code                          IPv6 Source Address
   IPv6 Destination Address
   UDP Source Port Range              UDP Destination Port Range
   TCP Source Port Range              TCP Destination Port Range
   TCP Flags
 Table Wildcard Capabilities:
   Incoming Port                      Ethernet Source
   Ethernet Type                      VLAN ID
   VLAN PCP                           IP DSCP
   IP Protocol                        IPv4 Source Address
   IPv4 Destination Address           TCP Source Port
   TCP Destination Port               UDP Source Port
   UDP Destination Port               ICMP Type
   ICMP Code                          IPv6 Source Address
   IPv6 Destination Address
   UDP Source Port Range              UDP Destination Port Range
   TCP Source Port Range              TCP Destination Port Range
   TCP Flags
 Table Instructions:
   Metering
   Apply Actions
      Set-Field
         Ethernet Destination          Ethernet Source
         VLAN ID                       VLAN PCP
         IP DSCP
      Output                             Push VLAN
      Pop VLAN                           Group
   GoTo 200
 Table-Miss Instructions:
   Metering
   Apply Actions
      Output                             Group
   GoTo 200

Regarding your second question (how the non-OF pipeline coordinates with OpenFlow vlan tagging), I'll ask someone with more expertise to get the correct answer.

Shaun

[Abhay_B]

Hi phpHavok,

HPE Aruba switches support OFPAT_PUSH_VLAN and OFPAT_POP_VLAN actions on v2 and v3 generation of ASICs from firmware release 15.17.

To clarify how VLAN tagging affects OpenFlow, let me take an example.

Let us say you have 3 VLANs on the switch VLAN 1, 2 and 3. Let us say VLAN 2 is your controller VLAN and VLAN 3 is your OpenFlow member VLAN.

openflow
controller-id 1 ip xx.xx.xx.xx controller-interface vlan 2
instance test
controller-id 1
member vlan 3
version 1.3 only
pipeline-model standard-match
enable
exit
exit
vlan 1
name "DEFAULT_VLAN"
ip address dhcp
exit
vlan 2
name "OF Controller VLAN"
untagged 1
ip add xx.xx.xx.xx/xx
exit
vlan 3
name "OF Member VLAN"
untagged 2-3
tagged 4-5

OpenFlow on the switch will only look at traffic inbound on VLAN 3.

For ports 2 and 3, since both have untagged membership on VLAN 3, all untagged packets ingress on these 2 ports will enter the OpenFlow pipeline. Also, all packets with a VLAN tag of '3' on these ports will enter the OpenFlow pipeline.

For ports 4 and 5, only packets that ingress with a VLAN tag of '3' on these ports will enter the OpenFlow pipeline. All the untagged frames on these 2 ports will default to VLAN 1 as they are untagged members on VLAN 1 and hence won't enter the OpenFlow pipeline since VLAN 1 is not an OpenFlow managed VLAN.

When the controller installs a flow with action as OFPAT_PUSH_VLAN, the hardware will attempt to force the packet out of the switch with a VLAN tag based on the egress VLAN for the packet. In case the inbound packet was untagged, the VLAN tag in the packet on the egress will be VLAN ID of the VLAN to which the port is an untagged member of if the packet is bridged.  

When the controller installs a flow with action as OFPAT_SET_FIELD to set VLAN_VID in the packet to VLAN X, the hardware will attempt to force the packet out of the switch with a VLAN tag of X. If the inbound packet was already tagged, the existing VLAN ID in the tag will be replaced with X.

I hope that clarifies some of your confusion.

Coming to the specific questions you have asked:

1. Popping a VLAN before outputting on a port resulting in the packet being dropped.

Was the packet dropped on the ingress of the neighbour or was it dropped on the egress of the same switch? Did you see the packet on the wire?

2. A packet arrives on an untagged port. I set the VLAN ID (what VLAN ID? it shouldn't have one. is there internal tagging?). I output the (now somehow tagged) packet on another untagged port. It successfully travels across the wire and arrives on the other side. Though the other side is configured as an access port, the tag containing the same VLAN as the native/untagged VLAN of the access port is automatically popped from the packet.

By set the VLAN ID, do you mean using the OpenFlow action OFPAT_SET_FIELD VLAN_VID? Or is it with just OFPAT_PUSH_VLAN action? If it is the latter, the VLAN ID in the packet at egress will be the same VLAN as the inbound VLAN of the packet (VLAN to which the port is untagged member of assuming the packet is bridged). Is the other side also a HPE Aruba switch?

Please let us know if we can clarify anything else for you.

If possible, can you please help us understand the use case that you are working on. It can help us understand the problem better and provide better suggestions.

Thanks!

Abhay