@c-po Request merge https://github.com/vyos/vyos-1x/pull/556

In T2943#76739, @runar wrote:

as a workaround you could add this to a post-boot script on the device.

This is disallowed by design by the VyOS team. the reason for this is partly because of the configuration order done by VyOS and how the dns lookup is handled by Wireguard.
Yes, the wg configuration utillity DOES handle DNS lookups, but NO, Wireguard does not handle them. This means that the DNS lookups is done once (and only once) when the wg command is executed on creation of the tunnel and then the resulting ip result is stored in wireguard. this results in the dns lookup will fail after a reboot of the VyOS device because it cant resolve the dns of the endpoint at that point (this is done before routing is enabled on the device)

To reproduce

PR for Rolling https://github.com/vyos/vyos-1x/pull/559

PR for CRUX https://github.com/vyos/vyatta-cfg-system/pull/130

Backported to crux

In T2744#76514, @Viacheslav wrote:

Can we replace igmp-proxy with pimd?

NDP Proxy has been implemented in T2898. For nat66 to work normally, proxy-ndp must be operated in static mode.

Already basically ready to merge

To reproduce this bug

I accidentally found sonarcloud, vyos now uses this system for quality control?

PR for crux https://github.com/vyos/vyos-1x/pull/558

PR https://github.com/vyos/vyos-build/pull/127
Also will be good cherrypick this to crux.

@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