[ovs-discuss] Reg. OVS 2.13 release announcement

[Vishal Deep Ajmera via discuss]

Hi,

 

I was wondering if any official announcement had been made for OVS 2.13
release in Feb, 2020. I probably missed it but I could not locate it on the
official openvswitch.org webpage either.

 

Can someone help with the link to the ovs-2.13 tar ball?

 

Warm Regards,

Vishal Ajmera

 



smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Reg. OVS + DPDK in containers

[Vishal Deep Ajmera via discuss]

Hi,

Does anyone know of any performance impact of running OVS + DPDK in a docker
container environment v/s running it on bare-metal ?

Are there any known functional limitations when running inside a container ?
We primarily use "netdev" bridges with "vhostuserclient" ports to connect to
guest VMs.

Regards,
Vishal


smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg. ofport set to -1

[Vishal Deep Ajmera]

Hi,

Gentle reminder for folks to share their thoughts. We have a potential fix for 
this issue wherein we do not release the ofport number until the failed port is 
deleted from the ovsdb. Once the failed port is deleted from the ovsdb, the 
ofport number is appended to the LRU list.

Does this make sense ?

Regards,
Vishal

From: Vishal Deep Ajmera
Sent: Tuesday, November 27, 2018 11:17 AM
To: Vishal Deep Ajmera ; 
ovs-discuss@openvswitch.org
Subject: RE: Reg. ofport set to -1

Anyone faced similar issue with other controllers?

From: 
ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org> 
mailto:ovs-discuss-boun...@openvswitch.org>>
 On Behalf Of Vishal Deep Ajmera
Sent: Wednesday, November 21, 2018 2:14 PM
To: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>
Subject: [ovs-discuss] Reg. ofport set to -1

Hi,

Currently in OVS we set "-1" for ofport field in interface table of OVS DB when 
we fail to initialize the interface. This means if we had allocated any ofport 
number earlier, it is released. When the above failed interface gets 
initialized successfully later it gets a "new" ofport number again. Due to 
change in ofport number, any SDN controller will have to change all the 
openflows corresponding to this interface (due to change in port number). I am 
not sure why we release the ofport number for the interface, unless it is 
deleted from the interface table itself.

Does it make sense to preserve the ofport number as long as the interface is 
present in OVS DB and release it once it is deleted? This will help controller 
not to modify existing flows but only replay (resync) the same, once interface 
comes back alive.

Need some guidance here how to handle such cases.

Warm Regards,
Vishal Ajmera


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-master crashes due to double locking of ofproto_mutex.

[Vishal Deep Ajmera]

Hi Ben, Jarno,

I am not sure why we have to take a lock (ofproto_mutex) for processing 
packet-out action. I think this action does not modify any open flow table. I 
could see that lock is required for actions like flow_add/flow_mod etc. as they 
are modifying the existing flow tables.

Any pointers for reasoning behind this will be very helpful. We are frequently 
hitting this scenario in our deployment and as you see below, it is quite easy 
to reproduce this by a set of open flow rules.

Warm Regards,
Vishal Ajmera

Following commit id introduced this lock in handle_packet_out:

commit 1f4a893366826e392722d5b1ba59e94331bfe5c9
Author: Jarno Rajahalme 
Date:   Wed Sep 14 16:51:27 2016 -0700

ofproto: Refactor packet_out handling.

Refactor handle_packet_out() to prepare for bundle support for packet
outs in a later patch.

Two new callbacks are introduced in ofproto-provider class:
->packet_xlate() and ->packet_execute().  ->packet_xlate() translates
the packet using the flow and actions provided by the caller, but
defers all OpenFlow-visible side-effects (stats, learn actions, actual
packet output, etc.) to be explicitly executed with the
->packet_execute() call.

Adds a new ofproto_rule_reduce_timeouts__() that must be called with
'ofproto_mutex' held.  This is used in the next patch.

Signed-off-by: Jarno Rajahalme 
Acked-by: Ben Pfaff 


From: ovs-discuss-boun...@openvswitch.org  
On Behalf Of Anil Kumar Koli via discuss
Sent: Wednesday, April 3, 2019 3:37 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] ovs-master crashes due to double locking of 
ofproto_mutex.

Hello OVS team,

OVS crash is observed in ovs-master when controller sends a packet with 
packet-out (output port as OFPP_TABLE) and any of the openflow table entry 
which gets hit results into a learn action.

Steps to reproduce:
1. Start the ovs-vswitchd in dpdk mode.
2. Configure the following flows
ovs-ofctl -OOpenflow13 add-flow br-int "table=0, priority=50, ct_state=-trk,ip, 
in_port=10 actions=ct(table=0)"
ovs-ofctl -OOpenflow13 add-flow br-int "table=0, priority=50, ct_state=+trk,ip, 
in_port=10 actions=ct(commit),resubmit(,1)"
ovs-ofctl -OOpenflow13 add-flow br-int "table=1 
actions=learn(table=2,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15],
 output:NXM_NX_REG0[0..15]),resubmit(,2)"
3. Send a packet with output as OFPP_TABLE
ovs-ofctl -OOpenflow13 packet-out br-int 'in_port=10 
packet=505400071011080045284006f97cc0a80001c0a800020008000a50022e7d,
 actions=TABLE'

This leads to a crash which is a case of double locking of oproto_mutex in 
handle_packet_out and ofproto_flow_mod_learn.
Can some one provide more insight of introducing ofproto_mutex lock in 
handle_packet_out which is the cause for above crash?

Please find the backtrace in the attachment.

Thanks & Regards,
Anil Kumar.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] of rules deleted on controller disconnect

[Vishal Deep Ajmera]

I think you need to set "fail-mode=secure" for the bridge connected to 
controller. By default it will be set as "standalone".

From: ovs-discuss-boun...@openvswitch.org  
On Behalf Of Alon Dotan
Sent: Tuesday, April 2, 2019 5:08 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] of rules deleted on controller disconnect

Hey,
Im using OVS 2.9.2 with faucet controller, when the controller disconnect all 
the of rules deleted...
how I can make the rules agnostic to controller disconnections?
Thanks,
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs 2.8.2 crash

[Vishal Deep Ajmera]

Hi,

I think this issue can be hit always when controller sends a packet with 
packet-out (output port as OFPP_TABLE) and any of the open-flow table entry 
which gets hit results into learn action.

Am I missing something?

Warm Regards,
Vishal Ajmera

From: ovs-discuss-boun...@openvswitch.org  
On Behalf Of Anil Kumar Koli via discuss
Sent: Friday, March 29, 2019 9:18 AM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] ovs 2.8.2 crash

Hello OVS team,

I have a ovs-vswitched crash of ovs version 2.8.2. I don't have the flow which 
has lead to this crash, but from the backtrace I could see that the crash is 
because of double locking. The ofproto_mutex lock is acquired in 
handle_packet_out() and the same lock is being tried to acquire in 
ofproto_flow_mod_learn().  I have the following questions?

  1.  Can we have a flow which can have both OFPACT_OUTPUT and OFPACT_LEARN to 
the same packet? If yes then we will a case of double lock issue.



  1.  I have not seen any such issue reported in upstream yet and this is a 
general case of controller to ovs communication.



  1.  Ofproto_muxtex locking in ofproto_flow_mod_learn() is obvious because, 
the pmd thread will be performing the actions.



  1.  Any usecase where we might hit this kind of open flow actions.



root@ubuntu16:/home/sdn/openvswitch# ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.8.2
DB Schema 7.15.0

root@ubuntu16:/home/sdn/openvswitch# gdb /usr/sbin/ovs-vswitchd 
../../core.compute-0-7.domain.tld.1552010169.ovs-vswitchd.66327
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/ovs-vswitchd...Reading symbols from 
/usr/lib/debug/.build-id/34/7e6150fd3a987639b05b2c297955d248b4d624.debug...done.
done.
[New LWP 66327]
[New LWP 66340]
[New LWP 66339]
[New LWP 66341]
[New LWP 66342]
[New LWP 66328]
[New LWP 66332]
[New LWP 66333]
[New LWP 66334]
[New LWP 66343]
[New LWP 66344]
[New LWP 66371]
[New LWP 66335]
[New LWP 66372]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `ovs-vswitchd unix:/var/run/openvswitch/db.sock 
-vconsole:emer -vsyslog:err -vfi'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f2f021e7428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2f0397cb00 (LWP 66327))]
(gdb) bt
#0  0x7f2f021e7428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f2f021e902a in __GI_abort () at abort.c:89
#2  0x0078de4e in ovs_abort_valist (err_no=, 
format=, args=args@entry=0x7ffc2630db28) at lib/util.c:347
#3  0x0078ded7 in ovs_abort (err_no=, 
format=format@entry=0x8cd4e9 "%s: pthread_%s_%s failed") at lib/util.c:339
#4  0x0075f439 in ovs_mutex_lock_at (l_=l_@entry=0xbc3c80 
, where=where@entry=0x8a1cd3 "ofproto/ofproto.c:5117") at 
lib/ovs-thread.c:76
#5  0x006a155f in ofproto_flow_mod_learn (ofm=ofm@entry=0x7ffc2630eab0, 
keep_ref=, limit=, 
below_limitp=below_limitp@entry=0x7ffc2630ea50) at ofproto/ofproto.c:5117
#6  0x006bd704 in xlate_learn_action (ctx=ctx@entry=0x7ffc26311f00, 
learn=learn@entry=0x32eab58) at ofproto/ofproto-dpif-xlate.c:5216
#7  0x006c06e3 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7ffc26311f00, 
group_bucket_action=group_bucket_action@entry=false)
at ofproto/ofproto-dpif-xlate.c:6580
#8  0x006c1f70 in xlate_recursively (deepens=false, rule=0x32ea9b0, 
ctx=0x7ffc26311f00) at ofproto/ofproto-dpif-xlate.c:4005
#9  xlate_table_action (ctx=0x7ffc26311f00, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=, with_ct_orig=)
at ofproto/ofproto-dpif-xlate.c:4131
#10 0x006bfdb1 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7ffc26311f00, 
group_bucket_action=group_bucket_action@entry=false)
at ofproto/ofproto-dpif-xlate.c:6631
#11 0x006c1f70 in xlate_recursively (deepens=false, rule=0x31ae620, 
ctx=0x7ffc26311f00) at ofproto/ofproto-dpif-xlate.c:4005
#12 xlate_table_action (ctx=0x7ffc26311f00, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=, with_ct_orig=)
at ofproto/ofproto-dpif-xlate.c:4131
#13 0x006bfdb1 

Re: [ovs-discuss] Reg. ofport set to -1

[Vishal Deep Ajmera]

Anyone faced similar issue with other controllers?

From: ovs-discuss-boun...@openvswitch.org  
On Behalf Of Vishal Deep Ajmera
Sent: Wednesday, November 21, 2018 2:14 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Reg. ofport set to -1

Hi,

Currently in OVS we set "-1" for ofport field in interface table of OVS DB when 
we fail to initialize the interface. This means if we had allocated any ofport 
number earlier, it is released. When the above failed interface gets 
initialized successfully later it gets a "new" ofport number again. Due to 
change in ofport number, any SDN controller will have to change all the 
openflows corresponding to this interface (due to change in port number). I am 
not sure why we release the ofport number for the interface, unless it is 
deleted from the interface table itself.

Does it make sense to preserve the ofport number as long as the interface is 
present in OVS DB and release it once it is deleted? This will help controller 
not to modify existing flows but only replay (resync) the same, once interface 
comes back alive.

Need some guidance here how to handle such cases.

Warm Regards,
Vishal Ajmera


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Reg. ofport set to -1

[Vishal Deep Ajmera]

Hi,

Currently in OVS we set "-1" for ofport field in interface table of OVS DB when 
we fail to initialize the interface. This means if we had allocated any ofport 
number earlier, it is released. When the above failed interface gets 
initialized successfully later it gets a "new" ofport number again. Due to 
change in ofport number, any SDN controller will have to change all the 
openflows corresponding to this interface (due to change in port number). I am 
not sure why we release the ofport number for the interface, unless it is 
deleted from the interface table itself.

Does it make sense to preserve the ofport number as long as the interface is 
present in OVS DB and release it once it is deleted? This will help controller 
not to modify existing flows but only replay (resync) the same, once interface 
comes back alive.

Need some guidance here how to handle such cases.

Warm Regards,
Vishal Ajmera


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

[Vishal Deep Ajmera]

> >
> > Vishal, will you send a patch to do that?
> >
> 
> Thanks Ben and Ethan for reviewing. I will send a patch to fix this on 
> dev-list.
> 
Hi Ben, Ethan,

I have sent a patch fixing this issue on mailing list for review.

Warm Regards,
Vishal
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

[Vishal Deep Ajmera]

> 
> Thanks.  After staring at it for a while, I think I'm comfortable with 
> removing it.
> 
> Vishal, will you send a patch to do that?
> 

Thanks Ben and Ethan for reviewing. I will send a patch to fix this on dev-list.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

[Vishal Deep Ajmera]

> 
> At first glance it looks like you're correct, but this code was added in
> 2013 with the following commit and hasn't changed since, so I wonder whether
> we're missing something important.  Ethan, you wrote this code, do you have
> any thoughts?
> 
> commit e79a6c833e0d72370951d6f8841098103cbb0b2d
> Author:   Ethan J. Jackson   Tue Sep 24 13:39:56
> 2013
> Committer:Ethan J. Jackson   Thu Dec 19 
> 13:27:23
> 2013
> 
> ofproto: Handle flow installation and eviction in upcall.
> 
> This patch moves flow installation and eviction from ofproto-dpif and
> the main thread, into ofproto-dpif-upcall.  This performs
> significantly better (approximately 2x TCP_CRR improvement), and
> allows ovs-vswitchd to maintain significantly larger datapath flow
> tables.  On top of that, it significantly simplifies the code,
> retiring "struct facet" and friends.
> 
> Signed-off-by: Ethan Jackson 
> Acked-by: Ben Pfaff 

Thanks Ben for looking into this issue. Should I send a formal patch
for review by removing this check (n_flows > 2000) ?

Warm Regards,
Vishal Ajmera
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

[Vishal Deep Ajmera]

Hi,



The udpif_revalidator function uses dump-duration time to determine the flow 
limit and tunes it as per system conditions for e.g. if duration is more, flow 
limit is reduced and vice-versa. However I notice one issue with the logic used 
in the implementation:



if (duration > 2000) {

flow_limit /= duration / 1000;

} else if (duration > 1300) {

flow_limit = flow_limit * 3 / 4;

} else if (duration < 1000 && n_flows > 2000

   && flow_limit < n_flows * 1000 / duration) {

flow_limit += 1000;

}



The issue is with small number of flows (n_flows < 2000). When revalidator does 
not get sufficient cpu cycles to run (duration > 2000) and the flow_limit is 
reduced to < 2000. Now, even if revalidator gets sufficient cycles from cpu 
(duration < 1000) the flow_limit will not increase since n_flows is still 
small. Also, it will not allow for addition of new flows due to low flow_limit. 
This result in ovs stuck with low flow-limit and no automatic recovery.



In my opinion the check n_flows > 2000 is incorrect in above code. Is my 
understanding correct or am I missing something ?

Warm Regards,

Vishal Ajmera




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg. ofproto: ofproto_rule_insert__

[Vishal Deep Ajmera]

Hi Ben,

I have sent patch for review on dev mailing list. If approved for master please 
backport it to 2.8 branch as well.

https://mail.openvswitch.org/pipermail/ovs-dev/2018-June/348266.html

Warm Regards,
Vishal Ajmera
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg. ofproto: ofproto_rule_insert__

[Vishal Deep Ajmera]

>Thanks for the bug report.

>The comment is pretty clear that a rule may not be reinserted and the 
>assertion matches that.  The >comment probably reflects how it's not safe to 
>cmap_remove() and then reinsert a cmap_node (before a >grace period has 
>elapsed).

>Do you have an example of how to get the assertion to trigger?

The comment is correct. If a rule is already inserted, we should reinsert it. 
However the check is incorrect. The assert is triggered if rule->state is 
RULE_INSERTED or RULE_REMOVED whereas it should only be triggered when 
rule->state is RULE_INSERTED.

Here is an example to trigger the assert:

# Create a netdev bridge
root@ubuntu-16:~# ovs-vsctl add-br br-test -- set Bridge br-test 
datapath_type=netdev

# Create a file with valid flows
root@ubuntu-16:~# cat flows.txt
flow add table=1,priority=0,in_port=2,actions=NORMAL
flow add table=1,priority=0,in_port=3,actions=NORMAL

# Add flows using bundle
root@ubuntu-16:~# ovs-ofctl bundle br-test flows.txt -OOpenflow13

# Dump Flows
root@ubuntu-16:~# ovs-ofctl dump-flows -OOpenflow13 br-test
 cookie=0x0, duration=2.465s, table=1, n_packets=0, n_bytes=0, 
priority=0,in_port=2 actions=NORMAL
 cookie=0x0, duration=2.465s, table=1, n_packets=0, n_bytes=0, 
priority=0,in_port=3 actions=NORMAL

# Create a file to modify existing flows. Add an entry with invalid flow for 
e.g. invalid group id.
root@ubuntu-16:~# cat flow-modify.txt
flow modify table=1,priority=0,in_port=2,actions=drop
flow modify table=1,priority=0,in_port=3,actions=group:10

# Modify flows using bundle
root@ubuntu-16:~# ovs-ofctl bundle br-test flow-modify.txt -OOpenflow13

First flow rule will be modified since it is a valid rule. However second rule 
is invalid since no group with id 10 exists. Bundle commit tries to revert 
(insert) the first rule to old flow which results in ovs_assert at 
ofproto_rule_insert__() since old rule->state = RULE_REMOVED.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] IP addressing of OVS

[Vishal Deep Ajmera]

You can create ifcfg-* files under /etc/network/interfaces.d/ in case of Ubuntu 
and set the IP address there.

BTW which version of OVS are you using ?

Regards,
Vishal

From: ovs-discuss-boun...@openvswitch.org  
On Behalf Of Tejali Bhujbal
Sent: Thursday, June 14, 2018 2:33 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] IP addressing of OVS

Hi Everyone,
I am not able to save ip addresses on ovs and keep that ports up.
After every reboot I have to up that ports and ip addresses manually:
Is there any special ovs commands?


Thanks in advance

Kind regards

Tejali Sonawane-Bhujbal
Department Engineer - NTNU IT
Byggteknisk, s-226, Gløshaugen
Contact- +47-96708171
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Reg. ofproto: ofproto_rule_insert__

[Vishal Deep Ajmera]

Hi,

In bundle based resync, we try to apply all rules from the bundle one-by-one. 
If a rule encounters any error, we revert back (undo) rules which were applied 
successfully. This is accomplished in function add_flow_revert() -> 
replace_rule_revert() -> ofproto_rule_insert__() using old_rule pointer. The 
old_rule state in this case would be RULE_REMOVED since the rule has been 
successfully replaced by new_rule. However, function ofproto_rule_insert__() is 
asserting when rule->state != RULE_INITIALIZED. Is this correct ? I think 
assert condition should be: ovs_assert(rule->state != RULE_INSERTED).

Does this make sense ? I am not very familiar with bundle based resync's 
though. If the change looks ok, I will post a patch in dev-list.

Warm Regards,
Vishal Ajmera

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

>> Zak had completed most of the work to set the RSO flags, so I'm sure he'd be 
>> happy 
>> to send it out if you want to take the patches in yourself.  However, I 
>> don't think it 
>> makes sense to include that functionality more generally in OVS.

Hi Justin,

Can you please share the patch for this feature ? We would like to work on it 
as our product requires this feature to be supported in OVS. Do you have any 
alternatives apart from controller based mechanism ?

Regards,
Vishal

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

>>I believe you should already be able to set the SLL and TLL options.  Does 
>>that not work for you?
>> In order to set up IPv6 NA responder we will be required to modify incoming 
>> solicitations with SLL 

>> option (multicast solicitations) to an Advertisement with TLL option. My 
>> understanding is that current >> support is only to modify existing TLL 
>> option, if already present in the packet.

Hi Justin,

Can we get a preliminary patch for this feature, in case it is ready ?

Warm Regards,
Vishal
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

>> Zak is working on that feature; I expect patches will hit the mailing list 
>> in the next week or two.
>> 
>> Hi Justin,
>> 
>> As part of this feature, will it also enable us to rewrite the options 
>> tlv:type field from SLL (1) to TLL (2) Or may be a set-field option to 
>> rewrite these fields in Options TLV. This will help in supporting multicast 
>> solicitations.

>>I believe you should already be able to set the SLL and TLL options.  Does 
>>that not work for you?
In order to set up IPv6 NA responder we will be required to modify incoming 
solicitations with SLL option (multicast solicitations) to an Advertisement 
with TLL option. My understanding is that current support is only to modify 
existing TLL option, if already present in the packet.

Regards,
Vishal
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

> Zak is working on that feature; I expect patches will hit the mailing list in 
> the next week or two.
> 
> Hi Justin,
> 
> As part of this feature, will it also enable us to rewrite the options 
> tlv:type field from SLL (1) to TLL (2) Or may be a set-field option to 
> rewrite these fields in Options TLV. This will help in supporting multicast 
> solicitations.

Hi Justin,

In case you have an RFC patch ready for this feature, can you please post it ? 
We can help in reviewing and testing it.

Warm Regards,
Vishal Ajmera
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

> Zak is working on that feature; I expect patches will hit the mailing list in 
> the next week or two.

Hi Justin,

As part of this feature, will it also enable us to rewrite the options tlv:type 
field from SLL (1) to TLL (2) Or may be a set-field option to rewrite these 
fields in Options TLV. This will help in supporting multicast solicitations.

Warm Regards,
Vishal
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

> On Apr 8, 2018, at 9:55 AM, Ben Pfaff <b...@ovn.org> wrote:
> 
> On Sun, Apr 08, 2018 at 04:34:16PM +0000, Vishal Deep Ajmera wrote:
>> 
>> In the above message, fields R (Router flag), S (Solicited flag) and O
>> (Override flag) cannot be set. Is my understanding correct ?
> 
> Yes.
> 
> It would be reasonable to be able to match and set these, so I imagine
> that we would accept patches to enable that.

> Zak is working on that feature; I expect patches will hit the mailing list in 
> the next week or two.

Thank you Ben and Justin.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

Hi,

We are trying to setup Neighbor Solicitation Responder using OpenFlow pipeline 
in OVS however it seems some of the fields in Neighbor Advertisement Message 
Format cannot be set using OpenFlow set actions. Following is the frame format 
of NA message:

0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Code  |  Checksum |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|S|O| Reserved|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  +   +
  |   |
  +   Target Address  +
  |   |
  +   +
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-

In the above message, fields R (Router flag), S (Solicited flag) and O 
(Override flag) cannot be set. Is my understanding correct ?

Also, is there a way to recalculate the checksum and write it to checksum field 
when we set the Target Address?

Warm Regards,
Vishal Ajmera

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Write to arbitrary packet location in OVS

[Vishal Deep Ajmera]

On Wed, Apr 04, 2018 at 06:51:05AM +, Vishal Deep Ajmera wrote:
> Is there a way in OVS today, wherein we can set OpenFlow pipeline
> actions to write (copy) from a register to arbitrary location in the
> packet. The start offset for read (from register) & write (to packet)
> along with size of data can be set as part of action.

>> No.

Ok Thanks Ben.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Hi Flavio,

I have sent a formal patch to mailing list. Sorry for submitting a little late.

Warm Regards,
Vishal Ajmera

-Original Message-
From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Vishal Deep Ajmera
Sent: Saturday, January 20, 2018 10:38 AM
To: Flavio Leitner <f...@sysclose.org>
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

> It looks good to me. I hope it does work for any number of ports
> and doesn't show any errors.  If that's the case, please submit a
> formal patch to ovs-dev@ and don't forget to request to patch 2.9
> (if you need that) as it's branched off at this point.

Ok Flavio. I will send formal patch to ovs-dev mailing list.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Reg. tc flow offload apis in netdev-vport

[Vishal Deep Ajmera]

Why is TC flow offload APIs being added in netdev-vport ?

For linux TC offloads I believe a device needs to be present in linux
to operate on. As per my understanding netdev-vport classes are used
to represent tunnels (vxlan, gre etc.) and none of them creates a linux device.

All the TC offload related APIs will anyway fail because these netdev's do
not have if-index in linux.

Do we have a representation of netdev-vport netdev's in linux
similar to netdev-linux ?

Warm Regards,
Vishal Ajmera

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

> It looks good to me. I hope it does work for any number of ports
> and doesn't show any errors.  If that's the case, please submit a
> formal patch to ovs-dev@ and don't forget to request to patch 2.9
> (if you need that) as it's branched off at this point.

Ok Flavio. I will send formal patch to ovs-dev mailing list.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

> BTW, I suggested earlier but maybe I wasn't clear.
> 
> Instead of adding networking configuration to the bridge's port, just
> leave it alone with a name that doesn't bother you.
> 
> Then create an internal port with the name and the networking
> configuration you need. It won't change its MAC and neither lose
> the routes. They both will be tap devices anyways.

Issue with assigning IP and routes to a tap port is that this tap port gets
a random mac address which cannot be guaranteed to be unique
across multiple nodes. I think that is the reason why bridge is assigned
same mac address of a physical port (when port is added to a bridge) since 
physical ports will have unique mac address.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

> OK, what about this patch instead? It should fix the issue without the
> errors.  I have not tested.

I tried your patch but it does not re-add the routes. The reason is doing
$ ifup br0 will not invoke ifup-post since the bridge port is already UP and so 
$OVSBRIDGECONFIGURED will be 'true'.

I think instead of doing 'ifup $OVS_BRIDGE', we should run ${OTHERSCRIPT} 
$OVS_BRIDGE 
under the mac check. Tried this and it is working.

Updated patch below.

+   BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
ovs-vsctl -t ${TIMEOUT} \
-- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
-- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
-- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
$OVS_EXTRA}
+   BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
+   # The bridge will change its MAC to be the lower one among all 
its
+   # ports. Restore the configuration if that happens.
+   if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
+   ${OTHERSCRIPT} "$OVS_BRIDGE"
+   fi

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Hi Flavio,

I tried to look closer into ifup-ovs script particularly for OVSDPDKPort & 
OVSDPDKBOND cases. 
With the change given below (git diff) at the end OVSDPDKBOND case, I see that 
the routes 
are getting installed again after adding dpdkbond port to the bridge. Perhaps 
the same fix 
needs to be done for OVSDPDKPort case as well. I think we need to invoke 
$OTHERSCRIPT
(ifup-eth) for the bridge in each of the above cases.

Does this fix in ifup-ovs script makes sense ?  If you agree, I will post a 
patch for review on 
ovs-dev list.


diff --git a/rhel/etc_sysconfig_network-scripts_ifup-ovs 
b/rhel/etc_sysconfig_network-scripts_ifup-ovs
index b95220a..132ed29 100755
--- a/rhel/etc_sysconfig_network-scripts_ifup-ovs
+++ b/rhel/etc_sysconfig_network-scripts_ifup-ovs
@@ -202,6 +202,7 @@ case "$TYPE" in
ovs-vsctl -t ${TIMEOUT} \
-- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
-- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} 
$OVS_OPTIONS ${IFACE_TYPES} ${OVS_EXTRA+-- $OVS_EXTRA}
+   ${OTHERSCRIPT} $OVS_BRIDGE
;;
*)
echo $"Invalid OVS interface type $TYPE"

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Hi Flavio,

Thanks for looking into this issue. I believe the order of initialization does 
not matter. 
Just an FYI: I tried with your suggestion of renaming the bridge name to zbr0 
but it did 
not solve the issue. In my opinion the issue is with networking scripts which 
is not 
triggering route addition again for the bridge LOCAL port. Let me explain it a 
little more.

As you see in the steps I followed, first we add the bridge br0 ($ifup br0). At 
this time the 
bridge LOCAL interface gets a random MAC address. Once the interface is 
configured, the 
networking service gets to see a new interface and invokes the route addition 
(due to 
presence of file route-br0) via ifup-eth/ifup-post script.

Next when we add dpdk-bond ports ($ifup dpdkbond0), the bridge LOCAL interface 
is 
reconfigured with MAC address of one of the dpdk ports (since these are 
physical ports). 
At this time OVS only makes IOCTL calls for setting device flags to DOWN and UP.
Once the device flag is set to UP again, I was assuming that ifup-eth/ifup-post 
script should get 
invoked again but it did not happen. Thus all the routes for br0 interface did 
not get added 
again.

I hope this clarifies the issue.

Warm Regards,
Vishal Ajmera

-Original Message-
From: Flavio Leitner [mailto:f...@sysclose.org] 
Sent: Tuesday, January 16, 2018 9:17 AM
To: Vishal Deep Ajmera <vishal.deep.ajm...@ericsson.com>
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

On Tue, Dec 26, 2017 at 08:31:49AM +, Vishal Deep Ajmera wrote:
> Hi,
> 
> On Red-Hat, kernel IP Routes are getting deleted whenever a dpdk-bond 
> port is added to "netdev" type bridge.  I understand that when a DPDK 
> port is added to ovs, the bridge port (LOCAL) is reconfigured with MAC 
> address which requires IOCTL calls to bring the device down and up. 
> This causes kernel to remove the routes.
> 
> Can someone please have a look and let me know what am I missing here ?

Hi Vishal,

I think when the interface goes down to change the MAC address, the routes will 
go away.  The only way to to make sure the routes will be restored is to change 
the initialization order.

In your case, br0 is initialized first, then dpdkbond0 which will cause the 
issue.

The order is alphabetical, so try renaming br0 to something like
zbr0 to see if the bridge is reconfigured with the routes.

fbl

> Steps to reproduce the issue:
> 
> # Create the bridge in OVS.
> $ ifup br0
> 
> # Dump the routes
> $ ip route
> 11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
> 100.100.100.10 via 11.2.0.202 dev br0
> 100.100.100.20 via 11.2.0.201 dev br0
> 169.254.0.0/16 dev br0 scope link metric 1036
> 
> # Add DPDK Bond to bridge br0
> $ ifup dpdkbond0
> 
> # Dump the routes
> $ ip route
> 11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
> --> Other routes for br0 are missing.
> 
> Here are the ifcfg files for the bridge BR0 and DPDKBOND0 port along 
> with static routes.
> =
> $ cat ifcfg-br0
> DEVICE=br0
> ONBOOT=yes
> HOTPLUG=no
> NM_CONTROLLED=no
> PEERDNS=no
> DEVICETYPE=ovs
> TYPE=OVSUserBridge
> BOOTPROTO=static
> IPADDR=11.2.0.26
> NETMASK=255.255.255.0
> OVS_EXTRA="set bridge br0 fail_mode=standalone"
> 
> $ cat ifcfg-dpdkbond0
> DEVICE=dpdkbond0
> ONBOOT=yes
> HOTPLUG=no
> NM_CONTROLLED=no
> PEERDNS=no
> DEVICETYPE=ovs
> TYPE=OVSDPDKBond
> OVS_BRIDGE=br0
> BOND_IFACES="dpdk0 dpdk1"
> OVS_OPTIONS="bond_mode=balance-tcp other_config:lacp-time=fast lacp=passive"
> 
> $ cat route-br0
> 100.100.100.10 via 11.2.0.201 dev br0
> 100.100.100.20 via 11.2.0.202 dev br0
> 
> =
> 
> Warm Regards,
> Vishal
> 

> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


--
Flavio

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Haven't received any suggestions yet and not able to fix the issue. The only 
workaround that resolved the issue was to restart the OVS.

Did anyone else face the same issue as described below ?

Warm Regards,
Vishal Ajmera

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Vishal Deep Ajmera
Sent: Tuesday, January 02, 2018 3:43 PM
To: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

Can someone help with route issue below ?

Warm Regards,
Vishal

From: 
ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org> 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Vishal Deep Ajmera
Sent: Tuesday, December 26, 2017 2:02 PM
To: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>
Subject: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

Hi,

On Red-Hat, kernel IP Routes are getting deleted whenever a dpdk-bond port is
added to "netdev" type bridge.  I understand that when a DPDK port is added to
ovs, the bridge port (LOCAL) is reconfigured with MAC address which requires
IOCTL calls to bring the device down and up. This causes kernel to remove the
routes.

Can someone please have a look and let me know what am I missing here ?
Steps to reproduce the issue:

# Create the bridge in OVS.
$ ifup br0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
100.100.100.10 via 11.2.0.202 dev br0
100.100.100.20 via 11.2.0.201 dev br0
169.254.0.0/16 dev br0 scope link metric 1036

# Add DPDK Bond to bridge br0
$ ifup dpdkbond0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
--> Other routes for br0 are missing.

Here are the ifcfg files for the bridge BR0 and DPDKBOND0 port along with
static routes.
=
$ cat ifcfg-br0
DEVICE=br0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSUserBridge
BOOTPROTO=static
IPADDR=11.2.0.26
NETMASK=255.255.255.0
OVS_EXTRA="set bridge br0 fail_mode=standalone"

$ cat ifcfg-dpdkbond0
DEVICE=dpdkbond0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSDPDKBond
OVS_BRIDGE=br0
BOND_IFACES="dpdk0 dpdk1"
OVS_OPTIONS="bond_mode=balance-tcp other_config:lacp-time=fast lacp=passive"

$ cat route-br0
100.100.100.10 via 11.2.0.201 dev br0
100.100.100.20 via 11.2.0.202 dev br0

=

Warm Regards,
Vishal

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] interface can't be connected after attached to bridge

[Vishal Deep Ajmera]

Hi Greg,

Please refer to “Common Configuration Issues” page on OpenvSwitch. This issue 
is listed as very first one ☺.

http://docs.openvswitch.org/en/latest/faq/issues/

Warm Regards,
Vishal Ajmera

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Gregory Rose
Sent: Friday, December 29, 2017 10:53 PM
To: netsurfed ; ovs-discuss 
Subject: Re: [ovs-discuss] interface can't be connected after attached to bridge

On 12/26/2017 12:08 AM, netsurfed wrote:

Hi all,
  I have a physical interface with an IP, and can connect with another machine 
by "ping" cmd.
However, after adding to a ovs bridge, It can no longer be connected with any 
other machine by "ping" cmd, although the IP is still there.
  I wonder if this is normal ? And why not be connected by "ping" cmd ?
  THX.

I tried to monitor the interface with "tcpdump". The target machine has 
returned the ARP Reply, but the HWaddress in ARP is still incomplete.

My OVS version is "2.8.90", and OS is "Ubuntu 16.04.2 LTS".
root@node26:~# uname -a
Linux node26 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

[cid:image001.png@01D385B0.10783CD0]




___

discuss mailing list

disc...@openvswitch.org

https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Once you assign a physical interface to a bridge, any bridge, not just OVS 
bridges, then you need to reassign the IP address to the bridge and remove it 
from the physical interface.

There is a lot of documentation out there on how to configure bridges.

https://help.ubuntu.com/community/NetworkConnectionBridge

Thanks,

- Greg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bridge not working..

[Vishal Deep Ajmera]

Hi Steven,

Could you please dump the “ip route” table of kernel on the host ? I am 
suspecting if gateway configuration (10.80.180.1) on kitbr0 is causing an 
issue. Can you try removing the gateway configuration and verify again ?

Warm Regards,
Vishal Ajmera

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Steven Pollock
Sent: Thursday, January 04, 2018 11:21 AM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Bridge not working..

Hopefully this is the correct mailing list, there is no description on the 
admin page.

Running on Ubuntu 16.04 on top of vmware.

ens192 is connect to the 10.80.180.0/24 network
ens224 is connected to a standard vswitch4, and a windows machine is also 
connected to vswitch4

I expected packets from the windows machine 10.80.180.222 to pass through 
kitbr0 to any devices on the 10.80.180.0/24 network 
connected on ens192

Here is the /etc/network/interfaces


auto ens192

iface ens192 inet manual

auto ens224

iface ens224 inet manual



auto kitbr0

allow-ovs kitbr0

iface kitbr0 inet static

address 10.80.180.223

netmask 255.255.255.0

gateway 10.80.180.1

 ovs_type OVSBridge

 ovs_ports ens192 ens224


I also note that the mac address on the bridge and ens224 are the same.

The windows machine off ens224 can ping the bridge at 10.80.180.223
The devices off ens192 (the rest of the 10.80.180.x network) cannot ping 
10.80.180.223 however


ens192Link encap:Ethernet  HWaddr 00:50:56:ab:e2:5b

  inet6 addr: fe80::250:56ff:feab:e25b/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:74 errors:0 dropped:0 overruns:0 frame:0

  TX packets:369 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:4964 (4.9 KB)  TX bytes:35695 (35.6 KB)



ens224Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:289 errors:0 dropped:0 overruns:0 frame:0

  TX packets:166 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000

  RX bytes:26138 (26.1 KB)  TX bytes:15431 (15.4 KB)



kitbr0Link encap:Ethernet  HWaddr 00:50:56:ab:46:85

  inet addr:10.80.180.223  Bcast:10.80.180.255  Mask:255.255.255.0

  inet6 addr: fe80::250:56ff:feab:4685/64 Scope:Link

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

  RX packets:349 errors:0 dropped:37 overruns:0 frame:0

  TX packets:96 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1

  RX bytes:25386 (25.3 KB)  TX bytes:10749 (10.7 KB)



root@ovs:/etc/network# ovs-vsctl show

3a6b26a7-6e7a-44fd-8893-65f2c8fac4f2

Bridge "kitbr0"

Port "kitbr0"

Interface "kitbr0"

type: internal

Port "ens192"

Interface "ens192"

Port "ens224"

Interface "ens224"

ovs_version: "2.5.2"


Any clues about what is going are much appreciated. (I do not have a controller 
at this time)

thanks,

-Steve


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Can someone help with route issue below ?

Warm Regards,
Vishal

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Vishal Deep Ajmera
Sent: Tuesday, December 26, 2017 2:02 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

Hi,

On Red-Hat, kernel IP Routes are getting deleted whenever a dpdk-bond port is
added to "netdev" type bridge.  I understand that when a DPDK port is added to
ovs, the bridge port (LOCAL) is reconfigured with MAC address which requires
IOCTL calls to bring the device down and up. This causes kernel to remove the
routes.

Can someone please have a look and let me know what am I missing here ?
Steps to reproduce the issue:

# Create the bridge in OVS.
$ ifup br0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
100.100.100.10 via 11.2.0.202 dev br0
100.100.100.20 via 11.2.0.201 dev br0
169.254.0.0/16 dev br0 scope link metric 1036

# Add DPDK Bond to bridge br0
$ ifup dpdkbond0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
--> Other routes for br0 are missing.

Here are the ifcfg files for the bridge BR0 and DPDKBOND0 port along with
static routes.
=
$ cat ifcfg-br0
DEVICE=br0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSUserBridge
BOOTPROTO=static
IPADDR=11.2.0.26
NETMASK=255.255.255.0
OVS_EXTRA="set bridge br0 fail_mode=standalone"

$ cat ifcfg-dpdkbond0
DEVICE=dpdkbond0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSDPDKBond
OVS_BRIDGE=br0
BOND_IFACES="dpdk0 dpdk1"
OVS_OPTIONS="bond_mode=balance-tcp other_config:lacp-time=fast lacp=passive"

$ cat route-br0
100.100.100.10 via 11.2.0.201 dev br0
100.100.100.20 via 11.2.0.202 dev br0

=

Warm Regards,
Vishal

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Vishal Deep Ajmera]

Hi,

On Red-Hat, kernel IP Routes are getting deleted whenever a dpdk-bond port is
added to "netdev" type bridge.  I understand that when a DPDK port is added to
ovs, the bridge port (LOCAL) is reconfigured with MAC address which requires
IOCTL calls to bring the device down and up. This causes kernel to remove the
routes.

Can someone please have a look and let me know what am I missing here ?
Steps to reproduce the issue:

# Create the bridge in OVS.
$ ifup br0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
100.100.100.10 via 11.2.0.202 dev br0
100.100.100.20 via 11.2.0.201 dev br0
169.254.0.0/16 dev br0 scope link metric 1036

# Add DPDK Bond to bridge br0
$ ifup dpdkbond0

# Dump the routes
$ ip route
11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
--> Other routes for br0 are missing.

Here are the ifcfg files for the bridge BR0 and DPDKBOND0 port along with
static routes.
=
$ cat ifcfg-br0
DEVICE=br0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSUserBridge
BOOTPROTO=static
IPADDR=11.2.0.26
NETMASK=255.255.255.0
OVS_EXTRA="set bridge br0 fail_mode=standalone"

$ cat ifcfg-dpdkbond0
DEVICE=dpdkbond0
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSDPDKBond
OVS_BRIDGE=br0
BOND_IFACES="dpdk0 dpdk1"
OVS_OPTIONS="bond_mode=balance-tcp other_config:lacp-time=fast lacp=passive"

$ cat route-br0
100.100.100.10 via 11.2.0.201 dev br0
100.100.100.20 via 11.2.0.202 dev br0

=

Warm Regards,
Vishal

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss