@c-po looking at your commit d80398b6, I don't think that's how the hw-id node was supposed to be used. It was never used as a way to change the interface's mac address, rather it was used to rename the interface with the matching mac address to the name it has in config.boot. This is done by some vyatta scripts at boot time. If we later set the same mac on the interface that it should already have (as it was renamed by the vyatta scripts), that's pretty pointless to do IMO.

@jjakob detect_if_systemipv6_is_disabled just an idea, but looking to interfaces-openvpn.py, it's easy:

PR https://github.com/vyos/vyatta-cfg-vpn/pull/30

Disabling IPv6 on the system is something not mainlined in VyOS - there are open PRs on GitHub which needs to be approved by @dmbaturin. As Disabling IPv6 would also require the CLI to disable all IPv6 inputs dynamically which is something not possible at the moment.

Looks good. Is detect_if_systemipv6_is_disabled() already a
system function? If so, It can be incorporated (by you if you wish, or by
me). The last line is missing += by the way.

This code doesnt break if ipv6 is disabled by system wide:

Yup that did it. Thanks!

The form will be made consistent with other commands, using an explicit 'op' (show|generate) and 'path' as list of strings. For example:

Fixed in the latest rolling.

Fixed.

Fixed in the latest rolling

sever@r11:~$ show vrrp 
VRRP is not running
sever@r11:~$ show vrrp detail 
VRRP is not running
sever@r11:~$ show vrrp statistics 
VRRP is not running
sever@r11:~$

Works for me

The above PR is tested to fix this issue and T2345.

https://github.com/vyos/vyos-1x/pull/372 will now not display tunnel (but gre-bridge) as options for bridge. Still not preventing them to be used.

works if run as root (or sudo) but not as it.

Make sense, because IPIP this is L3, the bridge is L2.
In this case, we should not show L3 as an allowed interface for bridge.

/sys/class/ieee80211 does not exist on VirtualBox perhaps the interface configuration should fail it is missing ?

So the commands were not on crux under the tunnel section and trying to use either ip link or brctl is failing:

crux has another syntax, but interface tunnels not bridgeable in crux

For all the bridge issues, I wanted to see what was happening on crux, taking T2356 as reference:

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

With this patch, all works as expected. Thanks @thomas-mangin

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

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

Related with https://phabricator.vyos.net/T2223

PR https://github.com/vyos/vyos-1x/pull/368

Ah, I figured it out - the contents of vyos.log.debug are used as the path to the logfile, if empty (but present) the default /tmp/developer-log will be used, otherwise no logfile will be written. But I think I've hit a bug - if multiple 'flag' are set (other than 'log') the system hangs during boot.

Fixed in latest rolling

sever@r11-ansible# set interfaces ethernet eth3 description test
[edit]
sever@r11-ansible# commit
[ interfaces ethernet eth3 ]
Interface ethernet eth3 does not exist

In T421#61055, @tbr wrote:

In T421#61020, @jack9603301 wrote:

No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:

• The router can directly use the prefix obtained by PD to subordinate devices and specific bridges, and use the prefix allocation of ISP for further classification.
• For those who use the ula intranet address, I hope to add a function option without requiring me to specify a fixed ISP assigned address (the PPPoE dial-up of ISP will generate a different address and prefix each time)

Yes, I agree... I think this can work. But baby steps first :)

In T421#61020, @jack9603301 wrote:

No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:

• The router can directly use the prefix obtained by PD to subordinate devices and specific bridges, and use the prefix allocation of ISP for further classification.
• For those who use the ula intranet address, I hope to add a function option without requiring me to specify a fixed ISP assigned address (the PPPoE dial-up of ISP will generate a different address and prefix each time)

In T421#61005, @tbr wrote:

In T421#60930, @CRCinAU wrote:

Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?

It would make sense to offer this for any WAN connection type - I'm not sure there's a usage case for any other type...

Yes you're oversimplifying :) But I agree it is also not so mega complex either. It is indeed in practice just a setting to enable it on an interface.

The dhcpv6-pd option would only allow to receive a prefix on a given interface. Then, as a secondary step, the prefix can be used by the router via RA on internal interfaces for address assignment (SLAAC or DHCPv6).

But ok. I'm probably missing something here. I just want to sday that the EdgeMax routers can already do dhcpv6-pd for years, and I never had any issue with their way of configuring it. I think vyos could do a very similar configuration approach and be done with it... so, I'm going to attempt in adding this myself. I need to learn the specifics of vyos builds and workflows, but other than that I have plenty of experience. Only time is a major deal breaker :)

Australia's largest mobile carrier is currently moving to IPv6 only for mobile handsets with NAT64 at their edges....

For routers that support IPv6, it will be necessary to support DHCPv6 PD and better support for NPT to set Wan dynamic address forwarding. Although this is just a personal idea, IPv6 is the future trend, and vyos need to make better preparations for supporting IPv6!

No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:

In T421#60930, @CRCinAU wrote:

Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?

It would make sense to offer this for any WAN connection type - I'm not sure there's a usage case for any other type...

In T421#60929, @tbr wrote:

Well, I have been using EdgeMax routers for the past 7 years or so (from the day that the ER-3 Lite was released). I use dhcpv6-pd with them and I think the config is pretty solid. I would do it very similar, if not the same.

It is very close to what @gadams proposed (see above), where the dhcpv6-pd option is added under the interface that gets the delegated prefix. Then, that prefix can be advertised on other interfaces. Important is the possibility to subdivide an assigned prefix into various subnets on different interfaces (using the sla-id option). I think it makes sense to put the dhcpv6-pd under the interfaces, just like normal address assignment falls under an interface. Moreover, dhcpv6-pd and normal IPv6 address assignment can be combined (an IPv6 interface can get a prefix and an address at the same time).

For me personally, I was hoping to start using vyos for my routing/firewall. But without PD it is unusable for me. The alternatives (pfsense, untange, Mikrotik CHR) all have their limitations too. For vyos this feature would be a huge gain.

NPTv6 has nothing to do with PD. It's used to do NAT of IPv6 prefixes.

Can PD be used for nptv6?

I don't know, I just use wide-dhcpv6-client to get the prefix i get from my ISP routed to vyos.

In T421#60971, @danielpo wrote:

I solved this myself by building my own vyos iso and just adding --custom-package "wide-dhcpv6-client". I configured wide-dhcpv6 myself.
It works fine for now.

Works for me ..

[ interfaces tunnel tun0 ]
DEBUG/IFCONFIG cmd 'ip tunnel add tun0 mode gre local 127.0.0.1 remote 1.1.1.1 dev eth0 ttl 255 tos inherit'

I solved this myself by building my own vyos iso and just adding --custom-package "wide-dhcpv6-client". I configured wide-dhcpv6 myself.
It works fine for now.