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

PR removing zone-policy op-mode: https://github.com/vyos/vyos-1x/pull/2304

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

Op-mode command reduce
PR https://github.com/vyos/vyos-1x/pull/2302

vyos@r4:~$ show conf com | match firew
set firewall ipv4 input filter default-action 'accept'
set firewall ipv4 input filter rule 1 action 'accept'
set firewall ipv4 input filter rule 1 description 'Allow loopback'
set firewall ipv4 input filter rule 1 inbound-interface interface-name 'lo'
set firewall ipv4 input filter rule 1 source address '127.0.0.0/8'
set firewall ipv4 input filter rule 2 action 'accept'
set firewall ipv4 input filter rule 2 description 'Allow established/related'
set firewall ipv4 input filter rule 2 state established 'enable'
set firewall ipv4 input filter rule 2 state related 'enable'
set firewall ipv4 input filter rule 60 action 'accept'
set firewall ipv4 input filter rule 60 description 'Allow SSH from trusted networks'
set firewall ipv4 input filter rule 60 destination port '22'
set firewall ipv4 input filter rule 60 protocol 'tcp'
set firewall ipv4 input filter rule 10000 action 'drop'
set firewall ipv4 input filter rule 10000 description 'Drop everything else'
vyos@r4:~$ 
vyos@r4:~$ produce firewall rule-resequence start 10 step 10

PRs:
https://github.com/vyos/vyos-1x/pull/2298
https://github.com/vyos/vyatta-op/pull/71
https://github.com/vyos/vyos-build/pull/419

Oops, sorry about that!

@Apachez It is not FQDN based

Should I ask this to you.

In T5601#160566, @vvinci00 wrote:

Hello,

I need to reverse proxy TCP traffic.
the traffic is not HTTP/HTTPS

Contact our sales or ask forum

It's possible to use VyOS as reverse proxy on TCP traffic (not HTTP)?
if yes, what configuration it's necessary?
if not, do you know any solutions that can help me?

In T5601#160566, @vvinci00 wrote:

Hello,

I need to reverse proxy TCP traffic.
the traffic is not HTTP/HTTPS

I need to reverse proxy TCP traffic.
the traffic is not HTTP/HTTPS

set netns name mgmt
set interfaces virtual-ethernet veth1 address '10.0.0.0/31'
set interfaces virtual-ethernet veth1 peer-name 'veth10'
set interfaces virtual-ethernet veth10 address '10.0.0.1/31'
set interfaces virtual-ethernet veth10 netns 'mgmt'
set interfaces virtual-ethernet veth10 peer-name 'veth1'

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

set system sysctl parameter net.ipv4.tcp_syncookies value '1'
set system sysctl parameter net.ipv4.tcp_timestamps value '1'

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

You do not use port 80/443, so it does not have HTTP-HEADER (in theory).

service LB_port_451 {
    listen-address 10.1.1.1
    mode tcp
    port 451

Try to change to port 80 and check if it works.
You need another solution/configuration

Some highly unscientific tests (only did 3 reboots of each to rule out that any uncached data at the host would affect the result since I run this in a VM through VirtualBox 7.0) shows a difference of up to 2.1% improvment when having a config with 200 static routes.

Parent task is completed - Bugs will get their own subtask and linked to this parent if possible.

This should fix the hostname issue reported to BGP neighbors: https://github.com/vyos/vyos-1x/pull/2289

In T4502#160404, @Apachez wrote:

Perhaps a possible way to detect if the nic supports hardware flowtables or not.

Try to set sudo ethtool -K eth0 hw-tc-offload on.

If the result becomes:

Actual changes:
hw-tc-offload: off [requested on]
Could not change any device features

Then it doesnt support hardware flowtables.

Could also verify by reading the capability like so:

$ ethtool -k eth0 | grep hw-tc-offload
hw-tc-offload: off [fixed]

Perhaps a possible way to detect if the nic supports hardware flowtables or not.

Some feedback from the #netfilter channel over at libera.chat:

I got some funny results which I hope somebody else (with a faster cpu) are able to verify?

First tests unsecseful

PR https://github.com/vyos/vyos-build/pull/416

Im guessing that what this task complains about has a huge part of the time it takes to complete smoketests.

Hello @sdev Sorry to bother you. The issue hasn't been fixed in the recent rolling release: VyOS 1.5-rolling-202309170024

In T5586#160073, @Apachez wrote:

How does FRR/vrrpd work regarding SNMP compatability?

Im thinking if the keepalived could be replaced in favour of FRR/vrrpd?

And for now keep keepalived around only for virtual-server (unless that too can be dealt with by FRR/vrrpd)?

I will put this as "wontfix" because a fix would need additional work of stopping/starting correct FRR-service (if this occurs in future then this task can be reopened).

I will close this task as a duplicate of https://vyos.dev/T4502 where work is in progress.

Added PR https://github.com/vyos/vyos-1x/pull/2278 for smoketest fix.

Ok, I was thinking if that then waited for some password or such.

I haven't tried anything else since I rebooted back into 1.4, but I did try sudo su - which gave the same error.

How does a simple "sudo bash" work?