[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Issue with Basic OVS + VXLAN + OF and MTU
From:       nick.couchman () seakr ! com (Nick Couchman)
Date:       2016-01-28 20:29:48
Message-ID: 922376187.720882.1454012988893.JavaMail.zimbra () seakr ! com
[Download RAW message or body]

----- Original Message -----
> From: "Nick E Couchman" <nick.couchman at seakr.com>
> To: discuss at openvswitch.org
> Sent: Thursday, January 28, 2016 10:23:30 AM
> Subject: [ovs-discuss] Issue with Basic OVS + VXLAN + OF Configuration

> So, I'm starting to get my feet wet with software-defined networking and am
> running into some issues with my relatively basic configuration.  I have a
> system (we'll call it vSwitchA) connected to a network - let's say
> 192.168.1.0/24 - running Open vSwitch and the Floodlight OpenFlow controller.
> I've got OVS successfully configured and talking to Floodlight.  I have
> another system (vSwitchB), across a couple of L3 physical network hops, also
> talking to the Floodlight controller, and also running OVS.  I've then added a
> VXLAN tunnel between the two systems to (presumably) allow traffic to go
> between the systems.  If I assign IP addresses to the vSwitch on both of the
> systems, I can ping back and forth between the two.  Interestingly, I cannot
> SSH between the two systems over those IP addresses, which is the first
> indication that the VXLAN stuff isn't working quite properly.
> 
> Looks something like this:
> 
> 192.168.1.0/24 <--> eth0-vSwitchA <--VXLAN over existing L3 Networks-->
> vSwitchB-eth1 <--> KVM Guest
> 
> On vSwitchB I have KVM set up, including scripts to add KVM guests to the
> vSwitch.  I create a guest and set it to PXE boot.  There's a DHCP server on
> the 192.168.1.0/24 network (attached through vSwitchA), and a TFTP server
> located on a network adjacent to that (192.168.2.0/24).  If I boot a guest
> system attached to vSwitchB, the PXE boot successfully obtains an IP address,
> but when it tries to download the pxelinux stuff from TFTP, it fails (always).
> 
> I've checked things like firewall, SELinux, and the obvious things like that,
> and can't see a reason why the traffic isn't making it through.  I haven't
> developed a clear pattern/picture with tcpdump as to how far the packets make
> it in either direction.  I'm not sure if, because the TFTP server is on another
> subnet away from the FloodLight controller, if the vSwitches don't know the
> proper path for the traffic?  But, since it is routed, I would think they'd
> just look for the default router, which they do know the path for, and go from
> there.  Also, the fact that SSH traffic doesn't work across the link directly
> between vSwitchA and vSwitchB over VXLAN seems to indicate something else.
> 
> Anyone have any ideas what might be going on here?  Any configs I can try, or
> further debugging I can do to try to figure it out?  I've tried dumping the
> flows on the switches, but because they are fairly dynamic and controlled by
> the Floodlight controller, it's hard to pin them down during the actual
> problem.  I'm seeing some dropped packets on the OVS switch in Linux via the ip
> command, but no errors, overruns, etc.  Not sure if that could indicate an MTU
> issue?
> 
> Thanks in advance,
> Nick
> 

I just love it when the extra five minutes of debugging answers my question.  The \
issue does look like a MTU issue - I lowered MTU on the OVS vSwitches and interfaces \
to 1400 and things seem to be working just fine.  The only exception is the PXE boot \
- still can't get that to work, but it looks like that is because iPXE does not honor \
the DHCP server "option interface-mtu" option that I have set to lower MTU via DHCP, \
and I can't figure out the obvious way to force iPXE into lowering MTU.

-Nick

==
This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary \
Information. If this message is not intended for you, you are strictly prohibited \
from using this message, its contents or attachments in any way. If you have received \
this message in error, please delete the message from your mailbox. This e-mail may \
contain export-controlled material and should be handled accordingly.


[prev in list] [next in list] [prev in thread] [next in thread]