I pick this up as I did the rewrite of this whole stuff

@Viacheslav thank you for testing!

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

I have tried multiple times to reproduce this with 1.2-rolling-201912060217 with no luck. It would be great if together with logs you will provide a detailed description of the environment. Because, possible that even CPU cores count or memory size can lead to some condition, in which dhclient-script cannot get proper values from config and add unwanted servers to the resolv.conf.

https://github.com/vyos/vyos-1x/commit/fde531d3791a3d71aa27f99244d7cbb3b3625bf0

looks like i had an old version, newer iso doesn't show that issue.

There have been some time since i've managed to work on this now, and in the mean-time the whole ethernet/bridge sertup have been rewritten into python, so i need to restart my work on this implementation , also the bridge membership part is moved around in the cli so information in this ticket is out-of-sync with the current implementation and needs to be rethinked

Could you provide the log output in a case when DNS servers, received from DHCP appears in resolv.conf? As I understand, it should happen immediately after the boot.
Also, please, check if they are not deleting after the first DHCP lease renewal.

Just a quick note that this issue remains in 1.2.4-epa1

https://github.com/vyos/vyos-1x/pull/177
https://github.com/vyos/vyatta-cfg-vpn/pull/27

@zsdc:

Please reopen T1786 in case of further troubles.

I can't so I've reopened this one; I don't have permissions to do this :(

I agree. If it works in a way that is consistent with what the command promises, let's use it.

The fix suggested in the pull request did not resolve the issue as a consequence of T1847. With that issue resolved, we can consider this merge.

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

@christopher.crews07
In you example some mistake (2 times vif-s)

This bug is fixed in latest rolling releases 1.3.
Tested on

[email protected]# run show vers
Version:          VyOS 1.3-rolling-201912040242

Thanks

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:

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.

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

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

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

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

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.

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

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

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

This should be done when rewriting the whole flow-accounting portion