[ovs-discuss] Ubuntu 14.04 GRE tunnel

Ben Pfaff blp at nicira.com
Tue May 20 14:41:25 UTC 2014


The FAQ has some suggestions:

A: To debug network behavior problems, trace the path of a packet,
   hop-by-hop, from its origin in one host to a remote host.  If
   that's correct, then trace the path of the response packet back to
   the origin.

   Usually a simple ICMP echo request and reply ("ping") packet is
   good enough.  Start by initiating an ongoing "ping" from the origin
   host to a remote host.  If you are tracking down a connectivity
   problem, the "ping" will not display any successful output, but
   packets are still being sent.  (In this case the packets being sent
   are likely ARP rather than ICMP.)

   Tools available for tracing include the following:

       - "tcpdump" and "wireshark" for observing hops across network
         devices, such as Open vSwitch internal devices and physical
         wires.

       - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
         later or "ovs-dpctl dump-flows <br>" in earlier versions.
         These tools allow one to observe the actions being taken on
         packets in ongoing flows.

         See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
         documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
         documentation, and "Why are there so many different ways to
         dump flows?" above for some background.

       - "ovs-appctl ofproto/trace" to observe the logic behind how
         ovs-vswitchd treats packets.  See ovs-vswitchd(8) for
         documentation.  You can out more details about a given flow
         that "ovs-dpctl dump-flows" displays, by cutting and pasting
         a flow from the output into an "ovs-appctl ofproto/trace"
         command.

       - SPAN, RSPAN, and ERSPAN features of physical switches, to
         observe what goes on at these physical hops.

   Starting at the origin of a given packet, observe the packet at
   each hop in turn.  For example, in one plausible scenario, you
   might:

       1. "tcpdump" the "eth" interface through which an ARP egresses
          a VM, from inside the VM.

       2. "tcpdump" the "vif" or "tap" interface through which the ARP
          ingresses the host machine.

       3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
          the host interface through which the ARP egresses the
          physical machine.  You may need to use "ovs-dpctl show" to
          interpret the port numbers.  If the output seems surprising,
          you can use "ovs-appctl ofproto/trace" to observe details of
          how ovs-vswitchd determined the actions in the "ovs-dpctl
          dump-flows" output.

       4. "tcpdump" the "eth" interface through which the ARP egresses
          the physical machine.

       5. "tcpdump" the "eth" interface through which the ARP
          ingresses the physical machine, at the remote host that
          receives the ARP.

       6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
          remote host that receives the ARP and observe the VM "vif"
          or "tap" interface to which the flow is directed.  Again,
          "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.

       7. "tcpdump" the "vif" or "tap" interface to which the ARP is
          directed.

       8. "tcpdump" the "eth" interface through which the ARP
          ingresses a VM, from inside the VM.

   It is likely that during one of these steps you will figure out the
   problem.  If not, then follow the ARP reply back to the origin, in
   reverse.


On Tue, May 20, 2014 at 08:50:15AM +0200, Tommaso Patrizi wrote:
> I???ve read somewhere else that I can overlook the log warnings.  
> 
> Actually the two interfaces can ping each other and I can use psql to connect to the other interface.
> 
> But data streaming from pg_basebackup is not working.
> 
> Any hint (ufw is disabled on both ends)
> 
> Thanks again
> 
> Tommaso  
> 
> ------------------------------------
> 
> IN OBSCURO MIRANDA RELUCENT
> 
> 
> On Tuesday 20 May 2014 at 00:30, Ben Pfaff wrote:
> 
> > Please don't drop the list.
> >  
> > I guess that you will need to figure out some other reason, then, why
> > "No such device" is showing up. Perhaps you could try "strace".
> >  
> > On Mon, May 19, 2014 at 10:29:13PM +0200, Tommaso Patrizi wrote:
> > > It's the log of server 10.1.1.254 and there actually is a port with that
> > > name.
> > >  
> > > Thanks
> > > Il 19/mag/2014 22:05 "Ben Pfaff" <blp at nicira.com (mailto:blp at nicira.com)> ha scritto:
> > >  
> > > > On Mon, May 19, 2014 at 08:56:41AM +0200, Tommaso Patrizi wrote:
> > > > > Hi, I installed the 2.0.1 openswitch version included with the Ubuntu
> > > >  
> > > > 14.04 distribution.
> > > > >  
> > > > > I set up a simple gee tunnel and containers are pinging each other but
> > > > any data flux is blocked.
> > > > >  
> > > > > 2014-05-19T00:02:08.362Z|00942|netdev_linux|WARN|ethtool command
> > > > ETHTOOL_GSET on network device pl17753eth1 failed: No such device
> > > > > 2014-05-19T00:02:08.376Z|00943|ofproto|WARN|Dropped 37 log messages in
> > > >  
> > > > last 7767 seconds (most recently, 7736 seconds ago) due to excessive rate
> > > >  
> > > > It looks very much like there's no actual port with the name you specified.
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org (mailto:discuss at openvswitch.org)
> > http://openvswitch.org/mailman/listinfo/discuss
> >  
> >  
> 
> 



More information about the discuss mailing list