2009-07-08 13:19:16 -07:00
|
|
|
|
/*
|
2010-02-10 11:09:40 -08:00
|
|
|
|
* Copyright (c) 2008, 2009, 2010 Nicira Networks.
|
2009-07-08 13:19:16 -07:00
|
|
|
|
*
|
2009-06-15 15:11:30 -07:00
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at:
|
2009-07-08 13:19:16 -07:00
|
|
|
|
*
|
2009-06-15 15:11:30 -07:00
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
2009-07-08 13:19:16 -07:00
|
|
|
|
*/
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
|
#include "flow.h"
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
2010-10-28 17:13:18 -07:00
|
|
|
|
#include "byte-order.h"
|
2009-07-08 13:19:16 -07:00
|
|
|
|
#include "coverage.h"
|
|
|
|
|
#include "dynamic-string.h"
|
|
|
|
|
#include "hash.h"
|
|
|
|
|
#include "ofpbuf.h"
|
|
|
|
|
#include "openflow/openflow.h"
|
|
|
|
|
#include "openvswitch/datapath-protocol.h"
|
|
|
|
|
#include "packets.h"
|
2010-05-07 11:43:18 -07:00
|
|
|
|
#include "unaligned.h"
|
2010-07-16 11:02:49 -07:00
|
|
|
|
#include "vlog.h"
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
2010-10-19 14:47:01 -07:00
|
|
|
|
VLOG_DEFINE_THIS_MODULE(flow);
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
2009-07-16 12:58:28 -07:00
|
|
|
|
static struct arp_eth_header *
|
|
|
|
|
pull_arp(struct ofpbuf *packet)
|
|
|
|
|
{
|
|
|
|
|
return ofpbuf_try_pull(packet, ARP_ETH_HEADER_LEN);
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
|
static struct ip_header *
|
|
|
|
|
pull_ip(struct ofpbuf *packet)
|
|
|
|
|
{
|
|
|
|
|
if (packet->size >= IP_HEADER_LEN) {
|
|
|
|
|
struct ip_header *ip = packet->data;
|
|
|
|
|
int ip_len = IP_IHL(ip->ip_ihl_ver) * 4;
|
|
|
|
|
if (ip_len >= IP_HEADER_LEN && packet->size >= ip_len) {
|
|
|
|
|
return ofpbuf_pull(packet, ip_len);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct tcp_header *
|
2010-08-30 00:24:53 -07:00
|
|
|
|
pull_tcp(struct ofpbuf *packet)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
if (packet->size >= TCP_HEADER_LEN) {
|
|
|
|
|
struct tcp_header *tcp = packet->data;
|
|
|
|
|
int tcp_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
|
|
|
|
|
if (tcp_len >= TCP_HEADER_LEN && packet->size >= tcp_len) {
|
|
|
|
|
return ofpbuf_pull(packet, tcp_len);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct udp_header *
|
2010-08-30 00:24:53 -07:00
|
|
|
|
pull_udp(struct ofpbuf *packet)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
return ofpbuf_try_pull(packet, UDP_HEADER_LEN);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct icmp_header *
|
2010-08-30 00:24:53 -07:00
|
|
|
|
pull_icmp(struct ofpbuf *packet)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
return ofpbuf_try_pull(packet, ICMP_HEADER_LEN);
|
|
|
|
|
}
|
|
|
|
|
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
static void
|
2010-09-03 11:30:02 -07:00
|
|
|
|
parse_vlan(struct ofpbuf *b, struct flow *flow)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
struct qtag_prefix {
|
2010-10-26 15:24:26 -07:00
|
|
|
|
ovs_be16 eth_type; /* ETH_TYPE_VLAN */
|
|
|
|
|
ovs_be16 tci;
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
};
|
|
|
|
|
|
2010-10-26 15:24:26 -07:00
|
|
|
|
if (b->size >= sizeof(struct qtag_prefix) + sizeof(ovs_be16)) {
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
struct qtag_prefix *qp = ofpbuf_pull(b, sizeof *qp);
|
|
|
|
|
flow->dl_vlan = qp->tci & htons(VLAN_VID_MASK);
|
2010-10-26 13:09:28 -07:00
|
|
|
|
flow->dl_vlan_pcp = vlan_tci_to_pcp(qp->tci);
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-26 15:24:26 -07:00
|
|
|
|
static ovs_be16
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
parse_ethertype(struct ofpbuf *b)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
struct llc_snap_header *llc;
|
2010-10-26 15:24:26 -07:00
|
|
|
|
ovs_be16 proto;
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
|
2010-10-26 15:24:26 -07:00
|
|
|
|
proto = *(ovs_be16 *) ofpbuf_pull(b, sizeof proto);
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
if (ntohs(proto) >= ODP_DL_TYPE_ETH2_CUTOFF) {
|
|
|
|
|
return proto;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (b->size < sizeof *llc) {
|
|
|
|
|
return htons(ODP_DL_TYPE_NOT_ETH_TYPE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llc = b->data;
|
|
|
|
|
if (llc->llc.llc_dsap != LLC_DSAP_SNAP
|
|
|
|
|
|| llc->llc.llc_ssap != LLC_SSAP_SNAP
|
|
|
|
|
|| llc->llc.llc_cntl != LLC_CNTL_SNAP
|
|
|
|
|
|| memcmp(llc->snap.snap_org, SNAP_ORG_ETHERNET,
|
|
|
|
|
sizeof llc->snap.snap_org)) {
|
|
|
|
|
return htons(ODP_DL_TYPE_NOT_ETH_TYPE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ofpbuf_pull(b, sizeof *llc);
|
|
|
|
|
return llc->snap.snap_type;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-26 15:24:26 -07:00
|
|
|
|
/* Initializes 'flow' members from 'packet', 'tun_id', and 'in_port.
|
|
|
|
|
* Initializes 'packet' header pointers as follows:
|
2010-08-13 10:46:12 -07:00
|
|
|
|
*
|
|
|
|
|
* - packet->l2 to the start of the Ethernet header.
|
|
|
|
|
*
|
|
|
|
|
* - packet->l3 to just past the Ethernet header, or just past the
|
|
|
|
|
* vlan_header if one is present, to the first byte of the payload of the
|
|
|
|
|
* Ethernet frame.
|
|
|
|
|
*
|
|
|
|
|
* - packet->l4 to just past the IPv4 header, if one is present and has a
|
|
|
|
|
* correct length, and otherwise NULL.
|
|
|
|
|
*
|
|
|
|
|
* - packet->l7 to just past the TCP or UDP or ICMP header, if one is
|
|
|
|
|
* present and has a correct length, and otherwise NULL.
|
|
|
|
|
*/
|
2009-07-08 13:19:16 -07:00
|
|
|
|
int
|
2010-10-26 15:24:26 -07:00
|
|
|
|
flow_extract(struct ofpbuf *packet, ovs_be32 tun_id, uint16_t in_port,
|
2010-09-03 11:30:02 -07:00
|
|
|
|
struct flow *flow)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
struct ofpbuf b = *packet;
|
|
|
|
|
struct eth_header *eth;
|
|
|
|
|
int retval = 0;
|
|
|
|
|
|
|
|
|
|
COVERAGE_INC(flow_extract);
|
|
|
|
|
|
|
|
|
|
memset(flow, 0, sizeof *flow);
|
2010-04-12 11:49:16 -04:00
|
|
|
|
flow->tun_id = tun_id;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
flow->in_port = in_port;
|
2010-04-12 11:49:16 -04:00
|
|
|
|
flow->dl_vlan = htons(OFP_VLAN_NONE);
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
|
|
|
|
packet->l2 = b.data;
|
|
|
|
|
packet->l3 = NULL;
|
|
|
|
|
packet->l4 = NULL;
|
|
|
|
|
packet->l7 = NULL;
|
|
|
|
|
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
if (b.size < sizeof *eth) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
/* Link layer. */
|
|
|
|
|
eth = b.data;
|
|
|
|
|
memcpy(flow->dl_src, eth->eth_src, ETH_ADDR_LEN);
|
|
|
|
|
memcpy(flow->dl_dst, eth->eth_dst, ETH_ADDR_LEN);
|
|
|
|
|
|
|
|
|
|
/* dl_type, dl_vlan, dl_vlan_pcp. */
|
|
|
|
|
ofpbuf_pull(&b, ETH_ADDR_LEN * 2);
|
|
|
|
|
if (eth->eth_type == htons(ETH_TYPE_VLAN)) {
|
|
|
|
|
parse_vlan(&b, flow);
|
|
|
|
|
}
|
|
|
|
|
flow->dl_type = parse_ethertype(&b);
|
|
|
|
|
|
|
|
|
|
/* Network layer. */
|
|
|
|
|
packet->l3 = b.data;
|
|
|
|
|
if (flow->dl_type == htons(ETH_TYPE_IP)) {
|
|
|
|
|
const struct ip_header *nh = pull_ip(&b);
|
|
|
|
|
if (nh) {
|
|
|
|
|
flow->nw_src = get_unaligned_u32(&nh->ip_src);
|
|
|
|
|
flow->nw_dst = get_unaligned_u32(&nh->ip_dst);
|
|
|
|
|
flow->nw_tos = nh->ip_tos & IP_DSCP_MASK;
|
|
|
|
|
flow->nw_proto = nh->ip_proto;
|
|
|
|
|
packet->l4 = b.data;
|
|
|
|
|
if (!IP_IS_FRAGMENT(nh->ip_frag_off)) {
|
|
|
|
|
if (flow->nw_proto == IP_TYPE_TCP) {
|
|
|
|
|
const struct tcp_header *tcp = pull_tcp(&b);
|
|
|
|
|
if (tcp) {
|
|
|
|
|
flow->tp_src = tcp->tcp_src;
|
|
|
|
|
flow->tp_dst = tcp->tcp_dst;
|
|
|
|
|
packet->l7 = b.data;
|
|
|
|
|
}
|
|
|
|
|
} else if (flow->nw_proto == IP_TYPE_UDP) {
|
|
|
|
|
const struct udp_header *udp = pull_udp(&b);
|
|
|
|
|
if (udp) {
|
|
|
|
|
flow->tp_src = udp->udp_src;
|
|
|
|
|
flow->tp_dst = udp->udp_dst;
|
|
|
|
|
packet->l7 = b.data;
|
|
|
|
|
}
|
|
|
|
|
} else if (flow->nw_proto == IP_TYPE_ICMP) {
|
|
|
|
|
const struct icmp_header *icmp = pull_icmp(&b);
|
|
|
|
|
if (icmp) {
|
|
|
|
|
flow->icmp_type = htons(icmp->icmp_type);
|
|
|
|
|
flow->icmp_code = htons(icmp->icmp_code);
|
|
|
|
|
packet->l7 = b.data;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
} else {
|
|
|
|
|
retval = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else if (flow->dl_type == htons(ETH_TYPE_ARP)) {
|
|
|
|
|
const struct arp_eth_header *arp = pull_arp(&b);
|
|
|
|
|
if (arp && arp->ar_hrd == htons(1)
|
2010-08-30 00:24:53 -07:00
|
|
|
|
&& arp->ar_pro == htons(ETH_TYPE_IP)
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
&& arp->ar_hln == ETH_ADDR_LEN
|
|
|
|
|
&& arp->ar_pln == 4) {
|
|
|
|
|
/* We only match on the lower 8 bits of the opcode. */
|
|
|
|
|
if (ntohs(arp->ar_op) <= 0xff) {
|
|
|
|
|
flow->nw_proto = ntohs(arp->ar_op);
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
2009-07-16 12:58:28 -07:00
|
|
|
|
|
2010-08-30 00:24:53 -07:00
|
|
|
|
if ((flow->nw_proto == ARP_OP_REQUEST)
|
datapath: Fix handling of 802.1Q and SNAP headers.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
|
|
|
|
|| (flow->nw_proto == ARP_OP_REPLY)) {
|
|
|
|
|
flow->nw_src = arp->ar_spa;
|
|
|
|
|
flow->nw_dst = arp->ar_tpa;
|
2009-07-16 12:58:28 -07:00
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Extracts the flow stats for a packet. The 'flow' and 'packet'
|
|
|
|
|
* arguments must have been initialized through a call to flow_extract().
|
|
|
|
|
*/
|
|
|
|
|
void
|
2010-09-03 11:30:02 -07:00
|
|
|
|
flow_extract_stats(const struct flow *flow, struct ofpbuf *packet,
|
2009-07-08 13:19:16 -07:00
|
|
|
|
struct odp_flow_stats *stats)
|
|
|
|
|
{
|
|
|
|
|
memset(stats, '\0', sizeof(*stats));
|
|
|
|
|
|
|
|
|
|
if ((flow->dl_type == htons(ETH_TYPE_IP)) && packet->l4) {
|
|
|
|
|
if ((flow->nw_proto == IP_TYPE_TCP) && packet->l7) {
|
|
|
|
|
struct tcp_header *tcp = packet->l4;
|
|
|
|
|
stats->tcp_flags = TCP_FLAGS(tcp->tcp_ctl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
stats->n_bytes = packet->size;
|
|
|
|
|
stats->n_packets = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-09 16:43:47 -08:00
|
|
|
|
/* Extract 'flow' with 'wildcards' into the OpenFlow match structure
|
2010-11-05 11:10:35 -07:00
|
|
|
|
* 'match'. 'flow_format' should be one of NXFF_*. */
|
2009-07-08 13:19:16 -07:00
|
|
|
|
void
|
2010-09-03 11:30:02 -07:00
|
|
|
|
flow_to_match(const struct flow *flow, uint32_t wildcards,
|
2010-11-05 11:10:35 -07:00
|
|
|
|
int flow_format, struct ofp_match *match)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
2010-11-05 11:10:35 -07:00
|
|
|
|
if (flow_format != NXFF_TUN_ID_FROM_COOKIE) {
|
2010-04-12 11:49:16 -04:00
|
|
|
|
wildcards &= OFPFW_ALL;
|
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
match->wildcards = htonl(wildcards);
|
2010-04-12 11:49:16 -04:00
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
|
match->in_port = htons(flow->in_port == ODPP_LOCAL ? OFPP_LOCAL
|
|
|
|
|
: flow->in_port);
|
|
|
|
|
match->dl_vlan = flow->dl_vlan;
|
2009-11-11 14:59:49 -08:00
|
|
|
|
match->dl_vlan_pcp = flow->dl_vlan_pcp;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
memcpy(match->dl_src, flow->dl_src, ETH_ADDR_LEN);
|
|
|
|
|
memcpy(match->dl_dst, flow->dl_dst, ETH_ADDR_LEN);
|
|
|
|
|
match->dl_type = flow->dl_type;
|
|
|
|
|
match->nw_src = flow->nw_src;
|
|
|
|
|
match->nw_dst = flow->nw_dst;
|
2010-01-21 17:34:05 -08:00
|
|
|
|
match->nw_tos = flow->nw_tos;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
match->nw_proto = flow->nw_proto;
|
|
|
|
|
match->tp_src = flow->tp_src;
|
|
|
|
|
match->tp_dst = flow->tp_dst;
|
2009-11-11 14:59:49 -08:00
|
|
|
|
memset(match->pad1, '\0', sizeof match->pad1);
|
|
|
|
|
memset(match->pad2, '\0', sizeof match->pad2);
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2010-11-05 11:10:35 -07:00
|
|
|
|
flow_from_match(const struct ofp_match *match, int flow_format,
|
2010-10-26 15:24:26 -07:00
|
|
|
|
ovs_be64 cookie, struct flow *flow, uint32_t *flow_wildcards)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
2010-05-10 18:23:18 -07:00
|
|
|
|
uint32_t wildcards = ntohl(match->wildcards);
|
2010-04-12 11:49:16 -04:00
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
|
flow->nw_src = match->nw_src;
|
|
|
|
|
flow->nw_dst = match->nw_dst;
|
2010-11-05 11:10:35 -07:00
|
|
|
|
if (flow_format == NXFF_TUN_ID_FROM_COOKIE && !(wildcards & NXFW_TUN_ID)) {
|
2010-04-12 11:49:16 -04:00
|
|
|
|
flow->tun_id = htonl(ntohll(cookie) >> 32);
|
2010-05-06 14:05:25 -07:00
|
|
|
|
} else {
|
2010-05-10 18:23:18 -07:00
|
|
|
|
wildcards |= NXFW_TUN_ID;
|
2010-05-06 14:05:25 -07:00
|
|
|
|
flow->tun_id = 0;
|
2010-04-12 11:49:16 -04:00
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
flow->in_port = (match->in_port == htons(OFPP_LOCAL) ? ODPP_LOCAL
|
|
|
|
|
: ntohs(match->in_port));
|
|
|
|
|
flow->dl_vlan = match->dl_vlan;
|
2009-11-11 14:59:49 -08:00
|
|
|
|
flow->dl_vlan_pcp = match->dl_vlan_pcp;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
flow->dl_type = match->dl_type;
|
|
|
|
|
flow->tp_src = match->tp_src;
|
|
|
|
|
flow->tp_dst = match->tp_dst;
|
|
|
|
|
memcpy(flow->dl_src, match->dl_src, ETH_ADDR_LEN);
|
|
|
|
|
memcpy(flow->dl_dst, match->dl_dst, ETH_ADDR_LEN);
|
2010-01-21 17:34:05 -08:00
|
|
|
|
flow->nw_tos = match->nw_tos;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
flow->nw_proto = match->nw_proto;
|
2010-05-10 18:23:18 -07:00
|
|
|
|
if (flow_wildcards) {
|
|
|
|
|
*flow_wildcards = wildcards;
|
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
char *
|
2010-09-03 11:30:02 -07:00
|
|
|
|
flow_to_string(const struct flow *flow)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
struct ds ds = DS_EMPTY_INITIALIZER;
|
|
|
|
|
flow_format(&ds, flow);
|
|
|
|
|
return ds_cstr(&ds);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2010-09-03 11:30:02 -07:00
|
|
|
|
flow_format(struct ds *ds, const struct flow *flow)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
2010-04-12 11:49:16 -04:00
|
|
|
|
ds_put_format(ds, "tunnel%08"PRIx32":in_port%04"PRIx16
|
|
|
|
|
":vlan%"PRIu16":pcp%"PRIu8
|
|
|
|
|
" mac"ETH_ADDR_FMT"->"ETH_ADDR_FMT
|
|
|
|
|
" type%04"PRIx16
|
|
|
|
|
" proto%"PRIu8
|
|
|
|
|
" tos%"PRIu8
|
|
|
|
|
" ip"IP_FMT"->"IP_FMT
|
|
|
|
|
" port%"PRIu16"->%"PRIu16,
|
|
|
|
|
ntohl(flow->tun_id),
|
|
|
|
|
flow->in_port,
|
|
|
|
|
ntohs(flow->dl_vlan),
|
|
|
|
|
flow->dl_vlan_pcp,
|
|
|
|
|
ETH_ADDR_ARGS(flow->dl_src),
|
|
|
|
|
ETH_ADDR_ARGS(flow->dl_dst),
|
|
|
|
|
ntohs(flow->dl_type),
|
|
|
|
|
flow->nw_proto,
|
|
|
|
|
flow->nw_tos,
|
|
|
|
|
IP_ARGS(&flow->nw_src),
|
|
|
|
|
IP_ARGS(&flow->nw_dst),
|
|
|
|
|
ntohs(flow->tp_src),
|
|
|
|
|
ntohs(flow->tp_dst));
|
2009-07-08 13:19:16 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2010-09-03 11:30:02 -07:00
|
|
|
|
flow_print(FILE *stream, const struct flow *flow)
|
2009-07-08 13:19:16 -07:00
|
|
|
|
{
|
|
|
|
|
char *s = flow_to_string(flow);
|
|
|
|
|
fputs(s, stream);
|
|
|
|
|
free(s);
|
|
|
|
|
}
|
2010-10-20 16:33:10 -07:00
|
|
|
|
|
|
|
|
|
/* flow_wildcards functions. */
|
|
|
|
|
|
|
|
|
|
/* Given the wildcard bit count in bits 'shift' through 'shift + 5' (inclusive)
|
|
|
|
|
* of 'wildcards', returns a 32-bit bit mask with a 1 in each bit that must
|
|
|
|
|
* match and a 0 in each bit that is wildcarded.
|
|
|
|
|
*
|
|
|
|
|
* The bits in 'wildcards' are in the format used in enum ofp_flow_wildcards: 0
|
|
|
|
|
* is exact match, 1 ignores the LSB, 2 ignores the 2 least-significant bits,
|
|
|
|
|
* ..., 32 and higher wildcard the entire field. This is the *opposite* of the
|
|
|
|
|
* usual convention where e.g. /24 indicates that 8 bits (not 24 bits) are
|
|
|
|
|
* wildcarded. */
|
|
|
|
|
ovs_be32
|
|
|
|
|
flow_nw_bits_to_mask(uint32_t wildcards, int shift)
|
|
|
|
|
{
|
|
|
|
|
wildcards = (wildcards >> shift) & 0x3f;
|
|
|
|
|
return wildcards < 32 ? htonl(~((1u << wildcards) - 1)) : 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-03 11:00:58 -07:00
|
|
|
|
/* Return 'wildcards' in "normal form":
|
|
|
|
|
*
|
|
|
|
|
* - Forces unknown bits to 0.
|
|
|
|
|
*
|
|
|
|
|
* - Forces nw_src and nw_dst masks greater than 32 to exactly 32.
|
|
|
|
|
*/
|
|
|
|
|
static inline uint32_t
|
|
|
|
|
flow_wildcards_normalize(uint32_t wildcards)
|
|
|
|
|
{
|
|
|
|
|
wildcards &= wildcards & OVSFW_ALL;
|
|
|
|
|
if (wildcards & (0x20 << OFPFW_NW_SRC_SHIFT)) {
|
|
|
|
|
wildcards &= ~(0x1f << OFPFW_NW_SRC_SHIFT);
|
|
|
|
|
}
|
|
|
|
|
if (wildcards & (0x20 << OFPFW_NW_DST_SHIFT)) {
|
|
|
|
|
wildcards &= ~(0x1f << OFPFW_NW_DST_SHIFT);
|
|
|
|
|
}
|
|
|
|
|
return wildcards;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 20:15:56 -07:00
|
|
|
|
/* Initializes 'wc' from 'wildcards', which may be any combination of the
|
|
|
|
|
* OFPFW_* and OVSFW_* wildcard bits. */
|
2010-10-20 16:33:10 -07:00
|
|
|
|
void
|
|
|
|
|
flow_wildcards_init(struct flow_wildcards *wc, uint32_t wildcards)
|
|
|
|
|
{
|
2010-11-03 11:00:58 -07:00
|
|
|
|
wc->wildcards = flow_wildcards_normalize(wildcards);
|
2010-10-20 16:33:10 -07:00
|
|
|
|
wc->nw_src_mask = flow_nw_bits_to_mask(wc->wildcards, OFPFW_NW_SRC_SHIFT);
|
|
|
|
|
wc->nw_dst_mask = flow_nw_bits_to_mask(wc->wildcards, OFPFW_NW_DST_SHIFT);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 20:15:56 -07:00
|
|
|
|
/* Initializes 'wc' as an exact-match set of wildcards; that is, 'wc' does not
|
|
|
|
|
* wildcard any bits or fields. */
|
|
|
|
|
void
|
|
|
|
|
flow_wildcards_init_exact(struct flow_wildcards *wc)
|
|
|
|
|
{
|
|
|
|
|
flow_wildcards_init(wc, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-03 11:00:58 -07:00
|
|
|
|
static inline uint32_t
|
|
|
|
|
combine_nw_bits(uint32_t wb1, uint32_t wb2, int shift)
|
|
|
|
|
{
|
|
|
|
|
uint32_t sb1 = (wb1 >> shift) & 0x3f;
|
|
|
|
|
uint32_t sb2 = (wb2 >> shift) & 0x3f;
|
|
|
|
|
return MAX(sb1, sb2) << shift;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Initializes 'dst' as the combination of wildcards in 'src1' and 'src2'.
|
|
|
|
|
* That is, a bit or a field is wildcarded in 'dst' if it is wildcarded in
|
|
|
|
|
* 'src1' or 'src2' or both. */
|
|
|
|
|
void
|
|
|
|
|
flow_wildcards_combine(struct flow_wildcards *dst,
|
|
|
|
|
const struct flow_wildcards *src1,
|
|
|
|
|
const struct flow_wildcards *src2)
|
|
|
|
|
{
|
|
|
|
|
uint32_t wb1 = src1->wildcards;
|
|
|
|
|
uint32_t wb2 = src2->wildcards;
|
|
|
|
|
|
|
|
|
|
dst->wildcards = (wb1 | wb2) & ~(OFPFW_NW_SRC_MASK | OFPFW_NW_DST_MASK);
|
|
|
|
|
dst->wildcards |= combine_nw_bits(wb1, wb2, OFPFW_NW_SRC_SHIFT);
|
|
|
|
|
dst->wildcards |= combine_nw_bits(wb1, wb2, OFPFW_NW_DST_SHIFT);
|
|
|
|
|
dst->nw_src_mask = src1->nw_src_mask & src2->nw_src_mask;
|
|
|
|
|
dst->nw_dst_mask = src1->nw_dst_mask & src2->nw_dst_mask;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns a hash of the wildcards in 'wc'. */
|
|
|
|
|
uint32_t
|
|
|
|
|
flow_wildcards_hash(const struct flow_wildcards *wc)
|
|
|
|
|
{
|
|
|
|
|
/* There is no need to include nw_src_mask or nw_dst_mask because they do
|
|
|
|
|
* not add any information (they can be computed from wc->wildcards). */
|
|
|
|
|
return hash_int(wc->wildcards, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'a' and 'b' represent the same wildcards, false if they are
|
|
|
|
|
* different. */
|
|
|
|
|
bool
|
|
|
|
|
flow_wildcards_equal(const struct flow_wildcards *a,
|
|
|
|
|
const struct flow_wildcards *b)
|
|
|
|
|
{
|
|
|
|
|
return a->wildcards == b->wildcards;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if at least one bit or field is wildcarded in 'a' but not in
|
|
|
|
|
* 'b', false otherwise. */
|
|
|
|
|
bool
|
|
|
|
|
flow_wildcards_has_extra(const struct flow_wildcards *a,
|
|
|
|
|
const struct flow_wildcards *b)
|
|
|
|
|
{
|
|
|
|
|
#define OFPFW_NW_MASK (OFPFW_NW_SRC_MASK | OFPFW_NW_DST_MASK)
|
|
|
|
|
return ((a->wildcards & ~(b->wildcards | OFPFW_NW_MASK))
|
|
|
|
|
|| (a->nw_src_mask & b->nw_src_mask) != b->nw_src_mask
|
|
|
|
|
|| (a->nw_dst_mask & b->nw_dst_mask) != b->nw_dst_mask);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 20:15:56 -07:00
|
|
|
|
static int
|
|
|
|
|
count_ones(ovs_be32 mask)
|
|
|
|
|
{
|
|
|
|
|
#if __GNUC__ >= 4
|
|
|
|
|
return __builtin_popcount(mask);
|
|
|
|
|
#else
|
|
|
|
|
int bits;
|
|
|
|
|
|
|
|
|
|
for (bits = 0; mask; bits++) {
|
|
|
|
|
mask &= mask - 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return bits;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
set_nw_mask(struct flow_wildcards *wc, ovs_be32 mask,
|
|
|
|
|
ovs_be32 *maskp, int shift)
|
|
|
|
|
{
|
|
|
|
|
int wcbits = 32 - count_ones(mask);
|
|
|
|
|
if (flow_nw_bits_to_mask(wcbits, 0) == mask) {
|
|
|
|
|
wc->wildcards &= ~(0x3f << shift);
|
|
|
|
|
wc->wildcards |= wcbits << shift;
|
|
|
|
|
*maskp = mask;
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Sets the IP (or ARP) source wildcard mask to CIDR 'mask' (consisting of N
|
|
|
|
|
* high-order 1-bit and 32-N low-order 0-bits). Returns true if successful,
|
|
|
|
|
* false if 'mask' is not a CIDR mask. */
|
|
|
|
|
bool
|
|
|
|
|
flow_wildcards_set_nw_src_mask(struct flow_wildcards *wc, ovs_be32 mask)
|
|
|
|
|
{
|
|
|
|
|
return set_nw_mask(wc, mask, &wc->nw_src_mask, OFPFW_NW_SRC_SHIFT);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Sets the IP (or ARP) destination wildcard mask to CIDR 'mask' (consisting of
|
|
|
|
|
* N high-order 1-bit and 32-N low-order 0-bits). Returns true if successful,
|
|
|
|
|
* false if 'mask' is not a CIDR mask. */
|
|
|
|
|
bool
|
|
|
|
|
flow_wildcards_set_nw_dst_mask(struct flow_wildcards *wc, ovs_be32 mask)
|
|
|
|
|
{
|
|
|
|
|
return set_nw_mask(wc, mask, &wc->nw_dst_mask, OFPFW_NW_DST_SHIFT);
|
|
|
|
|
}
|