I've been testing , now we are able to configure BMP with load configuration .in latest version 8.2.2(they solved these issues)

Yes it is, although PR https://github.com/vyos/vyos-vm-images/pull/25 then caused some new issues but I just now reported those in T4278

@higebu it looks like PR https://github.com/vyos/vyos-vm-images/pull/25 caused some new issues (I use the qemu.yaml build). First:

fatal: [localhost]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'enable_dhcp' is undefined"}

I propose to use this in the template (same for enable_ssh):

{% if enable_dhcp | default(True) %}

Or alternatively define those variables in all playbooks.

Sure, but its not being applied in the pdns recursor so I cant use static host mapping for ipv6 in my network, only locally on the vyos host. (It works fine with ipv4).

@hakwerk . Is this solved in PR https://github.com/vyos/vyos-vm-images/pull/24 ??

Splitting ipv4 files, and just adding what needed. In my case, I extracted content from geoip-ipv4.nft and create and include file geoip-CA-ipv4.nft (Canada IPs)

Perhaps only in-use sets can be determined and loaded?

After some custom build and POC, here's what I got:

• Filtering works, as shown in this table:

@SrividyaA Thanks !!!!

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

Thanks, Not really sure what happened, but I deleted config.boot and rebooted, Now it works to add a policy again.

Error implies that firewall failed to configure on boot as mangle table is missing. Any logs/config trace from boot?

Can you share configuration that you are deleting? So far, I can't reproduce error

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

My guess, looking now at commit logs, is that T4250 broke this. It looks like we attempted to move the settings to system logs, but the rsyslog part of the config still remains in system syslog, where the default does not match the new logrotate template (and the settings between rsyslog and logrotate can get out of sync).

Note: Equuleus still uses the C preprocessor. // substrings (otherwise interpreted as comments) were escaped as \/\/ in op-mode-definitions/generate-public-key-command.xml.in in Equuleus and should be converted back eventually.

Hi all,

FRRouting Release 8.2.2 was relased, when we will see this implemented?

The same issue with set interfaces bonding bond0 arp-monitor interval 'X' option. Also extra conversion between variable types.
Added the fix to the same PR.

Fixed in https://github.com/vyos/vyos-1x/pull/1249

The PR is merged with the wrong Task number. This can be closed.

IKEv2 has a different working behavior compared to the IKEv1. IKEv2 provides proper inline rekeying of IKE SAs by use of CREATE_CHILD_SA exchanges. This means that new keys may be established without any interruption of the existing IKE and IPsec SAs.

Update download URL -> PR: https://github.com/vyos/vyos-vm-images/pull/26

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

PR for 1.4: https://github.com/vyos/vyos-1x/pull/1247

Fixed for both 1.3 and 1.4.

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

You are correct, my config is not correct.

emmm, I know it.

In T4288#119770, @chesskuo wrote:

I found the swanctl.conf.
The config does not match the vyso config.

I set the close_action as restart, but config does not show this line.

Your configuration should be like:

A simplified validator that rejects non-ipv6 address range (still lacks of 1st ipv6 minor than 2nd address validator):

Re-open to investigate failure in vyos-configtest.

Re-open to investigate failure in vyos-configtest.

Re-open to investigate failure in vyos-configtest.

For 1.4, problem is in ipv6-range validator, which accepts lots of values that should be considered as invalid:

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

Actually, let's leave it in 1.3 but backport the warning and generate public-key-command.

@zsdc Do you have any idea for CLI configuration mode?

Hello sir, thank you !!!

Could you try to use "ikev2"? Will the same problem be if you use "ikev2"?

Similar situation in VyOS 1.3-stable-202202191602

system seems to be able to process flow data now and im seeing the flow data (netflow and sflow) reach my destination pathed via flow location, appears to work now!