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

PR: https://github.com/accel-ppp/accel-ppp-ng/pull/42

PR: https://github.com/vyos/vyos-build/pull/1298

PR: https://github.com/vyos/vyos-1x/pull/5459
DOCS-PR: https://github.com/vyos/vyos-documentation/pull/2240

Dublicate with T9290

https://github.com/FRRouting/frr/pull/22921 got merged can we ask the frr project for a backport or do it self?

Implemented conditional DHCP options via client classification, extending the existing client-class framework (previously limited to Option 82 relay-agent matching):

Thanks for catching this, a.kudientsov — and sorry for the regression. The mistake was narrowing the bare except: in fqdn_resolve() to except gaierror: based on the assumption that getaddrinfo() only ever raises gaierror, without checking that other OSErrors (e.g. transient network failures) can hit the same call and need to keep being
swallowed here too. c-po's fix in #5406 (back to except OSError:, since gaierror is a subclass) looks correct to me.

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

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

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

Thx for the Information, but I saw here also the possibility to give this to upstream finding a better solution for this.

Root cause confirmed — this is an upstream FRR behavior change, not a VyOS bug.

Thanks for the full dump — that actually complicates things rather than confirming the kernel-FIB-metric theory. Your new output shows the static route absent from the

kernel FIB on both 1.4.4 and 1.5.1 (only proto kernel metric 256 present in each), which contradicts the earlier 1.4.4 snippet showing proto static metric 20 there. So
either that earlier capture was momentary/stale, or the kernel-installed route is not stable over time (e.g. it disappears/reappears around RA refresh or a DHCPv6 lease
event).

PR https://github.com/vyos/vyos-documentation/pull/2195

Thanks - that rules out BGP/extended-nexthop entirely then, good to know it's a legitimate RA from your upstream (AWS) gateway, not a self-sent one.

Both the config and the relevant sysctls (accept_ra/accept_ra_pinfo/
forwarding) being identical on 1.4.4 and 1.5.1 rules out an interface-
config or sysctl-default explanation. I initially suspected a kernel
patch-level difference (6.6.117 vs 6.6.144), but I don't think that's
it either: the likely real candidate is T7531 (bgpd's automatic IPv6
RA sending, the bgp ipv6-auto-ra behavior, disabled via
set protocols bgp parameters disable-ipv6-auto-ra).

Thanks, that rules out a config difference - the eth0 setup (DHCP/DHCPv6/autoconf) and the resulting address are identical between the two versions.

---Thanks for the detailed comparison, that confirms the route-selection theory: on 1.5.1 there's now a third competing entry for this prefix that doesn't exist on

1.4.4:

Looking at your last output more closely - I think this might not be an FRR-side redistribution bug at all, but a route-selection conflict on your box.

Took a look at the current vpp-1.5 code to scope this out.

hi please try:

Root cause found: ask_yes_no() in python/vyos/utils/io.py:57 catches EOFError from input() but loops right back to the top of while True with no backoff or exit condition:

Thanks for the detailed follow-up, this is helpful.

PR: https://github.com/vyos/vyos-1x/pull/5389
PR: https://github.com/vyos/vyos-documentation/pull/2193

@Apachez default powerdns: https://doc.powerdns.com/recursor/security.html it seems it was taken over from the debiab powerdns package.

Hi, thanks for the detailed report.

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.