[ovs-discuss] ovs fragment handling

[pei Jikui]

hi,

I have a question about how the ovs handling the ip fragments that  is it 
possible that different actions will be enforced to the first fragment and the 
upcoming ones?

For example, if we have an openflow rule to define the action A for udp packet 
with destination port 123. We also have the default "normal" action for the 
fragments.

For this case, the action A will be conducted to the first ip fragment which 
has the udp destination port 123, and the action normal will be enforced to the 
other fragments?

Thanks.


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

[ovs-discuss] OVS Tuple Space Searching Algorithm

[pei Jikui]

HI,

I am trying to understand how the Tuple Space Searching works in vswitchd when 
it tries to search an openflow rule for the upcall packets.

Following is my understanding about the procedure. I am not sure if the 
understanding is right or not since I couldn't understand well how the tss hash 
tables work together with the trie trees.


1)The data structures.



[cid:113ac556-883d-4c04-9d0d-25083c406333]

 *   For every openflow table, there are several sub-tables each one has 
the same mask for rules.
 *   For staged search purpose, in each sub-table, there are 4 hash tables 
which are built based on the meta, meta+l2, meta+l2+l3, meta+l2+l3+l4 
respectively.
 *   For prefix tracking purpose, in each sub-table, there are 2 or 3? 
Prefix trees which are used to track the source-ip, dest-ip fields? ( from the 
source code, it seems we have 3 trie trees? What's the other items is tracking 
by the trie tree besides the source ip and dest ip?)


2)The rule search procedure of each table.

The routine will first search the four hash tables and find the rule. Then use 
the prefix trees for the prefix tracking purpose which will potentially reduce 
the flow entries in datapath?  Is this right or not? What's the right procedure 
of the matching if the answer is no?


Thanks


Jikui

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

[ovs-discuss] 回复: [ovs-dev] 回复: one issue in vxlan functionality of the kernel-datapath type of ovs

[pei Jikui]

Attach the diff which I have verified locally.
Thanks.

[root@localhost ovs]# git diff
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index dc30824..c5a7de6 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2678,9 +2678,12 @@ revalidate(struct revalidator *revalidator)
 }
 if (kill_them_all || (used && used < now - max_idle)) {
 result = UKEY_DELETE;
-} else {
+/*Only validate the ukey if the flow's action is not drop.Since 
for the drop flows, there might be not validated.*/
+} else if (f->actions_len > 0) {
 result = revalidate_ukey(udpif, ukey, &f->stats, &odp_actions,
  reval_seq, &recircs);
+} else {
+result = UKEY_KEEP;
 }
 ukey->dump_seq = dump_seq;




发件人: ovs-dev-boun...@openvswitch.org  代表 pei 
Jikui 
发送时间: 2019年6月2日 9:42
收件人: Ben Pfaff
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: [ovs-dev] 回复: one issue in vxlan functionality of the kernel-datapath type 
of ovs

hi,

I looked into this further and found the root cause.

1) for the unwanted packets(no vxlan tunnel configured for this case), the 
receiver will install the drop-action flow to the datapath.
2) when the revalidator thread is trying to age-out/clean-up the flows 
installed in step 1), they are considered as invalidated by revalidator thread 
since the revalidator thread could not find the xport for them. Hence the 
revalidator thread delete the them very soon.
3) that is causing all the upcoming packets are sending to userspace again.   
And repeat the steps that  a) send to userspace, b) install drop-action flow 
table c) the revalidator thread delete them.
4) A proposed fix is if the flow's action is drop, we only bank on the time 
age-out mechanism to clean them up and don't enforce the revalidate_ukey action 
for them.

Thanks.

Jikui


发件人: pei Jikui 
发送时间: 2019年5月25日 7:31
收件人: Ben Pfaff
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type 
of ovs

In my test bed there is no any dropping flow entry generated in the datapath, 
which causes all the unwanted vxlan packets will go to the slow path.  That’s a 
little time-consuming for this case.



发送自 Outlook<http://aka.ms/weboutlook>

________
发件人: Ben Pfaff 
发送时间: 2019年5月25日 2:36
收件人: pei Jikui
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type 
of ovs

On Sat, May 18, 2019 at 10:23:50AM +, pei Jikui wrote:
> I found one issue in the vxlan functionality in kernel-datapath type of ovs 
> which could be potentially optimize?
>
>
> For example, there is a machine (A) running ovs with one configured one vxlan 
> interface with tunnel value 123,  then all the vxlan traffics destinate to 
> this machine(A) will be dealt with the ovs.
>
>
> Although the ovs in machine A only configured with one vxlan tunnel (123), 
> all the vxlan traffics regardless the tunnel value is 123 or not, will be 
> delivered to the vswitchd to do the slow path if there is no flow tables 
> found in the datapath.
>
> This is due to the vxlan configuration such as the configured vxlan tunnel 
> valuse does not exist in the datapath. (There is only one vxlan tunnel with 
> vni value 0 exist in the datapath’s vxlan configuration).

It's true, but does it matter?  It would be unusual for a host to
receive much VXLAN traffic that it is only going to drop.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 回复: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type of ovs

[pei Jikui]

hi,

I looked into this further and found the root cause.

1) for the unwanted packets(no vxlan tunnel configured for this case), the 
receiver will install the drop-action flow to the datapath.
2) when the revalidator thread is trying to age-out/clean-up the flows 
installed in step 1), they are considered as invalidated by revalidator thread 
since the revalidator thread could not find the xport for them. Hence the 
revalidator thread delete the them very soon.
3) that is causing all the upcoming packets are sending to userspace again.   
And repeat the steps that  a) send to userspace, b) install drop-action flow 
table c) the revalidator thread delete them.
4) A proposed fix is if the flow's action is drop, we only bank on the time 
age-out mechanism to clean them up and don't enforce the revalidate_ukey action 
for them.

Thanks.

Jikui

____
发件人: pei Jikui 
发送时间: 2019年5月25日 7:31
收件人: Ben Pfaff
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type 
of ovs

In my test bed there is no any dropping flow entry generated in the datapath, 
which causes all the unwanted vxlan packets will go to the slow path.  That’s a 
little time-consuming for this case.



发送自 Outlook<http://aka.ms/weboutlook>


发件人: Ben Pfaff 
发送时间: 2019年5月25日 2:36
收件人: pei Jikui
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type 
of ovs

On Sat, May 18, 2019 at 10:23:50AM +, pei Jikui wrote:
> I found one issue in the vxlan functionality in kernel-datapath type of ovs 
> which could be potentially optimize?
>
>
> For example, there is a machine (A) running ovs with one configured one vxlan 
> interface with tunnel value 123,  then all the vxlan traffics destinate to 
> this machine(A) will be dealt with the ovs.
>
>
> Although the ovs in machine A only configured with one vxlan tunnel (123), 
> all the vxlan traffics regardless the tunnel value is 123 or not, will be 
> delivered to the vswitchd to do the slow path if there is no flow tables 
> found in the datapath.
>
> This is due to the vxlan configuration such as the configured vxlan tunnel 
> valuse does not exist in the datapath. (There is only one vxlan tunnel with 
> vni value 0 exist in the datapath’s vxlan configuration).

It's true, but does it matter?  It would be unusual for a host to
receive much VXLAN traffic that it is only going to drop.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs datastructure sw_flow_mask

[pei Jikui]

Sorry there is a typo in the original email.

I meant there must be some reasons beyond my understanding and I am eager to 
know the reasons.



发送自 Outlook<http://aka.ms/weboutlook>


发件人: ovs-discuss-boun...@openvswitch.org  
代表 pei Jikui 
发送时间: 2019年5月28日 21:37
收件人: ovs-discuss@openvswitch.org
主题: [ovs-discuss] ovs datastructure sw_flow_mask

hi,

We define the range, begin and end, for  the struct sw_flow_mask.  I am just 
wondering why we don't take use of the bitmap for it?

For example, if we we have an openflow rule which defines the "source mac and 
dstip for some certain actions".
1) based on the 'begin-end' mask design, we need to calculate the hash values 
based on the items from the source mac to the dstip.
2) if we use the bitmap for the mask, we could calculate the hash value only 
based on two items of source mac and dstip.

Comparing with 1), 2) is better for the speed of calculating the hash-value and 
it also saves some memory spaces (only a u32 bitmap is used instead of two u32 
for begin and end)?

I know there are must be some reasons behind my current understanding and glade 
to know them.


Thanks.

Jikui



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

[ovs-discuss] ovs datastructure sw_flow_mask

[pei Jikui]

hi,

We define the range, begin and end, for  the struct sw_flow_mask.  I am just 
wondering why we don't take use of the bitmap for it?

For example, if we we have an openflow rule which defines the "source mac and 
dstip for some certain actions".
1) based on the 'begin-end' mask design, we need to calculate the hash values 
based on the items from the source mac to the dstip.
2) if we use the bitmap for the mask, we could calculate the hash value only 
based on two items of source mac and dstip.

Comparing with 1), 2) is better for the speed of calculating the hash-value and 
it also saves some memory spaces (only a u32 bitmap is used instead of two u32 
for begin and end)?

I know there are must be some reasons behind my current understanding and glade 
to know them.


Thanks.

Jikui



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

Re: [ovs-discuss] [ovs-dev] one issue in vxlan functionality of the kernel-datapath type of ovs

[pei Jikui]

In my test bed there is no any dropping flow entry generated in the datapath, 
which causes all the unwanted vxlan packets will go to the slow path.  That’s a 
little time-consuming for this case.



发送自 Outlook<http://aka.ms/weboutlook>


发件人: Ben Pfaff 
发送时间: 2019年5月25日 2:36
收件人: pei Jikui
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type 
of ovs

On Sat, May 18, 2019 at 10:23:50AM +0000, pei Jikui wrote:
> I found one issue in the vxlan functionality in kernel-datapath type of ovs 
> which could be potentially optimize?
>
>
> For example, there is a machine (A) running ovs with one configured one vxlan 
> interface with tunnel value 123,  then all the vxlan traffics destinate to 
> this machine(A) will be dealt with the ovs.
>
>
> Although the ovs in machine A only configured with one vxlan tunnel (123), 
> all the vxlan traffics regardless the tunnel value is 123 or not, will be 
> delivered to the vswitchd to do the slow path if there is no flow tables 
> found in the datapath.
>
> This is due to the vxlan configuration such as the configured vxlan tunnel 
> valuse does not exist in the datapath. (There is only one vxlan tunnel with 
> vni value 0 exist in the datapath’s vxlan configuration).

It's true, but does it matter?  It would be unusual for a host to
receive much VXLAN traffic that it is only going to drop.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 回复: An issue that the deleted flow tables in kernel based datapath couldn't be established again

[pei Jikui]

Ben,

Much thanks for your reply.
1) I know this command will be rarely used by customer.  For me, the reason why 
I used this command is trying to understand the full-cycle of packet traveling 
in OVS system.
   And I do not know if there are some cases for the customer in the real world 
to use this command.

3) a) Not for every packets to the userspace. Just for the packets generated 
the packet_miss upcall.
 b) The initial thinking
 i) for the case to delete all the flow tables, then cleanup all the 
ufid keys in userspace.
 ii) No much think for the case how to delete the according ufid for 
the deleting specific flow entries.

Thanks

Jikui


发送自 Outlook<http://aka.ms/weboutlook>


发件人: Ben Pfaff 
发送时间: 2019年5月24日 0:57
收件人: pei Jikui
抄送: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] An issue that the deleted flow tables in kernel based 
datapath couldn't be established again

On Thu, May 23, 2019 at 11:57:05AM +, pei Jikui wrote:
> 1)I found a case in the netlink based datapth, that if we delete the 
> existing datapath flow tables via “ovs-dpctl del-flows”, the according 
> datpath flow tables could not be created again and then  all the consecutive 
> packets need to go through the user-space slow path.

OK.

One way to avoid this problem is to not run "ovs-dpctl del-flows".  Is
there a reason you want to run that command?

> 2)I also found the potential root cause.  It is because when we delete 
> the datapath flow tables, their according ufid keys stored in the userspace 
> vswitchd are not deleted accordingly.  So, when the coming packets’ 
> packet_missing upcall sent to vswitchd, they ufid key is still in the 
> UKEY_OPERATIONAL status so that the DPIF_FP_CREATE message will not be sent 
> to datapath anymore.

That does seem like a plausible root cause.

> 3)That will be causing the above case.  The possible fixinges are,
>
> a) Send the DPIF_FP_CREATE message to datapath regardless if the according 
> ufid key exists or not. (I have verified this fix).

Do you mean, send the message on every packet that comes to userspace?
This could have performance implications, but I don't know how much.

> b) More fine-graind fix is when we execute “ovs-dpctl del-flows **”, we also 
> should clean up the according ufid cach in vswitch.

How do you suggest that userspace should detect that the flows were
deleted?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] An issue that the deleted flow tables in kernel based datapath couldn't be established again

[pei Jikui]

Hi,

1)I found a case in the netlink based datapth, that if we delete the 
existing datapath flow tables via “ovs-dpctl del-flows”, the according datpath 
flow tables could not be created again and then  all the consecutive packets 
need to go through the user-space slow path.


2)I also found the potential root cause.  It is because when we delete the 
datapath flow tables, their according ufid keys stored in the userspace 
vswitchd are not deleted accordingly.  So, when the coming packets’ 
packet_missing upcall sent to vswitchd, they ufid key is still in the 
UKEY_OPERATIONAL status so that the DPIF_FP_CREATE message will not be sent to 
datapath anymore.


3)That will be causing the above case.  The possible fixinges are,

a) Send the DPIF_FP_CREATE message to datapath regardless if the according ufid 
key exists or not. (I have verified this fix).

b) More fine-graind fix is when we execute “ovs-dpctl del-flows **”, we also 
should clean up the according ufid cach in vswitch.


4)The topology used for testing,

a) topology

[cid:a29e324b-5e60-46be-864c-3bf6358e6bf2]



b)configuration

Machine A:

ovs-vsctl add-br0 br0

ovs-vsctl add-port br0 vxlan �C set interface vxlan type=vxlan 
options:remote_ip=10.128.0.157 options:key=123

ip link set dev br0 up

ip addr add 1.2.3.4/24 dev br0

Machine B:

ovs-vsctl add-br0 br0

ovs-vsctl add-port br0 vxlan �C set interface vxlan type=vxlan 
options:remote_ip=10.128.0.156 options:key=123

ip link set dev br0 up

ip addr add 1.2.3.5/24 dev br0

c) steps for testing

a) ping 1.2.3.4 from Machine B. It works.

b)ovs-dpctl dump-flows in Machine A, we could catch the datapath flow 
tables.

c) ovs-dpctl del-flows in Machine A and then “ovs_dpctl del-flows” we could 
see the flow tables could never come back again.

d)Add the logs in datatpath and vswitch, we could see for every ping 
packets, a packet miss upcall was sent to vswtichd while the DPIF_FP_CREATE 
message is not sent to datapath since their according ufid cash’s status is 
UKEY_OPERATIONAL.


Thanks


Jikui

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

[ovs-discuss] one issue in vxlan functionality of the kernel-datapath type of ovs

[pei Jikui]

hi,


I found one issue in the vxlan functionality in kernel-datapath type of ovs 
which could be potentially optimize?


For example, there is a machine (A) running ovs with one configured one vxlan 
interface with tunnel value 123,  then all the vxlan traffics destinate to this 
machine(A) will be dealt with the ovs.


Although the ovs in machine A only configured with one vxlan tunnel (123), all 
the vxlan traffics regardless the tunnel value is 123 or not, will be delivered 
to the vswitchd to do the slow path if there is no flow tables found in the 
datapath.

This is due to the vxlan configuration such as the configured vxlan tunnel 
valuse does not exist in the datapath. (There is only one vxlan tunnel with vni 
value 0 exist in the datapath’s vxlan configuration).


Is this designed intentional or not? If not, should we do some optimization for 
this? Such as to push the vxlan configurations into datapath and drop the 
packets in datapath and does not deliver the unwanted packets to userspace?




Thanks


Jikui


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

[ovs-discuss] 回复: mapping between the upcall request in kernel and the upcall_handler thread in userspace

[pei Jikui]

I found an answer illustrated as the below diagram. I will match the souce 
codes again.
Thanks.


[cid:2dae6eda-27cc-4688-952a-02eae1fc8836]



发件人: pei Jikui
发送时间: 2019年5月7日 22:49
收件人: ovs-discuss@openvswitch.org
主题: mapping between the upcall request in kernel and the upcall_handler thread 
in userspace

When the datapath in kernel sends upcall request to vswitchd in the userspace, 
which upcall_handler thread in vswitch will deal with this upcall request?  
What's the criteria for dispatching a certain upcall to  a certain 
upcall_handler?


Much thanks


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

[ovs-discuss] mapping between the upcall request in kernel and the upcall_handler thread in userspace

[pei Jikui]

When the datapath in kernel sends upcall request to vswitchd in the userspace, 
which upcall_handler thread in vswitch will deal with this upcall request?  
What's the criteria for dispatching a certain upcall to  a certain 
upcall_handler?


Much thanks


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

[ovs-discuss] 回复: 回复: gre_sys vxlan_sys . genev_sys etc interfaces

[pei Jikui]

My understanding is that we have a global gre_sys device for all the gre 
vports. All the traffics will be sent and received by this gre_sys device, 
based on the different parameters carried in the packets, the packets will 
further be delivered to different  gre vports.

And this also works for other type of tunnel interfaces such as vxlan_sys 
genev_sys etc ...

Is my understanding right?

Thanks.


发件人: pei Jikui 
发送时间: 2019年4月16日 10:48
收件人: Gregory Rose; ovs-discuss@openvswitch.org
主题: 回复: [ovs-discuss] gre_sys vxlan_sys . genev_sys etc interfaces

Much thanks for the help.

What're the scenarios that OVS uses these devices to send and receive the 
packets?

Thanks




发送自 Outlook<http://aka.ms/weboutlook>


发件人: Gregory Rose 
发送时间: 2019年4月15日 23:51
收件人: pei Jikui; ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] gre_sys vxlan_sys . genev_sys etc interfaces



On 4/15/2019 2:38 AM, pei Jikui wrote:
hi,

During the initialization of ovs, lots of interfaces such as 
gre_sys,genev_sys,vxlan_sys will be created and could be shown by "ip a".

My question is , why does ovs create these interfaces and how it uses them in 
which kinds of scenarios?

The Linux kernel has "fully backed" devices for net name spaces.  These are 
those devices.

- Greg


Much thanks.





___
discuss mailing list
disc...@openvswitch.org<mailto: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] 回复: gre_sys vxlan_sys . genev_sys etc interfaces

[pei Jikui]

Much thanks for the help.

What're the scenarios that OVS uses these devices to send and receive the 
packets?

Thanks




发送自 Outlook<http://aka.ms/weboutlook>


发件人: Gregory Rose 
发送时间: 2019年4月15日 23:51
收件人: pei Jikui; ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] gre_sys vxlan_sys . genev_sys etc interfaces



On 4/15/2019 2:38 AM, pei Jikui wrote:
hi,

During the initialization of ovs, lots of interfaces such as 
gre_sys,genev_sys,vxlan_sys will be created and could be shown by "ip a".

My question is , why does ovs create these interfaces and how it uses them in 
which kinds of scenarios?

The Linux kernel has "fully backed" devices for net name spaces.  These are 
those devices.

- Greg


Much thanks.





___
discuss mailing list
disc...@openvswitch.org<mailto: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] gre_sys vxlan_sys . genev_sys etc interfaces

[pei Jikui]

hi,

During the initialization of ovs, lots of interfaces such as 
gre_sys,genev_sys,vxlan_sys will be created and could be shown by "ip a".

My question is , why does ovs create these interfaces and how it uses them in 
which kinds of scenarios?

Much thanks.


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

[ovs-discuss] 回复: replace the openvswitch.ko without losing the bridge interface's configuration

[pei Jikui]

Much thanks.

It works well.




发件人: Ben Pfaff 
发送时间: 2019年3月21日 2:06
收件人: pei Jikui
抄送: ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] replace the openvswitch.ko without losing the bridge 
interface's configuration

On Wed, Mar 20, 2019 at 07:02:41AM +0000, pei Jikui wrote:
> When I replace the openvswitch.ko with a new modified one, the configuration 
> on the bridge such as br0 is lost.  I need to reconfigure its ip address and 
> bring it up again manually.
>
> Is there any alternative that we could replace the openvswitch.ko without 
> losing the bridge interfaces’ configuration?

Yes, you could use the script we provide and document for that purpose,
either "ovs-ctl force-reload-kmod" or one of the distro-specific
wrappers of it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 回复: replace the openvswitch.ko without losing the bridge interface's configuration

[pei Jikui]

Thanks for your remind. Yes, this is how I personally resolve this issue.

While for the customer, if they are upgrading their ovs to a new version, will 
they have to reconfigure the interface?  If this is the case, personally I do 
not think this is a friendly way to them.

Doesn't OVS have a solution for this?

THanks.

Jikui




发送自 Outlook<http://aka.ms/weboutlook>


发件人: Numan Siddique 
发送时间: 2019年3月20日 19:01
收件人: pei Jikui
抄送: ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] replace the openvswitch.ko without losing the bridge 
interface's configuration



On Wed, Mar 20, 2019 at 12:35 PM pei Jikui 
mailto:jk...@hotmail.com>> wrote:

When I replace the openvswitch.ko with a new modified one, the configuration on 
the bridge such as br0 is lost.  I need to reconfigure its ip address and bring 
it up again manually.

I think you can use network scripts and restart your network to configure back 
the br0's ip address whenever you reload openvswitch.ko


Thanks
Numan


Is there any alternative that we could replace the openvswitch.ko without 
losing the bridge interfaces’ configuration?

The steps I used to replace the openvswitch on the centos.

1)Compile the openvswitch

make -j `nproc`

make install

2)Replace the openvswitch.ko

ovs-dpctl del-dp system@ovs-system

rmmod openvswitch

insmod ./datapath/linux/openvswitch.ko

ovs-ctl restart



Thanks.


Jikui

___
discuss mailing list
disc...@openvswitch.org<mailto: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] 回复: replace the openvswitch.ko without losing the bridge interface's configuration

[pei Jikui]

What's more, the steps I followed is from the openvswitch FAQ document in 
http://docs.openvswitch.org/en/latest/faq/issues/

But even follow these steps, every time I need to reconfigure the bridge 
interface such as br0's ip address etc ...
Common Configuration Issues - Open vSwitch 
Documentation<http://docs.openvswitch.org/en/latest/faq/issues/>
A: More than likely, you’ve looped your network. Probably, eth0 and eth1 are 
connected to the same physical Ethernet switch. This yields a scenario where 
OVS receives a broadcast packet on eth0 and sends it out on eth1, then the 
physical switch connected to eth1 sends the packet back on eth0, and so on 
forever.
docs.openvswitch.org






Q: I can’t unload the openvswitch kernel module. Why?

A: The userspace might still hold the reference count. So rmmod openvswitch 
does not work, for example:

$ lsmod | grep openvswitch
openvswitch   155648 4
nf_conncount  24576  1 openvswitch


Use the command below to drop the refcnt:

$ ovs-dpctl del-dp system@ovs-system
$ rmmod openvswitch



发送自 Outlook<http://aka.ms/weboutlook>


发件人: ovs-discuss-boun...@openvswitch.org  
代表 pei Jikui 
发送时间: 2019年3月20日 15:02
收件人: ovs-discuss@openvswitch.org
主题: [ovs-discuss] replace the openvswitch.ko without losing the bridge 
interface's configuration


When I replace the openvswitch.ko with a new modified one, the configuration on 
the bridge such as br0 is lost.  I need to reconfigure its ip address and bring 
it up again manually.

Is there any alternative that we could replace the openvswitch.ko without 
losing the bridge interfaces’ configuration?

The steps I used to replace the openvswitch on the centos.

1)Compile the openvswitch

make -j `nproc`

make install

2)Replace the openvswitch.ko

ovs-dpctl del-dp system@ovs-system

rmmod openvswitch

insmod ./datapath/linux/openvswitch.ko

ovs-ctl restart



Thanks.


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

[ovs-discuss] replace the openvswitch.ko without losing the bridge interface's configuration

[pei Jikui]

When I replace the openvswitch.ko with a new modified one, the configuration on 
the bridge such as br0 is lost.  I need to reconfigure its ip address and bring 
it up again manually.

Is there any alternative that we could replace the openvswitch.ko without 
losing the bridge interfaces’ configuration?

The steps I used to replace the openvswitch on the centos.

1)Compile the openvswitch

make -j `nproc`

make install

2)Replace the openvswitch.ko

ovs-dpctl del-dp system@ovs-system

rmmod openvswitch

insmod ./datapath/linux/openvswitch.ko

ovs-ctl restart



Thanks.


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

[ovs-discuss] 回复: 回复: GRE interface packet receive procedure

[pei Jikui]

Thanks all for the help.
I got the answer by adding some debug logs.

In our testbed in which the OVS is using the kernel datapath, GRE will receive 
the gre packets by gre_rcv function call registered in dp_init.



发件人: ovs-discuss-boun...@openvswitch.org  
代表 pei Jikui 
发送时间: 2019年3月20日 7:03
收件人: Gregory Rose; ovs-discuss@openvswitch.org
主题: [ovs-discuss] 回复: GRE interface packet receive procedure

Thanks for your help.

If OVS is using DPDK user space datapath, which one is used for receiving the 
GRE packets?
On the counterpart, how about OVS is using the traditional kernel datapath?

Thanks

Jikui

发件人: Gregory Rose 
发送时间: 2019年3月20日 4:18
收件人: pei Jikui; ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] GRE interface packet receive procedure


On 3/19/2019 6:29 AM, pei Jikui wrote:
> hi,
>
> 1) I am reading the OVS source code about how a GRE interface in OVS
> receives packets into OVS bridge.
>
>  I found there are two places that the GRE packets will possibly
> be received into OVS bridge.
>
> a) . The first place is when we create a gre interface with
> gre_create->ovs_netdev_link->netdev_rx_handler_register
>   The register rx_handler is netdev_frame_hook which will
> receive the packets into the ovs bridge.
>
>  b) The second place is located at the dp_init which will register
> a packet handler function gre_rcv for GRE protocol packets.
>  gre_rcv will also receive the packets to OVS bridge.
>
>
> 2) My questions are,
>  a)  Which is the real receive handler for the GRE packets?
>  b) Is it possible that the packets could be received by both of
> the two cases. If yes, for which scenarios will be match to each one?

OVS supports a user space datapath and a kernel datapath so it depends
on whether you're using the user space datapath or the kernel datapath.

- Greg

>
> Thanks much.
>
> Jikui
>
>
>
>
> ___
> 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] 回复: GRE interface packet receive procedure

[pei Jikui]

Thanks for your help.

If OVS is using DPDK user space datapath, which one is used for receiving the 
GRE packets?
On the counterpart, how about OVS is using the traditional kernel datapath?

Thanks

Jikui

发件人: Gregory Rose 
发送时间: 2019年3月20日 4:18
收件人: pei Jikui; ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] GRE interface packet receive procedure


On 3/19/2019 6:29 AM, pei Jikui wrote:
> hi,
>
> 1) I am reading the OVS source code about how a GRE interface in OVS
> receives packets into OVS bridge.
>
>  I found there are two places that the GRE packets will possibly
> be received into OVS bridge.
>
> a) . The first place is when we create a gre interface with
> gre_create->ovs_netdev_link->netdev_rx_handler_register
>   The register rx_handler is netdev_frame_hook which will
> receive the packets into the ovs bridge.
>
>  b) The second place is located at the dp_init which will register
> a packet handler function gre_rcv for GRE protocol packets.
>  gre_rcv will also receive the packets to OVS bridge.
>
>
> 2) My questions are,
>  a)  Which is the real receive handler for the GRE packets?
>  b) Is it possible that the packets could be received by both of
> the two cases. If yes, for which scenarios will be match to each one?

OVS supports a user space datapath and a kernel datapath so it depends
on whether you're using the user space datapath or the kernel datapath.

- Greg

>
> Thanks much.
>
> Jikui
>
>
>
>
> ___
> 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] GRE interface packet receive procedure

[pei Jikui]

hi,

1) I am reading the OVS source code about how a GRE interface in OVS receives 
packets into OVS bridge.

 I found there are two places that the GRE packets will possibly be 
received into OVS bridge.

a) . The first place is when we create a gre interface with 
gre_create->ovs_netdev_link->netdev_rx_handler_register
  The register rx_handler is netdev_frame_hook which will receive the 
packets into the ovs bridge.

 b) The second place is located at the dp_init which will register a packet 
handler function gre_rcv for GRE protocol packets.
 gre_rcv will also receive the packets to OVS bridge.


2) My questions are,
 a)  Which is the real receive handler for the GRE packets?
 b) Is it possible that the packets could be received by both of the two 
cases. If yes, for which scenarios will be match to each one?

Thanks much.

Jikui



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

[ovs-discuss] 答复: 回复: a question regarding to tap internal interface

[pei Jikui]

Thank you for the help.

发送自 Outlook

发件人: Ben Pfaff 
发送时间: 2019年3月19日 4:32:22
收件人: pei Jikui
抄送: ovs-discuss@openvswitch.org
主题: Re: 回复: [ovs-discuss] a question regarding to tap internal interface

I think that "tap" is just the name of the interface in that case.  I
don't know why it is named "tap".

On Sat, Mar 16, 2019 at 11:27:21PM +, pei Jikui wrote:
> Ben,
>
> Thanks much for your reply.
>
> My confusion comes from the openstack's official document of 
> https://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html
>
>As illustrated in the picture, we can see that the interface used to 
> connect ovs and dhcp-netns is a tap interface. While from the output of 
> "ovs-vsctl show", it indicates that the type of interface is internal.  That 
> confuses me much.
>
>I am thinking that the tap interface is for the name of the interface 
> instead of the type of the interface?
>
> Thanks
>
>
>
>
>
>
>
>
> 发送自 Outlook<http://aka.ms/weboutlook>
>
> 
> 发件人: Ben Pfaff 
> 发送时间: 2019年3月17日 1:44
> 收件人: pei Jikui
> 抄送: ovs-discuss@openvswitch.org
> 主题: Re: [ovs-discuss] a question regarding to tap internal interface
>
> On Sat, Mar 16, 2019 at 11:24:34AM +, pei Jikui wrote:
> > hi,
> >
> > 1) From the openstack documents, we know that for the tenant's dhcp 
> > functionality, the usage is to connect a dhcp netns to the ovs using a tap 
> > interface.
> > At the same time, the ovs-vsctl show that the tap interface is a type of 
> > internal interface for OVS.
>
> This is wrong.  Tap and internal are different kinds of interfaces.
> What does ovs-vsctl show that makes you confuse the two?
>
> > While I could not add a tap type interface to ovs as an internal type of 
> > interface for OVS.
> >
> > The commands I used,
> > a) ip tuntap add dev tap0 mode tap.
> > b) ovs-vsctl add-port ovs0 tap0 -- set inteface tap0 type=internal
>
> These commands are wrong.  If you create a tap interface, you must not
> tell ovs-vsctl that it is an internal interface.
>
> What led you to believe that these commands were correct?
>
> > error: "could not add network device tap12 to ofproto (No such device)"
> >
> > 2) My questions are ,
> >a) how to add a tap interface to OVS and set it as internal type of 
> > interface of OVS?
>
> You cannot.  That is not possible.


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

[ovs-discuss] a question regarding to tap internal interface

[pei Jikui]

hi,

1) From the openstack documents, we know that for the tenant's dhcp 
functionality, the usage is to connect a dhcp netns to the ovs using a tap 
interface.
At the same time, the ovs-vsctl show that the tap interface is a type of 
internal interface for OVS.

While I could not add a tap type interface to ovs as an internal type of 
interface for OVS.

The commands I used,
a) ip tuntap add dev tap0 mode tap.
b) ovs-vsctl add-port ovs0 tap0 -- set inteface tap0 type=internal

error: "could not add network device tap12 to ofproto (No such device)"

2) My questions are ,
   a) how to add a tap interface to OVS and set it as internal type of 
interface of OVS?
   b) Even if the tap interface could be added into ovs, could it be added into 
a netns again?  If the tap interface could be added into ovs and a netns, how 
the traffic flows between the ovs and netns.

Much thanks.












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

[ovs-discuss] 回复: 回复: a question about the interface type change

[pei Jikui]

Much thanks.


发送自 Outlook<http://aka.ms/weboutlook>


发件人: Ben Pfaff 
发送时间: 2019年3月15日 10:01
收件人: pei Jikui
抄送: disc...@openvswitch.org
主题: Re: 回复: [ovs-discuss] a question about the interface type change

Please don't drop the mailing list.

OVS supports changing interface types, but it's not going to delete an
existing tap device for the purpose of creating an internal device with
the same name.

On Fri, Mar 15, 2019 at 12:17:26AM +, pei Jikui wrote:
> Thanks for your help.
>
> When I tried to change a system interface to internal type, the following 
> result occurs. Does that mean that we could not change an interface's type in 
> OVS?
>
> 1) There is no error hint in cli.
> "ovs-vsctl set interface tap11 type=internal".
>
> 2) The interface tap11 could not be list in the output of "ovs-dpctl show" 
> anymore.
>
> 3) output of "ovs-vsctl show" indicates there is something wrong with the 
> interface tap11.
> [root@localhost ~]# ovs-vsctl show
> 9d6ac6bb-ea06-489f-b7f6-b681cd617b1e
> Bridge "ovs0"
> Port "tap11"
> Interface "tap11"
> type: internal
> error: "could not add network device tap11 to ofproto (No 
> such device)"
> Port "ovs0"
> Interface "ovs0"
>         type: system
> ovs_version: "2.10.1"
>
>
>
>
> 发送自 Outlook<http://aka.ms/weboutlook>
>
> ________
> 发件人: Ben Pfaff 
> 发送时间: 2019年3月15日 0:46
> 收件人: pei Jikui
> 抄送: ovs-discuss@openvswitch.org
> 主题: Re: [ovs-discuss] a question about the interface type change
>
> On Thu, Mar 14, 2019 at 03:12:03PM +, pei Jikui wrote:
> > I have a question regarding to the ovs' interface type.
> >
> > For example, we have added an port tap1 into the ovs bridge as the default 
> > type of interface, system as designed.
> > The command line is " ovs-vsctl add-port br0 tap1"
> > If we change the interface tap1's type to internal via the command link 
> > "ovs-vsctl set interface tap1 type=internal".
>
> This will try to create a system internal device called tap1.  It won't
> work properly because there's already a system tap device named "tap1"
> and will thus cause a name conflict.  Thus, it's a bad idea and unlikely
> to do anything useful.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] a question about the interface type change

[pei Jikui]

I have a question regarding to the ovs' interface type.

For example, we have added an port tap1 into the ovs bridge as the default type 
of interface, system as designed.
The command line is " ovs-vsctl add-port br0 tap1"
If we change the interface tap1's type to internal via the command link 
"ovs-vsctl set interface tap1 type=internal".

What happens to the interface tap1? Will its receiving and sending handlers be 
changed?  Which function in the source code is for the type change purpose?

Thanks in advance?


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

[ovs-discuss] 答复: How does OVS gre packet flow

[pei Jikui]

I got a well understanding about this with the help of the following post.

https://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/#scenario-3-the-isolated-bridge

thanks

Pei


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

Re: [ovs-discuss] How does OVS gre packet flow

[pei Jikui]

I got a well understanding about this with the help of the following post.

https://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/#scenario-3-the-isolated-bridge

thanks

Pei


发件人: pei Jikui 
发送时间: 2019年1月28日 22:40
收件人: ovs-discuss@openvswitch.org
主题: 答复: How does OVS gre packet flow

more information, the experiment I did is,

1) at HostA,
ping 1.2.3.5 it succeeded.   tcpdump -n -e -i ens33 proto gre at hostB could 
capture the GRE packet.

at HostB,
ping 1.2.3.4 it succeeded.   tcpdump -n -e -i ens33 proto gre at hostA could 
capture the GRE packet.


While I still want to understand how the GRE packet is encapsulated one Host 
and then forwarded to the other Host.  How the gre1 interface's functionality 
is called at each host? The two bridges at each host are not connected, how the 
packets forwarded between the two bridges br1 and br2 at each host?

Thanks much in advance.


发件人: pei Jikui
发送时间: 2019年1月28日 22:20
收件人: ovs-discuss@openvswitch.org
主题: How does OVS gre packet flow

hi,

1) I am experimenting the OVS GRE tunnel with the following configurations with 
two hosts, HOSTA and HOSTB. The  experiment succeeded while I still could not 
understand how the packet flows between the two hosts.

There are two bridges created by ovs-vsct at each host (br1 and br2).  These 
two bridges in one Host aren't even connected then how the packets are 
forwarded between the two bridges in one host and among the two hosts hence? 
And how the packets are encapsulated with the GRE header?

2) test-bed and configuration

HostA with ip 10.128.0.155
HostB with ip 10.128.0.156

At HostA:
a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.155/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.156

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


At HostB:

a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.156/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.155

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


Thanks

Jikui

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

[ovs-discuss] 答复: How does OVS gre packet flow

[pei Jikui]

more information, the experiment I did is,

1) at HostA,
ping 1.2.3.5 it succeeded.   tcpdump -n -e -i ens33 proto gre at hostB could 
capture the GRE packet.

at HostB,
ping 1.2.3.4 it succeeded.   tcpdump -n -e -i ens33 proto gre at hostA could 
capture the GRE packet.


While I still want to understand how the GRE packet is encapsulated one Host 
and then forwarded to the other Host.  How the gre1 interface's functionality 
is called at each host? The two bridges at each host are not connected, how the 
packets forwarded between the two bridges br1 and br2 at each host?

Thanks much in advance.


发件人: pei Jikui
发送时间: 2019年1月28日 22:20
收件人: ovs-discuss@openvswitch.org
主题: How does OVS gre packet flow

hi,

1) I am experimenting the OVS GRE tunnel with the following configurations with 
two hosts, HOSTA and HOSTB. The  experiment succeeded while I still could not 
understand how the packet flows between the two hosts.

There are two bridges created by ovs-vsct at each host (br1 and br2).  These 
two bridges in one Host aren't even connected then how the packets are 
forwarded between the two bridges in one host and among the two hosts hence? 
And how the packets are encapsulated with the GRE header?

2) test-bed and configuration

HostA with ip 10.128.0.155
HostB with ip 10.128.0.156

At HostA:
a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.155/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.156

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


At HostB:

a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.156/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.155

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


Thanks

Jikui

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

[ovs-discuss] How does OVS gre packet flow

[pei Jikui]

hi,

1) I am experimenting the OVS GRE tunnel with the following configurations with 
two hosts, HOSTA and HOSTB. The  experiment succeeded while I still could not 
understand how the packet flows between the two hosts.

There are two bridges created by ovs-vsct at each host (br1 and br2).  These 
two bridges in one Host aren't even connected then how the packets are 
forwarded between the two bridges in one host and among the two hosts hence? 
And how the packets are encapsulated with the GRE header?

2) test-bed and configuration

HostA with ip 10.128.0.155
HostB with ip 10.128.0.156

At HostA:
a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.155/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.156

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


At HostB:

a)Create two bridges br1 and br2

   ovs-vsctl add-br br1

   ovs-vsctl add-br br2

b)Configure br1

  ovs-vsctl add-port br1 ens33

  ip addr flush dev ens33

  ip addr add 10.128.0.156/24 dev br1

c)Configure br2

  ovs-vsctl add-port br2 gre1 -- set interface gre1 type=gre options: 
remote_ip=10.128.0.155

  ip addr add 1.2.3.4/24 dev br2

  ip link set dev br2 up


Thanks

Jikui

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

[ovs-discuss] 答复: 答复: openvswitch.ko replacement

[pei Jikui]

much thanks for the great help.

pei




发件人: Numan Siddique 
发送时间: 2019年1月24日 20:40
收件人: pei Jikui
抄送: ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] 答复: openvswitch.ko replacement



On Thu, Jan 24, 2019 at 6:07 PM pei Jikui 
mailto:jk...@hotmail.com>> wrote:
more information about the errors.
1) when tried "insmod openvswitch"
[root@localhost ovs]# insmod ./datapath/linux/openvswitch.ko
insmod: ERROR: could not insert module ./datapath/linux/openvswitch.ko: File 
exists

2) When I tried "rmmod openvswitch"

rmmod: ERROR: Module openvswitch is in use

3) After "ovs-vsctl del-br " all the bridges, the above two commands run well.

Please the FAQ here - http://docs.openvswitch.org/en/latest/faq/issues/
You can't unload the module unless its reference count drops to 0.


Thanks
Numan


Thanks

Pei



发件人: 
ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org> 
mailto:ovs-discuss-boun...@openvswitch.org>>
 代表 pei Jikui mailto:jk...@hotmail.com>>
发送时间: 2019年1月24日 18:43
收件人: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>
主题: [ovs-discuss] openvswitch.ko replacement

Hi,

In the ovs version 2.9.10, I made some changes in the datapath and want to 
replace the openvswtich.ko with the new built one.
While I couldn't insmod this new openvswitch.ko unless I delete all the bridges 
using "ovs-vsctl del-br *".

Is this by design or there are some ways to avoid deleting the bridges in order 
to replace the new openvswitch.ko?

Thanks.

Pei
___
discuss mailing list
disc...@openvswitch.org<mailto: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] 答复: openvswitch.ko replacement

[pei Jikui]

more information about the errors.
1) when tried "insmod openvswitch"
[root@localhost ovs]# insmod ./datapath/linux/openvswitch.ko
insmod: ERROR: could not insert module ./datapath/linux/openvswitch.ko: File 
exists

2) When I tried "rmmod openvswitch"

rmmod: ERROR: Module openvswitch is in use

3) After "ovs-vsctl del-br " all the bridges, the above two commands run well.

Thanks

Pei



发件人: ovs-discuss-boun...@openvswitch.org  
代表 pei Jikui 
发送时间: 2019年1月24日 18:43
收件人: ovs-discuss@openvswitch.org
主题: [ovs-discuss] openvswitch.ko replacement

Hi,

In the ovs version 2.9.10, I made some changes in the datapath and want to 
replace the openvswtich.ko with the new built one.
While I couldn't insmod this new openvswitch.ko unless I delete all the bridges 
using "ovs-vsctl del-br *".

Is this by design or there are some ways to avoid deleting the bridges in order 
to replace the new openvswitch.ko?

Thanks.

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

[ovs-discuss] openvswitch.ko replacement

[pei Jikui]

Hi,

In the ovs version 2.9.10, I made some changes in the datapath and want to 
replace the openvswtich.ko with the new built one.
While I couldn't insmod this new openvswitch.ko unless I delete all the bridges 
using "ovs-vsctl del-br *".

Is this by design or there are some ways to avoid deleting the bridges in order 
to replace the new openvswitch.ko?

Thanks.

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

[ovs-discuss] 答复: Help about "ovs-vsctl add-port" command

[pei Jikui]

Ben,

Much thanks for your quick reply.

1) Yes, I DID check the logs located at /usr/local/ovs/var/log/openvswitch. The 
message is just the same as the one popped up for ovs-vsctl command.
Following is the pieces from the log files.

2019-01-22T16:34:08.333Z|00051|bridge|WARN|could not open network device port1 
(No such device)

2) I also tried with the older version 2.0.0 and the results are different with 
newer version such as 2.11.90. Please see the following blocks.
a) for the version 2.11.90. The error message will occure since port1 does 
not exist.

[root@localhost ovs]# ovs-vsctl --version

ovs-vsctl (Open vSwitch) 2.11.90

DB Schema 7.16.1


[root@localhost ovs]# ovs-vsctl show

ad38d546-6cbc-4291-89f9-f2b4adb2f68d

Bridge "br0"

Port "br0"

Interface "br0"

type: internal

ovs_version: "2.11.90"

[root@localhost ovs]# ovs-vsctl add-port br0 port1

ovs-vsctl: Error detected while setting up 'port1': could not open network 
device port1 (No such device).  See ovs-vswitchd log for details.

ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".



b) For version 2.0.0. The error message will not occur even if the port1 was 
NOT pre-created.


root@localhost ~]# ovs-vsctl --version

ovs-vsctl (Open vSwitch) 2.0.0

Compiled Apr 19 2018 17:57:34

[root@localhost ~]# ovs-vsctl add-br br0

[root@localhost ~]# ovs-vsctl add-port br0 port1

[root@localhost ~]# ovs-vsctl show

3bfbc88a-0329-4594-b21d-2d9fd8d97c27

Bridge "br0"

Port "br0"

Interface "br0"

type: internal

Port "port1"

Interface "port1"

ovs_version: "2.0.0"




Thanks


Pei




发件人: Ben Pfaff 
发送时间: 2019年1月24日 11:51
收件人: pei Jikui
抄送: ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] Help about "ovs-vsctl add-port" command

On Thu, Jan 24, 2019 at 03:10:48AM +, pei Jikui wrote:
> 1) When I tried to add a port in ovs-version 2.8.1 via "ovs-vsctl add-port 
> br0 port1" command, the following error hint occurred.
>
> "ovs-vsctl: Error detected while setting up 'poas': could not open network 
> device poas (No such device).  See ovs-vswitchd log for details.
> ovs-vsctl: The default log directory is "/usr/local/ovs/var/log/openvswitch"."

We wrote this error message to encourage people to look at the log.  It
even says where the log is so that you can look at it more easily.
Despite that, you have not told us what is in the log.  Can you explain
how the error message could make this clearer?  We really are trying to
be helpful here, but numerous people read the error message and don't
actually pay any attention to it.  Why?

> 2) While the same command works well in ovs version2.0.0.
>
> 3) I googled and there is a answer saying that before adding a port into ovs, 
> the port must be seen via "ifconfig -a" which mean it must exist before being 
> added into ovs.
>
> Is the answer 3) is right? If yes, this is a behavior change from 2.0.0.? If 
> 3) is not the right answer, how I could fix this?

3) is right and it has not changed since the very first version of OVS
in 2009.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Help about "ovs-vsctl add-port" command

[pei Jikui]

Hi,

1) When I tried to add a port in ovs-version 2.8.1 via "ovs-vsctl add-port br0 
port1" command, the following error hint occurred.

"ovs-vsctl: Error detected while setting up 'poas': could not open network 
device poas (No such device).  See ovs-vswitchd log for details.
ovs-vsctl: The default log directory is "/usr/local/ovs/var/log/openvswitch"."

2) While the same command works well in ovs version2.0.0.

3) I googled and there is a answer saying that before adding a port into ovs, 
the port must be seen via "ifconfig -a" which mean it must exist before being 
added into ovs.

Is the answer 3) is right? If yes, this is a behavior change from 2.0.0.? If 3) 
is not the right answer, how I could fix this?

Thanks.

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