I want to know the behavior of the implementation when upgrading the vyos version

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

If your device supports virtualization, you can consider running both VyOS and cups servers in KVM (there are many open source projects that can do this, such as Proxmox Ve)

Why install the remote print sharing service on the router and use cups, you must install the printer driver on the cups server to make it work. VyOS is not a general server operating system, so you should install cups on a physical server or virtual server

Where possible, we can consider MBR+UEFI dual boot, which also exists in most distributions

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

@primoz Use the latest rolling version test the day after the merge is submitted

Consider integrating Snort

I mainly have 2 questions:

I mainly have 2 questions:

1. Using DPDK may cause low configuration hardware to fail to install vyos?
2. Is it possible to use DPDK and VPP to cause all services that depend on the system protocol stack to fail to discover the interface?

Maybe this implementation also has a dependency problem, I will fix it in the near future

Sorry, I have changed the repair implementation
PR: https://github.com/vyos/vyos-1x/pull/638

@c-po Please merge this PR, the problem will be fixed directly

I may have to change the configuration priority. Due to priority issues, the settings may fail

@primoz Can you contact me in Slack?

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

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

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

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?

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

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.

Can I restart ping? Can be restored after restart

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 don't know what you mean?

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

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

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

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

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:

LiveCD is usually only used for temporary testing and installation, isn't it? Will using this restriction cause the normal use of livecd to become troublesome?

I am a little confused. What is the specific function of the --allow-cd-boot compilation parameter that this task hopes to add? Forgive me for not seeming to understand!

https://github.com/vyos/vyatta-cfg-qos/pull/8
https://github.com/vyos/vyos-1x/pull/621

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

@c-po This task has been completed for so long, can the PR be reviewed?
PR: https://github.com/vyos/vyos-1x/pull/508

I took a brief look, the ip command seems to support the relevant tunnel type

TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |
           bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |
           gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |
           vti | nlmon | team_slave | bond_slave | bridge_slave |
           ipvlan | ipvtap | geneve | vrf | macsec | netdevsim | rmnet |
           xfrm }

Try to port NDP Proxy to the NAT66 code of T2518 and automatically generate it

Note that because the test requirements are not met for the time being (vyos does not use the linux kernel with a kernel version of 5.8+ for the time being), it cannot be tested well. The merged code has not undergone any testing. Please upgrade the vyos linux kernel to 5.8+ , Let me know that I can perform related tests, and merge after testing

Okay, then I can merge this service into NAT66

I can consider migrating to the implementation of nat66, but I'm not sure if there is a case where the nat66 feature does not need to be enabled, but NDP proxy needs to be enabled

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

@dmbaturin @artooro Come on, remember not to forget NAT46

@c-po I am thinking, although it is not possible to incorporate NAT66, whether we can prioritize how to improve and incorporate NDP Proxy