[ovs-discuss] ARP issues with KVM and OVS..?
gtaylor at tnetconsulting.net
Sun Jan 6 19:37:16 UTC 2019
On 1/4/19 3:19 PM, Alexander Witte wrote:
> Environment: KVM Fedora
> I 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the discuss