Hi Ben,
2016-02-25, Ben Pfaff:
To allow having the best of both worlds (avoid perf penalty in all cases,
but avoid complex code to automatically determine whether recirculation is
needed or not), would it be possible to specify in a flow, after an mpls
match, whether or not recirculation is want
2016-02-26, Thomas Morin:
2016-02-25, Ben Pfaff:
Thomas: can you provide an example of the actions for your use case?
mpls,in_port=1,mpls_label=200,mpls_bos=1
actions=pop_mpls:0x0800,mod_dl_src:5a:19:2a:49:c1:ee,mod_dl_dst:fa:16:3e:2f:82:b0,output:220
220 being a patchport, a veth or a tap
Hi Ben,
2016-02-25, Ben Pfaff:
On Thu, Feb 25, 2016 at 10:26:28AM +0100, thomas.mo...@orange.com wrote:
Sorry to chime in a bit late, but this recirculation performance penalty for
the basic/key use-case where OVS receives an IP-in-MPLS frame and forwards
it to the destination (e.g. a local VM)
Hi Jesse, Simon,
It is great to see this work moving forward !
There is one cosmetic thing that we may want to address, which is how to
name these ports.
- I believe that it is better to avoid the l3 port naming, since they
will apply to all protocols that can be designated with an ethertype,
Hi Jarno, Lori,
On 12/10/2014 02:45 AM, Jarno Rajahalme wrote:
We should add a new metadata key field OVS_KEY_ATTR_PACKET_ETHERTYPE, that
contains the ethertype of the associated packet attribute. While this would be
strictly needed only for L3 packets, it would be cleaner to include it with a
Hi,
I ran into the same issue as the one described below (post on
ovs-discuss a few months back).
The goal is to use a vport tunnel configured to use a flow-based remote
IP, e.g:
ovs-vscl add-port br-vnet tun-port -- set Interface tun-port
type=gre options:remote_ip=flow
This works fin
