You mean you want QoS based on VLAN which is named 802.1p ?

According to https://community.intel.com/t5/Ethernet-Products/XXV710-V2-NIC-doesn-t-support-quot-ethtool-m-quot-Is-this-a-bug/m-p/730841 you need to:

In T6221#182954, @fetzerms wrote:

I only created a vrf (but did not assign it to anything else). Is that intend to break connectivity?

Thats common with other vendors aswell.

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Personally I dont think its a good idea to be able to use VyOS as a jumphost towards victims of scanning.

I think the wrapping should be left for the output to select since you can either be in a regular serialconsole of 80x25 or some highresmode which brings more characters per line or even through SSH with a 4k monitor which will be plenty of lines.

Since descriptions can be very long I assume there will be a linewrap at the end?

Sure but if the function "port auto-power-down" is mapped to the ethtool function of disabling EEE then it should be safe?

Reopened with status "Known issue" due to revert by PR 3177.

To clearify:

In T6162#180827, @ErnyTech wrote:

In T6162#180826, @Apachez wrote:

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?

This is up to Intel as far as I know

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

Wouldnt PPPoE always assign IP dynamically?

Comparing to other vendors setting the password either in cleartext or as a salted hash (where when saved in config file its always saved as a salted hash - but it will accept a cleartext edition too if you wish that for whatever reason) through the CLI is the standard in NOS.

Also since dynamic and not static IP is being used it would be handy if the DHCP exchange can be captured using tcpdump and do this both on the 1.3 where this works and on 1.4/1.5 where this doesnt work.

Proper would be to throw out chrony and use ntpsec instead which supports proper filtering.

There do already exists tasks regarding commit and boot times such as: https://vyos.dev/T5388

I wouldnt call 1m37s of commit time for a single line of configchange as "resolved"...

Also probably related: https://forum.vyos.io/t/long-commit-time-for-multiple-vrfs/14053

Is this related to the long commit and boot times when one have more than a handful routes or firewall rules as described in https://vyos.dev/T5388 ?

1.3.3 and rolling from 2020?

While at it, whats the configured response time in nginx?

Is "\" really a valid path for bootfile?

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

Instead of that sysrq stuff, how does it work if you try these 3 tests?

If the peer reconnects after the first disconnect - does the local VTI interface go "UP" again?

How do one re-open? :-)

Similar task(s):

While at it having a description for a firewall rule within the firewall itself thats longer than 256 is just "wrong" IMHO aka "you are doing it wrong".

In T5619#177706, @ErnyTech wrote:

Unfortunately I haven't seen this before, for me this choice of using the out-of-tree driver is extremely wrong!

Most of the community's development is done on the mainline kernel driver (where among other things I'm working on sending patches to improve the ixgbe driver), if there are issues in the mainline driver they should be reported or resolved with a patch to be applied in vyos downstream and then send it to the Intel-wired-lan mailing list.

Please @samip537 can you tell me in a short list what exactly problems you encounter with the mainline Linux driver?

Adding https://forum.vyos.io/t/quick-and-dirty-benchmark-of-cores-vs-mhz/13831/ for reference which also concludes that something is off with the commit and boot times of VyOS.

Its mainly a headsup for maintainers to go through the report and fix whats possible.

Its not clear if its fixed or not:

Same as with https://vyos.dev/T5619.

Related?

Again, notifing upstream (or downstream) is not only about VRRP.

GARP is needed for VRRP but the GARP setting is also needed when doing NAT.

Logrotate just renames the logs so that doesnt bring many writes.

Personally I would prefer that the "automagic" firewall ruleset would be done optionally through method described in:

Another good thing is that any logging can be done without spoling the user/pass which otherwise is the case with todays oneliner approach.

Could for example be that set system options logtoram enables the feature while set system options logtoram size 32M sets the desired size where the default is 32M or whatever would be needed as a sane minimum.

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

How come partprobe fails but not partx?

Having support for vhost is handy when you dont want just to blindly share a single documentroot but have the ability to use multiple at a single host.

Hopefully this can be resolved for VyOS 2.0 in the future...

Hopefully this can be resolved for VyOS 2.0 in the future...

Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?

You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?

Related to the list provided in https://vyos.dev/T5706 ?

Instead of "TEST-NET-X" and "TEST-IP-X" it could use "REPLACED-NET-X" and "REPLACED-IP-X" or such (where X defines the unique item thats being replaced).

I think its a bit odd to completely disable EEE where the solution would be to disable EEE by default but having the config option to adjust for EEE if wanted.

Also while at it, the smoketests regarding UPnP should probably be updated by this task aswell since they claim everything is OK:

Wouldnt this rather be a task for secure60 to add compatability to parse and understand snmp and syslog received from a VyOS device?

"hw-id" should define which physical interface is mapped to which ethX VyOS interface.

Wouldnt this break things with compatibility with other vendors?

I agree, even if its "odd" at first sight I like that all interfaces are named ethX within VyOS and then its a matter to map each to physical interface by hw-id (which is done automagically during first install but can be remapped if wanted).

Does all the interfaces at bananapi represent a hw-id which can be used to map to the ethX syntax of VyOS?

The fear of having the HTTP-API part of nginx compromised by another virtualhost config (as in they are sharing the same process) should be overcome by having a dedicated config file and start a 2nd nginx process.

I would vote for that (using nginx as backend since it already exists).

Instead of "file-server" I think "http-server" would be a better name or even "web-server" in this context.

Verified with VyOS 1.5-rolling-202311081451.

I would mainly want to log new conntrack entries for various reasons.

Do you have any example of in which context that exists?

In that PR, shouldnt also ifb* be included?

Shouldnt dummy* and some others be excluded aswell?

@shthead: Im talking about features in VyOS. I dont care what others such as Juniper does or doesnt do.

@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:

Both single-active and all-active should be supported when it comes to EVPN Multihoming.

Original template /usr/share/vyos/templates/chrony/chrony.conf.j2 (just the allow and listen sections):

Turns out that the output of bindaddress will be broken unless put in a loop even if a single entry the only allowed entry.

Since the root cause for this task have been identified and fixed by the reporting user (and the task is set to invalid) I have created another task for the spinoff regarding cleaning up of the template used by chronyd:

As it seems according to https://manpages.debian.org/bookworm/chrony/chrony.conf.5.en.html both bindaddress and binddevice can only be specified once.

Ahh yes, I think there is another task in here regarding adding firewall rules by default to the firewall to avoid situations like this :-)

I added the above modifications to /usr/share/vyos/templates/chrony/chrony.conf.j2 and rebooted VyOS 1.5-rolling-202310240118.

I havent been using ninja2 scripting previously but Im guessing something like this would be needed:

Here is the output of sudo ls -la /run/chrony (just booted up so drift will probably missing for some time):

Any docs or example on how bfd interacts with pim?

PR created: https://github.com/vyos/vyatta-op/pull/79

PR created: https://github.com/vyos/vyatta-op/pull/79

How is your current ntp configuration (as outputed by show config commands)?