added not on old-style cfg-mode templates

Added a sidenote about switching on router and routing on switch

First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6

@hagbard This commit adds a route to the kernel routingtable and bypassing FRR, this is no good and this would break. Please make the script add the appropiate commands to frr instead. This way frr will be in charge of populating the kernel table. Also note that this route needs to be removed on dhcp release

That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..

looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….

When a host-name is not present, set the same default as on a newly installed device... router or vyos.. (atm. i don't remember what it says)

And yea, i feel like the configuration is quite backwards in the curremt implementation... Configuration of the ppp interface should be in its own interface block, and not inside a parent interface like it is today.. the parent is only an attribute on the ppp interface...

PPP supports many forms of transfer, hense the dialer interface on cisco. almost all supported ppp/slip etc. functions are supported by the dialer function in a cisco device. Now, vyos supports PPPoE, but we don't support any other PPP "format".. if we intend to add support for more formats (serial nullmodem, modem, isdn++) then i would favor a new Dialer or Dialup interface type.. if not.. why not call it pppoe?

Code is now merged, please test in the next rolling release tomorrow

i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

Hi rherold!

Hi adestis, what you descripe is possible to do today with the help of a shellscript and the crontab, if you are interested i could help you create a script that does this for you, the one drawback is that the failover-time is in the ballpark of minutes, and the routes are not present in the configuration... Also, cron fills the log with messages every time it executed

That is not how wireguard works ? that is how ipsec and openvpn works.

This is how ipv4 works :) and have nothing to do with wireguard, ipsec etc. Actually the config you have applied eill in some situations work, but that relies on the handling of the packets inside the kernel and is not following the tcp/ip principles... If you take a look on the quick start guide on the wireguard webpage you se it there aswell... https://www.wireguard.com/quickstart/.

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

Until we redesign the firewall CLI, I'm making the rules match eth0+ instead. I hope the performance impact will not be too high.

The fault is found in the vyos-strongswan codeset,

@c-po i've updated the Dockerfile and added build notes in README.md to build the vyos-strongswan module in this PR: https://github.com/vyos/vyos-build/pull/31 . please test it out

I've added a PR in vyatta-cfg-system (https://github.com/vyos/vyatta-cfg-system/pull/94)

Sorry @hagbard this was completely forgotten from my part.

I did a build yesterday that went trough without issues..
I was using custom kernel, wireguard module and strongswan module. So from my point of view everything is fine now.

@syncer, this is a quite serious security issue and a deal breaker for dmvpn. As we have earlier stated that dmvpn is working now (http://blog.vyos.net/vyos-development-news-in-august-and-september) i think this needs to be fixed before 1.2LTS ... OR. We need to make a new statement that states that dmvpn will be broken in 1.2LTS..

I've been trying to get a dev environment for vyos-strongswan up and running for a couple of days now but are unable to compile it.. right now i'm stuck with the compile system not finding my libsoup-2.4 package :/

While it is work ongoing on this, the code for LLDPD is quite old. i would request an upgrade to the newest version . https://github.com/vincentbernat/lldpd/tree/1.0.1

The fault is verified on the latest rc8 and the latest rolling vyos-1.2.0-rolling+201811251437-amd64.iso

Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?

Another way is to check in /etc/os-release, but that is also a changeable file.... Wondering where lsb_release reads it from ( no pc atm, so cannot check)

Its a little hack, but not the ultimate one i think :p temporary files for storing state is used quite a few times inn the original bash/perl scripts

as noted on slack:
A way to implement the run once for tag :
If we in the tag after first execution add a temp file 'touch /tmp/complete-blah' , then we check for existance on that file on every run and skip of it exists..
in eg. wireguard/node.def:

end: if [ ! -f /tmp/runonce-wireguard.lock ]; then
         sudo sh -c "${vyos_conf_scripts_dir}/wireguard.py"
         touch /tmp/runonce-wireguard.lock
     fi

Whis way the wireguard.py shuld only execute on the first "execution" and be skipped on all recurring runs.

I've been looking into how this is implemented in all instances of interfaces/* and everyone uses the same run on every tag value instance approach.
Here are a couple of examples of easy implementations looked from node.def
openvpn:
sudo /opt/vyatta/sbin/vyatta-update-ovpn.pl "$VAR(@)"

I see T959 is targeted for 1.3 release and is hereby requesting a backport of these commands from T959 into 1.2 before LTS is released (if there isn't any dependencies between the show commands and the rewrite of conf mode scripts)

This is exactly the same issue i reported in T786, for every interface thats created the script runs its full processing.. when 10 interfaces are created it tries to execute it 10 times and so on. I have purposed a fix for this behaveor in T786 and there is a PR (https://github.com/vyos/vyos-1x/pull/33) on this. Another thing that could be done to fix this is to fix the underlaying vbash code that makes this happen, but i think that is a larger task.

Ahh, my mistake! Will remember that :)

@hagbard, the powerctrl.py script allready have everything needed, --check to check for scheduled reboot. :)

Hmm.. i think some things is missing here... the "reboot" and "poweroff" commands is using the new /usr/libexec/vyos/op_mode/powerctrl.py script to schedule reboots, but "show reboot" and "show poweroff"

General:
Support for multiple non-ASCII, non-Unicode encodings

• Remove it

I've now sucessfully labbed your config, and are able to get dmvpn up and running with your ipsec config :

Yes, in some situations this is resolvable eg in the service broadcast-relay example. Here the owner parameter could be moved to the "top-node" for that block. the problem with interfaces is that every config block is a tagNode, so we can't do that trick without moving it to the interfaces node that catches all interfaces., and not just interfaces of the type you want.

nize @c-po!
a new image is created to hotfix frr not starting before vyatta-router: http://dev.packages.vyos.net/tmp/vyos-1.2.0-frr-20180825.iso

@c-po, Ahh! :)
You could compile the vyos/vyos-strongswan github repo, but a image is the best to test with.
i had issues with just apply'ing strongswan patches. (strongswan crashed and hung my device when restarting services)
The latest image created is http://dev.packages.vyos.net/tmp/vyos-dmvpn-0820.iso created by @dmbaturin on 21.aug ..
after that is installed change this:

@c-po did you manage to test disabling cisco-unity in a mixed vyos/cisco environment?

I think the best is to use the default from the protocoll.. (autogenerate port if none is specified) 51820 could be a completion help option on the listen-port command

@c-po, As far as i can see it does not distinguish between server and client mode.
From the manual:

@hagbard i actually haven't tried it in real life, only looked at the command syntax'es.

@hagbard
Thats much better! :D
"peer" in "peer-pubkey" is also a bit redundant, just call it "pubkey"

as far as i can see this should be possible. it looks like the cisco_unity plugin is used to automatically install routes and other things that is not needed when we are running inside a gre tunnel as is done in dmvpn. but i have not looked into the unity plugins code so i'm not completely sure.

I think that using the key as a peer identifier makes the configuration unreadable its quite hard to identify each peer when you have more than one of them. I would like to se the peer identifier to be a name/description instead and that key is added as a leafNode instead...

after @dmbaturin rolled a new image with patched opennhrp script and swanctl code dmvpn works as expected when manually disabling the cisco_unity plugin in /etc/strongswan.d/charon/unity.conf .

I got dmvpn up and running. here is the list of things to do:

To do the same example as it is running in the current-rolling devel i have reverted my patch:

The current implementation of the config interpretor does not work that way.
It is correct that your config script needs to take account of all added/removed config within your tagNode, but the script will actually run once for every tagNode instance you define.
let me take an easy example:

after intense searching i came across this:

i will try to do some work on implementing this if its possible to get it upstream if i succeed?

in my latest PR i've also added a rewrite of "show host *" in show-host.xml. this rewrite does not need any wrapper scripts.

@dmbaturin ahh, my fault.

When trying to migrate " show login " and "show history" the new syntax scripts fails to retrieve information from the current user.
The reason is that everything that is executed by the new syntax scripts are wrapped inside sudo.
(from build-command-op-templates line 140: node_def += "run: sudo sh -c \"{0}\"\n".format(command.text) . )

i've added all files i have finished now.
i also have nearly completed files for show system and show log, but they need some tweeking and completion/op_mode scripts to be finished.

Finished so far:

• reboot
• poweroff
• show arp
• show bridge
• show date
• show disk
• show configuration
• show hardware
• show raid
• show users