[ovs-discuss] vhost communication between virtio drivers in vms
I'm trying to achieve communication across an OVS switch between to VMs
connected together via an ovs bridge. I was able to do this with a ovs
bridge with to generic libvirt 'network' types. I'm failing to replicate
using DPDK vhost.
In libvirt 'network' scenario vnet[0,1] ports are added to the bridge that
also has a port for the physical NIC on the system. The switch defaults to
its L2 function and I can access the system's IP addresses.
In the DPDK vhost scenario, the client server connections get made, but the
host running the switch doesn't put the ports on the IP stack. I haven't
been able to route a packet between the VMs. Do I need to create "flows"
to mimic a single wire type of connection? I don't need L2 function, but I
did think it might be possible to move IP packets through DPDK. Any
pointers appreciated.
[root@cn03 openvswitch]# ovs-vsctl show
d78a22bb-84c7-46d4-9625-6c9c38aeeff7
Bridge br0
Port br0
Interface br0
type: internal
Port vnet1
Interface vnet1
Port vnet0
Interface vnet0
Port enP5p1s0f0
Interface enP5p1s0f0
Bridge ovs-br0
datapath_type: netdev
Port dpdkvhostclient0
Interface dpdkvhostclient0
type: dpdkvhostuserclient
options:
{vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostclient0"}
Port dpdkvhostclient1
Interface dpdkvhostclient1
type: dpdkvhostuserclient
options:
{vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostclient1"}
Port ovs-br0
Interface ovs-br0
type: internal
ovs_version: "2.13.1"
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovn] does not match prerequisite
On Tue, Oct 20, 2020 at 11:55 AM Tony Liu wrote: > > Hi, > > From ovnsb log, I see many of the following messages. > What does it mean? Is that a concern? > > 2020-10-20T18:52:50.483Z|00093|raft|INFO|current entry eid 2ab3eff8-87e1-4e19-9a1f-d359ad56a9ad does not match prerequisite c6ffd854-6f6e-4533-a6d8-b297acb542e0 in execute_command_request > > > Thanks! > Tony This is expected in cluster mode when there are concurrent transactions initiated from different cluster nodes. It is recommended to connect to the leader for write-heavy clients. Occasional conflict is ok and the transaction will be resubmitted. Thanks, Han ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovn] does not match prerequisite
Hi, >From ovnsb log, I see many of the following messages. What does it mean? Is that a concern? 2020-10-20T18:52:50.483Z|00093|raft|INFO|current entry eid 2ab3eff8-87e1-4e19-9a1f-d359ad56a9ad does not match prerequisite c6ffd854-6f6e-4533-a6d8-b297acb542e0 in execute_command_request Thanks! Tony ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenvSwitch Message too large
Perhaps the interface creating the packet has the wrong MTU?
For instance, a VM is using MTU 1500 but then packets gets
encapsulated?
fbl
On Mon, Oct 19, 2020 at 09:59:13PM +0700, KhacThuan Bk wrote:
> Hi all,
>
> I'm using ovs with bonding interface. All interface is using mtu 1500.
> But in ovs-vswitchd.log i saw some log about "Message too long". I cannot
> use ovs-tcpdump to trace message. Any one used face this problem can tell
> my what is problem. I have some info follow this.
>
> less /var/log/openvswitch/ovs-vswitchd.log
> 2020-10-16T10:26:34.876Z|5804855|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.883Z|5804856|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804857|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804858|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804859|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804860|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804861|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804862|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.947Z|5804863|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:35.179Z|5804864|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
>
>
> [root@host1 ~]# ovs-vsctl show
> a861ee0a-595a-462a-8729-68de6a9026d8
> Manager "ptcp:6640:127.0.0.1"
> is_connected: true
> Bridge br0
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> datapath_type: netdev
> Port phy-br0
> Interface phy-br0
> type: patch
> options: {peer=int-br0}
> Port "bond0"
> Interface "bond0"
> Port br0
> Interface br0
> type: internal
>
> [root@host1 ~]# ip link show bond0
> 10: bond0: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether e4:43:4b:ed:33:20 brd ff:ff:ff:ff:ff:ff
>
> [root@host1 ~]# ovs-vsctl list interface bond0
> _uuid : 89181c9b-f123-48fb-97ed-3252e39f41ce
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 10
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "e4:43:4b:ed:33:20"
> mtu : 1500
> mtu_request : 1500
> name: "bond0"
> ofport : 3
> ofport_request : []
> options : {}
> other_config: {}
> statistics : {collisions=0, rx_bytes=428325175126, rx_crc_err=0,
> rx_dropped=3644084274, rx_errors=0, rx_frame_err=0, rx_over_err=0,
> rx_packets=2667110862, tx_bytes=345128207711, tx_dropped=0, tx_errors=0,
> tx_packets=563989135}
> status : {driver_name=bonding, driver_version="3.7.1",
> firmware_version="2"}
> type: ""
>
> [root@host2 ~]# ovs-vsctl list interface br0
> _uuid : c3df3fc1-b78d-464f-af39-1fee5aff12dc
> admin_state : down
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : full
> error : []
> external_ids: {}
> ifindex : 24
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : 1000
> link_state : down
> lldp: {}
> mac : []
> mac_in_use : "e4:43:4b:ec:c5:60"
> mtu : 1500
> mtu_request : []
> name: br0
> ofport : 65534
> ofport_request : []
> options : {}
> other_config: {}
> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=1000184, tx_errors=0, tx_packets=0}
> status : {driver_name=tun, driver_version="1.6",
> firmware_version=""}
> type: internal
> ___
> discuss mailing list
>
[ovs-discuss] Adding new match field to OvS
Hello everyone, I am currently working on the addition of two new fields to ovs: I already followed the guideline in the FAQs adding my new field to lib/flow. h and lib/meta-flow. h also adding support for nx_put_raw() in lib/nx-match.c. Whenever I try to add a new flow after compiling the modified version it seems that the switch knows about the new field (no errors are thrown), but when dumping the flows it appears that it has been ignored not displaying in the flow. What am I missing? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS 2.13.1-1: ovs-pki req+sign option is not generating the certificate NAME-cert.pem file.
Hi Ben, I use "OpenSSL 1.1.0l" . root@home:/# /usr/bin/openssl version OpenSSL 1.1.0l 10 Sep 2019 Thank you, Warm Regards, Ramesh.G On Mon, Oct 19, 2020 at 11:33 PM Ben Pfaff wrote: > What version of OpenSSL are you using? Run "openssl version". > > On Mon, Oct 19, 2020 at 01:26:05PM +0530, NR 85 wrote: > > Hi Ben, > > > > Here is the contents of the ovs-pki.log when executing "/usr/bin/ovs-pki > > req+sign test --force". > > > > ovs-pki.log : > > > > Generating RSA private key, 2048 bit long modulus > > .+ > > ...+ > > e is 65537 (0x010001) > > Using configuration from ca.cnf > > Error Loading extension section usr_cert > > > > Kindly help resolve this issue. > > > > Thank you, > > Warm Regards, > > Ramesh.G > > > > On Sat, Oct 17, 2020 at 10:08 AM Ben Pfaff wrote: > > > > > On Fri, Oct 16, 2020 at 06:28:45PM +0530, NR 85 wrote: > > > > Hi Team, > > > > > > > > I am facing an issue in ovs-pki in which req+sign option is not > > > generating > > > > the certificate. Kindly look into this issue and provide your > suggestion. > > > > > > > > From the logs below it will be clear that the "test-cert.pem" file > is not > > > > generated and the file with name "test-cert.pem.tmp18614" is > generated > > > with > > > > zero byte. > > > > > > ovs-pki produces its own log. It's probably named ovs-pki.log and > > > probably in /var/log. What's in it? > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
