thx for the backport @c-po runs fine on 1.3 rolling.

Can this be backported to 1.3 cause I run into the problem today on 1.3.5

@Apachez I would also not want this. Example bgp on eth0 with one peer. I would not like to see to have the bgp port open for all source ips, only for the configured peers and not more.
To make it better to manage for the admins I would like to see a syntax like in junos:

I disagree with that. Cause only why bgp is running, we don't need the port to be reachable on all interfaces or for all source IP's.

today I want test how fast firewall rules loading and changing in vyos performed. I took an vyos-1.4-rolling-202308180646-amd64.iso boot it as kvm guest.
Then I added some rules with:

Looks like the Problem still exist in 1.4. Are there any plans?

https://github.com/vyos/vyatta-cfg-quagga/pull/100 I have tried to fixed it. Works on my local system.
But need migration script.

Is there some progress? VPP is available for AArch64 in meantime.
Here some news about VPP performance:

After digging a step deeper we could also move the function into:

Stumbled again about it and would ask if it is not possible to switch to the iptables extension so that rp filter will also work for IPv6.
From my point of view we must create in firewall setup a new chain RPFILTER in IPv4 and IPv6.

vyos@gw-1:~$ show interfaces ethernet eth1 physical
Settings for eth1:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g

:...skipping...
Settings for eth1:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
                       drv probe link
Link detected: yes

driver: igb
version: 5.6.0-k
firmware-version: 0. 6-1
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
~
vyos@gw-1:~$ show interfaces ethernet eth2 physical
Settings for eth2:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
                       drv probe link
Link detected: yes

driver: igb
version: 5.6.0-k
firmware-version: 0. 6-1
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
vyos@gw-1:~$

anything new here?

Please take a look at the commit 9213ce6672582bc12f02c1530726fe97030d2cfe for kernel 5.13.

It seems that what I thought is true:

could this help https://patchwork.ozlabs.org/project/netfilter-devel/patch/776b8819c85c83088478b933a35691133055347a.1430733932.git.daniel@iogearbox.net ?

as I wrote on slack, from my point of view it is a kernel problem. It seems that the conntrack in the kernel detects the packets eben if they come in on an input interface in default and so
the nat code won'T match cause for conntrack the outgoing interface is still eth0 which is in vrf OOBM instead pppoe0.

As requested the config{F1499926}

thx for the fast feedback.

@Viacheslav yes it was rc4 got the link some day's befor release via slack. I will setup a test lab next days, these boxes are now in production.

mii-mon was fine. Link was enabled on the switch and the link for the interface was up. But on the LACP was not enabled on the switch.
So I would exepect to see the sub interfaces from the bond as up but the bond has to be down.

for me it looks like a name lookup error. I have read the forum entry mentioned above. And they fixed it by disabling name lookup.

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: