Ah yes, it's taken entirely from the string, my fault I tested with the version you can only use an IP address.

It actually does work, if only by accident

Actually I found out that the address:port wasn't implemented at all even if you were able to set it, it never was used within the config. I have that fixed now (not pushed yet). I also moved that part within the nodes, so it's going to be:

It work for 1.2 version (used systemd-shutdownd.service).
For 1.3 some bug with:

Thank you @kroy,

[email protected]:~$ sudo ip addr add "192.168.1.1/24" dev eth1.100

That command (above) don't correct for vif-s, with sudo you assign ipv4 only to one tag 8021q (Cvlan) .

This should be all of the relevant configs from the ASA side

Do you keep by any chance the ASA configuration you used? If so, would you please share it?

This is reported as resolved by Line2 in parent T1801; the related issue mentioned therein is also resolved by the revised fix in T1801.

Opened a separate task about the incorrect behaviour with the edit-level: T1846

Created a PR with the above change: https://github.com/vyos/vyos-1x/pull/174

This works better:

diff --git a/python/vyos/config.py b/python/vyos/config.py
index 13b2c10..82483cb 100644
--- a/python/vyos/config.py
+++ b/python/vyos/config.py
@@ -137,7 +137,10 @@ class Config(object):
         if self.__session_env:
             p = subprocess.Popen(cmd, stdout=subprocess.PIPE, env=self.__session_env)
         else:
-            p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
+            env = os.environ
+            env['VYATTA_TEMPLATE_LEVEL'] = '/'
+            env['VYATTA_EDIT_LEVEL'] = '/'
+            p = subprocess.Popen(cmd, stdout=subprocess.PIPE, env=env)
         out = p.stdout.read()
         p.wait()
         if p.returncode != 0:

Simple fix could be to just override VYATTA_TEMPLATE_LEVEL and VYATTA_EDIT_LEVEL.

Okay, that doesn't work. It likely requires some variables like these:

VYATTA_ACTIVE_CONFIGURATION_DIR=/opt/vyatta/config/active
VYATTA_CONFIG_TMP=/opt/vyatta/config/tmp/tmp_1929
VYATTA_CHANGES_ONLY_DIR=/opt/vyatta/config/tmp/changes_only_1929
VYATTA_TEMP_CONFIG_DIR=/opt/vyatta/config/tmp/new_config_1929

Seems based on the uses of the Config-class, for example this in vyos-http-api-server:

session = ConfigSession(os.getpid())    
env = session.get_session_env()    
config = vyos.config.Config(session_env=env)

that the intention was to have a clean environment unless called with session_env=something.

Seems like that paths are absolute regardless of the environment variables:

It would be pretty simple to pass VYATTA_{TEMPLATE,EDIT}_LEVEL=/ as environment variables in Config._run():

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

Can this please be splittet in a host and a port node? Only WireGuard uses this notation all other services have a dedicated port node

That is caused by: session_config_text = self._run([self._cli_shell_api, '--show-working-only', '--show-show-defaults', 'showConfig'])

@hagbard That however doesn't fix the issue where the entire config session seems to be invalid if you are not at the top level. After T1758 (commit above) the ConfigTree for session_config only contains nodes under the [edit <node>] level, not the whole config.

If your node exists, you won't see that issue, only if it doesn't. The above PR should fix that, but I have requested a review from @dmbaturin to make sure I don't introduce something into it he doesn't want there.

Okay, it seems that the major issue here is caused by commit d9ee0b95d1020b6d5412dd011ebb1ef7f6ef3fc7 / [vyos.config] T1758: use vyos.configtree for reading values, instead of calling cli-shell-api.

https://github.com/vyos/vyos-1x/pull/172
should also fix https://github.com/vyos/vyos-1x/pull/171 which wouldn't be required then anymore

I just noticed that the contents of that config look awfully lot like the config node ([edit interfaces ethernet eth0]) I was at.

The ConfigTree gets created with config_string:

in configtree.py the function return_value from /usr/lib/libvyosconfig.so.0 gets called with some integer and 'interfaces ethernet'. It returns 'null'

Regardin the interface not being configured:

The original error for reference:

@dmbaturin

c.return_value('local-ip') &&  c.return_value(['local-ip'])

would work, shall I rewrite it to a single item list? conf.exists() does only accept s string as argument.

The above PR gets rid of the exception during commit.

https://phabricator.vyos.net/rVYOSONEX3400b1dd79702553ebbd40516bf454f3fe47885b seems to have broken interface configuration. See T1844

Pull request with a fix: https://github.com/vyos/vyos-1x/pull/171

Personally I would keep it under the interface itself but @dmbaturin should have the final decission

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

If FRR has all we need we should use it - drops one additional dependency

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

@Merijn I am consulting with the author of the pull request; I still need to confirm behavior before we can consider merging.

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

The resolution in T1801 will prevent the error in this case.

I just have a gut feeling its better suited under the interface instead of a dedicated service. For FRR, have a look into the BFD implementation

• What other nodes will be unter the prefix tagNode?
• How would namesevrers be configured?

The general solution has been merged into vyos-1x.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

Hmm, that's actually a good point (http://docs.frrouting.org/en/latest/ipv6.html). I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.

c-po closed T1840: PPPoE doesn't not rename pppX to pppoeX as Resolved.
Mon, Dec 2, 19:52 · VyOS 1.3 Equuleus

On the other hand it still can live in the interface directly which would spare the migrator. VLANs are a good example - I‘ve written a common function to parse it in each interface. I am not fully convinced on any implementation be it under an interface or as dedicated service.

That is definately much better then before. But it doe not fix the second problem.

Works as expected. Now I can use VyOS 1.3 on my PPPoE link(s)

If we replace string 108 in file /usr/libexec/vyos/op_mode/powerctrl.py

PR https://github.com/vyos/vyatta-cfg-op-pppoe/pull/8

Backported

In rolling this was fixed T1204, we need add this to crux.

https://phabricator.vyos.net/T1228 sent the bug and I backported from upstream . The PR is in T1228 but needs to be merged into our package which I don't have permissions for.

as far as i know the content of the platform field is the first characters from sysdescr (20 characters?). on one of my devices this is

System Description:
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 14-May-15 02:39 by prod_rel_team

As noone complained that this option is not working (and it is an extension to regular ppp) I propose to remove it.

This is not possible as it requires changing the C source code of vyatta-bash during runtime.

Yes, I know that the best way to do is a python rewriting from perl, I love perl :-(