The pull request is created to fix this issue:

@Viacheslav , I tested in the 1.4 version, it seems that the neighborship is stuck in ExStart state with basic config. This behavior is not seen in 1.2.5 and 1.3
And also no frr.log is created.

@Viacheslav , working on it and update you soon.

@SrividyaA Can you recheck it in 1.4?

PR https://github.com/vyos/vyatta-cfg-quagga/pull/68

show tech-support

PR https://github.com/vyos/vyatta-cfg-quagga/pull/67

Created the feature request on forum.

'nopmtudisc' option still not present

Still present in the 1.2.6-S1 release. Makes vyos unusable in environment with DHCP WAN IPs and using the DNS forwarder for specific domains. Those domain forwarders are lost every time the ISP renews the public IP.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/63

Fixed

vyos@r5-roll:~$ show ntp 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*194.0.5.123     85.199.214.102   2 u    4   64    3   39.557   -2.748   2.504
+167.86.115.96   235.106.237.243  3 u   39   64    3   45.816    5.476   0.830
+195.128.100.150 131.188.3.222    2 u    4   64    3   43.219   -1.425   1.734
vyos@r5-roll:~$ 
vyos@r5-roll:~$ show version

CLI command will be: set interfaces tunnel tun10 parameters ip no-pmtu-discovery, Also PMTU can not be changed in IPv6 sourced tunnels, a validation check has been added.

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

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

NTP doesn't work when you configure listen-address 0.0.0.0.

@runar we also added no- in the 1.3 series, so I'd prefer: set interfaces tunnel tun0 parameters ip disable-pmtu-discovery or set interfaces tunnel tun0 parameters ip no-pmtu-discovery

Very well.

@tuxis-ie we are running FRR 7.3 and can not easily upgrade to 7.4 due do changes in the FRR behavior and known bugs which we already faced in a rolling release which was running FRR 7.5.

I see it is in https://github.com/FRRouting/frr/releases/tag/frr-7.4 ..

Hmm. It has been merged here: https://github.com/FRRouting/frr/pull/5855

@tuxis-ie
FRR doesn't allow you to set that value. It's not a bug of VyOS.
In commands description allowed values (0-4294967295)

r12-1.2.6(config)# route-map FOO permit 100
r12-1.2.6(config-route-map)# set local-preference 
  (0-4294967295)  Preference value
r12-1.2.6(config-route-map)# set local-preference 
  (0-4294967295)  Preference value
r12-1.2.6(config-route-map)# set local-preference -10
% Unknown command: set local-preference -10

As far as i know all our other "disable" commands starts wirh "disable-"

I'd personally recommend "pmtu-discovery-disable", but either would be fine.

Proposed CLI

set interfaces tunnel tun0 parameters ip disable-pmtu-discovery

https://github.com/vyos/vyatta-cfg-quagga/pull/60

PR https://github.com/vyos/vyatta-wanloadbalance/pull/8

I successfully update the image from 1.2.6-s1 to VyOS 1.3-rolling-202012231522

Pull request submitted to change the permissions:

The issue here is that "set protocols ospf default-information originate" propagates a default route even if there is an inactive route for 0.0.0.0/0. It should only propagate if "always" is used. So, maybe the inactive route is not in the routing table (in the routing sense) but it seems to be taken into consideration for redistribution.

Imagine if you use for example BGP and don't have a default route or set it to blackhole.
Then you originate the default route for a neighbor.
Why it should not announce the default route to the neighbor?

This is expected behavior, so routes not installed in the routing table.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.

Issue is fixed in the latest rolling release. The IPv4 remote-host hostname in client mode works without adding the option '--proto udp4'.
Tested in VyOS 1.3-rolling-202011060217