Alin,
Saurabh shared the wireshark trace you sent him. I agree that the packets have 
protocol 0x01 - ICMP. So, ping packets are directly being sent over the wire 
without encap.

To start with, let's clear out the following variables:
1. Is there a patch port at all between br-int and br-pif? I remember you 
mentioning that you had used a patch port earlier.
2. Also, I see the following controller entry in vsctl output you sent earlier. 
Can we remove it? This was not covered in the steps we provided.
       Controller "ptcp:9999:127.0.0.1"

In fact, just to help trouble shooting, can you pls. recreate the VXLAN ports 
on both the hosts? You mentioned that checksum offload is disabled for Tx and 
Rx on both the VIF and the physical NIC, that is fine.

Once the VXLAN ports are re-created, let's start running ping from VM on HV1 -> 
VM on HV2, and trouble shoot things one step at a time as follows:
1. Does VTEP to VTEP ping work? ie. ping sent from the HV1 to HV2 from and to 
VTEP IP address.
   - If yes, no connectivity issues.

2. Does the packet sent by the VM show up on the physical NIC on sender, and is 
it encapsulated?
   - If no, then there's issues on the Tunnel Tx side. We need to look at the 
flows to see what is going on. Just output of ovs-dpctl.exe a few times, would 
give us enough information.

3. What is the UDP checksum in the VXLAN packet?
   - Should be 0.

4. Is the packet received on the physical NIC of the receiver host?
   - If yes, then packet is making it to the PIF bridge.

5. What are the flows seen on the receiver host?
   - Do we see a flow that forwards the outer VXLAN packet to port ending with 
#216?
   - If yes, then packet is going to the decap code.
   - If no, then the packet is being dropped either during miss, or during 
decap.
   - For an issue with packet miss, looking at "ovs-vswitchd.exe -v" logs will 
help. Do we see a "packt recvd with proto" log?
   - For an issue with decap code, it is hard to debug.

6. Is the packet being received by the VM?
   - If no, then the packet is being dropped during decap or during miss.

Trying out steps #1-#6, will at least point us towards the right direction to 
debug this further. I know we are at step #2 now. But, let's try re-creating 
the VXLAN ports, and give it a shot.

Thanks for trying out the solution.

Look forward to hearing from you.

thanks,
Nithin


On Jul 25, 2014, at 8:42 PM, Saurabh Shah <ssaur...@vmware.com> wrote:

> Hi Alin
> Sorry, but I am a little confused.  So, the two VM’s on different HyperV can 
> ping each other, but the ping is not encapsulated in a VXLAN header? Is that 
> what you are seeing.
> 
> Thanks!
> Saurabh
> 
> From: Alin Serdean 
> <aserd...@cloudbasesolutions.com<mailto:aserd...@cloudbasesolutions.com>>
> Date: Friday, July 25, 2014 at 8:30 PM
> To: Saurabh Shah <ssaur...@vmware.com<mailto:ssaur...@vmware.com>>, 
> Alessandro Pilotti 
> <apilo...@cloudbasesolutions.com<mailto:apilo...@cloudbasesolutions.com>>
> Cc: "dev@openvswitch.org<mailto:dev@openvswitch.org>" 
> <dev@openvswitch.org<mailto:dev@openvswitch.org>>
> Subject: RE: [ovs-dev] [PATCH v2 0/3] Support for OVS datapath on Windows 
> platform.
> 
> I have disabled the RX/TX checksum offload on both HyperV and VM's (also 
> tried with a KVM).
> 
> The pings work but they are not encapsulated using VXLAN.
> 
> Kind Regards,
> Alin.
> ________________________________________
> From: Saurabh Shah [ssaur...@vmware.com<mailto:ssaur...@vmware.com>]
> Sent: Saturday, July 26, 2014 5:50 AM
> To: Alin Serdean; Alessandro Pilotti
> Cc: dev@openvswitch.org<mailto:dev@openvswitch.org>
> Subject: Re: [ovs-dev] [PATCH v2 0/3] Support for OVS datapath on Windows 
> platform.
> 
> 
> I disabled RX/TX
> (02) works
> (03) works
> 
> Here is a flow with a tun_id maybe it will help:
> PS C:\ovs_guys\binaries> .\ovs-dpctl.exe dump-flows | findstr tun
> 2014-07-26T02:10:30Z|00001|socket_util|ERR|4789:0.0.0.0: bind: Only one
> usage of each socket address (protocol/network a
> ddress/port) is normally permitted.
> skb_priority(0),skb_mark(0),in_port(16777216),eth(src=00:0c:29:45:77:70,ds
> t=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=
> 10.13.8.101,tip=10.13.8.160,op=1,sha=00:0c:29:45:77:70,tha=00:00:00:00:00:
> 00), packets:0, bytes:0, used:never, actions:1
> 6777225,16777289,16777288,set(tunnel(tun_id=0x0,src=10.13.8.101,dst=10.13.
> 8.160,tos=0x0,ttl=64,flags(df,key))),16777218
> PS C:\ovs_guys\binaries>
> 
> I can see it trying but not for the VMs they still don't trasmit under
> VXLAN.
> 
> I am assuming you have disabled RX/TX checksum on both the HyperV¹s and
> the VM¹s. So, do the pings work now? You mentioned that (02) and (03)
> works, but the comment above seems to suggest that something is still not
> working.
> 
> Saurabh
> 
> 
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=91mA6r8Rec0D5fXtrjPsGwf6HAu9Bs7dygwKFmbq7OA%3D%0A&s=7d944c578438874b8048b65eb40d95bedc304a1c4aa7de99593847fd6196f55d

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to