On 1/4/19 3:19 PM, Alexander Witte wrote:
Hi!
Hi Alex,
Environment: KVM FedoraI have a weird issue where a VM can ping one way through the open vswitch but the other way doesn't seem to want to go through. The setup is like this:VM1 --> OVS --> VM2.VM1 has two interfaces: interfaceA is tagging a VLAN in the VM. InterfaceB has no tagging anywhere.
So VM1 interfaceA is adding 802.1Q VLAN tagging inside the guest OS. Correct?
Is OvS doing any filtering? Or is it trying to handle all traffic, tagged and untagged from the guest as best as it can?
VM2 has two interfaces: interfaceA is being tagged (in OVS) with the same VLAN as VM1. Interface B has no VLAN.
So VM2 interfaceA is untagged and OvS is assigning a Port VLAN ID (PVID) to the untagged traffic that's coming into OvS. Correct?
Is OvS doing any filtering?Are interfaces A and interfaces B in the same VLAN in OvS? Or are they in different VLANs?
Interface B can ping through both ways fine. InterfaceA can ONLY ping through Centos --> Cisco. Pinging in the other direction does not work.
Please clarify what CentOS & Cisco are in this context. You've been saying VM1 & VM2. Are CentOS & Cisco the names of the VMs (respectively?)? Or are you also trying to connect from OvS out to the real world and talk to a physical Cisco device?
We traced it to arp replies not making it back through the OVS in one direction. Pretty weird.
Please elaborate on which way traffic works. Also, please elaborate on what tcpdump (et al) shows on the interfaces when pinging either direction.
I can ping one way but not the other way.
What happens if you clear the ARP cache? Do things work? Or is this by chance a bigger issue?
The OVS ports are being created dynamically. I'm defining some libvirt network XMLs that have portgroups in them that are assigned to an OVS. Then I do a virt-install to create the VMs which places the NICs in the portgroups on the OVS. So I create the OVS ports dynamically when the VM boots. OVS-VSCTL show looks fine. If needed I can paste it here (just gotta clean it up a bit since I've been experimenting).
Sadly, I don't know enough about how libvirt interfaces with OvS to comment. Though I should do some reading as I'd like to start using it with libvirt. - I'd appreciate any pointers you have handy to what you followed. (I've not gone looking yet.)
I'm curious if this is common issue/user mistake or are there some gotchas when doing this with KVM virtual machines...? Do these need to be hardcoded as TAP interfaces or INTERNAL interfaces.
I would be quite surprised if you needed to hard code anything, be it TAP or internal interfaces. I would /think/ that you would want to use internal interfaces. At least that's what I use for all my manually created network namespaces (proto containers).
If this is not a common problem/resolution are there any specific commands I can run to paste here to give any willing helper some more insight?
I'd like to see the pertinent parts of the output from "ovs-vsctl show" while both VM1 and VM2 are running and connected. Please state which OvS interfaces belong to which VM & associated guest interface.
Things I've tried: -Removing the VLAN tag.
I would expect that you would need to remove the tagging from the guest OS in VM1 and the port tagging from the OvS port connected to VM2.
-Separating the two interfaces to separate OpenvSwitches.
I would think that you could connect the interfaces to the same OvS as long as they were in non-overlapping VLANs. I.e. interfaces A playing with VID 11 and interfaces B in VLAN 2222.
Any help is greatly appreciated!
I don't know if it's related at all. But I've had a problem creep into my sandbox workstation configuration (it's probably a kernel nob that i fobbed without realizing it) where I have to disable Rx & Tx offload on my OvS (internal) interface. If I don't do that, (I /think/) I am able to ARP & ping, but TCP (I notice it with SSH) connections establish and then subsequently stall & ultimately fail to pass traffic. Disabling Rx & Tx offload on the OvS (internal) interface returns things to normal. Note: This is the OvS (internal) interface from the host, not the OvS interfaces for the guests.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
