Well - making all IPv6 stuff a noop is not coded into VyOS. Can you show real life examples of increased attack surface?

it's enabled by default.

It's useful when the user is sure he doesn't want IPv6, as it lessens the attack surface, especially if the user doesn't know he needs to configure a IPv6 firewall separately to the IPv4 firewall. Even link-local addresses can be used to launch attacks in the absence of a firewall config.
IMO the configured interface addresses and v6 nodes should become no-ops, possibly print a warning on commit.
On the other hand, leaving IPv6 enabled, would be better to move in the direction of v6 adoption. Personally, I'd prefer this, and leave v6 enabled by default.

in my opinion it should be always enabled

Actually why do you wan't to disbale IPv6 on the system? I think this is a huge workpackage.

Downloaded the latest rolling, the only thing I have done with the rolling was installing it on a fresh Proxmox VM. I created two firewall groups with the same name - one for address-group and the other is for port-group.

@c-po this is operation commands, as I understand you propose to write py script with return_effective_ , correct?

can you try to reproduce in rolling, please?

Regarding the reference counter for changes. It can also be implemented by storing in an Interface specific class level dictionary the last know state of the interface.
However, should multiple instances of the class be run by multiple programs then this could become problematic and this limitation should be kept in mind.

The recent change in implementation have changed the code from "if/else" to data-driven.
For example, every class now has a "definition" dictionary which indicates what the interface can/cannot do, for example, be bonded or not or it it supports vlan.

Thanks for the quick fix - I was to blind finding it on my own :/

There this three types of functions which as class can have:

• "normal" when the first argument is "self"
• classmethod (using the @classmethod decorator before the function). In that case self replaced from an instance of the class by a reference to the class itself (often called cls, in that case InterfaceClass)
• staticmethod (where the function does not need class data and is jus placed under the class) can be called with InterfaceClass.func()

DFLT_BGP_IMPORT_CHECK can only be set by changing the profile? It can't be set directly? We don't need to change the default timers, just this parameter.

We don't can do it as default behavior.
Frr documentation, frr has profiles

Fix will be in any rolling release after vyos-1.3-rolling-202003270650-amd64.iso

While you are working on this I'd suggest the default behavior to be to check if IGP routes exist by default. The reason most implementations check IGP is described in my initial bug submission along with diagrams. Since advertising unconditionally breaks dynamic routing it may make sense to make this a default.

@jestabro Create it please.

Thanks, @Viacheslav. We will need to add a migration script for the previous setting; that is simple in this case, since, as you observed, it was a no-op, and can just be dropped. If you are busy, I can add it.

@jestabro I fixed commit to

There is a Pull Request available to correct this: https://github.com/vyos/vyatta-cfg-quagga/pull/45

PR for this task
https://github.com/vyos/vyos-build/pull/97
https://github.com/vyos/vyos-1x/pull/274

Add show commands for multicast/igmp/pim

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

Thanks - understood.

also I would remove L107-L109 and move the debug message to the exception handler of L114

I think this throws a exception that isn't caught: https://github.com/vyos/vyos-1x/blob/583e9d907236a4a98fe40e97a378c1fb655f8a95/python/vyos/ifconfig/ethernet.py#L114

root@vyos:~# /sbin/ethtool --show-pause eth0
Pause parameters for eth0:
Cannot get device pause settings: Operation not supported
root@vyos:~# echo $?
76

@thomas-mangin Which commit do you mean, https://github.com/vyos/vyos-1x/commit/60d35d1d4d3a5acec6e39cccb166fd33490b6c27 ?
I can definitely say that did not fix the issue for r8169, the router failed boot after upgrading to 1.3-rolling-202003250217. If there were any patches after that, I can't see them.

Hi jjakob, AFAICS the patch above should have fixed any problem with the ethtool. If not I will need to understand why.

Good catch!

I'm still getting the same behavior on 1.3-rolling-202003250217:

vyos@vyos:~$ show interfaces wireless
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
wlan0            -                                 u/u  
vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces wireless wlan0 disable

Actually I had link-mtu 0 on br0 for a long time now and it worked without problem previously, maybe 0 was a special meaning for radvd?
br0 is the only interface that had ipv6 router-advert, I included one of the eth's for completeness:

interfaces {
    bridge br0 {
        address 192.0.2.1/24
        address 2001:db8::1/64
        aging 300
        description LAN
        firewall {
            local {
                name lan-local
            }
        }
        hello-time 2
        ipv6 {
            dup-addr-detect-transmits 2
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag true
                max-interval 600
                other-config-flag false
                prefix 2001:db8::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        max-age 20
        member {
            interface eth0 {
            }
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth4 {
            }
            interface wlan0 {
            }
        }
        priority 20480
        stp
    }
    ethernet eth0 {
        duplex auto
        hw-id xx:xx:xx:xx:xx:xx
        smp-affinity auto
        speed auto
    }
}

I already hotfixed the issue on mine by adding r8169 into the unsupported list - but as said, that's not the real solution.

@jjakob I had that discussion with @thomas-mangin already - the best solution would be a dynamic probe via ethtool in verify()

Maybe check the physical interface support via ethtool in the ethernet validate() function and raise a configerror if it doesn't? Or should the default be disabled and should a config command be enable-flow-control? The script that actually sets the flow control should definitely just print a warning to the syslog and not fail.

was this was not already fixed ?
https://github.com/vyos/vyos-1x/commit/8f39784c847801c0b766a0c9289da0976ffd0604#diff-ca1457dc16e0b9a43de02cf08140b65aR123