@Viacheslav et. al. note that the succinct Mem-Info message shown above was added after v4.19 (commit ef8444ea), so was only seen during the brief window when we moved to 5.8 before reverting the kernel version, due to QAT issues and a bug affecting parted.

Works properly, tested on 1.3-rolling-202009290117.
One remark, jitter will be applied for all accounting packet except the first packet. The first packet is a flag that the session is started.

Can we replace igmp-proxy with pimd?

Works properly on VyOS 1.3-rolling-202009290117.
When command set service pppoe-server authentication radius preallocate-vif committed, pppoe-server send the next attributes in Access-Request packet on a client authorization:

NAS-Port = 0
NAS-Port-Id = "ppp0"
NAS-Port-Type = Virtual

killing FRR
sudo service stop frr
restart igmp-proxy
restart igmp-proxy

Successfully tested on 1.3-rolling-202009290117

set service pppoe-server authentication radius called-sid-format 'ifname:mac'

Radius recived Called-Station-Id = "eth1:50:00:00:05:00:01"

set service pppoe-server authentication radius called-sid-format 'ifname'

Radius recived Called-Station-Id = "eth1"
By default radius recive Called-Station-Id = "50:00:00:05:00:01"

PR https://github.com/vyos/vyos-1x/pull/557

https://github.com/vyos/vyos-1x/pull/556

Hello, I has one question. If we config vlan_mon=eth1, 100-200, it will auto create interfaces. How to config per-interface? or no need to config?

The way I was thinking is on this Juniper page here.

So far I have seen that BFD for static routes in FRR is currently under development:
https://github.com/FRRouting/frr/issues/3369

PR https://github.com/vyos/vyos-1x/pull/555

Yeah, I'm going to second the motion on this one. I've been down the road of SNMP before, and just navigating the available metrics and trying to figure out what they are is less than straightforward. I mean, I've been at this sysadmin thing for a bit over 10 years now and I couldn't manage something useable out of it. It might be because I'm not a great sysadmin, but a lot of people are not great sysadmins. 😛 Having this feature would be great for accessibility and discoverability.

This issue also exists in:

Version:          VyOS 1.3-rolling-202009271030
Release Train:    equuleus

Write redundant and intrusive code for all interface types, which may introduce unknown errors (I can’t guarantee 100% accuracy without testing)

@c-po I am thinking about a problem. Placing proxy-ndp under the child node of interface may generate redundant implementation code and is intrusive. In fact, for proxy-ndp, only one configuration file is needed. Is this Reasonable? I don't even know how to fully test whether the intrusive code affects the basic functions of the router.

It looks like this problem is around here
https://github.com/vyos/vyatta-cfg/blob/current/etc/bash_completion.d/vyatta-cfg#L280-L290

backported to crux

Testing on crux

PR https://github.com/vyos/vyos-1x/pull/554

That’s how it is now and it doesn’t work.

PR https://github.com/vyos/vyos-1x/pull/553

PR https://github.com/vyos/vyatta-cfg-system/pull/129

Implemented in https://github.com/vyos/vyos-1x/commit/5db3d63160670c796ed74a170862c367048d89bb

Cant we run dhcpd as dhcp user which is also a member of hostsd group?

@kroy could you be so kind and write a smoketest for it, too?

This is a problem again.

PR should correct this

Yes that's correct. And there is already some sort of check implemented for the node traffic-policy, so it does not fail when the pppoe interface does not exist yet. It just shows a warning: https://github.com/vyos/vyatta-cfg-qos/blob/bbf2b2f06b7a0f883f7134df5e2b3e089015738e/scripts/vyatta-qos.pl#L198

I think I know what's happening here.

I would also like to add that wouldn't it make more sense to set the protocol mode under host aswell rather behind "facility".