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

Let the responsible person of T2859 take care of it. I have not been able to see the problem from the information you provided for the time being. If you are familiar with python and linux, you can consider troubleshooting by yourself to try to find the problem. If not, just ask Maintenance personnel reproduce the fault

@c-po I have changed the PR to prohibit WLAN ports from joining VLAN-aware bridge ports

Contains 2 patch submissions

This patch changes the settings and does not modify the vlan filter settings when VLAN awareness is not set, but the root cause of different problems is that the following code does not set the wireless port to the bridge normally:

Strange, the problem seems to be that the interface has not been added to the bridge. I may submit a patch about VLAN awareness to refuse to operate the vlan filter setting without enabling VLAN awareness, but I am not sure whether it has any Relationship, manual operation is normal:

Whether the VLAN aware bridge is activated?

Please execute and analyze the following command to return the result, and carry out fault exploration, if possible, please output the result

Is there no NAT policy?

I'm curious about how to do ERSPAN?

If you do not change show int, you can output the specific information of vlan id in the command show interfaces bridge vlan

Now there is a new plan, please see T3071

Now there is a new plan, please see T3071

@runar The latest image already supports VLAN aware bridge, so this task list can be closed

Request merge PR:

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