It seems your ovs version is 2.10.0. I thought it should have this feature
ready. Add Justin to see if he can confirm on this.
Is there any core files in your /var/core or /var/log/core?
Thanks,
Daniel
> On Oct 18, 2018, at 1:00 AM, Ravi Kerur wrote:
>
> Hello Daniel,
>
> When I tried to con
I have a lucrative business proposal to discuss with you, please contact me on
my email:
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hi Daniel,
When I try to ping I seeing following vxlan udp unreachable, when I try to
ping from host2-to-host1, basically packets entering br-phy and should be
delivered to br-int(on which vxlan is configured). Any configuration needed
to route packets from br-phy to br-int? What version of OVS is
Hi Mark,
Thanks a lot for the feedback.
Regarding the figures, i attached the PNGs (shows in my sent items), but looks
like they got filtered.
My bad on that, is there a location, where OVS community uploads images for
references.
Please bear with us, hopefully, we will be able to avoid some of
Hi Ankur,
Thanks for the detailed document! I always appreciate it when things are
planned out in great detail so we know exactly what to expect.
A general comment: there are places below where things like "figure 1"
and "figure OVN bridge deployment" are referenced, but we can't see
them. I
Thanks John,
I agree with you that this configuration is between vxlan0 and VF port and we
will see only decap packets from vxlan0.
So, I created another config on bridge br1 instead of br0 to mirror all traffic
between eth0.101 and tep0 port. How will this get mapped into the offloaded
flow.
---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
de
Thanks Ben/Ilya,
Will give that a shot and update, I had to roll back to 2.9. But will
update. Thanks again and appreciate the quick reply, Shahaji
On Wed, Oct 17, 2018 at 11:35 AM Ben Pfaff wrote:
> On Tue, Oct 16, 2018 at 06:46:52PM -0400, Shahaji Bhosle via dev wrote:
> > Just upgraded to 2.1
On Wed, Oct 17, 2018 at 12:25:47PM -0700, Yifeng Sun wrote:
> This patch fixes the bug that all datapath and vport ops are returning
> wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
>
> This commit backports upstream net-next's commit 804fe108fc92e59
> ("openvswitch: Use corre
This patch fixes the bug that all datapath and vport ops are returning
wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
This commit backports upstream net-next's commit 804fe108fc92e59
("openvswitch: Use correct reply values in datapath and vport ops").
Signed-off-by: Yifeng Su
Hello Daniel,
When I tried to configure vxlan routes I had mentioned I was seeing errors,
when I checked log files under /var/log/openvswitch there is no
information...
-rw-r- 1 root adm 0 Oct 17 06:25 ovs-vswitchd.log
-rw-r- 1 root adm 536 Oct 17 12:32 ovsdb-server.log
cat ovs
On Mon, Oct 15, 2018 at 04:12:19PM -0700, Justin Pettit wrote:
>
> > On Oct 10, 2018, at 1:35 PM, Ben Pfaff wrote:
> >
> > Since OVS added LACP support back in 2011, bonds have ignored the updelay
> > and downdelay values for bonds with configured LACP. The reason is not
> > clear, but at least
On Wed, Oct 17, 2018 at 10:01 PM Ben Pfaff wrote:
> On Wed, Oct 17, 2018 at 05:33:05PM +0530, nusid...@redhat.com wrote:
> > From: Numan Siddique
> >
> > We see the below trace when a port is added to a bridge and the
> configured
> > controller is down
> >
> > 0x7fb002f8b207 in raise () fro
All of these seem fine to me.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Tue, Oct 16, 2018 at 07:47:16PM +0300, Ilya Maximets wrote:
> NO_OFFLOAD_API was removed while netdev classes initialization
> refactoring, but netdev-bsd still uses it. Instead of
> redefining it, I just refactored the BSD classes to be same
> as other netdevs.
>
> CC: Ben Pfaff
> Fixes: 89c0
On Wed, Oct 17, 2018 at 06:24:56PM +0200, Lorenzo Bianconi wrote:
> >
> > On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> > > >
> > > > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > > > >
> > > > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff w
On Wed, Oct 17, 2018 at 05:33:05PM +0530, nusid...@redhat.com wrote:
> From: Numan Siddique
>
> We see the below trace when a port is added to a bridge and the configured
> controller is down
>
> 0x7fb002f8b207 in raise () from /lib64/libc.so.6
> 0x7fb002f8c8f8 in abort () from /lib64/li
On 10.10.2018 19:22, Tiago Lam wrote:
> From: Mark Kavanagh
>
> There are numerous factors that must be considered when calculating
> the size of an mbuf:
> - the data portion of the mbuf must be sized in accordance With Rx
> buffer alignment (typically 1024B). So, for example, in order to
>
>
> On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> > >
> > > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > > >
> > > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets wrot
On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> >
> > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > >
> > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets wrote:
> > > > > >
On Wed, Oct 17, 2018 at 7:45 PM Eelco Chaudron wrote:
>
>
> On 17 Oct 2018, at 14:03, nusid...@redhat.com wrote:
>
> > From: Numan Siddique
> >
> > We see the below trace when a port is added to a bridge and the
> > configured
> > controller is down
> >
> > 0x7fb002f8b207 in raise () from /l
On Tue, Oct 16, 2018 at 06:46:52PM -0400, Shahaji Bhosle via dev wrote:
> Just upgraded to 2.10 and running OvS with DPDK , I used to set MTU to 1900
> to accommodate VxLAN headers in 2.9 but not I cannot send packets bigger
> than 1518 bytes. Is this a known issue, I have not got chance to check t
On 17 Oct 2018, at 14:03, nusid...@redhat.com wrote:
From: Numan Siddique
We see the below trace when a port is added to a bridge and the
configured
controller is down
0x7fb002f8b207 in raise () from /lib64/libc.so.6
0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
0x7fb00495
Wow, proper TDD!
Is it possible to get this backported at least down to 2.10 ?
Acked-by: Miguel Angel Ajo
More context here: https://bugzilla.redhat.com/show_bug.cgi?id=1640045
On Wed, Oct 17, 2018 at 2:59 PM Numan Siddique wrote:
>
>
> On Wed, Oct 17, 2018 at 6:27 PM Miguel Angel Ajo Pelay
On Wed, Oct 17, 2018 at 6:27 PM Miguel Angel Ajo Pelayo
wrote:
> Wow, that was quick Numans,
>
> Did you try the negative of the test? (removing your patch on the C side
> and trying the test
> to make sure it fails?)
>
Yes. I actually started with the test to make sure it fails before working
o
Wow, that was quick Numans,
Did you try the negative of the test? (removing your patch on the C side
and trying the test
to make sure it fails?)
On Wed, Oct 17, 2018 at 2:08 PM wrote:
> From: Numan Siddique
>
> We see the below trace when a port is added to a bridge and the configured
> cont
>
> On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > >
> > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets wrote:
> > > > > > Hi,
> > > > > >
> > > > > > it seems that travis-ci is failing due to a tes
I am Peter Wong director of operations, Hong Kong and Shanghai Banking
Corporation Limited Hong Kong. I have a very confidential business
proposition involving transfer of $18.350.000.00 that will be of great
benefit for both of us. Reply for more details as regards this
transaction
Best Regards
P
On Fri, Oct 12, 2018 at 9:52 PM Ben Pfaff wrote:
> On Fri, Aug 24, 2018 at 10:35:16AM -0700, Ben Pfaff wrote:
> > When the status of a port changes, ofproto calls into connmgr to notify
> > controllers. Sometimes, particular changes are only visible to
> controllers
> > running specific versions
From: Numan Siddique
We see the below trace when a port is added to a bridge and the configured
controller is down
0x7fb002f8b207 in raise () from /lib64/libc.so.6
0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
0x7fb004953026 in ofputil_protocol_to_ofp_version () from
/lib64/libop
> When enabled with DPDK OvS deals with two types of packets, the ones
> coming from the mempool and the ones locally created by OvS - which are
> copied to mempool mbufs before output. In the latter, the space is
> allocated from the system, while in the former the mbufs are allocated
> from a mem
Jumbo frames worked fine for me no so long ago on master branch.
Have you checked the log? What does it say?
Best regards, Ilya Maximets.
On 17.10.2018 01:46, Shahaji Bhosle wrote:
> Hi Ilya
> Just upgraded to 2.10 and running OvS with DPDK , I used to set MTU to 1900
> to accommodate VxLAN head
32 matches
Mail list logo