Starting with this daemon config reduces the logging entries dramatically:

@panachoi maybe this upgrade helps

Hmm no movement...

personally I prefer bmon to iftop

Pull request: https://github.com/vyos/vyos-1x/pull/47

We are using "Double static NAT" life hack in AWS, so IPsec protocols works actually without NAT
And it is working good.

@c-po i have redacted the parts of the config i dont want leaked and i will just change the passphase :)

@Maltahl can you share your hub/spoke configuration? This helps us to reproduce your issue.

trying to setup DMVPN HUB using the wiki as reference on 1.2.0-rolling+201808272007

@UnicronNL also likes constellations, so let's go with it.

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

Hi @Merijn,
FRR changed quite a few commands here and there, most are easy fixes indeed.

I believe i found the cause in the following issue on FRRouting
https://github.com/FRRouting/frr/issues/1440

Simply fixing the node.def for remote-port and local-port will break existing configuration as also the Perl script requires changes for this to work.

Working perfectly with VyOS acting as DMVPN HUB.

My impression was that is was related to the adding of ipv6-next-hop to a route-map.
But without the IPv6 static routes the config commits fine.
When adding the first IPv6 static route the error is shown.

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

Nope, It was an offer to test a pre-build image ;).

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

This is part of T792

VyOS 1.2 is currently missing the kernel module. However, enabling it and marking the AMI as "Supports ENA" is sufficient. ENA is running stable and fast in the stock Linux kernel for me.

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.

When cisco_unity plugin is disabled globally, can Cisco DMVPN clients still connect?

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 .

Just updated to build from 20180821, and its still stopping; I'm glad that I'm not the only one seeing this, so it probably is some kind of bug. Again, nothing in the log at all, just the startup:

• set service dhcp-server shared-network-name <xyz> authoritative enable should be changed to be only set service dhcp-server shared-network-name <xyz> authoritative
• set service dhcp-server dynamic-dns-update enable true|false should be changed to be only set service dhcp-server dynamic-dns-update
• set service dhcp-server hostfile-update enable|disable should be changed to be only set service dhcp-server hostfile-update

Added few more rewrites:

It stops here, too. Why? I have no idea, yet

gotcha, now I see the fnords.

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:

I'm not sure if I did understand the issue correctly, however I don't think it's a good idea. Tag nodes can be nested and you need to figure out if a change happened anyway, so the script runs only once anyway.
Since you mention wireguard, let take me that as an example.

Tested it today again with 1.2.0-rolling+201808181101, no issues anymore.

A newer version of isc-dhcrelay is now available

after intense searching i came across this:

If we'd use

range {
    start 172.16.0.1
    stop 172.16.0.250
}

this would be transparent for IPv4 and IPv6

@hagbard I don't have a running vyos instance where I could verify immediately. But if it's not reproduceable anymore by following the steps I described then I'd assume it's fixed?

@binaryanomaly
Hi, is that still an issue? I tried to reproduce it today and used all of the August rolling images, but can't reproduce it anymore.