@bbs2web, here's what I got...

@bbs2web, getting this one (https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202012070521-amd64.iso) and will troubleshoot...

That's a little unclear to me. If the interface is defined but doesn't yet exist, then it needs to be created. A brief look at the code makes it seem like it always creates new interfaces with type=monitor.

I guess the best thing would be to not add this interface at all

Thanks for the quick fix!

@primoz Delete the old one, create a new bridge after commit, and then commit. Can it work normally?

it's an edit + delete/delete/delete ... no creation (at least in my edge case).

Important note on this PR - in order to build the GCC plugins which perform most of the self-protection work, the Docker container needs gcc-8-plugin-dev installed. Otherwise it builds, but silently downgrades the configs dropping RANDSTRUCT/STACKLEAK silently.
Pulled RSBAC out for now (issues with building the rest while its in there but disabled), validated builds with and without the plugins package for GCC8.

Installed 1.3-rolling-202012060217 yesterday and the VLAN interfaces don't appear to get MPLS enabled. I essentially removed the following lines, which work as expected when present:

set system sysctl custom net.mpls.conf.eth0/11.input value '1'
set system sysctl custom net.mpls.conf.eth0/13.input value '1'
set system sysctl custom net.mpls.conf.eth0/14.input value '1'

@c-po Does the deletion of the bridge occur after the new bridge is created or before?

Added an inert patch (disabled in Kconfig) for https://www.rsbac.org/ on 5.4. This can be used to significantly harden the restrictions intended by the CLI to limit users to specifically defined roles, same goes for applications/containers.
If adding container support to VyOS is still on the roadmap, we're going to want to take extra care to enforce the boundaries between them and the host since real world use cases are pretty much guaranteed to leave old vulnerable containers running on long-running network appliances making for a variable and worsening attack surface over time.
This isn't quite as integrated and doesnt provide nearly the coverage as what you get with grsec+pax, but a rough approximation of "role-based FS restrictions and runtime hardening" is now in the pull request along with the other stuff which seemed pertinent for upstream.

Thank you sir. Worked through a clean build, updated patches, rebased, and pushed.

As it looks to me (but i'm not sure yet), the configuration system is fixing devices one by one and was trying to add port into new bridge before the old bridges were removed (and so ports were still in them). If this is the case ... not sure that there even exist an easy fix.

OK, the latest PR can be tested. I just tested the basic functions and the effectiveness of the migration script. But I haven't submitted the PR of vyatta-cfg-system

Okay, debugging with @jack9603301 showed that there was/is an issue. If you are running DHCP client on the interface which is using mirroring, this indeed becomes an issue as traffic is dropped until the session is re-established.

In the latest PR implementation, eth0 will shake at the moment when the eth0 configuration is changed, but it seems to be restored immediately

Do you have any good fixes?

first delete original, commit, then new and final commit.

You mean, if you submit it in 2 steps and configure it separately, it works fine?

For some reason ... nothing in logs:

It works nicely with VXLANs ... no problems there. You can use it like this to get local port into vxlan (without this, vxlans become useless). I have problems with bond interface (everything else works). Debugging now.

In the test topology, the same situation was found in the mirror test of pppoe0

I am a little doubtful whether this is in design, and whether there will be a short-term up to down to up conversion when the interface is modified.

Of course, restarting ping works, but all flows in transit will stop, this is not what you wan't on an edge device running 10GBit/s of traffic

Can I restart ping? Can be restored after restart

Running VyOS 1.3-rolling-202012060217 immediately when I enable port mirroring all sessions are dropped on this link.

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Logically speaking, any interface that can be added as a member interface when setting the bridge interface should be fine. bridge vlan applies to any member interface, but I don’t know why it is sometimes possible and sometimes not. I need More information to determine the problem (since there is a situation that can be set successfully, and no abnormality is reported, then the setting should be successful, WLAN is not working because the WLAN bridge is set by hostapd)

I wonder if this configuration should be possible at all. In my opinion native-vlan and allowed-vlan should be supported only on bond and ethernet interface types

Taking the following configuration as a pool serving relays:

Put in a new PR to enable LDP local label allocation control.

I don't know what you mean?

Disable downgrades in general is a bad idea. We still can leave the user with a broken config on downgrade but prevent it is bad. Imagine a very simple config, that would be downgradable.

successfully tested on the self-build image from crux branch and the latest rolling image

Before that, should we consider completely migrating the vyos firewall implementation?

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

yes, specifying "ipv6" has the same effect as "ipv6 enable"

Do I only need to execute the following commands when I want to start ipv6?

Not sure that it makes sense to downgrade the image from 1.3 to 1.2.
Because there are also no migration "downgrade" scripts.
I propose to add an additional check and disable downgrade images for "add system image".

Still old format for completion help

To clarify the fault here. the smoketest is looking for the word "Config()" inside all conf_mode scripts without taking into account that this could be part of another name. the patch above modifies the behavior to not mat when a alpha-character is in front of the C in Config.
full regex: [^a-ZA-Z]Config\(\)

PR https://github.com/vyos/vyos-1x/pull/632
fix regex in smoketest.

Thanks, @c-po , works as expected.

vyos@vyos:~$ show  lldp neighbors 
Capability Codes: R - Router, B - Bridge, W - Wlan r - Repeater, S - Station
                  D - Docsis, T - Telephone, O - Other

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

Calculating setting is always the smartest idea. I also have a WIFI6 NIC with me, the problem is it is not supported by Linux 4.19. which we currently are forced to use.

It seems related to this patch https://github.com/vyos/vyos-1x/commit/b39d623170377b2e99fd7e88b627afea71e4d00c#diff-e4557e4a7b41f0e9328ac0e7d7c0305416f0f1e42d46af27c2135ca976434fce
Appears only if you have 2 or more lldp neighbors.

Cool let me know if you still need my config

Ok, with cisco device and added vif 1 I can reproduce this issue

vyos@vyos# run show lldp neighbors 
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/lldp_op.py", line 121, in <module>
    config_text = tmpl.render(parse_data(neighbors))
  File "/usr/libexec/vyos/op_mode/lldp_op.py", line 50, in parse_data
    for local_if, values in data.items():
AttributeError: 'list' object has no attribute 'items'

I still can't reproduce this issue.

vyos@vyos:~$ show configuration commands | match lldp
set service lldp interface eth1
set service lldp legacy-protocols cdp
set service lldp management-address '192.168.255.31'
set service lldp snmp enable
vyos@vyos:~$ show lldp neighbors 
Capability Codes: R - Router, B - Bridge, W - Wlan r - Repeater, S - Station
                  D - Docsis, T - Telephone, O - Other

It looks like the issue is CDP. If I remove the CDP piece of the config then it works.

I just upgraded to the absolute latest rolling release that came out early this morning and it has the same issue.

As far as I know, you only need to work in the vyos-1x repo

I just tried the show lldp neighbors again and it doesn't work but sudo lldpcli show neighbors works

mlaney@vyos:~$ sudo lldpcli show neighbors

LLDP neighbors:

Interface: eth1, via: CDPv2, RID: 1, Time: 0 day, 08:19:01

Chassis:     
  ChassisID:    local Cisco-Sw1.local
  SysName:      Cisco-Sw1.local
  SysDescr:     cisco WS-C2960S-48LPS-L running on
                Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 15.2(2)E9, RELEASE SOFTWARE (fc4)
                Technical Support: http://www.cisco.com/techsupport
                Copyright (c) 1986-2018 by Cisco Systems, Inc.
                Compiled Sat 08-Sep-18 14:56 by prod_rel_team
  MgmtIP:       10.22.87.254
  Capability:   Bridge, on
Port:        
  PortID:       ifname GigabitEthernet1/0/9
  PortDescr:    GigabitEthernet1/0/9
  TTL:          180

Interface: eth1, via: CDPv2, RID: 1, Time: 0 day, 08:18:47

Chassis:     
  ChassisID:    local Cisco-Sw1.local
  SysName:      Cisco-Sw1.local
  SysDescr:     cisco WS-C2960S-48LPS-L running on
                Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 15.2(2)E9, RELEASE SOFTWARE (fc4)
                Technical Support: http://www.cisco.com/techsupport
                Copyright (c) 1986-2018 by Cisco Systems, Inc.
                Compiled Sat 08-Sep-18 14:56 by prod_rel_team

Here is my lldp config. ETH0 is WAN ETH1 is lan that is why only eth1 has lldp enabled.

maybe it happened after that commit https://github.com/vyos/vyos-1x/commit/c87ad948999c28c3c9449f98d60b545481ea29d5
because it was work in VyOS 1.3-rolling-202011250217

Hi, guys, I found an interesting script in frrouter's github repo. In fact, this is purely because someone wrote a script and submitted the following bug report:

@thadrumr please provide your lldp configuration. show configuration commands | match lldp
I can't reproduce this issue in lab with the latest rolling. Provide please detailed reproducing steps, also will be helpful to get an output

sudo lldpcli show neighbors