SPINE-1 BGP config(JunOS):

set protocols bgp group UNDERLAY mtu-discovery
set protocols bgp group UNDERLAY export FROM-UNDERLAY
set protocols bgp group UNDERLAY local-as 4200020001
set protocols bgp group UNDERLAY graceful-restart disable
set protocols bgp group UNDERLAY multipath multiple-as
set protocols bgp group UNDERLAY bfd-liveness-detection minimum-interval 350
set protocols bgp group UNDERLAY bfd-liveness-detection multiplier 3
set protocols bgp group UNDERLAY neighbor 10.177.77.2 peer-as 4200030001
set protocols bgp group UNDERLAY neighbor 10.177.77.10 peer-as 4200030002
set protocols bgp group OVERLAY type internal
set protocols bgp group OVERLAY local-address 10.177.75.1
set protocols bgp group OVERLAY family evpn signaling
set protocols bgp group OVERLAY cluster 10.216.255.255
set protocols bgp group OVERLAY peer-as 64542
set protocols bgp group OVERLAY local-as 64542
set protocols bgp group OVERLAY multipath
set protocols bgp group OVERLAY neighbor 10.177.75.3 description LEAF-1
set protocols bgp group OVERLAY neighbor 10.177.75.4
set protocols bgp group OVERLAY neighbor 10.176.75.1
set protocols bgp group OVERLAY neighbor 10.176.75.2
set protocols bgp group OVERLAY neighbor 10.177.75.5 description VyOS
set protocols bgp group OVERLAY neighbor 10.176.75.3 description HV205
set protocols bgp log-updown

This is working frr configuration:

No, this is not correct for my set up. Configuration commited without error but lost peering

1. Peer-group UNDERLAY - eBGP(directly connected peers)
2. Peer-group OVERLAY - iBGP

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

Tested in different possibilities:

The 1.3.x behaviour,

1. VTI interfaces without IPsec is not created

# 1.3
set interfaces vti vti10 address '10.0.0.1/30'
commit

@c-po, while I don't wish to put words in the mouths of others, I believe the belief is that the interface should stay oper-down.

https://github.com/vyos/vyos-1x/pull/3090

Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.

Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.

Perfect, that's what I was trying to better understand. Thanks for the clarification!

The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.

Gotcha! The thing I keep struggling to understand is why is the full section of the config removed? This will 100% cause outages. If there's part of the config that is invalid, only that part should not be applied. You shouldn't remove 19 valid lines of config due to a single invalid line. Particularly with almost all of the instances I've seen of this, the invalid line is just cosmetically invalid, and doesn't cause any issues with the operation of the system.

Well, nothing is deleted, rather the config section is not applied if the verification steps do not pass: if the user ignores the error and warnings and saves the subsequent working configuration, the resident config.boot file will be overwritten. So I agree that it an issue for consideration, if we distinguish those cases in which this may occur, as above. Considering those cases, we can not or would not want to (1) automatically fix migration errors, in some sense or other, to avoid non-application of config sections on migration failure; bugs in the migration system should be fixed, and improvements to the migration system itself are part of the current development plans (2) support non-verified/non-existent interfaces without clarification of when if ever that is appropriate, such as the current investigation. There is current development of the design to refine the verification stage, unrelated to this specific task. Given the preceding, I would not say either that it is a case of 'everything's fine' or of 'design flaw'; design evolution is appropriate perhaps.

@jestabro, do you guys consider the process of deleting the entire config section for a single offending line working as intended? Or do you consider it a design flaw/bug that will get fixed? I'm trying to understand if that is an intentional design choice and will permanently be part of VyOS going forward, or if it's just part of growing pains as VyOS moves from 1.3 to 1.4.

Config sections not applied after failed verification is not a surprise, as discussed above, though it is understandably frustrating: warnings are provided on failure and upon entering config-mode subsequent to failure, to help avoid overwriting the saved config before investigation. As we continue this discussion we should distinguish the various issues (and I will open subtasks as appropriate):
(1) missing config sections on migration need to be debugged, as with T6076, ongoing ...
(2) verification of 'late' arriving interfaces (general); configuring ZeroTier (specific): I'm looking into what may be considered for the general issue, as mentioned, and I have some initial ideas; thanks to the details provided by @L0crian I'll reproduce the specific configuration for experiment
(3) support for hotplugging interfaces: not planned at the moment, but may be discussed again for 1.5

https://vyos.dev/T6076 is also similar...

I wanted to add this post from the forums to this thread. It appears to be the same behavior where the failure of a single line deletes the logical section:
https://forum.vyos.io/t/upgrade-from-1-3-6-to-1-4-0-epa1-looses-complete-dhcp-configuration/13935

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

@paigeadelethompson it is another issue, open a separate bug report

Do you refer to initially admin-down or oper-down?

Now trying to migrate a second router, with different config. I have corrected the mistakes I could see in the config and have removed policy route config with tcp flags.

Thanks - yes - there were in fact 3 "passive-interface" entries for old interfaces, which I should have tidied. Having deleted them, the migration completed.

Check opennhrp.conf file
Could be bug if the ispec in the config T6084

Still broken in 1.4.0-epa1 (self-built).

If the peer reconnects after the first disconnect - does the local VTI interface go "UP" again?

The motivation here was from T5660, for which it was not needed. However, a version of the constructions in the branch above will be useful for development of the modern commit algorithm and comparison with the idiosyncrasies of legacy (T5492). Put on hold for now.

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

You don't have eth0.150

is it possible to extend this feature to json api of vyos?

Rebooting the failed image (I did not redo the upgrade - the failed image remained on the router) produces:-

itconsult@ha-r02a:~$ cat /tmp/vyos-configd-script-stdout

Gotcha, thanks!

The configuration checks are the 'verify' stage of the respective config mode script; general structure here:
https://docs.vyos.io/en/sagitta/contributing/development.html#configuration-script-structure-and-behaviour

What is the content of
/tmp/vyos-configd-script-stdout ?

In T5991#178350, @jestabro wrote:

I raised this issue for discussion last week, and am testing more 'lenient' verification in cases such as above; I'll add results and plans here, as available.

I raised this issue for discussion last week, and am testing more 'lenient' verification in cases such as above; I'll add results and plans here, as available.

Thanks for that.

1.4 https://github.com/vyos/vyos-1x/pull/3062
1.5 https://github.com/vyos/vyos-1x/pull/3061

PR https://github.com/vyos/vyos-build/pull/514

Firewall failed migration due to incorrect subnet, 1.3 firewall did not correctly validate those fields. Correcting source address on rule 30 on TO-ROUTER chain should migrate the firewall properly.