Did a rebuild and found the silent error:

While I was checking my old build, I have seen this on /live/filesystem.packages:

I need to modify the file(/etc/swanctl/swanctl.conf) manually, from emote_ts = dynamic[gre] to remote_ts = 0.0.0.0/0[gre].

I test that issue on 1.2.5. but not work

Have the opportunity to study whether it is because of pppd configuration file error?

Well a bit more verbosity would be good. As usual:

• provide config
• logfiles
• routing table
• interface ip list

Dial on demand still doesn't work

If you think about it carefully, maybe for vyos, if you don't consider supporting SDN, then Linux bridge is a good choice.

I have been thinking about a problem. OVS can work in SDN controller mode. However, if OVS works in SDN controller mode, whether router related functions related to routing configuration will fail. If someone wants to implement it, then whether SDN switching control mode and non SDN related modules need exclusive processing to prevent conflicts should be considered.

After some benchmarking of this code i have i've gotten hold of a quite large test configuration that takes a waste amount of time to load into vyos.

Waiting for the next rolling version, thank you.

There is a basic test for this which should be expanded.

Can regression testing of some sort be added for this? I've seen this issue crop up before now, so I would guess this is a good candidate for that if possible.

@thomas-mangin I'm convinced: for get_child_nodes and get_node, we'll return a dict of respective dicts:

A very fast look on the source indicated wrong dictionary keys which have bewn missed out during migration to get_config_dict() - please try next rolling.

My guess is this will be resolved by the full BGP rewrite - I also do not like the current behavior.

Closed - this is available as set system ip layer4-hashing

Oh, neat. Thanks, I'll close this then!

I would very much like you reconsider classifying this as a bug if not security issue.

Is this bug report not handled?

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

The same for ipv6 is available under set system ipv6 layer4-hashing

HI! On 1.3 layer4-hashing is activated by using the set system ip layer4-hashing command

Okay, I like that video already ...

@thomas-mangin Firstly, I needed to write this version before reasonably debating the pros/cons of various approaches --- the important idea developed is that the use of get_sub_dict, and ability to return the sub_dict under the diff'ed nodes will allow a fluid use in writing conf_mode scripts --- beyond that, I am not particularly attached to any details of implementation, yet.

As I click "sail", I just realise that as there is only one config per router, ConfigDict could be a subclass of Config which could be itself singleton. So even if it is subclassed, all instances could/would share the same underlying data and could be used inter-exchangeably for the content of the config.

@jestabro I would like to hear why you advocate this API and why you believe it is better than the one I have suggested.

Using the mentioned defaults in https://tools.ietf.org/html/rfc3414#appendix-A.3.2

@thomas-mangin and @runar I do like the enum idea, however, this would add boilerplate to the conf_mode scripts, which would quickly become annoying in practice ... rather, common workflow just wants the actionable data (added, deleted) _and_ the ability to then access values under the node in question. Consequently, I'm following @runar 's suggestion of returning a tuple, combined with the return_as_dict arg to allow access to sub-data.

This somehow relates to T2651

It does work (eth0 is actually my management vrf interface) if I put the IP for downloads.vyos.io into my /etc/hosts (I guess using a vrf for outgoing DNS requests would be even trickier but this workaround is okay for me, especially since I have a local update mirror reachable via static IP):

@moepman can you check command?

The reason this is failing is VyOS 1.2 lacks proper input validation on the loglevel nodes.

One forgotten point: get_config_diff obtains the config_dicts at root level, so any movement within/between sub-sections are available, with set_level.

It is true that get_config_dict is slow, so it should only be called once (twice for diff) per session. Consequently, the work flow will be:

Adding screenshots showing the error and the fix.

Regarding the API proposed, most of these functions are also syntactic sugar for the same operations. Looking at the use cases, there is two: getting information about a leaf value, or getting information about tagNode changes.

So, as far as useful helper functions, one certainly wants:
get_child_nodes_changed(... path)
get_value_changed(... path)

@runar in fact, that's all one wants in current use case: has the list of elements, directly _under_ the specified node, changed? For example, (1) change of values (2) added or removed tag node entries.

Yes, I'm expanding all paths under the specified path

About is_changed, i see the need to have a function that tells if there are any changes in the path tree under the given path.. specified.

Yes, I definitely prefer a return type of tuple ...

Good point, get_value_changed is a better name for this. As you want to distinguish between a returned value of False and a "Not Changed" using a two tuple (namedTuple?) returned with new and old value makes it easy to "see" the difference

Regarding is_value_changed, I was thinking the other way around: get_value_changed returns None if no change, so is_value_changed would be redundant --- put good point: one may/will want both old and new values

I am entirely open to suggestions here; the underlying functions support any such forms. Note however, that we want to distinguish between new/deleted paths and changed values --- one could treat these all as a difference in path, but it will be more convenient for use if we make the distinction ...