[ovs-dev] [PATCH]: Trio of small fixes

Ben Pfaff blp at nicira.com
Thu Oct 28 17:16:12 UTC 2010


On Thu, Oct 28, 2010 at 10:03:35AM -0700, Jean Tourrilhes wrote:
> On Thu, Oct 28, 2010 at 10:00:15AM -0700, Ben Pfaff wrote:
> > On Wed, Oct 27, 2010 at 06:19:57PM -0700, Jean Tourrilhes wrote:
> > > ovs-1.0.1-hpl-enable-local.diff
> > > -------------------------------
> > > 	In-band control steal the ARP to/from the local interface even
> > > before they get to rule processing. If one want to be able to process
> > > those ARPs with actual OpenFlow rules, one as to use the
> > > option --out-of-band. But, when you do that, OFPP_LOCAL does not
> > > exist, which defeat the purpose.
> > > 	This patch adds an option to force OFPP_LOCAL to exist when
> > > not running in-band.
> > 
> > I'm pretty sure that we intend for OFPP_LOCAL to always be available.
> > Do you see a reason to make this optional, as opposed to always-on?
> 
> 	I don't know what was your intention and if you had a reason
> to not make it available, so I treated carefully.
> 	Also, my patch is a quick hack, if you enable both --in-band
> and --local, I don't know what will happen.

OK.

Can you describe the problem that this fixes in a bit more detail?

Without your patch, on "master", when I run:

        ovs-dpctl add-dp br0
        ovs-dpctl add-if br0 eth0
        ovs-dpctl add-if br0 eth1
        ovs-dpctl add-if br0 eth2
        ovs-openflowd --out-of-band br0 unix:/tmp/socket
        ovs-ofctl show br0

I see the LOCAL port listed in the output, and when I further run:

        ifconfig br0 192.168.0.20

I can "ping" br0 from elsewhere.  So the problem isn't obvious.

Thanks,

Ben.




More information about the dev mailing list