21:39:35.057600 IP6 (flowlabel 0xba774, hlim 1, next-header UDP (17) payload length: 76) fe80::20d:b9ff:fe53:7ee.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=95b13f (client-ID hwaddr/time type 1 time 643212067 000db95307ec) (IA_NA IAID:1 T1:0 T2:0) (elapsed-time 1681) (option-request DNS-server DNS-search-list) (IA_PD IAID:2 T1:0 T2:0))
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 19 2020
Based on a bond interface
@fetzerms thanks for getting back to us - I also successfully tested it.
set service dhcpv6-server shared-network-name TEST subnet 2001:db8::/64 prefix-delegation start 2001:db8:1000:: prefix-length '56' set service dhcpv6-server shared-network-name TEST subnet 2001:db8::/64 prefix-delegation start 2001:db8:1000:: stop '2001:db8:2000::'
Yes it is, we auto publish it if there is a change.
May 18 2020
@jack9603301 looking for a „service dhcpv6-server“ configuration which hands out the prefixes via ethernet so I can implement the client side.
I know that this does not cover all use cases but it is a PoC working for some users (not all of course). Next step would be adding this to ethernet based interfaces.
Documentationnupdated here https://docs.vyos.io/en/latest/interfaces/pppoe.html#ipv6
In T421#63882, @Azayaka wrote:
May 17 2020
Enjoy testing
From the Git commit:
set service pppoe-server authentication local-users username test password 'test' set service pppoe-server authentication mode 'local' set service pppoe-server client-ip-pool start '192.168.0.1' set service pppoe-server client-ip-pool stop '192.168.0.10' set service pppoe-server client-ipv6-pool delegate '2001:db8:8003::/48' delegation-prefix '56' set service pppoe-server client-ipv6-pool prefix '2001:db8:8002::/48' mask '64' set service pppoe-server name-server '8.8.8.8' set service pppoe-server name-server '2001:4860:4860::8888' set service pppoe-server interface 'eth1' set service pppoe-server local-ip '10.100.100.1'
May 16 2020
May 14 2020
May 12 2020
I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
No Problem - nice to see races for bugfixes
May 11 2020
Thank you for the good explanation in the issue!
Okay the problem here is that FRR stores the network as fe::/64 and not as fe::0/64 which was specified on the VyOS commandline. Thus the grep command used when deleting the route does not find the proper FRR entry and gives that error.
May 10 2020
That could als help on debugging like adding vyos-config-debug option or as I like on my hosts, vga=773 when debugging and checking for config migration issues.