The policy route works only with an interface (inbound direction) and doesn't work otherwise.
It's always been like this.

In T5324#151418, @greenpsi wrote:

I think I found the real problem:

The 62-temporary-interface-rename.rules udev rule runs in initramfs before the USB modem is detected:

Jun 30 14:32:11 vyos kernel: r8169 0000:03:00.0 e3: renamed from eth1
Jun 30 14:32:11 vyos kernel: r8169 0000:02:00.0 e2: renamed from eth0

[...]

Jun 30 14:32:11 vyos kernel: usb 1-1: new high-speed USB device number 2 using xhci_hcd
Jun 30 14:32:11 vyos kernel: ata2: SATA link down (SStatus 4 SControl 300)
Jun 30 14:32:11 vyos kernel: ata1: SATA link down (SStatus 4 SControl 300)
Jun 30 14:32:11 vyos kernel: usb 1-1: New USB device found, idVendor=12d1, idProduct=1f01, bcdDevice= 1.02
Jun 30 14:32:11 vyos kernel: usb 1-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Jun 30 14:32:11 vyos kernel: usb 1-1: Product: HUAWEI HiLink
Jun 30 14:32:11 vyos kernel: usb 1-1: Manufacturer: HUAWEI

So the modem does not get renamed to eX and thus, if the modem has an ethX name that conflicts with the configuration from the 65-vyos-net.rules udev rule, the renaming of the interfaces from eX to ethX fails because a duplicate already exists.

So in conclusion, if VyOS wants to support USB Ethernet devices, the 62-temporary-interface-rename.rules udev rule should be deferred until the USB devices are detected or something like that.

It did work in the test enviroment, I just returned from a long vacation and will be deploying that update to some production boxes and enabling it on there tomorrow.

VyOS 1.4-rolling-202306280317 show the following additional dmesg items

Tried the following:

echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove
echo 1 > /sys/bus/pci/rescan

Attempted a modprobe -r ath10k_pci and the re-load the module. The following dmesg is what I saw after.

Yes, checked it working, please closed it.

@ServerForge Could you check if it works as expected?
If yes you can close it.

@cuongdt1994 Could you check it? If it works as expected, we can close it.

Requires to rewrite PIM to get_config_dict https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/protocols_pim.py

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

set qos interface eth0 egress 'test'
set qos policy shaper test bandwidth '300mbit'
set qos policy shaper test class 23 bandwidth '150mbit'
set qos policy shaper test class 23 match one ip protocol 'tcp'
set qos policy shaper test class 23 match two ip protocol 'udp'
set qos policy shaper test default bandwidth '20mbit'
set qos policy shaper test default queue-type 'fair-queue'
commit

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

set qos interface eth0 ingress '300m-in'
set qos policy limiter 300m-in default bandwidth '300mbit'
set qos policy limiter 300m-in default burst '125000000b'
commit

The IPv6 reverse path filter functionality would be great if it worked properly.
On the other hand, the current sysctl based solution does not allow for adding exceptions.

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

I think I found the real problem:

That fixes it. It does seem like more of a band-aid solution though. I don't want to have to do that for every router I deploy using this setup

Wireguard is not yet exists in the system when tun is already exists due to priority

vyos@r14:~$ /opt/vyatta/sbin/priority.pl | match "tun|wireguard"
380 interfaces/tunnel
381 interfaces/wireguard

Thank you very much, I compiled the image, now it remains only to check.
As soon as I check, I will write.

Hi @vfreex . The idea is to add this feature, and several more, once we get new firewall cli structure: https://github.com/vyos/vyos-1x/pull/2016

The above setting works and also if configured like this:

Try set protocols bgp neighbor eth1 interface remote-as xxx

Same in https://forum.vyos.io/t/need-some-help-troubleshooting-nic-detection/11291/15

I was able to test this for ISIS. I'll test OSPF hopefully tomorrow.

In rolling release, it does not accept remote-as configured as a part of peer-group, commit error is received:

I opened PR https://github.com/vyos/vyos-1x/pull/2062 for this.

The issue was fixed with update container image vyos/vyos-build:current to the latest

I found the following log in /run/udev/log/vyos-net-name from the vyos_net_name python script:

In T5324#151306, @Viacheslav wrote:

e2 it is a temporary name to rename ethX in correct way
You have to use “ethernet ethX address x.x.x.x”

I found invalid interface name with lastest build (fresh install and none configuration)

https://github.com/vyos/vyos-build/pull/370

I found your devices supported but I need build and check again.

@aztec102 please show version running.

e2 it is a temporary name to rename ethX in correct way
You have to use “ethernet ethX address x.x.x.x”

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