Vxlan implementation doesn't provide a field to change it, do you know how we
can change it? I search ovs source code, there isn't a field to change tp_dst
in tunnel header.
Actions=set_field:
Or load:
Or move:
-----Original Message-----
From: Jiri Benc [mailto:[email protected]]
Sent: Thursday, November 24, 2016 9:16 PM
To: Yang, Yi Y <[email protected]>
Cc: Jan Scheurich <[email protected]>; Manuel Buil
<[email protected]>; [email protected]; Georgios
Paraskevopoulos ([email protected]) <[email protected]>;
Georg Schmuecking <[email protected]>; László Sürü
<[email protected]>
Subject: Re: Potential bug in NSH patch for OVS
On Thu, 24 Nov 2016 12:57:40 +0000, Yang, Yi Y wrote:
> I noticed vxlan module always uses tp_dst from tunnel metadata in
> preference to vxlan->cfg.dst_port, this isn't the result we want in
> some use cases, for example, if we create two vxlan port which have
> different dst_port, when we forward the packet from the first vxlan
> port to the second one, we need the packet should be sent out with the
> second vxlan port's dst_port as tp_dst, but current vxlan module will
> use that one from the first vxlan port, the source code in vxlan
> module and our experiment have confirmed this.
Ah, okay. That was not clear from the previous mail. And I don't follow the
ovs-discussion list.
> The line in file datapath/linux/compat/vxlan.c is here:
>
> dst_port = info->key.tp_dst ? : vxlan->cfg.dst_port;
>
> Anybody knows how we can change this? The below change seems more
> reasonable to me, or do we have some ways to dynamically change it by
> openflow actions?
>
> dst_port = vxlan->cfg.dst_port ? : info->key.tp_dst;
As I explained, this is wrong.
Probably ovs should clear the metadata that don't have "flow" specified in the
tunnel options when outputting to a tunnel. But that's a job for the openflow
translation layer, not for the kernel datapath.
Meanwhile, as a workaround, you should be able to set the destination port in
the openflow rule. Won't help for the NORMAL action, though.
Jiri
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
