There is the similar task https://vyos.dev/T1518

It fails on the server. I have reproduced the issue in our internal lab. Will share the details.

From my testing, all traffic that originates from an interface attached to a VRF, will show the source interface as the VRF master interface, regardless of the zone attached to that interface. This will make it difficult to segment traffic between interfaces attached to the same VRF. For example:

In T2251#150145, @ganawaj wrote:

This bug is still present in the latest 1.4 rolling release

This bug is still present in the latest 1.4 rolling release

Chiming in here as a 'me too', on vyos-1.4-rolling-202305300317

@zsdc I built the image now, and it works as expected. The issue looks resolved. Thank you.

@dutty can you try to build an image again and check now?

Yes, T4737 looks the same.

In T5243#149267, @Viacheslav wrote:

Maybe the related bug described in T4737
Could you show a version of FRR?

show version all | match frr

In T970#149229, @olivier.hault wrote:

How far are we in the testing of this important feature ?

How far are we in the testing of this important feature ?

Please re-test with latest 1.4 release as the firewall was moved from iptables -> nftables

Does it fail on the client or on the server? I am unable to reproduce this given the instructions above.

In T5186#148568, @diodep wrote:

In T5186#148559, @c-po wrote:

Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.

Is it the same bug as T5048 ?

In T5186#148559, @c-po wrote:

Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.

Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.

Backport for 1.3.3 https://github.com/vyos/vyos-1x/pull/2001

@c-po I guess it should be v5.4.234

In T5186#148294, @rh7819 wrote:

this is cause by

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.4.235&id=7a6fb69bbcb21e9ce13bdf18c008c268874f0480

tcindex classifier is removed by upstream kernel, so

08:04:48 DEBUG - filter add dev eth1 parent 11: protocol ip prio 1 handle 128 tcindex classid 11:a

fails.

this is cause by

It should work for 1.4

set policy route foo interface eth1v1

PR for equuleus:
https://github.com/vyos/vyos-1x/pull/1969

PR for equuleus:
https://github.com/vyos/vyos-http-api-tools/pull/5

@Harliff Could you check it? Available in the latest rolling release

vyos@r14# set  protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 
Possible completions:
   all-available        All targets must be alive
   any-available        Any target must be alive (default)

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

set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 'any-available'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.1'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.11'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check timeout '3'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 interface 'eth0'

That would be great!

In T1237#147125, @Harliff wrote:

Sorry, missed some messages.

In T1237#146586, @Viacheslav wrote:

We have targets-checks 203.0.113.1, 192.0.2.1, and if any of these targets are unreachable, we delete this route.
Is it correct?

It is not correct. I think it would be better to remove the route if ALL of corresponding targets are unreachable.

A target may become unreachable due to a problem of its own rather than an uplink failure. This is the reason why I asked to add multiple targets per uplink.

In T1237#146839, @Viacheslav wrote:

@Harliff Could you re-check?

Sorry, missed some messages.

Thanks for clarifying. Yes , I also saw the possibility of extending role based IAM to add on-premise image (that could be interesting for VyOS).

@fernando

1. In order to apply SSM auto-configuration of the CloudWatch agent, an SSM agent must be installed that installs the CloudWatch agent with the necessary configuration. Currently, there is no SSM agent inside VyOS AWS images, and I haven't heard anything about willingness to include it.
2. The amazon-cloudwatch-agent package has only one dependency, libc6. Therefore, it does not need the aws-cli to be configured or set up at all.
3. Granting access to the CloudWatch service from an EC2 instance is done by applying the corresponding IAM role to the instance. While it is possible to do this via manual credential input, it is an unwanted practice inside AWS.
4. The possible scenario of sending data to CloudWatch out of AWS is unique and requires another Phorge task, I think.

@unity when you need AWS credential , will they be automatically deployed from SSM or will we have to add those credentials in the virtual machine? ? shouldn't aws-cli be integrated?

This was addressed within T4364, and backported in T4874.

I've created the PR https://github.com/vyos/vyos-documentation/pull/987 as a temporary explanation for users on how to preserve CloudWatch Agent configuration in a semi-automated way, using the SSM Parameter Store.

The firewall for ocserv is handled by https://gitlab.com/openconnect/ocserv/-/blob/master/src/ocserv-fw and uses iptables by default

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

@Harliff Could you re-check?

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

In T5153#146789, @Viacheslav wrote:

Could you send sudo nft list ruleset ?

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1952
PR for 1.4 fix https://github.com/vyos/vyos-1x/pull/1953

For 1.4 rate-limit in the wrong place

set vpn pptp remote-access authentication rate-limit

Expected in the radius section:

set vpn pptp remote-access authentication radius rate-limit

Yes, I forgot to add this task. I'll make the PR

@n.fort Could you add PR for 1.3?

@fernando Could you add PR for 1.3?

Could you send sudo nft list ruleset ?

Notice. Initially this task was about monitoring scripts but they were deprecated. Then aws-cloudwatch-agent emerged.
aws-cloudwatch-agent was successfully added to vyos-build:equuleus. But cloudwatch configuration preservation between image updates is not.
This task was closed mistakenly prematurely thus should be reopen.

Targets and logs will be fixed in the next rolling release

Requires some additional work
we need to preserve configuration between upgrade
alternatively, we need to investigate if default config can be used with VM role

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

We have targets-checks 203.0.113.1, 192.0.2.1, and if any of these targets are unreachable, we delete this route.
Is it correct?

Is it possible to implement multiple test targets instead of just one?

Bug: unable to rename a failover route:

@Viacheslav Ok!

@Harliff It is better to write to this task if you find bugs or propose new features.
So anyone could claim/fix it.
Thanks.

@Viacheslav, where is best place to discuss the feature (ask a question or report a bug)?