On Feb 3, 2013, at 8:56 PM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote:
> I'm running with the latest master, and I noticed I can no longer configure
> VXLAN ports. I'm tracking this down, but wanted to let folks on the list know
> as well.
>
> I am configure my VXLAN port like this:
>
> ovs-vsctl add-port br2 vxlan1 -- set interface vxlan1 \
> type=vxlan options:remote_ip=192.168.1.14 options:key=flow
>
> And I see this in the logs:
>
> 2013-02-03T20:54:11Z|00232|dpif|WARN|system@ovs-system: failed to add vxlan1
> as port: Invalid argument
>
> Upping the verbosity doesn't provide any more clues. The output of
> "ovs-vsctl" and "ovs-dpctl show" below seem to indicate that userspace thinks
> the port is there but the kernel doesn't configure it. GRE ports seem to work
> fine. Any ideas?
>
> Thanks,
> Kyle
>
> [root@linux-br ~]# ovs-vsctl show && ovs-dpctl show
> ccec5b74-c8aa-4006-8712-ad6b95daedfb
> Bridge "br2"
> Port "vxlan1"
> Interface "vxlan1"
> type: vxlan
> options: {key=flow, remote_ip="192.168.1.14"}
> Port "br2"
> Interface "br2"
> type: internal
> Bridge "br1"
> Port "br1"
> Interface "br1"
> type: internal
> Port "eth1"
> Interface "eth1"
> Bridge "eth2-tun"
> Port "eth2"
> Interface "eth2"
> Port "eth2-tun"
> Interface "eth2-tun"
> type: internal
> Bridge "eth2-int"
> Port "vxlan2"
> Interface "vxlan2"
> type: gre
> options: {remote_ip="192.168.10.14"}
> Port "eth2-int"
> Interface "eth2-int"
> type: internal
> ovs_version: "1.9.90"
> system@ovs-system:
> lookups: hit:21 missed:30 lost:0
> flows: 0
> port 0: ovs-system (internal)
> port 1: eth2-int (internal)
> port 2: gre_system (gre: df_default=false, ttl=0)
> port 3: br2 (internal)
> port 4: eth2
> port 5: eth2-tun (internal)
> port 6: eth1
> port 7: br1 (internal)
> [root@linux-br ~]#
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
I figured this out. It looks like the flow based tunneling changes no longer
propagate the destination UDP port down to VXLAN, which requires it. Because of
this, the VXLAN vport code in the kernel is returning an error. I'll go ahead
and fix these up now.
I guess this also signifies I should add some unit tests for VXLAN code to
catch these sorts of things. I'll add that to my list of items to work on as
well.
Thanks,
Kyle
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
