[ovs-dev] [ovs-discuss] gre tunnel create problem
rkerur at gmail.com
Mon Jun 25 17:40:50 PDT 2012
On Mon, Jun 25, 2012 at 3:33 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Thu, Jun 21, 2012 at 2:54 PM, ravi kerur <rkerur at gmail.com> wrote:
>> I would like to restart this discussion as I am having trouble with
>> configuration + performance. I would like send just tcp traffic via
>> gre tunnel and would like to push a vlan tag before sending via gre
>> tunnel. On receive side after gre decapsulation, match should happen
>> on vlan_vid and configured actions executed. I don't think it is
>> possible to do this in ovs currently based on what you had described
>> earlier in another thread, but just want to check again if its indeed
>> possible then how the flows should be configured on receive side.
>> On Tx side I have flows configured to match (gre_port = 2, eth_port = 1)
>> dl_type=0x0800, nw_proto=6, nw_src=<src-ip>,nw-dst=<dst-ip>,
>> dl_type=0x0800, nw_proto=47, nw_src=<src-ip>, nw-dst=<dst-ip>, actions=1
>> via tcpdump I see vlan packets encapsulated in gre header.
>> on Rx side, I had configured
>> dl_type=0x0800,nw_proto=47,nw_src=<dst-ip>, nw-dst=<src-ip>, actions=resubmit:2
> This flow doesn't decapsulate the packet, it just matches on the fact
> that it is GRE. If you want to decapsulate it, you should use a GRE
<rk> use GRE vport where? in actions or flow-matching? I had tried it
in actions by setting actions=2 and in didn't work. Are there example
configuration for this, it will be really helpful? I didn't see any on
>> For packets coming in, first flow is matched for gre, second flow is
>> never matched.
>> If i change second flow to
>> packets are matched but performance is bad. I am getting around
>> 100Kbits/s on a 1G nic. If I understand correctly, part of the issue
>> is that resubmit action is in userspace, but the bigger question is
>> why first config on the Rx side doesn't work?
> The flow setup for resubmit is handled in userspace but that doesn't
> mean that all packets go through userspace. It means that the
> resulting flow can only be based on the data in the headers available
> in a single pass.
More information about the dev