We can do some workaround for that level,

It seems that "call" doesn't react to env.

'VYATTA_EDIT_LEVEL': '/system/login'

https://github.com/vyos/vyos-1x/blob/810f4700acc9816178dc9a7f5f555bbde71a141d/src/conf_mode/system-login.py#L161

vyos@vyos:~$ show version
Version: VyOS 1.3-rolling-202005100117
Release Train: equuleus

PR https://github.com/vyos/vyatta-cfg/pull/34
PR https://github.com/vyos/vyos-1x/pull/798

This can be reproduced with the following config on 1.4

This looks very promising to me for VyOS 1.4-rolling-202104020417, can we please backport this @jestabro ?

show ipv6 route lists you the forwarding path - FIB
show ipv6 bgp or show ipv6 route bgp will show you the rib

I think the presence of the kernel default route may be the problem. It comes from RA through autoconf option on the interface. I will do some more testing.

Could you please try backporting this to 1.3 equuleus branch?

That one just bit me - and actually this is caused by loading the tunnel-broker config from https://github.com/vyos/vyos-1x/blob/b666f8ba97dc792aac90fad4c4c99e47caca7baf/smoketest/configs/tunnel-broker

https://github.com/vyos/vyatta-cfg-system/pull/144

There are two issues in this task (1) reordering of interfaces (2) redundant hw-id entries due to vyatta_net_name not parsing quoted values. A quick fix for (2) will be a PR for vyatta-cfg-system; the general issues the bug raises, regarding quoted values in configtree, will be addressed in the subtasks.

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

Chown for saved configuration file should be frr:frr

So my feeling tells me that the offender is here.

Hmm, where should the documentation for "gretap" be now? I checked the following and it's still missing:

Parent task: https://phabricator.vyos.net/T3356

Does anyone follow up on this?

Expect

vyos@r5-roll# set protocols ospf redistribute isis 
Possible completions:
   metric       OSPF default metric
   metric-type  OSPF metric type for default routes (default: 2)
   route-map    Route map reference

Update: It turns out the md5sum.txt files are put there by Debian's Live Build. Checksums are added on lb binary_checksums step of the build, which defaults to MD5 if no variable is provided to tell it otherwise. As Daniil suggested, we can put a second checksum step with SHA256 variable to produce both checksums, then check for sha256sum.txt files on new images. This way, old update scripts can still find an md5sum.txt in images.

@dtoux show ipv6 route vrf foo

I still see it in frr after the reboot but it is not showing in the output of show ipv6 route, so it seems like just a visualization problem.

To reproduce, on clean install 1.3.-rc3

set interfaces ethernet eth1 address '2620:18:6000:aa10::2/64'
set interfaces ethernet eth1 vrf 'foo'
set protocols vrf foo static route6 ::/0 next-hop 2620:18:6000:aa10::1
set vrf name foo table '1050'

@dtoux vtysh -c "show run"
Also, it doesn't show a directly connected ipv6 route.

What command do you use to get this?

The route present in the frr

!
vrf foo
 ipv6 route ::/0 2620:18:6000:aa10::1
 exit-vrf
!

The workaround for save command does not seem to work, have you tried for commit-archive option ?

Turns out vyatta-remote-copy.pl has been broken for a while. It fails to exchange encryption keys when it tries to establish an SSH connection (for SFTP or SCP), possibly because of the old libssh it relies on.