Or use a VRF T31, closing - feel free to reopen if you think this was done wrongly.

Ability to use Local PBR ref T439

VyOS 1.2.1 ships PowerDNS 4.1.12

@jjakob yes. Each ISO always ships the latest available PowerDNS version that is released and available via https://repo.powerdns.com/

vyos 1.2.0-rolling+201906161308 has pdns_recursor 4.1.14, should this be marked as fixed?

Sorry found it.

Would it be possible to add an option to bind an specific interface to an routing table?
I have tested the scenario above and create only the routing table via protocol static.
After this I manual add:

I added a log rule to:

why do we use fwmark in this case? As far as I can see ip rule give us all needed selectors:

@syncer thats not true:

it can be some other issue though
will appreciate if it's possible to get procedure how to reproduce and we happy to work with frr devs to address that

That seems odd, my global peerings all reset at the time of the test. @mariusno and @rherold did you experience something similar?

VyOS is not affected by this issue
https://vulmon.com/vulnerabilitydetails?qid=CVE-2019-5892
as it requires FRR build with certain options which we not use

Please unbreak now. The next test date was announced!!

Wow, this explains why all my sessions dropped yesterday.

Thx for the feedback indeed it runs much better with the virtio-net driver. Bit the e1000 is the default if you choose Debian as OS in Virtualbox.
VyOS is not available in Virtualbox as OS Template. I think we should try to get an own template with nice defaults into Virtualbox. Should I open a case
in Virtualbox for it? Do we have a list of settings that would be optimal for an VyOS vm?

Hi @rherold , these messages are verbose debug messages, change to virtio-net or to a different emulated driver to have them disappear. In general I recommend to use the virtio one which has a better performance too compared to emulated ones, plus less complex code. (https://github.com/MorteNoir1/virtualbox_e1000_0day)

I propose to proceed with a global change. Special case handling is always harder to test and the impact is only 5 seconds max in startup time - who cares on a 24/7 active device which is rarely rebootet?

In T1120#29573, @c-po wrote:

instead of differentiating between raid and non raid installations - why not always wait 5 seconds for the discs to settle? As this is only done once on startup this is IMHO better then a special case.

instead of differentiating between raid and non raid installations - why not always wait 5 seconds for the discs to settle? As this is only done once on startup this is IMHO better then a special case.

I've added SNMP restart on hostname change, it will be in the next nightly build.

Hey @Merijn, sorry for late reply and thanks for the patch! I've merged it in and it will be in the next nightly build.

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

I've changed it to handle the situation gracefully. Actual display of connecting SAs is another story of course... The fix will be in the next nightly build.

tested with most recent rolling version. problem still persists but it's not throwing errors.

Thanks for testing that guys.

And FYI max-ipv6-routes=10 and max-ipv4-routes=10 doesn't seem to help either.

In T1131#29483, @hagbard wrote:

Hi @danhusan, did you ever try another poll value, like 3 secs or 5 or anything like that? If set to 0, the host system won't show you any updated meta data, like if you change the ip address etc.
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L1662)
I'm therefore not entirely sure if that should be treated as a special case scenario (we could publish a kb if you run into that condition), or if it is a general issue since you 2 were the only ones experience that issue as far as I know.
I'm also not sure it only is triggered by your situation (full bgp table) or if it can happen on other occasions as well, if you came across more issues regarding that value, please let me know.

@MrXermon , yes that sounds reasonable. I found in the code that they limit it to 100 routes, can you please try the following:
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/conf.h#L138)

Hi @hagbard,
i played with different values and in my case (full table IPv6 router) the error continues during the following values:
3s, 5s, 10s, 20s, 30s
At 60s the CPU load starts to cycle between >30s full load, than it drops for a few seconds and raises again.

Hi @Barrysdca did you have a chance to test again?

Hi @danhusan, did you ever try another poll value, like 3 secs or 5 or anything like that? If set to 0, the host system won't show you any updated meta data, like if you change the ip address etc.
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L1662)
I'm therefore not entirely sure if that should be treated as a special case scenario (we could publish a kb if you run into that condition), or if it is a general issue since you 2 were the only ones experience that issue as far as I know.
I'm also not sure it only is triggered by your situation (full bgp table) or if it can happen on other occasions as well, if you came across more issues regarding that value, please let me know.

Commit also cherry-picked to crux branch

Thanks for the fix @dmbaturin! At what time will the next nightly be build?

@m.cremers The fix will be in the next nightly build, please re-test.

Changes verified in commit https://github.com/vyos/vyos-kernel/commit/729bd5fafec7d2ad345ab371b04d15d2cf627229 so IMHO this one is resolved

I have tested it in the 1.2.0-rc11. The problem only present when there is no established SAs exists.

One extra patch needed

SInce this is a 1-to-1 mapping it also opens up all incoming ports to the hosts behind the router.

PR https://github.com/vyos/vyatta-cfg-system/pull/96
Thanks @kroy

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