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
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 featuresThen 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
Im guessing that what this task complains about has a huge part of the time it takes to complete smoketests.
PR updated (again): https://github.com/vyos/vyos-1x/pull/2280
Hello @sdev Sorry to bother you. The issue hasn't been fixed in the recent rolling release: VyOS 1.5-rolling-202309170024
PR updated: https://github.com/vyos/vyos-1x/pull/2280
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)?
PR for latest: https://github.com/vyos/vyos-1x/pull/2281
PR for Equuleus: https://github.com/vyos/vyos-1x/pull/2282
PR created: https://github.com/vyos/vyos-1x/pull/2280
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.
Using VyOS 1.5-rolling-202309170024.
So what remains is how to solve point 1.
It looks like point 3 can be taken care of:
r4# show version FRRouting 9.0.1 (r4) on Linux(6.1.53-amd64-vyos)
Still has bugs
For example with redistribute
r4# conf t r4(config)# router eigrp 65001 r4(config-router)# redistribute connected % Configuration failed.
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?
Cannot pass the smoketest:
DEBUG - ====================================================================== DEBUG - FAIL: test_01_dyndns_service_standard (__main__.TestServiceDDNS.test_01_dyndns_service_standard) DEBUG - ---------------------------------------------------------------------- DEBUG - Traceback (most recent call last): DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_service_dns_dynamic.py", line 82, in test_01_dyndns_service_standard DEBUG - self.assertIn(f'use=if', ddclient_conf) DEBUG - AssertionError: 'use=if' not found in '### Autogenerated by dns_dynamic.py ###\ndaemon=300\nsyslog=yes\nssl=yes\npid=/run/ddclient/ddclient.pid\ncache=/run/ddclient/ddclient.cache\nweb=googledomains use=no \n # Web service dynamic DNS configuration for cloudflare: [cloudflare, test.ddns.vyos.io]\nusev4=ifv4, \\\nifv4=eth0, \\\nprotocol=cloudflare, \\\nzone=vyos.io, \\\npassword=paSS_@4ord \\\ntest.ddns.vyos.io' DEBUG - DEBUG - ---------------------------------------------------------------------- DEBUG - Ran 4 tests in 11.489s DEBUG - DEBUG - FAILED (failures=1)
Testing point 2 above with VyOS 1.5-rolling-202309170024.
I think this broke a whole lot of things for RADIUS users (these work fine in 1.4-rolling-202308040317, but are broken in 1.5-rolling-202309170024):
This is the one I was thinking of:
This seems to have been resolved since a few days (1.5-rolling nightly).
PR for sagitta https://github.com/vyos/vyos-build/pull/415
@Apachez The empty table inet vyos_offload is to ensure the table exists before deleting its content. Regarding hardware offload, I don't have a hardware supporting that. The implementation is totally based on documentation and I don't add any checks before applying the nftables config.
Output of ps auxww | grep -i frr after proposed v3 is applied:
Update of proposed changes (Ill call them proposed v3).
Update of proposed changes (Ill call them proposed v2).
If we alter the Jinja2 file we should also update the syntax - just ospf an example but its valid for all other SNMP stuff:
mgmtd can not be disabled. It's a mandatory FRR process.
I can create a PR if everyone agrees upon the proposed changes above however I have limited capability to test each and everyone of these changes.
Proposed data/templates/frr/daemons.frr.tmpl:
Fixed in PR: https://github.com/vyos/vyos-1x/pull/2276
PR created: https://github.com/vyos/vyos-build/pull/414
PR created: https://github.com/vyos/vyos-build/pull/413