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

Update: the "Low fit" verdict above for policy as-path-list/community-list/extcommunity-list/large-community-list ("no natural derivation source") needs a caveat.

@Viacheslav thx for cleanup the task,. Did you see that I ask for an decision from the team about the implementation?

You're right that device binding implicitly selects the VRF — bindacqdevice/binddevice on an interface that belongs to a VRF scopes that socket to it, no separate VRF
option needed for that to work at the chrony level.

binddevice/bindacqdevice are already separately configurable — binddevice maps to the existing interface option (incoming/listen), bindacqdevice to this PR's new
ource-interface (outgoing/client). So incoming vs. outgoing device binding is already independent.

Thanks for testing this — appreciate the data. To reconcile with what we saw: our issue wasn't IP-unnumbered per se, but specifically that our own address appears on
multiple devices simultaneously in the local route table (ip route show table local showed our loopback duplicated across lo + 3 P2P bond interfaces used for OSPF, since
our full-mesh core reuses the loopback address on each P2P link). We proved with a logging-only rule (fib daddr . iif type unicast log) that real traffic to our own
address was classified unicast, never local, even though ip route get reported local for the same case.

@Apachez: Thanks for the feedback — you're right that a source IP alone doesn't fully solve this for multi-VRF setups with overlapping address ranges.

https://github.com/vyos/vyos-1x/pull/5375

@L0crian the command :

https://github.com/vyos/vyos-documentation/pull/2187

https://github.com/vyos/vyos-1x/pull/5374

@L0crian thx for this information, this could help with my current setup. I will try it in the lab. But I also see that my patched could be usefull

I can create a patch for this if wanted

https://github.com/vyos/vyos-documentation/pull/2186

https://github.com/vyos/vyos-1x/pull/5372

https://github.com/vyos/vyos-documentation/pull/2185

See https://github.com/vyos/vyos-1x/pull/5371

I found it with some help of claude ... It was a problem with conntrack in this setup. I could fix it on 1.4 only manual with this commands:

I would also see this feature cause I do strict icmp filtering and this would make the config much better

Yes after reboot the command works. So to male it work it seems to be necessary to reboot the system after adding the interface.

I did some deeper debuging:

Yes got the information that the other side is no vyos (sorry didn't expect this) it's an current sophos box with strongswan.
It try to replicate it here between two vyos boxes the next days

https://github.com/FRRouting/frr/pull/18654 ok it is in Master not in stable in the moment.

Please put it on the list again because it should be supported by current frr:

I stumbled over it today on my 1.4 boxes. It would be nice to have the possibilty to exclude forwarding traffic from conntrack.

I have started playing around with it.

Same stuff see screenshoot:

After discussion with @tfiebig we found https://github.com/FRRouting/frr/issues/7738 and https://github.com/FRRouting/frr/pull/16354. This could fix it

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.