> On Jan 2, 2014, at 16:51, Jesse Gross <je...@nicira.com> wrote: > >> On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chr...@flirble.org> wrote: >> Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT): >>> >>>> On Mon, Dec 23, 2013 at 12:13 AM, Chris Luke <chr...@flirble.org> wrote: >>>> >>>> Open vSwitch handles the OPFF_NORMAL action by passing packets >>>> into a simple layer 2 learning switch. This commit adds the option to >>>> have >>>> packets passed back to the kernel as though Open vSwitch never touched >>>> them. This allows, for instance, bridge member ports to have IP addresses >>>> and for the host to run routing protocols on those ports. >>> >>> >>> Can you give a full example of how you would use this in a hybrid setting? >> >> >> It's pretty basic. Add a bunch of ports that already have configuration >> on them (IP addresses) to a bridge, put the bridge in the normal-means- >> send-it-back-to-the-kernel mode and install flows that match specific >> things, like either the address space of the ports, or targeted protocols >> such as ARP/OSPF/ISIS/LLDP/LDP/etc. I don't want any default learning switch >> behaviours between these ports. The bridge is then just a patch panel >> driven only by explicit flows. >> >> What I am trying to primarily do is model layer 3 behaviors in a controller, >> but more specifically an incremental approach to introducing OpenFlow to >> an existing wide area IP network. This hypothetical network does not run >> OVS (it's built with Cisco and Juniper and so on) but to model at scale I >> need lots of nodes, hence the interest in OVS. >> >> I do however also see value in the same methodology for more server-focused >> uses, such as LLDP as you mentioned. And the other area is the rookie >> mistake of adding your only port to a bridge whilst ssh'ed in and then >> losing access to said machine and wondering why. >> >> >>> I have some high level thoughts. Other people will probably have >>> additional comments. >>> * This type of concept has come up before and its usually in the >>> context of allowing an existing daemon like lldpad to be run on an OVS >>> port. At a minimum, we would need to make sure that whatever we do >>> here is compatible with that and ideally we would be able to >>> essentially solve both problems at the same time. If you are planning >>> on running routing protocol daemons then maybe it is already pretty >>> similar. >> >> >> Exactly. I have lldpd running on my test setup and it appears to work >> fine, but I'll dig into it to be sure. > > Do the packets sent from the daemon go through OVS? It doesn't seem > like they would and while this would likely work in many cases, it is > odd.
No, from the daemon they go directly out the port. The case that needs OVS involvement is incoming packets. > >>> * The OpenFlow "normal" concept already is already pretty overloaded >>> so I think it would be better if we didn't add more things to it. An >>> explicit action would probably make it more programmable as well. >> >> >> So, I originally played with a new action for the datapath to do this >> but it felt like I was touching a lot of code to make it work which >> is why I used a 'special' port number there. > > I don't think that it should require a very large amount of code but > in any case, I think having a new kernel action is the right way to do > it. I can look at that. > >> If you are suggesting a new openflow action, I think that's a broader >> conversation point. 'normal' in the OF protocol is imprecise, but it >> seems to suggest that the device do whatever is 'normal' for it. OVS >> took the approach of being a switch, whereas I want it to behave like a >> Linux machine normally would. I saw these as discrete modes of >> operation, hence the approach of switching which behaviour is desired. > > It seems impossibly confusing for OVS to have a switch that makes it > operate in a non-OVS mode, including with external configuration, etc. > Furthermore, I suspect that the most common use case of this would be > to have an LLDP daemon running on a port but OVS doing the traffic > switching. In that case, you could actually need to use both types of > "normal" simultaneously. I see that you added an additional action in > the newest revision of patch but that just means we have multiple very > similar mechanisms to configure this. Yes, I've come to that conclusion independently. I've split the patch up. Will post the series later. Originally I wanted to avoid custom open flow actions, since in my case I am modeling devices that are layer 3 focused. But I don't now think that's as big a deal as I did. If you feel the switch mode idea is a non-starter then I'll abandon it. > >>> * I'm not sure why we would need to remove any actions already >>> applied to packets when we hit this action. It seems different from >>> the OpenFlow action model. >> >> >> I don't think I drop any actions with my code. If I indicated otherwise >> then that was not intentional. In userspace it changes the behavior >> of the OFPP_NORMAL action to generate a datapath flow with an output >> action to the special 'normal' port. All other actions proceed as usual. >> >> The datapath merely sets a flag when the special port is encountered >> which instructs the hook to return the right value. The snag I came >> across was that this meant always cloning the skb we're given. Having >> since looked at clone_skb() it doesn't seem *that* expensive. > > I was referring to the need to do a skb_clone() for every incoming > packet, which I see you've removed now. > >>> * I agree that upcalls shouldn't work with this model - this seems >>> like it could be issue to making it work seamlessly. >> >> >> What suprised me is that I expected the first packet in a flow to >> fail. The kernel datapath hands it to userspace and forgets about it. >> Userspace does it's thing then programs a flow intp the DP and tries >> to send the packet. I expected this packet to get lost in the >> bitbucket, but instead I see it responding as though 'normal' Linux >> processing *did* happen. > > I think we need a cleaner way to reinsert the packet than setting the > type to loopback. I intend to dig into that. The loopback hack was a happy accident. > It's also not clear to me that using the loopback > device as a fallback in packet_cmd_execute() is the right thing to do. I think using lo as fallback is unnecessary and it should simply fail if it can't find the real input interface. > Doing this right might require upstream kernel changes. > >> I had ancitipated needing to do something to proactively program >> flows into the datapath for this 'normal' action so it catches the >> first packet. It may be I am seeing something else and this may yet >> be required. > > It's not really possible to proactively program flows in the OVS > kernel module since it uses information from the upcall when creating > actions, etc. > Cheers, Chris _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
