ovs userspace mode, set datapath_type = netdev, virtual host ping normal, iperf
server can not receive the udp or tcp packets received
Has anyone encountered a similar problem? How to solve?___
discuss mailing list
disc...@openvswitch.org
https://mail.op
ovs userspace mode how to install in centos7, datapath-type=netdev ??What does
??netdev?? stand for? as well as with the meter table relation
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
My question is two: 1.ovs user state ping normal, but iperf is not normal, how
to solve?
What are the functions supported by the 2.netdev type bridge?___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discu
In the manual of ovs-dpctl it says:
[...]
"missed" displays the number of packets not matching any existing flow and require user space processing.
"lost" displays number of packets destined for user space process but subsequently dropped before reaching userspace.
[...]
I have the foll
Hello everyone.
Regarding the subject, I would like to enable the HW offload function of TCP
checksum on the NIC in the following server configuration.
If you know how to set it, it would be greatly appreciated if you could teach it
The server configuration is a configuration in which the host O
H i Ilya Maxmets.
Thank ynu very much.
I was able to solve it with the command taught me.
it was very helpful.
Best regards.
iPhoneから送信
> 2021/07/24 1:51、Ilya Maximets のメール:
>
>
>>
>> Hello everyone.
>>
>> Regarding the subject, I would like to enab
Hi,
I have an appliance VM (Cisco vWLC) in libvirt/KVM, connected to an Open
vSwitch bridge through a virtio NIC. For untagged packets, this works fine.
However, the appliance also has a VLAN (I've numbered it 50), tagged using
802.1q. I've attached this to an EoGRE tunnel (tag=50, access port) to
On Wed, May 29, 2019 at 07:04:48PM +0200, Steinar H. Gunderson wrote:
> I have an appliance VM (Cisco vWLC) in libvirt/KVM, connected to an Open
> vSwitch bridge through a virtio NIC. For untagged packets, this works fine.
An update on this:
I've figured out that the untagged packe
On Thu, May 30, 2019 at 10:18:28AM +0200, Steinar H. Gunderson wrote:
> I've tried changing the NICs in the VM definition from virtio to e1000. This
> seemingly fixes communication from the host to the management plane in the VM
> (I no longer need to go through the physical swit
On Tue, Jun 04, 2019 at 01:27:03PM -0700, Ben Pfaff wrote:
> This is certainly super weird. OVS certainly passes ARP packets fine in
> all normal situations.
>
> This is probably something inside the kernel. You might use "ovs-dpctl
> dump-flows" to verify that the OVS kernel module is actually
On Wed, Jun 05, 2019 at 11:33:44AM -0700, Ben Pfaff wrote:
> Is it OVS's responsibility to pad the packets?
If the packet is generated on an OVS internal port, and the destination is a
local VM through hostnet? Surely it's OVS' responsibility then?
> I would think that the driver would take care
On Wed, Jun 05, 2019 at 02:45:53PM -0700, Ben Pfaff wrote:
> OVS, or at least the OVS kernel module, doesn't generate packets. It
> accepts them for processing from some source and then (sometimes)
> delivers them to some destination. Generally it expects that anything
> that comes in is suitable
On Fri, Jun 07, 2019 at 02:57:04PM -0700, Ben Pfaff wrote:
> 4. Kernel L2 stack pushes an Ethernet header.
>
> 5. Kernel Ethernet driver (or a helper) adds padding, etc. as needed and
>passes it to the hardware.
>
>If the "hardware" is an OVS internal device, no padded is needed, so
>
On Fri, Jun 07, 2019 at 03:51:33PM -0700, Gregory Rose wrote:
> In any case I'll try it out with the Debian buster distro and see. I think I
> can use scapy to simulate the undersized/bad CRC packets with the VLAN tag
> that the Cisco vWLC appliance VM sends. I want to see for myself that the
> Li
On Fri, Jun 07, 2019 at 02:06:45PM -0700, Gregory Rose wrote:
> Switches should not be doing any padding or checksum recalculations, that
> would impose a lot of overhead. Switches should just switch traffic.
To a certain extent, they have to. If you ever want to support VLAN trunks
and access po
On Fri, Jun 07, 2019 at 04:09:06PM -0700, Gregory Rose wrote:
> Sure, that's all true but the incoming packet to the switch should be
> padded to the correct size and have the proper checksum before all these
> other operations take place.
Ah, no, they don't have to.
If a NIC produces an 802.1Q-t
On Fri, Jun 07, 2019 at 04:50:43PM -0700, Gregory Rose wrote:
> I see your point - I think we're in agreement about well-formed 802.1q
> packets with VLAN tags being legal at 64 bytes. If openvswitch is not
> stripping the tag then re-tagging (if necessary) and then padding those
> VLAN packets th
On Mon, Jun 10, 2019 at 10:04:36AM -0700, Gregory Rose wrote:
>> It's not the issue we're encountering here. But it is an illustration that a
>> switch really needs to be able to pad; I don't believe openvswitch handles
>> this situation correctly either.
> Specific examples might help. Openvswitc
On Tue, Jun 11, 2019 at 11:06:15AM -0700, Gregory Rose wrote:
> That depends. Tap/tun interfaces can transfer data between user space
> programs and in such cases the packets don't need to be padded to Ethernet
> specs. However, to the extent that any host interface, whether it is
> virtual or ph
On Tue, Jun 11, 2019 at 01:32:22PM -0700, Gregory Rose wrote:
> I don't understand this. The OVS internal port is a switch port. It does
> not originate packets. When you say you 'send TCP on an OVS internal
> port', how are you doing that?
vlan1 is an OVS internal port:
ifconfig vlan1 10.0.0
On Tue, Jun 11, 2019 at 03:00:00PM -0700, Gregory Rose wrote:
> I see the source of the confusion here. The vlan1 interface is added to the
> OVS bridge and the port type
> is internal. Here's a better way to look at this:
>
> Net Device
> OVS switch
> |--|
On Tue, Jun 11, 2019 at 03:59:53PM -0700, Gregory Rose wrote:
> root@ubuntu-1604-base:~# ovs-vsctl add-br br0
> root@ubuntu-1604-base:~# ovs-vsctl show
> 6be291a9-6bab-4fff-bda9-7f54335b4884
> Bridge "br0"
> Port "br0"
> Interface "br0"
> type: internal
>
On Wed, Jun 12, 2019 at 09:53:02AM -0700, Gregory Rose wrote:
> You clipped this part:
> root@ubuntu-1604-base:~# ovs-ctl start
> * Starting ovsdb-server
> * system ID not configured, please use --system-id
> * Configuring Open vSwitch system IDs
> * Starting ovs-vswitchd
> * Enabling remote O
On Wed, Jun 12, 2019 at 10:23:06AM -0700, Gregory Rose wrote:
>> enp57s2 and enp57s3 are not involved in this at all. The traffic is coming
>> from vlan1 and going into vnet1.
> They're bridged in and can act as underlying transport for your vlan1
> interface.
This is true, but also irrelevant as
On Wed, Jun 12, 2019 at 10:53:52AM -0700, Gregory Rose wrote:
>> OK. The tap driver is backed by a character device in /dev/net/tun, right?
>> Could I strace ovs-vswitchd and see what it reads, or is there a fast path
>> here in the kernel driver so I wouldn't see it?
> OVS works on the standard Li
On Wed, Jun 12, 2019 at 01:21:21PM -0700, Gregory Rose wrote:
> No, I'm not saying that. I just pointed out that OVS works on Linux kernel
> skbs.
So I wonder, do skbs have the same minimum size guarantees as Ethernet frames
on the MAC? Is there even a policy here?
>> You intercept the skb and s
On Wed, Jun 12, 2019 at 10:32:54PM +0200, Steinar H. Gunderson wrote:
> I do wonder what will happen if I open up a TAP device and just read from
> /dev/net/tun, with no bridge in-between; whether I will get undersized frames
> on read() then. It will be an interesting experiment when I
27 matches
Mail list logo
