Moving to 1.3.x, let's combine this with dropping pre-6.5 compatibility and removal of old migration scripts.

Moving to 1.3.x, since there was no deprecation warning. Let's do it properly.

fixed in XML/python rewrite

In T725#18039, @c-po wrote:

@Lochnair see branches at:

• https://github.com/vyos/vyatta-iproute/tree/iproute2-vyos-4.18.y
• https://github.com/vyos/vyos-kernel/tree/linux-vyos-4.18.y

Nice work!

https://lwn.net/Articles/762566/ states:

The CAKE queuing discipline, which works to overcome bufferbloat and other problems associated with home network links, has been merged.

I'm well aware that it's been merged, but we still won't see it in a release before 4.19 is released mid-October.

ISO (with Kernel 4.18 and iproute2 4.18) can be found here at 11:30 p.m. CEST (UTC +2):

• http://www.mybll.net/vyos-1.2.0-rolling+201808202221-amd64.iso

cpo@LR1:~$ uname -a
Linux LR1.mucI.mybll.net 4.18.0-amd64-vyos #3 SMP Mon Aug 20 21:32:31 CEST 2018 x86_64 GNU/Linux

cpo@LR1:~$ sudo modprobe wireguard
cpo@LR1:~$ dmesg | tail -n 3
[  180.114930] wireguard: loading out-of-tree module taints kernel.
[  180.115868] wireguard: WireGuard 0.0.20180708-1 loaded. See www.wireguard.com for information.
[  180.115869] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld <[email protected]>. All Rights Reserved.

cpo@LR1:~$ ip -V
ip utility, iproute2-ss171113

Not that I've tested it "properly", but your ISO seemed to work fine in a VM I fired it up in.

@Lochnair see branches at:

• https://github.com/vyos/vyatta-iproute/tree/iproute2-vyos-4.18.y
• https://github.com/vyos/vyos-kernel/tree/linux-vyos-4.18.y

I've also started thinking about the template:

traffic-policy {
    cake cakepolicy {
        bandwidth 10mbit
        direction egress
        flow-isolation dual-srchost
        memlimit 4096000
        nat-lookup enable
        overhead 32 atm
        priority-queue diffserv4
        rtt 100ms
        split-gso enable
        wash disable
    }
}

Might as well if you're up for it :)

Upgrading to 4.18 should not take more then two hours incl. Iproute2 for me. Should we give it a try? Then I prepare an ISO

Hrrmf, 'twas more painful to get the iproute2 patches right than I'd hoped. Not sure how much effort I should spend getting the patches to apply, or if we should just bump to 4.18.
Apart from the kernel headers in the iproute2 tree, everything works as-is that way.

Thx for the info. Yeah it's a per person choice if in-tree is preferred over out-of-tree.

CAKE is upstream, but it didn't make it into 4.18, so it's currently only in master. To be fair it's easy enough to backport for 4.14, most of it is small changes.
Also I thought you'd prefer to stay on a LTS kernel, thus the backporting attempt.

Is this stuff upstream? If so, we could also upgrade to 4.18, the save the backporting trouble?

I've attempted to backport the CAKE patches accepted into net-next for the VyOS kernel here: https://github.com/Lochnair/vyos-kernel/commits/linux-vyos-4.14.y
I've gotten it to the point that it compiles, but I haven't tested to see if I accidentally broke anything. Partly because I haven't had the chance to look at backporting the tc stuff yet.

Removing LKM support requires reweiting some scripts which do a modprobe upon configuring stuff, but I line the idea in general.

So now as radius is ready, can we just repeat same for tacacs on basic level?
for now only same as for radius

Relevant
https://community.ubnt.com/t5/EdgeRouter/Qualcomm-Fast-Path-SFE-for-the-EdgeRouters/td-p/2041285

I've update installation manual of Zabbix agent for VyOS 1.2
It is easier to maintain now because of using of standard Jessie repository.
Only VyOS scripts should be maintained.

nuviso@ubuntu:~/vyos/build-iso/pkgs/vyatta-wirelessmodem$ cat 0001-T701-LTE-interface-dosen-t-come-up.patch
From 00a04474535ec0eb2b17fe1d4368abff7f3aae46 Mon Sep 17 00:00:00 2001
From: Subramonia Pillai <[email protected]>
Date: Wed, 20 Jun 2018 10:57:53 +0530
Subject: [PATCH] T701: LTE interface dosen't come up

I could see that T656 was already created, as a result of https://forum.vyos.io/t/inconsistency-in-wirelessmodem-wlm-interface-behavior-could-be-bug/1492.

Besides the typo,

we may want log this to tacacs

Interesting. Perhaps the config format has changed in newer versions? What do the docs say?

I'm not sure if HTML encoding is really the best thing to do, but I agree the problem exists.

This is a bit of ubunt's bug #1 by now. ;)

@c-po it will take time anyway, we will see on the go

This Tasks seems to be resolved since kernel 4.14, as the xen netfront bug in kernel is fixed in this version (https://patchwork.kernel.org/patch/9338979/).
I tested with latest nightly on AWS. No packetloss anymore with AES!

@higebu thanks for sharing the link. Looks like they also have some CLI examples. Does this apply to FRR, too? I remember the idea was to move to FRR for routing.

User space implementation in Zebra 2.0: https://github.com/coreswitch/zebra/blob/master/docs/srv6.md

Yes, it's a first step. I think the next step will be wrapper set/show commands for iproute2.

I found some interesting docs:

• https://inl.info.ucl.ac.be/system/files/ANRW-SR.pdf
• https://inl.info.ucl.ac.be/system/files/paper_10.pdf
• https://indico.uknof.org.uk/event/40/contribution/1/material/slides/0.pptx

I think it's first step.
Also it supported in iproute2 that we just updated

What is the benefit of simply enabling it in the Kernel configuration? I guess there is userspace support required, too? Or does it work out of the box?

Running Docker on current vyos. https://gist.github.com/higebu/f35fdd27d085b618a872a8b46c625e2e

@higebu not much there
not really easy to use vyos in containers
however, we can deliver via containers - apps that can be integrated with cli

• gui
• dns/dhcp (for IPAM)
• proxy servers
• monitoring proxies and agent relays

@syncer Could you share the details of the discussion?

In T535#12315, @Pretwolk wrote:

Hi, it has been a while since I did stuff with OpenVPN and bridging interfaces and I have no extended experience with openvpn in VyOS. But due to the way openvpn treats L3 traffic in a TUN interface, it isn't possible to bridge TUN interfaces. If you want to use the operating systems routing capabilities for openvpn traffic you need to use TAP interfaces as these interfaces are bridgable. Not sure how TAP interfaces work in VyOS though.

Hi, it has been a while since I did stuff with OpenVPN and bridging interfaces and I have no extended experience with openvpn in VyOS. But due to the way openvpn treats L3 traffic in a TUN interface, it isn't possible to bridge TUN interfaces. If you want to use the operating systems routing capabilities for openvpn traffic you need to use TAP interfaces as these interfaces are bridgable. Not sure how TAP interfaces work in VyOS though.