Yes, it does. thank you

@SrividyaA Can you confirm this is working as you expect?

@a.apostoliuk Can you confirm this is working as expected?

@jvoss thanks to confirm !

PR for op-mode command that fits new cli: https://github.com/vyos/vyos-1x/pull/2408

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

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

Do you have any idea for CLI?

Hi @fernando. I can confirm this behavior is still working correctly after this was merged:

I've tested this issues in our lasted rolling-realese , after last commit , it seems works without problems :

vyos@vyos# load test.conf
Loading configuration from 'test.conf'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@vyos# compare
[policy]
+ route-map TEST {
+     rule 10 {
+         action "permit"
+         set {
+             community {
+                 add "65001:1"
+             }
+             large-community {
+                 add "4200000000:100:1"
+             }
+         }
+     }
+ }

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

Used one of the latest rolling releases.
Configured the Radius server and VyOS

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

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2402

exactly , i'll give an example of what is the improving (or new cli) , we have a policy where we can mach different DSCPs associate with REAL TIME or VIOCE . Current in our cli , it would be something like this :

Using VyOS 1.5-rolling-202310220123.

Checked in VyOS 1.4-rolling-202310030309

LEFT router configuration

So, do you want to add a new syntax to archive the same behavior that we have for qos policy ?

The global state-policy was dropped from CLI.
Close it for now.

this case was resolved lasted configuration done .

this task is a re-definition from a traffic class , I think it could be more clear if we separate tc-filter in a class-map , so we can define different profiles in our cli based on services :

1.5 should not have such issues.
1.4: op-mode should be working as expected. Backport for https://github.com/vyos/vyos-1x/pull/2344 failed. I'll submit PR for 1.4 for such feature.

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

In T5673#162681, @Apachez wrote:

Should debug code really be part of production releases?

Wouldnt it be sufficient that you can enable this on your own if you want a debug build being made?

Should debug code really be part of production releases?

@rayzilt Could you re-check and close it if solved?

@Apachez I suppose it is.

• biosdevname is called by scripts in the initrd, so we can't remove it just yet.
• it's not completely abandoned and had quite a few releases since the point when Vyatta forked it.
• I sent a PR to allow biosdevname to run in VMs (that's the only thing that vyatta-biosdevname has and that's used in scripts): https://github.com/dell/biosdevname/pull/12

I could not find any uses of "slave" in current VyOS versions. If anyone finds any, feel free to start a discussion. VRRP "master" terminology cannot be changed because it's a part of the protocol spec itself, and, as said above, its counterpart is "backup".

The new-style op mode is well-established now, it's time to close the task.

The problem was resolved in the forum. Whether the underlying cause in FRR was resolves is another question...

PR for Saggita: https://github.com/vyos/vyos-1x/pull/2388

PR for 1.5 https://github.com/vyos/vyos-1x/pull/2386