I wonder if this used to work in the past?

@maznu @Merijn Can you test the latest rolling 1.4 release?
It should be fixed.
You can kill ripd/ripng/ospfd/bgpd/isisd daemons or allow it for watchfrr.

Turns out this is not a VyOS limitation but is a Linux Kernel/iproute2 limitation.

Fixed via https://github.com/vyos/vyatta-cfg-firewall/pull/21

This bug also persists in VyOS 1.2.7

So I finally stopped being lazy and got VyOS in to GNS3. As with our production routers MPLS remains off after restarting with either 1.3-rolling-202104021041 or 1.4-rolling-202104022042 for VLAN sub interfaces. Ethernet parent interfaces have their mpls state managed correctly.

It seems fixed for rolling release 1.4 because soft has been moved to FRR7.5.1
Of course it is not fixed for rolling release 1.3 (and as I understand won't be) due to FRR7.3.1

@syncer
Sorry to dredge up an old bug, but I believe I've hit this today on 1.2.7-LTS myself. Per @zsdc's original description, It seems that when you configure:

Added minisign package https://github.com/vyos/vyos-build/tree/current/packages/minisign and also included this in vyos-1x dependency list for crux, equuleus and current

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?

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:

Does anyone follow up on this?

@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
!

Looks good on 1.3-rolling-202103280642:

Looks good on 1.3-rolling-202103280642:

Looks good on 1.3-rolling-202103280642:

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

Possible reason "> 2" in description "Ruby > 2.3"

vyos@r5:~$ echo "Package versions:"; dpkg -l | grep ruby-curse -A 2
Package versions:
ii  ruby-curses                          1.2.4-1+b1                          amd64        curses binding for Ruby
ii  ruby-did-you-mean                    1.2.1-1                             all          smart error messages for Ruby > 2.3