Manuel, do you mean sfc103 demo? dmesg should be able to show invalid vxlan flags message if vxlangpe finds invalid flags. I didn’t encounter such issue in sfc104, please let me know how I can reproduce your issue in my machine.
From: Manuel Buil [mailto:[email protected]] Sent: Thursday, May 4, 2017 4:30 AM To: Yang, Yi Y <[email protected]> Cc: [email protected] Subject: Problem with vxlan-gpe interface in ovs2.6 Hello Yi Yang, We are using your docker image docker-ovs:yyang to test stuff in ODL-SFC Carbon. Today we found out that packets sent through an vxlan-gpe tunnel are not accepted by the other VTEP. This is the port sending the packets in OVS 1. Port "tundaae6e77d14" Interface "tundaae6e77d14" type: vxlan options: {dst_port="4880", exts=gpe, key=flow, local_ip="172.19.0.3", "nshc1"=flow, "nshc2"=flow, "nshc3"=flow, "nshc4"=flow, nsi=flow, nsp=flow, remote_ip=flow} Here is the output of tcpdump where the packets can be seen: 16:53:11.114196 IP 172.19.0.3.58481 > 172.19.0.2.4880: UDP, length 120 16:53:12.113785 IP 172.19.0.3.58481 > 172.19.0.2.4880: UDP, length 120 And this is the port in OVS 2 which receives the packets but for unknown reasons, it does not accept them: Port "tun28619095a5a" Interface "tun28619095a5a" type: vxlan options: {dst_port="4880", exts=gpe, key=flow, local_ip="172.19.0.2", "nshc1"=flow, "nshc2"=flow, "nshc3"=flow, "nshc4"=flow, nsi=flow, nsp=flow, remote_ip=flow} The traffic going through other vxlan ports (not gpe and using destination port 4789) works. I am bit lost on what might be the problem, so any hint you can provide us will be appreciated. I found out one thing which perhaps is the source of the problem. In the packets working this is the vxlan header: 0800 0000 0000 0000 The packets not working have the following vxlan header: 0c00 0003 0000 0800 Look at the first byte, the packets working have 000001000 and the ones not working 00001100. I checked the VXLAN spec and it says: VXLAN Header: This is an 8-byte field that has: - Flags (8 bits): where the I flag MUST be set to 1 for a valid VXLAN Network ID (VNI). The other 7 bits (designated "R") are reserved fields and MUST be set to zero on transmission and ignored on receipt. Not all are set to 0! could it be that the docker container where OVS2 is running drops the packets because it is expecting all flag bits to be 0 except for the one specifying VNI? Thanks, Manuel
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
