Does this mean to to disallow installing the syslinux bootloader to the iso by default? The reason for asking is the arm builds we try to make, as syslinux is incompatible with arm, and a iso cant be generated for such a system as it tries to install syslinux when building the image.

LiveCD is usually only used for temporary testing and installation, isn't it? Will using this restriction cause the normal use of livecd to become troublesome?

I think the intention here is by default build with no liveCD support, and use the flag to explicitly build liveCD images when needed. The justification is if an image is cloud type image, there are certain security assumptions about the live network the image is connected to (because many cloud providers provision an image via information over specific link local addresses). If you boot a physical PC with a cloud ISO, you run the risk of exposing cloud-init to the local network, which would allow trivial takeover.

Thank you @Dmitry, it will be in tomorrows rolling release.

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

I am a little confused. What is the specific function of the --allow-cd-boot compilation parameter that this task hopes to add? Forgive me for not seeming to understand!

Perhaps replace config (from_re "interface" | from_re "isis *") delete also and route-maps/prefix-lists from FRR configuration.
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/protocols_isis.py#L121

Before update

Ah, thanks for the clarification.

@c-po It's mean all NOT ports. If you want to drop not 22,23,24,25

This will be on my list to test here in a little bit. I'm almost done with stuff relating to LDP.

PR with changed types in docs https://github.com/vyos/vyos-documentation/pull/380
ESP transport mode works properly on Cisco Router and VyOS routers together.

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

DMVPN Spokes work properly behind a NAT if we use transport mode instead of tunnel. e.g.

set vpn ipsec esp-group ESP-HUB mode transport

So I think we need to add this info to docs.vyos.io and close this Feature Request

Put in a new PR to enable ethernet sub interface MPLS enablement. I screwed up the first one...but here's hoping this one is good.

See documentation https://docs.vyos.io/en/latest/system/ntp.html, support will be in next rolling release

Even on Kernel 5.4 this is not supported.

The command works on the experimental Kernel 5.9.9 VyOS ISO, but not using a 4.19 series Kernel. looks like it's not yet supported in nftables.

We actually need this:
http://git.nftables.org/nftables/commit/?id=35a6b10c1bc488ca195e9c641563c29251f725f3

Fixed.

Fixed

set nat source rule 1000 outbound-interface 'eth1'
set nat source rule 1000 source address '203.0.113.1-203.0.113.4'
set nat source rule 1000 translation address '10.0.0.1-10.0.0.4'
vyos@r5# commit
[ nat ]
Warning: IP address 10.0.0.1 does not exist on the system!
Warning: IP address 10.0.0.4 does not exist on the system!

PR https://github.com/vyos/vyatta-cfg-quagga/pull/57

@jjakob can you check the latest rolling?

https://github.com/vyos/vyatta-cfg-qos/pull/8
https://github.com/vyos/vyos-1x/pull/621

The root cause here is that there is yet no nftables map support in our template.

This one is holding us back from some great 1.3 features... would love to get it looked at!

PR https://github.com/vyos/vyatta-cfg-system/pull/132

+1

PR https://github.com/vyos/vyatta-cfg-firewall/pull/19

@Dmitry I dont really know if this is a good idea.
The reason for this is that the configuration synchronisation between frr daemons depends on the daemons started at the same time, and always running when global configuration is applied.. this is also one of the reasons why frr-daemons starts prior to vyos starting on bootup and not when a daemon is configured. I do not know if this will be a issue with PIM, so i'm not sure what will happen with this daemon.
as an example for such synctonization is a prefix-list.
If you start bgp and ospf and then create a prefix-list, the list will be created in both ospf and bgp.
If you start bgp , then create the prefix-list and then start ospf, ospf will not automatically add the prefix-list but when you show the combined configuration is is still show'ed as a global prefix-list.. to get the prefix-list into ospf you need to manually add the commands to the daemon to get in sync.

This probably happens at this stage.
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-image-existing#L217-L224

It seems a wrong logic.
We want that option to have an effect on "local" and "forward" directions, so we use table mangle and "PREROUTING" and VYATTA_FW_IN_HOOK hook
Generated rules

Following this issue request https://sourceforge.net/p/opennhrp/support-requests/3/ we need to use transport mode instead of a tunnel. Was tested on AWS node and it looks working even with selector remote_ts = dynamic[gre]

it stop at

AR      crypto/built-in.a
  LD [M]  crypto/crypto_simd.o
make[2]: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
make: *** [Makefile:1464: bindeb-pkg] Error 2
vyos_bld@7f2a9dc49956:/vyos/vyos-build-5.4.78/packages/linux-kernel$

T490