On 04/17/2018 06:19 PM, Ben Pfaff wrote:
On Sat, Apr 14, 2018 at 12:19:02PM -0300, Raymond Burkholder wrote:
On 04/13/2018 02:52 PM, Ben Pfaff wrote:
I'm quite sympathetic to that viewpoint--I think that OVS currently has
far too much distro-specific stuff in it. In the long run I'
times. Debian Stretch has 2.6, and nothing in Stretch-Backports.
Buster does have 2.8 at the moment, but Buster can be very unstable for
consistently building environments on demand.
--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net
--
This message has been scanned
>ip_dst);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
Ra
>
> > > Add a command to dump vhost-user's information.
> > >
> >
> > Thanks for the patch Flavio, I'll take a look in greater depth and test
later
> this week. On a first pass through though, I'd like to see the command
being
> added to the OVS DPDK vHost user how to also in documentation, just t
>
> New appctl 'netdev-dpdk/get-mempool-info' implemented to get result of
> 'rte_mempool_list_dump()' function if no arguments passed and
> 'rte_mempool_dump()' if DPDK netdev passed as argument.
>
> Could be used for debugging mbuf leaks and other mempool related issues.
> Most useful in pair w
> That's a good point, I don't have experience with that (what's the best
DSCP
> class), but we should make sure BFD packet, as control/monitoring traffic,
is
> prioritised over other types of traffic.
As indicated by Pradeep, CS6 is a good value, and I've seen that in various
locations.
>
> On
> The implementations I've worked on have used tos=0xC0 (DSCP CS6). Given
> that DSCP CS6 is recommended for network control traffic, and is used by
> OSPF, BGP etc., I think it is likely that many implementations do that for
BFD
> too. Since BFD flaps have significant impact, marking BFD packets w
> The thinking behind this was that IPsec had to work at the IP level so
> combining it in transport mode with a tunnel guarantees that.
In addition, I don’t know if it is helpful, but if ipsec is the way to go, they
guys over at Free Range Routing, a Quagga fork, are working some aspect of
ips
ave been
>> included in the patch series.
>>>>
>>>> (5) Stats: I haven’t looked into how this will affect stats within
>>>> OVS yet but
>>> [Sugesh] There are some special characters.
>>>> this is another item I will look at for th
ges are on only on native tunnel, this shouldn’t break non DPDK
build.
[snip]
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
Raymond Burkholder
https://blog.raymond.burkholder.net/
--
This message has been scanned
based wireless information:
http://blog.raymond.burkholder.net/index.php?/categories/75-Wireless
--
Raymond Burkholder
https://blog.raymond.burkholder.net/
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be
> On 24 May 2017, at 14:27, Greg Rose wrote:
>
> On Wed, 2017-05-24 at 19:56 +, root wrote:
>> From: Raymond Burkholder
>>
>> Current versions of systemd in Debian Stretch use
>> SYSTEMCTL_SKIP_REDIRECT instead of _SYSTEMCTL_SKIP_REDIRECT.
>> Pr
>
> Can you do a 'sh -x /etc/init.d/openvswitch-switch status' to see whether it
> looks at _SYSTEMCTL_SKIP_REDIRECT in any of the system libraries.
>
> For e.g, on a ubuntu15.04, when I run the above command, I get a match for
> _SYSTEMCTL_SKIP_REDIRECT variable in /lib/lsb/init-functions.d/4
> On 24 May 2017, at 09:31, Guru Shetty wrote:
>
> Does your '/etc/init.d/openvswitch-switch have the following line:
> https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.init#L30
>
> That line should prevent any redirects to systemd.
>
yes it does have:
_SYSTEMCTL_SKI
ok, sorry, this message can be ignored, I see github changes on Mar 17 to
reflect the ‘ip link’ change, but I think that the
'/etc/init.d/openvswitch-switch status’ may still be a problem.
> On 24 May 2017, at 08:42, Raymond Burkholder wrote:
>
> This probably isn’t an optima
sion
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
Raymond Burkholder
https://blog.raymond.burkholder.net
--
This message has been scanned for viruses and
dangerous content by MailScanne
Using a Debian Stretch daily snapshot from a few days ago, systemd looks to be
interfering with /etc/init.d/openvswitch.
These are the packages installed:
# dpkg -l | grep openvsw
ii openvswitch-common2.6.2~pre+git20161223-3 amd64Open
vSwitch common components
ii openv
openvswitch.org
> Subject: [ovs-dev] [PATCH] compat: Fix build error in kernel 4.10.0
>
> In kernel 4.10.0, the function "nf_defrag_ipv6_enable" need parameters
> "struct net *", so we need call it for each namespace init to load
netfilter
> fragment kmod.
>
&g
> boun...@openvswitch.org] On Behalf Of Greg Rose
> Sent: Tuesday, April 25, 2017 11:57
> On Tue, 2017-04-25 at 11:13 -0300, Raymond Burkholder wrote:
> > I am attempting to build openvswitch 2.7.90 on linux 4.10.12 on Debian
> > using:
>
> Which version or distrib
I am attempting to build openvswitch 2.7.90 on linux 4.10.12 on Debian
using:
92 wget https://github.com/openvswitch/ovs/archive/master.zip
93 unzip master.zip
94 cd ovs-master/
95 dpkg-checkbuilddeps
96 DEB_BUILD_OPTIONS='parallel=2 nocheck' fakeroot debian/rules binary
99
> > I understand that we can extend the current DNAT feature to include
> DNAT:port. But is there is a use case where you want to use this? Any
> extensions of the NAT table can be better designed if we understand the
> end use-case for it. If not, I will just take a look at the first version
of th
21 matches
Mail list logo