[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 > disc...@openvswitch.or
[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