Fixed by T1469 both in rolling and crux

@Dmitry that was actually I had in mind when I was implementing it. Otherwise it's hard to monitor if you want to have it down to specific ways it does route the traffic. Let's see if the community requests something like that. It would mean a whole buch of more flexibility but also way more items to configure and verify. IPv6 would be global anyway, so the only way there would to disable IPv6 on an interface, the subnets on Ipv6 are usually big enough, so it would only come down to Ipv4 anyway.

I just tested with a split dns config (so I can exlude the internal DNS server has resolved the external domain name I used for the test). It works again!

@hagbard I think authentication must work without any changes, but we just may use shared ip-address pool for any numbers of interfaces. If used current schemas, we will need adding ip-range for everyone interfaces.

@Dmitry What would be the benefit for that? You would lose the ability to authenticate a particular mac address via a specific interface, wouldn't you?

Build complete

I supposed something like that :-) I will test and report

Please check wirh upcomming rolling release. There was a fix in T1469

Thanks for the contribution

in vyos-1.2.0-rolling+201907031336 now the dns forwarding domain entries are completely missing in recursor.conf:

@c-po @dmbaturin I created two pull requests, one for 1.2.2, one to fix a problem on current branch

@ekim First of all, a quick fix for your situation with next-hop: add { } after the next-hop that is missing it. I.e.:

@mb300sd do you know how long it takes for the config to load for you? because the /etc/resolv.conf file is persistent. but on loading the config it should do the 'set system nameserver 2001:470:20::2' and overwrite the resolv.conf file.

Possibly a related problem here in T1497, we're still chasing an issue where disable-dhcp-nameservers isn't working on startup.

The issue here is not the scripts themself, it is our(vyattas) mixing of hardware/ system configuration.. the ethernet mapping table is a device specific table that only works on one particular device, all other configuration inside vyos is portable between devices, but this information is not.
This also makes it impossible to move a config file to another hardware without modifications (removing the hw-id mappings)

What is the purpose of getting the nic/mac mapping before configuration is applied? Is the result passed to a second script which pins the ethernet interface to its mac address? Why not write a script which dynamically reads the info from the config, parses it and applies further actions without the need of an intermediate file?

Yeah, that's the one I just installed.

@mb300sd i just created this one https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso did you already test with it?

Still using the dhcp servers on 1.2.0-rolling+201907022116. Will post back in a few hours if the one with a bunch of lines happens again.

Not sure when the messed up one with all the lines happens, it wasn't right after commit, seemed to be after sitting for a few hours, but it was broken again when I tried to add system image just now.

@UnicronNL yes. On boot it creates the resolv.conf with DHCP nameservers and missing the domain/search options. If I commit, it generates one with my configured servers and the domain/search options.

@mb300sd
could you please retest it with:
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso

Tested with:
set service ipoe-server authentication interface eth2 mac-address 08:00:27:2F:D8:06
set service ipoe-server authentication interface eth3 mac-address 08:00:27:2F:D8:06
set service ipoe-server authentication mode 'local'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:1::/48,56'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:2::/48,56'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:3::/48,56'
set service ipoe-server client-ipv6-pool prefix '2001:db8::/48,64'
set service ipoe-server dnsv6-server server-1 '2001:db8::'
set service ipoe-server dnsv6-server server-2 '2001:db8:aaa::'
set service ipoe-server dnsv6-server server-3 '2001:db8:bbb::'
set service ipoe-server interface eth2 client-subnet '192.168.0.0/24'
set service ipoe-server interface eth3 client-subnet '192.168.1.0/24'

So in my testing of VyOS - after tinkering with an edgerouter, this is a kinda major feature to be lacking...

I was able to reproduce your first issue...

@mb300sd can you share your config maybe?

@mb300sd do you mean after a fresh boot you get:

Updated to latest rolling, 1.2.0-rolling+201907020337

nice, a banner in the wiki page is also an elegant way to document the progress.
I would go through all pages i have already migrated and add the new via your template.

IPv6 is all static - he.net tunnels. Will try the rolling when it's up.

@mb300sd is the ipv6 address provided via dhcp?

It's at&t's dhcp server, I have no idea what they run.

@mb300sd what is the dhcp server you are using?
Could you also please share the content of the files:
/etc/resolv.conf.dhclient-new-eth0 (or other interface if you use an other)
/etc/resolv.conf.dhclient-old-eth0 (or other interface if you use an other)

@c-po @mb300sd found the issue 'Nameservers are not propagated into resolv.conf' (no script in node def) , also the issue with the split ipv6 does not seem to be in host_name.py, will look a bit further for that.

Hi Guys,

I was check ipoe local user authentication, with next config:

Hi rob! Nize that more people is involved in this :) i've started the large task of marking things that have been migrated to github, it's a lot of pages with outdated info thats not going to be migrated, also i find a lot of pages not having enough "end user" documentation that i don't know where to put.. eg. devel docs etc..

for some weeks/months i began to migrate the first wiki articles to github.
@syncer wanted to redirect the old wiki pages to the new rtd pages, so i create a list to document the progress.

The difference might be because my IPv6 server is first, but I'm also experiencing the non-update when I try to add 1.1.1.1 to see if having an IPv4 server first helps.

@c-po We have plurals everywhere we have more than one option under a subtree. dhcpv6-options, offload-options, "system options"
Since there's also the hostname option, and possibly other options we may want to send, that makes sense I guess.

Can't reproduce, but I experience a different issue - Nameservers are not propagated into resolv.conf

Unfortunately this is not 100% correct, the intel drivers are pinned to a specific version. Only vyos-wireguard, vyos-accel-ppp are using git HEAD revision from their individual repos.

and always download the latest upstream driver

i think that out-of-tree drivers also needs to be under the same control as modules and the kernel

I only see some minor problems, but in general I like the idea very much!

Putting the migration script on hold until I can get sample configs for "service dhcp6-server static-mapping identifier ..." and related host entries in /etc/dhcp/dhcpdv6.conf from an old vyos version with the old vyatta-cfg-dhcp-server scripts.
In particular if it was possible to set quoted strings as identifier which would be set unchanged in dhcpd6.conf, this would necessitate detecting whether the identifier was a quoted string or not, and converting the string to hex. If it wasn't possible to set quoted strings the migration script is not necessary.

I am confirming that the problem is not reproducing in the 2.0.17. We should upgrade keepalived distribution.

https://vyos.readthedocs.io/en/latest/services/ipoe-server.html