Submitted PR #23 on vyos/vyatta-cfg-quagga to fix this.

Yes, that's correct. When I enable redirects, it automatically disables receive redirects, which I didn't know but makes sense.
I have only set the redirect and dhcp on eth0, commit && save and rebooted, all looks good.

If you just enable and reboot it works too? I've seen this problem at different routers with RC3, RC11 and rolling, but I can't find obvious reason for it.

I still have no luck reproducing it, I loaded your config on a vm, runni9ng the smae version as you do but if I enable and disable redirects it switches between 1 and 0, as expected.

Hi @hagbard!
Config in attachment.

@zsdc I can't reproduce it, can you please share your config? I have only enable send redirects set, nothing else in the config and everything works like expected. I suspect that something is overwriting your variables. We'll find out.

Let's do as you suggest
we just need to nuke all mbr/gpt before install

Uh. That's pretty crazy! I'll play around with the option on the other VMs I am migrating from Proxmox VE to VMWare ESXi.

It is vmware-tools collecting all the routes from VyOS and reporting them to the hypervisor so you can see them in the ESXi GUI. Not really optimal for full tables.

Yes, but only IPv6. It seems that the VMware Tools only produce the load when the BGP sessions are established. Pretty strange! Maybe some sort of memory problem?

Do you have a full bgp table on this box?

Yep, seems to do the job.

IIRC I worked around this by editing /etc/vmware-tools/tools.conf and adding:

The shared-network-parameters is a real pain and should be used "without warranty" we should rather deprecate it and add proper CLI interface.

I saw that in earlier versions too, but not in 1.2.0-RC11. Can you please retest on RC11?

Next rolling release tonight will have the bugfix in place. Thanks for reporting.

As the DHCP client sometimes stores its lst IP address and sends a request for it you probably should delete the lease from the DHCP server:

With the following patch the statements are migrated. Needs some work to also migrate the metric and route-map settings. Will try to do that later.

Thanks for catching this! I've fixed it in the upcoming rc11.

@hagbarg Sorry I haven't spotted this earlier and had to revert your commit! Please check out my commits: this is how it's been done historically. You would have to also add PBR templates so I see no reason for duplicating that, especially in light of planned firewall overhaul that will rid us from interface templates.

Uh, yeah, that sucks. I'm implementing the kernel variables for wireguard at the moment and have a look into the other interfaces after that.

Here what I mean.
Before enabling rp_filter:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 0
net.ipv4.conf.l2tpeth1.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0

After enabling:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

After disabling:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

Ahh, I think I found it. Usually sysctl sets it to 1, or at least it must have that done in 1.1. I think the command should be called then enable-arp-filter to correct it.

Unless I misunderstood you, int(0) does disable (no source validation) rp_filter.

• CONFIG_MMC_BLOCK already enabled
• CONFIG_MMC_SDHCI_ACPI has been enabled

Thanks for testing and confirming. @trystan

I've installed on two hosts (virtual/cloud instance, and 1 physical) in,local,out rules all work as expected with default drop and firewall state-policy establish/related accepted.

@trystan next rolling image will have the functionality, if you'd like to manual install it, you can do so by installing http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-8_all.deb.
Thanks for your request and please let me know your results.

Please note:

I've tested that I can utilize the existing firewall functions/scripts which work, so I need to write a wrapper for it, but that will solve the issue. Shouldn't take too long.

Not directly but it was added here: https://github.com/librenms/librenms/pull/351

Oh, okay.
Then it looks like the issue is more at Observium and not VyOS.

I see OS version in libreNMS.

@c-po Thanks. Between the legit problem this task revealed early-on, some bad timing with the vyatta-config-migrate from earlier today, and a PEBKAC error, it looks like this might be resolved now.

In vyatta-cfg-firewall please do git checkout current prior to building it, as the submodule pointer is definately not up2date.

This seems to be working now. It's working both on my normal build tree and a brand new one, so it looks like I was just attempting when some cache somewhere hadn't updated

I was building yesterday fine except for the above-mentioned vyatta-cfg-firewall problem.

I was able to build yesterday using Docker, but not a traditional VM.

I did a build yesterday that went trough without issues..
I was using custom kernel, wireguard module and strongswan module. So from my point of view everything is fine now.

According to CI service build works as expected. Can you please retry?

Now a simple build is failing with: