@daniil it will be fixed in tomorrows rolling ISO.

Just adding that I too am experiencing this same issue with 1.2.5 while sending firewall logs to a remote syslog server. Running the command

sudo systemctl restart rsyslog

will show firewall logging for a few seconds before it stops completely. Issuing the command again will result in the same thing - logs for a few seconds and then stop. It appears that logging outside of the firewall still functions as expected as regular console log entries are still being sent.

First PR https://github.com/vyos/vyatta-cfg-quagga/pull/50 for delete templates for "protocol rip" from vyatta-cfq-quagga
Second PR https://github.com/vyos/vyos-1x/pull/454 for new XML-python style.

Can you share what you did to make it work again? NAT has recently be rewritten which could be the root cause.

A config Syntax is always migratable. Wide also supports scripts, but ISC PD (as I‘ve seen it, and interpret it) seems to have some rough edges. If you find a guide I will definately have a look.

I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.

@jjakob it was only choosen as it prooved to be "more simple" compared to ISC and that helper script. I have no affiliation with either implementation. I was not aware that it could cause other issue. If you need to change it to ISC you're free to go.

@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.

The purpose of choosing wide-dhcpv6 is to achieve DHCPv6 PD.

What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842

Successfully tested on 1.3-rolling-202006120643

Successfully tested on rolling 1.3-rolling-202006120643

Unfortunately this results in an error:

As a side-note, the kernel reacts correctly to this by rfc6145.

An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes.

Hmm, sshd listens on port 2 by default.

SNMPD must listen to the socket on the loop in vrf default. This is necessary for the protocol agentx to work.

The set protocols bgp XXX neighbor XXX address-family ipv6-unicast peer-group XXX command generate the router bgp XXX; address-family ipv6; neighbor XXX peer-group XXX', for vtysh, which does not supported (anymore? I cannot find any commits in FRR about syntax change, maybe this was migrated from old quagga).

This fixed now introduced a bug with comma separated ports

Please feedback as this is what you expect. Also it would be nice if could write something about that in our documentation: https://docs.vyos.io/en/latest/

Latest rolling release has all the fixes

Works as expected

The != port issue is yet to be fixed ...

Tomorrows rolling ISO will support VRF sourced SSH.

1. commit restrictions/permissions have not changed; all handled in the backend.
2. The daemon can not load the configs, as it does not have/need access to the config session; that's the point.
3. ?
4. the conf_mode script needs to reference the global config; re-setting level is basic hygiene --- the script should ask itself 'what if I am called again?'
5. we want to eat the args in the node.def; so you already have it.

Thank you very much for the POC. Very useful to understand the proposed design.

While I agree, that caching is a feature of the past, we rely heavily on vyatta-webproxy for authentication and also url-filtering (different source networks allowing access to different destination domains and/or IP ranges).