Hi all,
I am recently working on SDN and I was curious to visualize the OpenFlow
1.1 Sepc practically. I understand that OpenVSwitch supports adding of a
VLAN Tag using "mod_vlan_vid:XX" action(If there is no VLAN tag already).
Can someone please help me understand how it works (A code walk throug
On Thu, May 17, 2012 at 06:10:54PM -0700, Ben Pfaff wrote:
> On Fri, May 18, 2012 at 09:29:09AM +0900, Simon Horman wrote:
> > On Thu, May 17, 2012 at 09:48:23AM -0700, Ben Pfaff wrote:
> > > On Thu, May 17, 2012 at 05:59:09PM +0900, Simon Horman wrote:
> > > > This allows the tun_key tp be bassed
My Name is MRS ANGELA WILSON DUKE .Pls i want you to reply me back as soon as possible because i want to discuss something important with you,i wants to entrust $12.7 mill to your hand for charity work,waiting your reply for more info about this fund,MRS ANGELA WILSON DUKEFriends to go separate wa
On Fri, May 18, 2012 at 09:29:09AM +0900, Simon Horman wrote:
> On Thu, May 17, 2012 at 09:48:23AM -0700, Ben Pfaff wrote:
> > On Thu, May 17, 2012 at 05:59:09PM +0900, Simon Horman wrote:
> > > This allows the tun_key tp be bassed throughout user-space,
> > > attached to a flow. This is the essenc
On Thu, May 17, 2012 at 09:48:23AM -0700, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 05:59:09PM +0900, Simon Horman wrote:
> > This allows the tun_key tp be bassed throughout user-space,
> > attached to a flow. This is the essence of flow-based tunneling.
> >
> > This does not add tun_key or wildc
On Thu, May 17, 2012 at 09:52:05AM -0700, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 05:58:59PM +0900, Simon Horman wrote:
> > This series comprises a fresh batch of proposed changes to introduce
> > flow-based tunnelling.
> >
> > As things stands this series has a number of limitations, however a
On Thu, May 17, 2012 at 09:06:17AM -0700, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 09:00:18AM -0700, Ben Pfaff wrote:
> > On Thu, May 17, 2012 at 05:59:00PM +0900, Simon Horman wrote:
> > > this is a first pass at providing a tun_key which can be used
> > > as the basis for flow-based tunnelling.
On Thu, May 17, 2012 at 09:04:42AM -0700, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 05:59:02PM +0900, Simon Horman wrote:
> > Cc: Kyle Mestery
> > Signed-off-by: Simon Horman
>
> I think that this is inconsistent with patch 1, which I read as
> printing these attributes in the form "ipv4_tunnel
On Thu, May 17, 2012 at 12:17 PM, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 11:53:14AM -0700, Jesse Gross wrote:
>> It's possible that packets that are sent on internal devices (from
>> the OVS perspective) have already traversed the local IP stack.
>> After they go through the internal device, t
On Thu, May 17, 2012 at 12:01:45PM -0700, Justin Pettit wrote:
> Thanks for writing this up, Guru! Since we do have integrators that
> are not porting this to hypervisors, I took a crack at making it
> less hypervisor-specific. I've added my version below. What do you
> think?
>
> By the way, w
On Thu, May 17, 2012 at 11:53:14AM -0700, Jesse Gross wrote:
> It's possible that packets that are sent on internal devices (from
> the OVS perspective) have already traversed the local IP stack.
> After they go through the internal device, they will again travel
> through the IP stack which may ge
Thanks for writing this up, Guru! Since we do have integrators that are not
porting this to hypervisors, I took a crack at making it less
hypervisor-specific. I've added my version below. What do you think?
By the way, we're accumulating a lot of docs in the root directory. What do
people t
It's possible that packets that are sent on internal devices (from
the OVS perspective) have already traversed the local IP stack.
After they go through the internal device, they will again travel
through the IP stack which may get confused by the presence of
existing information in the skb. This
On Thu, May 17, 2012 at 05:58:59PM +0900, Simon Horman wrote:
> This series comprises a fresh batch of proposed changes to introduce
> flow-based tunnelling.
>
> As things stands this series has a number of limitations, however as it is
> a rather large change I wanted to get something out for rev
On Thu, May 17, 2012 at 05:59:09PM +0900, Simon Horman wrote:
> This allows the tun_key tp be bassed throughout user-space,
> attached to a flow. This is the essence of flow-based tunneling.
>
> This does not add tun_key or wildcards, other than the existing match for
> the tun_id. It is envisaged
On Thu, May 17, 2012 at 09:00:18AM -0700, Ben Pfaff wrote:
> On Thu, May 17, 2012 at 05:59:00PM +0900, Simon Horman wrote:
> > this is a first pass at providing a tun_key which can be used
> > as the basis for flow-based tunnelling. The tun_key includes and
> > replaces the tun_id in both struct ov
On Thu, May 17, 2012 at 05:59:02PM +0900, Simon Horman wrote:
> Cc: Kyle Mestery
> Signed-off-by: Simon Horman
I think that this is inconsistent with patch 1, which I read as
printing these attributes in the form "ipv4_tunnel(...)" not
"tun_key(...)". The output form should be valid for input.
On Thu, May 17, 2012 at 05:59:00PM +0900, Simon Horman wrote:
> this is a first pass at providing a tun_key which can be used
> as the basis for flow-based tunnelling. The tun_key includes and
> replaces the tun_id in both struct ovs_skb_cb and struct sw_tun_key.
>
> In ovs_skb_cb tun_key is a poi
As tunndevs no longer have a daddr the cache can no longer built in this way.
Furthermore, its not clear to me what the value of keeping the cache is in
the context of moving towards allowing use of in-tree tunnelling.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 383 ++
The lookup is now only based on the net and tunnel type.
It should be possible to either get rid of the lookup alltogether
or push it into the GRE and CAPWAP implementations, but this
change is simpler for now
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 110 +++--
The tun_key should always be present and correct.
Mutable no longer stores correct address information
and the saddr and daddr fields will be removed.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 42 +-
1 file changed, 17 inserti
On the user-space side of things, the existing tunnel classes become tunnel
realdev classes and new classes are added to provide tunnel tundevs.
On the datpath side of things, the existing tunnel vports are used as
tundev vports. A new vport is added for tunnel realdevs.
It should be possible to
tun_key should always be present and correct in ovs_tnl_send()
It ought to be possible to handle the ttl entirely
in user-space. This is not implemented yet. However, the
TNL_F_TOS_INHERIT is currently never set.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 10 ++-
Multicast may be handled in user-space (but isn't yet).
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 22 --
datapath/tunnel.h |3 ---
2 files changed, 25 deletions(-)
diff --git a/datapath/tunnel.c b/datapath/tunnel.c
index bad6846..29d2a0b 100
OVS_KEY_ATTR_TUN_ID may now be removed as it is
no longer used in any meaningful way.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/datapath.c |1 -
datapath/flow.c |1 -
include/linux/openvswitch.h |1 -
lib/dpif-netdev.c |1 -
lib/odp-
This allows the tun_key tp be bassed throughout user-space,
attached to a flow. This is the essence of flow-based tunneling.
This does not add tun_key or wildcards, other than the existing match for
the tun_id. It is envisaged that most if not all fields of the tun_key
could be wildcarded.
Cc: Ky
In essence this is a duplication of ovs_tnl_find_port(),
copying code from the datapath to vswitchd. It is planned
that the datapath version will be removed.
It is used to map from the tundev interface that a
packet is recieved by in the datapath to the tunnel realdev
interface used in user-sapce.
For tunnel realdevs this sets the remote IP and type,
and optionally source IP, ttl and tos. The remote IP
must non-zero.
For tunnel tundevs only the type is configured.
The remote IP must be zero.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
vswitchd/bridge.c | 69 ++
This is used to map a tunnel or VLAN realdevs to
tundev and vlandevs respectively. This is used
on transmit to map fromt the interface used
in user-space to the interface used in the datapath.
In the case where an interface is not a tunnel
and does not have VLAN splinters configured
a identity map
Add tunnel tundevs for tunnel realdevs as needed.
In general the notion is that realdevs may be configured by users
and from an end-user point of view are compatible with the existing
port-based tunneling code. And that tundevs exist in the datapath
arnd are actually used to send and recieve packe
Allow configuration of tunneling in ofproto_port instances.
For tunnel realdevs this includes the remote IP of the and type tunnel,
and optionally the local IP, tos and ttl.
For tunnel tundevs it only includes the type.
realdevs and tundevs can be differentiated by examining the remote IP,
which
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
include/linux/openvswitch.h | 11 +++
lib/odp-util.c | 12 ++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/include/linux/openvswitch.h b/include/linux/openvswitch.h
index 1ce021c..bf0b8f1 10064
In essence this attached the tun_key, if any,
to the output processing of a packet. This allows
it the packet to be transmitted using flow-based
tunneling as necessary.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
ofproto/ofproto-dpif.c | 16 +---
1 file changed, 13 insertions
this is a first pass at providing a tun_key which can be used
as the basis for flow-based tunnelling. The tun_key includes and
replaces the tun_id in both struct ovs_skb_cb and struct sw_tun_key.
In ovs_skb_cb tun_key is a pointer as it is envisaged that it will grow
when support for IPv6 to an ex
This duplicates parse_tunnel_config, the duplication will later be minimised.
iface_parse_tunnel() is currently only used to verify the configuration
by passing NULL as its third argument. It will later be used in storing
the configuration by passing a non-NULL argument. The purpose of verificatio
Hi,
This series comprises a fresh batch of proposed changes to introduce
flow-based tunnelling.
As things stands this series has a number of limitations, however as it is
a rather large change I wanted to get something out for review before it
grows even further.
The good news (for me at least)
Use the tun_key, which is the basis of flow-based tunnelling, on transmit.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
datapath/tunnel.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/datapath/tunnel.c b/datapath/tunnel.
Cc: Kyle Mestery
Signed-off-by: Simon Horman
---
lib/odp-util.c | 24
1 file changed, 24 insertions(+)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 2829a85..7316e19 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -927,6 +927,30 @@ parse_odp_key_attr(const ch
38 matches
Mail list logo
