On Tue, Feb 16, 2016 at 2:15 PM, Jiri Benc <jb...@redhat.com> wrote: > Sorry for the late answer, was busy with a conference and internal > meetings in the past two weeks. > > On Tue, 2 Feb 2016 17:15:15 -0800, Jesse Gross wrote: >> I think this sounds like a good idea if we can find a way to do it >> cleanly. From OVS's perspective, the main thing that we need is a way >> to indicate the first header that we expect to see. We used to have >> this in struct tnl_ptk_info proto but that is no longer exposed to >> OVS. We also want to make sure that a device that is configured in >> this mode behaves in a logical way when not connected to OVS - i.e. it >> knows whether to emit ARP for L2 ports but not L3. I suppose now that >> lightweight tunneling is here both interfaces are common and therefore >> the problem is the same in each case, which is a good thing. > > There's only one way to solve this cleanly in the kernel. The L2 vs. L3 > mode has to be selected while creating the tunnel interface and cannot > be changed afterwards (only by deleting and recreating the interface). > The reason is that the L3 interface needs to be of ARHRD_NONE type > instead of ARPHRD_ETHER. With additional flags set by the kernel > (IFF_NOARP in particular), this works as expected out of ovs, e.g. for > route based encapsulation. > > It's not possible to mix those two in a single interface. E.g. for > VXLAN-GPE, it's either Ethernet header is encapsulated or not for a > given interface (and thus for a given vport), and never both. If we did > that, such interface wouldn't work standalone, outside of ovs. > > I don't think it's a problem. The information whether Ethernet header > info is provided in the flow key or not can be directly deduced from the > net_device type. It's quite generic this way: if it's ARPHRD_ETHER, > there's Ethernet header, if it's ARPHRD_NONE, no L2 header is > available. In the future, it's easy to add different L2 transports if > desired in the same way. > > The user has to request the L2 or L3 mode when creating the VXLAN-GPE > interface. This will be the same for L3 Geneve, and likely for GRE, too > (I'll have to check the current implementation of that one). So yes, > we'll need a way to distinguish this when creating the vport. Either a > new vport type, or an L3 flag. It makes sense, actually: the vports are > very different, e.g. different flow rules are needed for L2 and L3 > tunnels (for L3, push_eth when switching to Ethernet will be needed to > be configured at least). > > Of course, currently, the kernel datapath allows only ARPHRD_ETHER > interfaces to be added to the ovs bridge and this will need to be > changed.
The thing that bothers me about this is that it's not really a binary split between Ethernet and IP. L2 "obviously" means Ethernet (although theoretically there could be other things), but L3 means IPv4, IPv6, MPLS, NSH, etc.? That is weird. From a non-OVS kernel perspective, setting L2 basically means that you want to do ARP on the interface and L3 is no ARP. However, if the tunnel is sending and receiving some additional tag then it's not really going to work directly in L3 mode. In the OVS case, you will definitely need to have different flows depending on the inner packet type. However, the most flexible way to handle this is by exposing it through the flow itself - it's not necessarily best to do this through the port, especially if it is not fully specific. Finally, I agree that it would be nice to be able to handle multiple types of encapsulated data at the same time. It seems difficult, or at least more complex, to achieve this with multiple ports. Each would try to register to the same handler and this would fail unless there is some kind of additional registration mechanism. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
