PR https://github.com/vyos/vyatta-op-quagga/pull/4/commits/7659873869d92c9ec6b363db7e06d2ba5b41e5f6
New syntax for commands "monitor protocol bgp enable", "monitor protocol bgp disable"

Yes, that's correct.

per default session=replace is set and if I understand correctly you'd like to have to have the option to change it to deny don't set it at all. Is that correct?

This was discussed previously: https://phabricator.vyos.net/T1129
Use """ which will be replaced with quotes when generating the isc dhcpd config.
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/dhcp_server.py#L813-L815

Hello!
Please also add "single-session" to
set service pppoe-server ppp-options

Its IKEv2, correct. Loglevel increased

@c-po this is IKEv2?
can you increase log level?

@syncer why remove 1.2? Bug should be fixed in 1.2.x bugfix releases

Actually i'm currently unable to reproduce the bug because since i removed the configuration for RPKI everything works fine. Even more interesting is that my second router with the exact same configuration does not have the problem.

It looks like the VyOS has the old command syntax.

Similar bug with FRR ref https://github.com/FRRouting/frr/pull/5450

Hi @MrXermon
Can you describe how we can reproduce this bug?
Can you show share your configuration?

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.

Protocol rewrite is more then overdue now ... :)

@c-po
I get other result.
After set from your example I see correct area
FRR

tagNode has been renamed to dnssl

Yepp, the issue is the quotes in dhcp server config (like the sample line i wrote).
i think, duplicates functionality doesnt matter, there are already such duplications: global-parameters, subnet-parameters, etc. That are for raw settings, if someone want a magic things in dhcp. But adding normal options to static-mapping-parameters are just a workaround.

Resolved since parent task closed

[edit system static-host-mapping]
vyos@vultr# set host-name test.lan inet 127.0.0.1
[edit system static-host-mapping]
vyos@vultr# commit
[edit system static-host-mapping]
vyos@vultr# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vultr# show system static-host-mapping
host-name test.lan {

inet 127.0.0.1

}
[edit]
vyos@vultr#

Sorry, I misunderstood your issue, indeed adding quotes inside the parameters is not possible now. A reimplementation would be needed.

https://github.com/vyos/vyos-1x/pull/182
We have to ship our own /etc/{init.d,default}/isc-dhcp{v4,v6}-server files since we can't overwrite the ones supplied by the debian package.

The current static-mapping-parameters can be used to add a quoted value, e.g.

static-mapping test {
                    ip-address x.x.x.x
                    mac-address yy:yy:yy:yy:yy:yy
                    static-mapping-parameters "option domain-name-servers 1.1.1.1, 9.9.9.9;"
                }

command

set service dhcp-server shared-network-name dhcpexample subnet 192.0.2.0/24 static-mapping example static-mapping-parameters "option domain-name-servers 192.0.2.11, 192.0.2.12;"

I'm experiencing the same issue of the service failing to start on 1.3.
The installation was first started with the default config in a VM that had a serial port. Then the installation was transferred to a physical machine without a serial port, and the whole /config directory was manually copied from the old installation on that machine. The machine was then rebooted. The result were the same errors in syslog/journal.
I believe the issue is that if the config.boot is manually replaced or edited on disk, the script that would normally be triggered on commit when deleting system console is never triggered, thus the service remains enabled, but there is no system console in the config to delete any more.

@sunser Can you please clarify if you still encounter that issue?

syslog is required by multiple targets and logs journald messages, stopping it works at the first commit, but the dependencies will start is automatically after reboot. the vyos config is being removed from rsyslog.d but the default rsyslog.conf will be used, which logs daemon, emerg (to console) and auth failures and would have to be changed in vyos-build if required.

Do you know what the outcome of this old task was?

Problem was in the wrong IKEv2 definition, set vpn ipsec ike-group IKE-AZURE ikev2-reauth must be yes

Yes, now the driver is there. But, as I am not using that driver, I have asked for confirmation, just in case.

Yeah I figured. vyos is being install into /dev/mdX, I can boot via live cd and mount mount it and it has everything in there, but there seems something wrong with writing the boot sector since I would see at least grub. Instead it is empty.

In T1869#49212, @hagbard wrote:

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

This requirement needs to be applied to 'running_config' as well, in case of (1) editing at the level of an unset node (parse error); (2) reading effective_value(s) in configuration mode (lacking full paths).

Resolved in commit fa85664ba050dab99d18d5d05018eea6a0fb0879

Thanks; this is necessary when (1) editing at the level of an unset node; (2) reading effective_value(s) in configuration mode. I will extend the original fix.

Just to add to this.

@jestabro problem is not resolved

@dmitry yes, I tried 1.2 rolling as well. I have not been able to try 1.2.3 stable due to a lack of access.

Hello @trae32566 , with 1.2-rolling the same installing result?

Have a screen recording 😄

T1846 fixes this

https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1671
https://phabricator.vyos.net/T770
are all related to the same issue.

There is certainly a race condition in interface renaming for VyOS 1.2. This is possibly also an issue for 1.3 but more testing is required before I'm sure of that.

I check it in latest rolling releases and it work fine (ipv4 and ipv6).