You can consider submitting a PR request in a rolling branch that has requested a merge.

Attempt two of the fix, so disregard everything in above attempt.

I have a working fix, which is comprised of earlier suggested fixes I mentioned in T1028 and T894:

I want to set this ticket back to "Needs testing" or even "Open", I have downloaded and tested vyos-rolling-2019-04-16 and it seems it is not properly fixed.

This requires fix, since workaround not fully acceptable

Hi all,

I'm a little confused about the status of this task.

So this problem still exists but I have no clue where to add it in our source @dmbaturin @UnicronNL

Looks like the issue with the same host displayed multiple times is fixed in the latest FRR.

Just upgraded another router from 1.1.8 to 1.2.0-epa3 without this problem.

Hmm... The config contains only one user - for which one I've reseted password. The user 'vyos' is completely missing!

Resetting password right now... Done, access granted!
It was lucky that I have access to console at this time...

Okay, spent the whole day messing with this and I've tracked it down so it's reproducible.

We need reproduction procedure so we can work with FRR guys on this

The config validation issue also seems to cause issues with route-maps applied - running config shows route maps applied but not configured inside FRR as can be seen with vtysh.

Hi Kim

After some searching i found that with the following commands it works:

@hagbard
Test setup created

@yun https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address that issue, can you please test? I only tested on VMs yet.

pending ci netplugd integration, local tests were quite successful, I think it can be release into rolling in the next few days.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-vmwaretools-scripts/vyos-vmwaretools-scripts_1.0-1_all.deb

I just tested with 1.2.0-EPA3 and it works! So the fix is included. Thanks c-po

T1181 will fix that issue.

hi kim

I can probably create a test setup this week and test the normal implementation in NPTv6 te see what is not working in my production setups.
As i do not have a build server at this moment creating a PR would be a bit difficult, the patch files are included in the comments above.

I think I know what you mean now, it also starts translating the global address on the external interface. Can you send a PR for the changes you've made please?

At the first quick review it works:

Then we do not have the same setup :-)
set interfaces ethernet eth0 address 'x.x.x.225/24'
set interfaces ethernet eth0 address 'x:x:x:x::225/64'
set interfaces ethernet eth1 address '10.0.201.1/24'
set interfaces ethernet eth1 address 'fd00:10:0:201::1/64'
set nat nptv6 rule 10 outbound-interface 'eth0'
set nat nptv6 rule 10 source prefix 'fd00:10:0:201::/64'
set nat nptv6 rule 10 translation prefix 'x:x:x:x::/64'
set protocols static route 0.0.0.0/0 next-hop x.x.x.1
set protocols static route6 ::/0 next-hop x:x:x:x::1

@Merijn I haven't added anything. I just tested nptv6 and it was working as expected. I used your setup you have initially posted, I just used a different interface for the outgoing traffic. I confirmed via tcpdump that NAT did work.

@hagbard What do you want me to try. I downloaded and loaded that rolling image and i do not see the proposed patches in it.
I rebooted the router and it did not work.

I've tested it without doing anything on the code and everything is working properly.

@bjtangseng I do not know if dmvpn was in rc.10.
Can you please try the same in the last roling release?

Confirmed. If we try to change variable with multiple values, will be applied only first of them. For example:

net.ipv4.tcp_wmem = 4098	16384	1643392

https://community.ubnt.com/t5/EdgeRouter/Issue-NAT-Exclude-with-load-balance/m-p/628739#U628739 this example shows how edgeos has dealt with this issue.

I don't know whether it can be helpful but I have a similar configuration working in OCI (Oracle Cloud Infrastructure).
eth0 interface is configured as follows :

I was mistaken. Seems to have lost the route again.

As of (at least) VyOS 1.2.0-rolling+201901090739 I believe this problem to be corrected.

Can't reproduce for a while
marking this as solved

Ok, @UnicronNL we will need document procedure and add it to other guides

recursor was upgraded