Please re-test with latest rolling-release if the issue persists.

Thanks for the help so far @Apachez !

My apologies @Apachez this was on 1.4-rolling-202212310809.

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

PR for Sagitta:
https://github.com/vyos/vyos-1x/pull/2207

Well in that case it boils down to if the FRR/vrrpd supports namespaces, various tracking (interface etc) aswell as multicast vs unicast which keepalived seems to support them all.

@dmbaturin Can we close it?

@mhamzahkhan Will be fixed in the next rolling release, could you re-check it?

In T2444#158779, @Apachez wrote:

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Things to verify however before a switch is performed (and keepalived is thrown out) is support for vrf/namespaces, various interface and other tracking and multicast vs unicast (it seems that keepalived supports them all - dunno about FRR/vrrpd).

https://docs.frrouting.org/en/latest/vrrp.html

One can enable snmp module through:

I will put this as resolved under protest :-)

To check if it works just use ss -tin, for example:

vyos@r14:~$ ss -tin
State                    Recv-Q                    Send-Q                                        Local Address:Port                                        Peer Address:Port                     Process                                                                                                                                                                                          
ESTAB                    0                         0                                            192.168.122.14:22                                         192.168.122.1:45446                    
	 bbr wscale:7,7 rto:201 rtt:0.103/0.048 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:140 ssthresh:138 bytes_sent:126383 bytes_acked:126383 bytes_received:20969 segs_out:2460 segs_in:2592 data_segs_out:2445 data_segs_in:341 bbr:(bw:503652048bps,mrtt:0.018,pacing_gain:1.25,cwnd_gain:2) send 15745242718bps lastsnd:3003449 lastrcv:3005252 lastack:3003448 pacing_rate 623269416bps delivery_rate 503652168bps delivered:2446 app_limited busy:2029ms rcv_space:14600 rcv_ssthresh:64076 minrtt:0.018 snd_wnd:64128
ESTAB                    0                         36                                           192.168.122.14:22                                         192.168.122.1:51320                    
	 bbr wscale:7,7 rto:201 rtt:0.427/0.555 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:148 ssthresh:136 bytes_sent:1779503 bytes_retrans:68 bytes_acked:1779399 bytes_received:167865 segs_out:12061 segs_in:12088 data_segs_out:11899 data_segs_in:3996 bbr:(bw:530564808bps,mrtt:0.068,pacing_gain:1.25,cwnd_gain:2) send 4015063232bps lastsnd:30 lastrcv:31 lastack:31 pacing_rate 525259160bps delivery_rate 458772272bps delivered:11899 app_limited busy:27667ms unacked:1 retrans:0/1 dsack_dups:1 rcv_rtt:392993 rcv_space:65229 rcv_ssthresh:84348 minrtt:0.024 snd_wnd:1344128
vyos@r14:~$

It should be disabled by default for all daemons. I guess it will be implemented in T4020
For your issue solution is set system frr snmp ldpd.

I dont know if something would break to run migrate from within another VyOS version but you could test something like this, preferly from last version that worked without errors ("5: 1.4-rolling-202306030305"?):

What VyOS version did you have there?

Note that regarding qdisc it seems that qdisc=fq_codel is nowadays supported according to:

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

I do not have a 29-30 migrate script

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Using the config you provided in Slack I managed to trace the error (or I think so):

I dont agree this is resolved.

Memtest86+ can easily be included in the iso by altering the lb_config_tmpl variable in https://github.com/vyos/vyos-build/blob/current/scripts/build-vyos-image

I think VyOS might need to accept as default traffic to/from localhost towards itself for both IPv4 and IPv6.

Please help to assign a dev to work with this problem, thanks a lot!

@n.fort
Nope, no VRF set up.

For now, commands are generated by XML to node.def
I don't see an easy way to add the alias feature. Some scripts expect the exact sequence of an argument and it could be broken with this feature.

It only saves the SSH keys https://github.com/vyos/vyatta-cfg-system/blob/c2d9dea2524297404fb27028c1f41124dc47c24f/scripts/install/install-image-existing#L223-L231

Are you using vrf? Maybe it's an issue and router can't resolve dns for ntp servers

@Viacheslav
I will check it today or tomorrow. But I believe I know the culprit, the new firewall rules didn't allow my VyOS instance to contact the CoreDNS (set to host mode) container that is hosted as a container in VyOS. I was unable to ping 127.0.0.1 as well as all of my VyOS's IP addresses.

Don't have this issue
@dcplaya Could you re-check in the newest rolling image?

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

Close it if this issue is solved.

Should be executed there, for future debugs https://github.com/vyos/vyatta-wanloadbalance/blob/c7708bc6ef689f5744272a15a601a56a03890afa/src/lbdecision.cc#L429

Just waiting for upstream updates

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

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

There definitely should be a second, i.e., max value 3600 seconds.

PR for 1.3.4 https://github.com/vyos/vyos-build/pull/393

I observed the trace from 1.4-rolling-202306180309 as I was trying to slowly increment up. This was the path I took to get there

grub was very buggy for me in a USB console. I did finally manage to get vyos-config-debug to boot.

Might be related: