> 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.
Yep I noticed this last Friday, probably should have sent an email out to the list so no one else was surprised. Unfortunately, I don't think the fix for this problem is totally straight forward. Currently the code has the assumption that a given ofport will only use one tnl_backer datapath port over it's lifetime. But with VXLAN ports, it's possible that an ofport's netdev configuration will change, and as a result it will have to switch to a new tnl_backer with a different config. I have some ideas which I think will resolve this issue, but I haven't gotten terribly far into the implementation. If you'd like to take it on, I'd be happy to discuss further, otherwise I'll probably have a fix out in the next couple of days. Ethan > > 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
