https://github.com/vyos/vyos-1x/commit/da8b089e48fef03518e2cd119e4bf84cf5630728

I also can confirm this works in 1.2.4

Sounds like a duplicate of T1632

Sounds like a duplicate of T1632

Welcome, thanks for testing!

Maybe for future CLI designs, the following would be cleaner: set service snmp extension name 'foo bar' script /usr/bin/echo

Restarting now no longer shows any error/warning

This is actually an "upstream" bug, see https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1384122 but it can be fixed via our own scripts.

Working fine on 1.3-rolling-202001260217.

Sure, I can probably do that in a day or two, will report back! Didn't even think to try that on my test device, my mind was just stuck at not wanting to upgrade my production devices at the moment.

Ah, your version is a bit old that could have been prior to the migration of the ip enable-arp-ignore script to XML/Python. Could you please retest with a newer rolling release?

https://github.com/vyos/vyatta-cfg-quagga/commit/5a1060a21dbc478c1aaaa4711e66bc882eeae114

Exactly, there is a race condition which I try to reproduce, but can not as ow now with VMware.

I just tried it on a different device with a more clean config, and it's reproducable with this config:

PR https://github.com/vyos/vyos-1x/pull/209
also added missing completion help values.

Confirming that I also report this on 1.3-rolling-202001240217. Just upgraded this morning and I see the same unknown layer 3 protocol error as reported.

This issue is still present in 1.3-rolling-202001240217

Unfortunately I can not reproduce this.

One seems t be the mastering parent process, try ps faux

SNMP with VRRP work

# snmpwalk -v2c -c public 10.0.0.1  VRRP-MIB:vrrpOperations
VRRP-MIB::vrrpNodeVersion.0 = INTEGER: 2
VRRP-MIB::vrrpNotificationCntl.0 = INTEGER: disabled(2)
VRRP-MIB::vrrpOperVrId.3.10 = INTEGER: 10
VRRP-MIB::vrrpOperVirtualMacAddr.3.10 = STRING: 52:54:0:1d:4:4e
VRRP-MIB::vrrpOperState.3.10 = INTEGER: backup(2)
VRRP-MIB::vrrpOperAdminState.3.10 = INTEGER: up(1)
VRRP-MIB::vrrpOperPriority.3.10 = INTEGER: 50
VRRP-MIB::vrrpOperIpAddrCount.3.10 = INTEGER: 1
VRRP-MIB::vrrpOperMasterIpAddr.3.10 = IpAddress: 10.0.0.2
VRRP-MIB::vrrpOperPrimaryIpAddr.3.10 = IpAddress: 10.0.0.1
VRRP-MIB::vrrpOperAuthType.3.10 = INTEGER: noAuthentication(1)
VRRP-MIB::vrrpOperAdvertisementInterval.3.10 = INTEGER: 1 seconds
VRRP-MIB::vrrpOperPreemptMode.3.10 = INTEGER: true(1)
VRRP-MIB::vrrpOperVirtualRouterUpTime.3.10 = Timeticks: (2) 0:00:00.02
VRRP-MIB::vrrpOperProtocol.3.10 = INTEGER: ip(1)
VRRP-MIB::vrrpOperRowStatus.3.10 = INTEGER: active(1)
VRRP-MIB::vrrpAssoIpAddr.3.10.10.0.0.254 = IpAddress: 10.0.0.254
VRRP-MIB::vrrpAssoIpAddrRowStatus.3.10.10.0.0.254 = INTEGER: active(1)

This feature request can be closed.
T1981 - Allow 'set src' to reference either IPv4 or IPv6
T1983 - Expose route-map when BGP routes are programmed in to FIB

@max1e6 Did you have a chance to test? Otherwise I assume the issue isn't present anymore.

Let me know if you come across any issues.

https://github.com/vyos/vyos-1x/commit/b11a301b130a01cba035a0cd5aa5b17c99eb1d44

By default we don't need delay, I think it must be configurable feature.

set service pppoe-server pado-delay delay 100 sessions 100
set service pppoe-server pado-delay delay 200 sessions 300
set service pppoe-server pado-delay delay 300 sessions 1000

and configuration for this

@Dmitry What default delays do you suggest?

@syncer After all considerations, because of the authentication modules squid brings in, I would rather stay with squid for now. Let me know what you think.

If it possible, please explain me in private message how I can reach this behaviour. In my LAB this does not reproduced.

This patch tested successful on VyOS 1.2.4 VM with 25 network interfaces.
Also works as expected on VyOS 1.3-rolling-202001230217
Thx @runar !

@TriJetScud Would please make it works on vyos latest version ?

This also could be the same issue as described in T577

This issue is possibly fixed in current by ticket T1970, could you retry with the newest current rolling release?

When using logrotate we can take full owership about the resources that will be used for number of files and its size - so i think this will be the best approach.

Please test and feedback in latest rolling.

Howadays there is the generic vyos.ifconfig Python class which deals with IPV6 dhcp client stuff.

I haven't tested the vyos-1x changes that @gadams made with 1.3 rolling (current). But it seems before we can do that we'll need to create the interface-definitions so they show up on the CLI and can be configured. Since I believe that's what changed in between minor versions.

I've attached a simple patch to expose FRRouting's built-in capability of being able to apply a route-map to routes that are submitted to the FIB from BGP to VyOS.

Why we not fix just logrotate config for it?

I've attached a simple patch to allow 'set src' to be either IPv4 or IPv6 addresses.