looks for my like an frr bug. Has someone contacted upstream?

https://github.com/vyos/vyatta-cfg-quagga/pull/43 created

removing the check makes it work like a charme push request incomming..

run into the same. If I add parameters default 'no-ipv4-unicast' to my config and commit I get the waring above. All runs fine, cause the sessions where already configured before.
If I do a reboot, bgp config in frr is neartly empty only "router bgp 64512" was there not more. Removing it and do an commit nothing changed. Removing it an reboot helped.

Pull Request: https://github.com/vyos/ppp-upstream/pull/2

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8597

I send a pull request to fix it:

I think we should make somewhere a list of services and which level of vrf support they have.
Openssh for example has build in support for vrf

Could be away. But from my experience most people use vrf to seperate managment from production, and as second prio seperate customers and so on.
But the managment vrf must not be the "default" vrf.

I got this on two production systems on the next two I migrated I changed my workflow to:

In this way we could also add vpp nat64 running complete in vpp independent from all other vyos services:

@cpo cumulus behave differently cause they use an other implementation as in pure frr. They use PTMD see https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Bidirectional-Forwarding-Detection-BFD/ and https://github.com/CumulusNetworks/ptm

Seems that it s merged an in 1.2.3 it looks in the moment good for me:

Seems that upstream did not backport the fixes to the stable version's. So it is only included in frr 7.2.
I asked them for backport.

You can add a community via route-map to your outgoing routes.

I have setup two vyos router and one is origination default.
All runs fine with this patches since more then 40 minutes so it fixes the problems.

Can we make a nightly with the patches from:

https://github.com/vyos/vyatta-op-quagga/pull/3 I hope now it looks better

Did I something wrong with https://phabricator.vyos.net/T1550 and https://github.com/vyos/vyatta-op-quagga/pull/2 that the pull request is not showing in phabricator?

https://github.com/FRRouting/frr/pull/4742 let's give it a try?

Some Feedback from the frr people:

Run into the same with 1.2.2

I created a pull request to fix it. @guertinf has already test the fix

For my point of view this is a dependency from the bfd protocol specs.

I have added the Documentation:

As far as I can see it is included in 1.2.1 so we can close this or?
If yes I will submit a config example for ospf ip unnumbered that uses it

Try: https://github.com/vyos/vyatta-cfg-quagga/pull/27/commits/8c741da0691cb392a86f249b61c3686a034f908a

https://github.com/vyos/vyatta-cfg-quagga/pull/27 < -- seems to look better

See my pull request: https://github.com/vyos/vyatta-cfg-quagga/pull/26

from Slack

can it be that the fix for T1243 is broken? I can understand that local-as can't be the same like remote-as if router-as diff from local-as but the patch forbit to set remote-as to the same like router-as that will break ibgp

I want to build a setup like described in:

@dmbaturin can you explain why we schedule it to the next release and not to 1.2.1 for example? Are there any policies?

I want write an follow up.

In T1309#34455, @runar wrote:

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

seems so but:

Here is the current frr documentation:

Hi runar,

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:

@TriJetScud please see :

can reproduce ob EPA3:

Can't reproduce with EPA3

@syncer @dmbaturin Please do not remove use current code!

@syncer thats not true:

Was it not RC6 which got 4.19.0? If I read the kernel changelog right there where some other problems with igb fixed in this area ....
Also I found https://ubuntuforums.org/showthread.php?t=2404431.

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

@merjin @c-po please have a look to the debian wiki page especially to the mibs-downloader.

We should have an eye on https://community.openvpn.net/openvpn/ticket/208 cause this will change the config logic again completly.

It is not a bug in VyOS self. If you look inside the description of this oid:

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?

Please go direct to version 1.0.3 cause:

pdns recursor is from the same people who writes dnsdist.
There are three products wirh diffrent scopes:

There is no way to signal DOH (DNS over HTTP/S) via dhcp.
DOH and DOT is supported in latest dnsdist packages see https://dnsdist.org/ and https://mailman.powerdns.com/pipermail/dnsdist/2018-August/000466.html.

As far as I can see it is enabled by default in recent frr:

I will bring this up again. We have now in 1.2 all we need.

Have you seen this: https://github.com/reubenhwk/radvd/issues/45 ??

I have take a look and the todo would be:

this is now fixed in 201810180337. Please test!
On my system ist runs without problems

I have the same problem here with 201810170747.
My router is without this firmware complete unuseable.

If you want have a better NAT64 solution take a look to jool. (http://jool.mx/en/index.html).

<dmbaturin> Hi! If you are ready to help with testing it, I'll be happy to make a CLI.
<dmbaturin> I think it should be orthogonal with all other features indeed, so a perfec candidate for RC3.
<dmbaturin> It would be perfect if you make a small write-up on setting it up by hand in FRR because I haven't used RPKI yet.

<dmbaturin> Hi! If you are ready to help with testing it, I'll be happy to make a CLI.
<dmbaturin> I think it should be orthogonal with all other features indeed, so a perfec candidate for RC3.