I'm marking this task as resolved, since it's been in 'Needs Testing' status for more than 6 months

I'm marking this task as resolved, since it's been in 'Needs Testing' status for more than 6 months.

We will not update FRR to 8.x for 1.3 LTS releases.

Closed for 1.3 too, because FRR version used in 1.3 doesn't support the feature

@icyfire0573 Can you re-check if nat op-mode commands works for you?

Marking as invalid, since firewall cli should move to a more organized and flexible cli strycture.

Thanks, @dex, agreed that this is misleading: this will be refined once the PR
https://github.com/vyos/vyos-1x/pull/2079
is merged.

@zoenan7 have you managed to report to upstream?

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

@zsdc was this ever backported to 1.3?

@sdev, so what is the state of this?

Closing this task since it has been in "Needs Testing" status for more than one year, for both 1.3 and 1.4 projects.

Once we move to new firewall and re-work on mangle/PBR, this could be achieved easily.

Working on latest build:

As said in previous comments, login banner is available, both on 1.3 and 1.4
I think this task can be marked as resolved

Possible duplicate? https://vyos.dev/T4190

Perhaps this request should be moved to the forums or somewhere a sysadmin can be reached for assistance?

well , I've had an idea how to make a workaround , I've used explicit-null label to add next-hop from the network-address connected sudo ip route add 10.0.0.1/32 encap mpls 0 via 10.0.0.2 dev eth1

I've done extra test , I confirm this behavior is associated transport label that can't be allocated when using interfaces directed connected to created ldp session without IGP protocols(ospf/isis) . let's see what is going on :

Jump action is available in 1.4
Then, I'm setting this task as resolved

There are several issues mentioned in this task so far, and they will be separated out to respective tasks. Firstly, we will address an obvious bug in the implementation that misnumbers entries in the commit log compared to archived commit files ...

During installation, this happens: https://github.com/vyos/vyatta-cfg-system/blob/bac61854acd40b4eae8b12e47be54306171f5c3c/scripts/install/install-image-existing#L201C3-L201C3

@trae32566 Thanks I can confirm it is a bug with using commit-archive location, there is a separate task https://vyos.dev/T5348
Thanks

As shared with @Viacheslav , I see the following on a 1.4 VM, built last week:

@Viacheslav So I figured out what's causing it..it looks like for some reason my commit-archive configuration on the secondary side (which works fine normally) is causing the hanging. As soon as I remove the set system config-management commit-archive on the secondary side, everything starts working fine, even with my full firewall configuration. Has this been tested at all with commit-archive? Could there be some sort of bug happening with it? Here's the section of the secondary side config, for reference:

[system config-management]
- commit-archive {
-     location "sftp://<someUser>:<somePass>@stor01a-rh9.int.trae32566.org/int/cr01b-vyos"
-     source-address "fd52:d62e:8011:fffe::3"
- }

Yeah I tried increasing the timeout to the maximum (300) and it still timed out, but I'll try config-sync mode 'set' I guess. The config is fairly large; 549 lines of just set firewall.

In T775#151897, @trae32566 wrote:

@Viacheslav I'm not sure why, but it appears that after doing this, there is high CPU usage on the secondary side, and eventually it stops responding entirely (bgp sessions go down, no response to anything via icmp) and has to be hard reset; it won't even respond to a console login attempt:

This makes me think something in my firewall configuration is making it unhappy. I can paste my full firewall config somewhere if you'd like, but I'd prefer if it's not public for security reasons (is email fine?).

@Viacheslav I'm not sure why, but it appears that after doing this, there is high CPU usage on the secondary side, and eventually it stops responding entirely (bgp sessions go down, no response to anything via icmp) and has to be hard reset; it won't even respond to a console login attempt:

In T775#151894, @trae32566 wrote:

@Viacheslav I think that fixed it...sorta. It looks like now it does sync successfully, though it appears to time out after awhile for some reason:

trae@cr01a-vyos:~$ configure
[edit]
trae@cr01a-vyos# set firewall name INT_TO_LOCAL rule 80 destination address 192.168.253.2-192.168.253.3                                                                                                                                                                                                                    
[edit]
trae@cr01a-vyos# commit
INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=cr01b-vyos.int.rtr.trae32566.org

An error occurred: HTTPSConnectionPool(host='cr01b-vyos.int.rtr.trae32566.org', port=443): Read timed out. (read timeout=60)
ERROR:vyos_config_sync:An error occurred: HTTPSConnectionPool(host='cr01b-vyos.int.rtr.trae32566.org', port=443): Read timed out. (read timeout=60)

That being said, it does appear to have set the config on the other side:

trae@cr01b-vyos# show firewall name INT_TO_LOCAL rule 80
 action accept
 description "API access"
 destination {
     address 192.168.253.2-192.168.253.3
 }
 protocol tcp
 source {
     address 192.168.253.2-192.168.253.3
 }
trae@cr01b-vyos# cat /var/log/nginx/access.log 
fd52:d62e:8011:fffe::2 - - [09/Jul/2023:09:54:23 -0500] "POST /configure-section HTTP/1.1" 200 80 "-" "python-requests/2.28.1"
fd52:d62e:8011:fffe::2 - - [09/Jul/2023:09:55:25 -0500] "POST /configure-section HTTP/1.1" 499 0 "-" "python-requests/2.28.1"

Also, If it's any easier / you'd prefer I can set up a Webex or something.

@Viacheslav I think that fixed it...sorta. It looks like now it does sync successfully, though it appears to time out after awhile for some reason:

trae@cr01a-vyos:~$ sudo nano -c +140 /run/scripts/commit/post-hooks.d/vyos_config_sync
trae@cr01a-vyos:~$ sudo systemctl restart vyos-configd
trae@cr01a-vyos:~$ configure
[edit]
trae@cr01a-vyos# set firewall name INT_TO_LOCAL rule 80 destination address 192.168.253.2-192.168.253.3                                                                                                                                                                                                                    
[edit]
trae@cr01a-vyos# commit
INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=cr01b-vyos.int.rtr.trae32566.org

@trae32566 Thanks, could you change one file and comment on one check?

sudo nano -c +140 /run/scripts/commit/post-hooks.d/vyos_config_sync

Set comment

# Config sync only if sections changed
#if not any(map(is_section_revised, sections)):
#    return

Same version on both, 1.4-rolling-202307070317. Also, if you can disable 2 factor on my Slack account ([email protected]) we can talk in Slack about this (lost my 2 factor app / backup codes).
@Viacheslav

@trae32566 Which version on the remote site?

In T775#151889, @Viacheslav wrote:

@trae32566 Try the same with ip address, I tested with IPv4 addresses

@trae32566 Try the same with ip address, I tested with IPv4 addresses

@Viacheslav Thanks for all the work on this, I'm glad to see it moving along! This doesn't appear to work for me on 1.4-rolling-202307070317; I've configured it for both firewall and NAT and it appears to not be getting triggered (though I've only tried firewall changes so far). Here's the primary side (cr01a-vyos.int) config:

trae@cr01a-vyos# show service config-sync
 mode load
 secondary {
     address cr01b-vyos.int.rtr.trae32566.org
     key <MyKey>
 }
 section nat
 section firewall

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

I tested this feature with the following firewall config:

set firewall group domain-group DG_TEST address 'nu.nl'
set firewall group domain-group DG_TEST address 'www.nu.nl'
set firewall interface eth1 out name 'ETH1_OUT'
set firewall name ETH1_OUT default-action 'accept'
set firewall name ETH1_OUT rule 10 action 'drop'
set firewall name ETH1_OUT rule 10 destination group domain-group 'DG_TEST'

A developer I work with reports this:

After nearly 30 reinstalls the upgrade finally blew up. The issue is in the initial copying of the config file, between lines 182 and 219 in the install script. That's where it happens... what's causing it / how it happens is still unclear...

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

I'm encountering similar issues on upgrade as well: the configuration fails to apply because of a broken config.boot file (incomplete; stops partway through, perhaps a migration issue?)

https://github.com/vyos/vyatta-cfg-quagga/pull/100 I have tried to fixed it. Works on my local system.
But need migration script.

Can we close this task?