The issue here is that "set protocols ospf default-information originate" propagates a default route even if there is an inactive route for 0.0.0.0/0. It should only propagate if "always" is used. So, maybe the inactive route is not in the routing table (in the routing sense) but it seems to be taken into consideration for redistribution.

Docuemntation from: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-tool_reference-tuned_adm

Imagine if you use for example BGP and don't have a default route or set it to blackhole.
Then you originate the default route for a neighbor.
Why it should not announce the default route to the neighbor?

This is expected behavior, so routes not installed in the routing table.

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

Sure—if you want to drop me an image I can try it out. I do have a working vyos-build as well, I can also try and produce my own with that change backed out when I get some time towards the end of the week.

@lucasec of course this commit could be related and we can try revert back to the old version. Would you be willing in testing a binary for us?

Put in a PR to add miscellaneous MPLS and LDP parameters.

I will perform a few additional tests tomorrow with the oldest available rolling releases (looks like October 13th as of writing). Will see if I can binary search my way to when things broke.

A few updates... the failure still occurs on latest rolling. Similar outcome—the kernel panics and dumps a stacktrace during the initial boot-up configure process. However, this issue goes back further than I expected (and initially expressed in the ticket). I goofed up in my testing of 1.3-rolling-202010260327 by booting with a default config file without the QAT option.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.

Put in a PR to add targeted LDP neighbors.

as we rely on OpenNHRP this looks like a dead end as of now. Maybe IPv6 support will get introduced and supported when we can migrate to FRR based NHRP - there is another task about that (T2326).

for reference:
my PIM config for allowing multicast from eth1.112 to eth1 (10.10.10.10 is a fictional ip):

show protocols pim 
 interface dum0 {
 }
 interface eth1 {
 }
 interface eth1.112 {
 }
 rp {
     address 10.10.10.10 {
         group 224.0.0.0/4
     }
 }

terminating watchfrr and pimd has solved the problem.
With my configuration everything was OK...

Your referenced commit is only relevant for validation logic if your hardware supports QAT or not. We now run Kernel 4.19.155 - please retry with the latest rolling release.

@tuxnet maybe this will help: https://docs.vyos.io/en/latest/routing/multicast.html

@christophedc0 Could you provide me with your pim configuration? i am not getting any further

set interfaces ethernet eth2 dhcp-options no-default-route

Available via set interfaces ethernet eth0 dhcp-options host-name

Issue is fixed in the latest rolling release. The IPv4 remote-host hostname in client mode works without adding the option '--proto udp4'.
Tested in VyOS 1.3-rolling-202011060217

Problem is the constraint statement in https://github.com/vyos/vyos-1x/blob/current/interface-definitions/include/nat-address.xml.i where ipv4-range returns 0 instead of 1.

See T3051 "OpenVPN: multiple client routes do not work in server mode" for follow up

I want to have native-vlan and allowed-vlan

Perfect! Then please share your full OpenVPN config so the issue can be recreated and fixed properly.

Until version 1.3-rolling-202010280217 it still worked.
I have not changed the configuration...

Can you please check if this used to work in older VyOS versions, e.g. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202010151549-amd64.iso or share your config and a network diagram.

Sure, no worries. We still have a *ton* of work on 7.3.1 to do so I'm sure we'll get to 7.5 in time :)

AWS hosted ntpd instances:
us-east-1 - 34.206.168.146 ipv6 2600:1f18:1632:5f01:3ee9:8db5:3a01:4018
eu-central-1 - 18.193.41.138 ipv6 2a05:d014:89b:f501:c695:7709:5430:16a1
ap-southeast-1 - 122.248.201.177 ipv6 2406:da18:cdf:e900:9420:6c3:f3:7abc

Neet to retest, the related task T2100

Not sure if it's relevant or not, but I think 7.5 was released....we might be able to just leapfrog 7.4 and go directly to 7.5 instead.

Put in a PR to add session hold time for static LDP neighbors.

now it works.
there seems to be another problem, the communication only works point to point, no routed traffic arrives on the opposite side.

Put in a PR to add TTL security for static LDP neighbors.

it sounds good to me.
I personally think the days with manually locking nic queues to cpu's is a bit outdated and we need something more dynamic.
After reading a bit on tuned i give my thumbs up

Hey, it seems that the big trouble now is the difference in the definition of the command line. If possible, I agree to conduct a survey to see your opinions.

@c-po i agree with using "native-vlan", but i dont agree on using "allowed-vlan".
"allowed-vlan" for me it dosn't actually describe that this vlan will be tagged on the port

Please try again with the next rolling release.

OK, I understand, PR has been updated

As I'm raised by A vendor starting with C and now switched to another vendor starting with A they both reference the function as native-vlan and allowed-vlan - this makes it easier for users which operate cross-platform.

set interfaces bridge br0 member interface eth0 allowed-vlan 2,4-9
set interfaces bridge br0 member interface eth0 native-vlan 101

The following writing methods can currently be used, such as:

I really like the idea of this interface and alwaysed watned to implement it - but I lacked of time, so first thank you @jack9603301 for picking this up.

It seems to be the same as the task list, but my basic realization is basically completed, see:

If two different vlan processing methods are not used for the same interface, then the two are not currently in conflict, unless the user sets vlan filter and eth0.10 on the same interface at the same time

I wonder what happens if I have a eth0.10 bridge member interface? Also what should happen when the user jas eth0 and eth1.10 bridge members? should this feature still work or is it exclusively only for native non vlan interfaces?