Also reported in T1830

In FRR 7.0.1 (VyOS 1.2.3) was some bug, due to which static routes were not updated (maybe, not in all cases or environments) after the next-hop state change. In VyOS 1.2.4 we use stable FRR 7.2, which processes this situation without problems. An example (key point from FRR debug log):
FRR 7.0.1:

Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Adding route rn 0x5612ea69d1f0, re 0x5612ea69d370 (type 2)
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Redist update re 0x5612ea69d370 (type 2), old (nil) (type -1)
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Adding route rn 0x5612ea69d490, re 0x5612ea69e110 (type 2)
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.0/30: Redist update re 0x5612ea69e110 (type 2), old (nil) (type -1)
Jan 13 15:29:51 vyos zebra[1041]: NHT processing check for zvrf default
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: Evaluate RNH, type 0
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30
Jan 13 15:29:51 vyos zebra[1041]: 0:10.230.230.1/32: Notifying client static about NH
Jan 13 15:29:51 vyos zebra[1041]: 0:192.168.20.1/32: Evaluate RNH, type 0

FRR 7.2:

Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Adding route rn 0x5574620a18b0, re 0x5574620a1930 (connected)
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Adding route rn 0x5574620a29b0, re 0x5574620a1850 (connected)
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30 update_from_ctx(): no fib nhg
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30 update_from_ctx(): rib nhg matched, changed 'true'
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.0/30: Redist update re 0x5574620a1930 (connected), old 0x0 (None)
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: Evaluate RNH, type Nexthop
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: NH resolved over route 10.230.230.0/30
Jan 13 15:33:23 vyos zebra[1042]: 0:10.230.230.1/32: Notifying client static about NH
Jan 13 15:33:23 vyos zebra[1042]: rib_add_multipath: 0:10.0.0.0/8: Inserting route rn 0x5574620a1b10, re 0x5574620a1a30 (static) existing (nil)
Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8: Adding route rn 0x5574620a1b10, re 0x5574620a1a30 (static)
Jan 13 15:33:23 vyos zebra[1042]: netlink_route_multipath(): RTM_NEWROUTE 10.0.0.0/8 vrf 0(254)
Jan 13 15:33:23 vyos zebra[1042]: netlink_route_multipath() (single-path): nexthop via 10.230.230.1  if 3(0)
Jan 13 15:33:23 vyos zebra[1042]: netlink_talk: netlink-dp (NS 0) type RTM_NEWROUTE(24), len=60 seq=10 flags 0x501
Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8 update_from_ctx(): no fib nhg
Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8 update_from_ctx(): rib nhg matched, changed 'true'
Jan 13 15:33:23 vyos zebra[1042]: 0:10.0.0.0/8: Redist update re 0x5574620a1a30 (static), old 0x0 (None)

So, configured static routes updating properly.

Dou can try to play around withe the node.def and interfaces-vxlan.py file and lower the limits to see if it works at all.

I was getting a lot missing dependencies even all the vyatta/vyos-* packages were being complained that they were required but weren't being installed. I'd already deleted and re-cloned the build repo and cleaned out my local docker several times so i'm not completely sure what fixed building 1.2 ISOs again. Frustrating but at least it's working for the time being.

I think we can close this task.
Nothing like that has happened in the last few months.

@elbuit

vyos@mpls# sudo nft list table nat
table ip nat {
	chain PREROUTING {
		type nat hook prerouting priority -100; policy accept;
		counter packets 0 bytes 0 jump VYATTA_PRE_DNAT_HOOK
	}

Thanks @Viacheslav, I've build a custom vyos 1.2.4 with nftables package because I want to add custom rules in nftables mode.

@elbuit
Rolling is support nft now.

vyos@mpls:~$ sudo nft -v
nftables v0.9.0 (Fearless Fosdick)

PR https://github.com/vyos/vyos-1x/pull/203
Adding commands for show mpls

@bmhughes For me an issue was that cpio is missing from the docker image

edit:
I can build working images now, I have no idea what's changed over what i've been trying for the last few days.

@bmhughes I tested this on the downloaded lts 1.2.4 iso and it seems to work fine...

All works, but seems we need works with timezone for correct converting USEC to "date time" format

Service custom don't support 2 ddns entries now.
It overwrite login/pass to (login02) for each custom service

Please use service custom

Very Nice!

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

Has been fixed already.

Created new Azure image

I'm also affected by this, but even with a relatively "small" configuration (2662 lines, at present, where more than half are firewall rules, 5 interfaces).

First tests for MPLS.
Latest rolling releases is supported it.

In this case we can use /run/systemd/shutdown/scheduled file for detecting powertrl scheduler
PR for this task https://github.com/vyos/vyos-1x/pull/201

https://github.com/vyos/vyos-1x/pull/200
adding CLI commands

Hang on, I see the error in syslog (only syslog), so at least I can reproduce it now.

@Merijn I tested with the latest rolling and can't reproduce the issue. From your error message yesterday it looks like your snmpd.conf has an issue. Can you copy that content as well?

@jjakob https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202001081700-amd64.iso and later should address that issue.

@hagbard

set service snmp community dummycomm authorization 'ro'
set service snmp community dummycomm client '8.8.8.8'
set service snmp community dummycomm client '8.8.4.4'
set service snmp contact 'noreply@nowhere.com'
set service snmp location 'Datacenter, City, Country'

Update
The problem was resolved by manually removing the interfaces from the file /config/config.boot (section flow-accounting)

Successfully tested on latest rolling 1.3-rolling-202001080217

Actually, this seems to be a build issue as a fresh build with the up to date vyos-build repo causes a fresh build of 1.2.3 to suffer the same problem.

Confirmed fix with that commit.

https://github.com/vyos/vyos-1x/commit/3863e5dc24a622090f52c13f8aa04e5c9f00341a should fix it.
(http://dev.packages.vyos.net/repositories/current/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb if you want to manually install and test or wait for tomorrows iso).

systemctl renamed it to syslog, so it won't be restarted correctly and the conf script won't generate the files correctly. It is correctly named within init.d.

It definitely remains in my config:

looks like service syslog did disappear from the default config.

@Merijn Can you please share the snmp part from your config?

I only have a workaround right now, it appears that grub.cfg can't be found. To boot at least the installed system do the following within the grub shell:

configfile /EFI/VyOS/grub.cfg

Move to 'Needs testing'; repo linked below. Add example of third-party package, and test, before PR.

Seems to be a simple fix so i've submitted a PR: https://github.com/vyos/vyos-1x/pull/199

@hagbard i tried testing by installing the package.
The service is running but not working correctly.
The following is shown:
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 10: Warning: Unknown token: smuxpeer.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 11: Warning: Unknown token: smuxpeer.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 12: Warning: Unknown token: smuxsocket.
Jan 07 10:25:54 server snmpd[9979]: notificationEvent OID: linkUp
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 21: Error: unknown notification OID
Jan 07 10:25:54 server snmpd[9979]: notificationEvent OID: linkDown
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 22: Error: unknown notification OID
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 23: Warning: Unknown token: monitor.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 24: Warning: Unknown token: monitor.
Jan 07 10:25:54 server snmpd[9979]: net-snmp: 2 error(s) in config file(s)

@bbabich If router A and router B connected via iBGP you need use nexthop-self

Hi @bbabich
How we can reproduce this bug?
I tested with 55 bgp-sessions. Each with its own unique filter. All filters applied as needed.
Without filters I announced 111 routes.
With filters per session I export 1 route to each peer.

Sure thing, let me know the result.

@Merijn https://github.com/vyos/vyos-1x/commit/78df0c46865b3af89d6bc327b4c1d08cc4450aff or tomorrows rolling, as you seem to compile it yourself is should now work out of the box when you install the new vyos-1x package.
(http://dev.packages.vyos.net/repositories/current/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb)

Debian default snmp user is called Debian-snmp while the script tries to get the uid of the user snmp. Looks like that is the entire issue.