[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