Re: [ovs-discuss] D-NAT rule
Please read the FAQ. http://docs.openvswitch.org/en/latest/faq/releases/ On Wed, Dec 14, 2016 at 09:49:31PM -0800, Joo Yong-Seok wrote: > Thanks. Current kernel version is 3.3.8. If we upgrade OVS only (to 2.6 or > latest), is it ok to work with that kernel version? or do I need to upgrade > kernel as well? > > BTW, I am working with openwrt. > > Best regards, > > - yongseok > > On Wed, Dec 14, 2016 at 9:05 PM, Ben Pfaff wrote: > > > On Wed, Dec 14, 2016 at 05:12:12PM -0800, Joo Yong-Seok wrote: > > > Is it possible to configure D-NAT rule in this version of ovs-ofctl? > > > > > > # ovs-ofctl --version > > > ovs-ofctl (Open vSwitch) 2.3.90 > > > Compiled Dec 12 2016 23:20:48 > > > OpenFlow versions 0x1:0x4 > > > > ... > > > > > It seems that ct action is not supported by this version. Any resolution > > > for this? > > > > Upgrade. > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] D-NAT rule
Thanks. Current kernel version is 3.3.8. If we upgrade OVS only (to 2.6 or latest), is it ok to work with that kernel version? or do I need to upgrade kernel as well? BTW, I am working with openwrt. Best regards, - yongseok On Wed, Dec 14, 2016 at 9:05 PM, Ben Pfaff wrote: > On Wed, Dec 14, 2016 at 05:12:12PM -0800, Joo Yong-Seok wrote: > > Is it possible to configure D-NAT rule in this version of ovs-ofctl? > > > > # ovs-ofctl --version > > ovs-ofctl (Open vSwitch) 2.3.90 > > Compiled Dec 12 2016 23:20:48 > > OpenFlow versions 0x1:0x4 > > ... > > > It seems that ct action is not supported by this version. Any resolution > > for this? > > Upgrade. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] D-NAT rule
On Wed, Dec 14, 2016 at 05:12:12PM -0800, Joo Yong-Seok wrote: > Is it possible to configure D-NAT rule in this version of ovs-ofctl? > > # ovs-ofctl --version > ovs-ofctl (Open vSwitch) 2.3.90 > Compiled Dec 12 2016 23:20:48 > OpenFlow versions 0x1:0x4 ... > It seems that ct action is not supported by this version. Any resolution > for this? Upgrade. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] D-NAT rule
Sorry, conntrack support was added in 2.5 and NAT in 2.6.
--Ben
> On Dec 14, 2016, at 5:12 PM, Joo Yong-Seok wrote:
>
> Is it possible to configure D-NAT rule in this version of ovs-ofctl?
>
> # ovs-ofctl --version
> ovs-ofctl (Open vSwitch) 2.3.90
> Compiled Dec 12 2016 23:20:48
> OpenFlow versions 0x1:0x4
>
> It seems that openvswitch is 2.3.90 and openflow is 1.1 to 1.3.
>
> Somehow, I am hitting following errors wit this version.
>
> # ovs-ofctl add-flow br-home
> table=0,in_port=1,ip,action=ct"("commit,zone=1,nat"("src=1.1.1.10-1.1.1.254"))",2
>
> ovs-ofctl: unknown action ct
>
> It seems that ct action is not supported by this version. Any resolution for
> this?
>
> Best regards,
>
> - yongseok
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] D-NAT rule
Is it possible to configure D-NAT rule in this version of ovs-ofctl?
# ovs-ofctl --version
ovs-ofctl (Open vSwitch) 2.3.90
Compiled Dec 12 2016 23:20:48
OpenFlow versions 0x1:0x4
It seems that openvswitch is 2.3.90 and openflow is 1.1 to 1.3.
Somehow, I am hitting following errors wit this version.
# ovs-ofctl add-flow br-home
table=0,in_port=1,ip,action=ct"("commit,zone=1,nat"("src=1.1.1.10-1.1.1.254"))",2
ovs-ofctl: unknown action ct
It seems that ct action is not supported by this version. Any resolution
for this?
Best regards,
- yongseok
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] MTU on ovs bridge
I have read articles online that an OVS bridge defaults to the MTU of the port that has the lowest configured MTU value. I wanted to confirm if this is in fact true. Is it not possible that the bridge has ports belonging to different segments (say segmented by vlan) and is not then possible that ports in each of these segments have a different configured MTU value? Thanks, Vijay ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Packets not forwarded to queues after hitting flows in OVS QoS
Open vSwitch has no control over how Linux does IP masquerading. I don't know what IP masquerading does to a packet's skb_priority, nor do I know how you configured IP masquerading, so I don't know the answer. On Wed, Dec 14, 2016 at 11:36:05AM +0100, Santhosh R P wrote: > Hi Ben, > > In the case where IP masquerading takes place, the packet from VM1 at > in_port(3) > is forwarded to enp0s25 at in_port(2) for masquerading, and then after > masquerading, the packet leaves from in_port(2) to in_port(1) for egress > queues and then transmission. > > If there is no masquerading, will the packet from VM1 at in_port(3) be > directly forwarded to in_port(1) ? > > I am new to OVS to suggest you anything now and have to make another setup > without masquerading to verify this, so asking you to confirm if this is > how it should be. Thanks for your help. > > Best Regards, > Santhosh. > > On Tue, Dec 13, 2016 at 9:54 PM, Ben Pfaff wrote: > > > On Tue, Dec 13, 2016 at 08:40:41PM +0100, Santhosh R P wrote: > > > When I add a flow like this, > > > > > > ovs-ofctl add-flow test priority=2000,in_port=2, > > actions=set_queue:1,normal > > > > > > ovs-dpctl dump-flows shows this (captured during the test): > > > > > > recirc_id(0),skb_priority(0),in_port(3),eth(src=52:54:00: > > 3e:2c:cf,dst=90:1b:0e:06:0e:c4),eth_type(0x0800),ipv4(frag=no), > > > packets:21617, bytes:904012530, used:0.000s, flags:SP., > > > actions:set(skb_priority(0x10002)),2 > > > recirc_id(0),in_port(2),eth(src=90:1b:0e:06:0e:c4,dst=00: > > 00:5e:00:01:01),eth_type(0x0800),ipv4(frag=no), > > > packets:21652, bytes:904023433, used:0.000s, flags:SP., actions:1 > > > > > > I see that the packet from VM1 in in_port(3) is set with > > > skb_priority(0x10002) and sent to port 2. Here, masquerading takes place > > > and the packet is sent out from the host at port 1. Before the packet > > > reaches the created egress queues, the skb_priority is reset. The > > > masqueraded packet reaches the default queue and no QoS takes place. > > > > If you have IP masquerading configured, and masquerading resets the > > skb_priority, then I'm not sure what OVS can do about that. What do you > > suggest? > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] It takes too long to create 512 bridges in ovs2.5.0
Hi, all In my test scenario, I found that it takes too long time, 488s, to create 512 bridges in ovs 2.5.0. After analyzing the code and some tests, I found that more than 70% of the time was consumed in the implementation of function xlate_txn_commit. Function type_run calls xlate_txn_start and xlate_txn_commit(calls ovsrcu_synchronize) to implement RCU locking in each cycle of the loop. Function ovsrcu_synchronize() was called too much times if there are certain number bridges, which means a lot of time waste. So, I was thinking if I can use ovsrcu_postpone replacing ovsrcu_synchronize to shorten the execution time of type_run when there are certain number bridges. I have tested this, and the result indicates that the time of creating 512 bridges will be short down to 269s. Result and my patch is as follows: ovsrcu_postpone ovsrcu_synchronize ovs 269 488 This is my patch: ofproto/ofproto-dpif-xlate.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index d5f18b6..59f4b5c 100644 --- a/ofproto/ofproto-dpif-xlate.c +++ b/ofproto/ofproto-dpif-xlate.c @@ -865,8 +865,9 @@ xlate_txn_commit(void) struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, &xcfgp); ovsrcu_set(&xcfgp, new_xcfg); -ovsrcu_synchronize(); -xlate_xcfg_free(xcfg); +ovsrcu_postpone(xlate_xcfg_free, xcfg); new_xcfg = NULL; } Whether this modification will introduce any problems? Any reply will be appreciated! Thanks for all the attention! B.R. Sha Zhang ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Packets not forwarded to queues after hitting flows in OVS QoS
Hi Ben, In the case where IP masquerading takes place, the packet from VM1 at in_port(3) is forwarded to enp0s25 at in_port(2) for masquerading, and then after masquerading, the packet leaves from in_port(2) to in_port(1) for egress queues and then transmission. If there is no masquerading, will the packet from VM1 at in_port(3) be directly forwarded to in_port(1) ? I am new to OVS to suggest you anything now and have to make another setup without masquerading to verify this, so asking you to confirm if this is how it should be. Thanks for your help. Best Regards, Santhosh. On Tue, Dec 13, 2016 at 9:54 PM, Ben Pfaff wrote: > On Tue, Dec 13, 2016 at 08:40:41PM +0100, Santhosh R P wrote: > > When I add a flow like this, > > > > ovs-ofctl add-flow test priority=2000,in_port=2, > actions=set_queue:1,normal > > > > ovs-dpctl dump-flows shows this (captured during the test): > > > > recirc_id(0),skb_priority(0),in_port(3),eth(src=52:54:00: > 3e:2c:cf,dst=90:1b:0e:06:0e:c4),eth_type(0x0800),ipv4(frag=no), > > packets:21617, bytes:904012530, used:0.000s, flags:SP., > > actions:set(skb_priority(0x10002)),2 > > recirc_id(0),in_port(2),eth(src=90:1b:0e:06:0e:c4,dst=00: > 00:5e:00:01:01),eth_type(0x0800),ipv4(frag=no), > > packets:21652, bytes:904023433, used:0.000s, flags:SP., actions:1 > > > > I see that the packet from VM1 in in_port(3) is set with > > skb_priority(0x10002) and sent to port 2. Here, masquerading takes place > > and the packet is sent out from the host at port 1. Before the packet > > reaches the created egress queues, the skb_priority is reset. The > > masqueraded packet reaches the default queue and no QoS takes place. > > If you have IP masquerading configured, and masquerading resets the > skb_priority, then I'm not sure what OVS can do about that. What do you > suggest? > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
