PR https://github.com/vyos/vyos-1x/pull/1986
set service pppoe-server authentication mode 'radius' set service pppoe-server authentication radius accounting-interim-interval '60' set service pppoe-server authentication radius server 203.0.113.1 key '123' set service pppoe-server client-ip-pool name POOL-01 gateway-address '192.0.2.1' set service pppoe-server client-ip-pool name POOL-01 subnet '192.0.2.0/24' set service pppoe-server interface eth1
In T5186#148294, @rh7819 wrote:this is cause by
tcindex classifier is removed by upstream kernel, so
08:04:48 DEBUG - filter add dev eth1 parent 11: protocol ip prio 1 handle 128 tcindex classid 11:a
fails.
We use FRR as the backend and it uses logical AND for match entries
this is cause by
PR https://github.com/vyos/vyos-1x/pull/1984
set high-availability disable set high-availability vrrp group GRP01 address 192.0.2.47/32 set high-availability vrrp group GRP01 interface 'eth1' set high-availability vrrp group GRP01 vrid '10'
It doesn't like protocol tcp
vyos@r14# sudo tc filter replace dev eth1 parent 1: protocol all u32 match ip protocol tcp 0xff action police rate 300000000 burst 15k flowid 1:a Illegal "match" [edit] vyos@r14#
But it works with protocol 6
vyos@r14# sudo tc filter replace dev eth1 parent 1: protocol all u32 match ip protocol 6 0xff action police rate 300000000 burst 15k flowid 1:a [edit] vyos@r14#
And next fail:
ardware UUID: 4d6f4d29-1ae8-446f-8d2b-3decd9da64c7
On 1.4-rolling-202305080742, speed limit and protocol detection still not worked out correctly too.
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
In T5116#147654, @Viacheslav wrote:I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html
def _format_show_counters(data: list):
data_entries = []
for entry in data:
Interface = entry.get('ifname')
Rx_Packets = entry.get('rx_packets')
Rx_Packets = entry.get('rx_bytes')
Tx_Packets = entry.get('tx_packets')
Tx_Bytes = entry.get('tx_bytes')
Rx_Dropped = entry.get('rx_dropped')
Tx_Dropped = entry.get('tx_dropped')
Rx_Errors = entry.get('rx_over_errors')
Tx_Errors = entry.get('tx_carrier_errors')
data_entries.append([Interface, Rx_Packets, Rx_Packets, Tx_Packets, Tx_Bytes, Rx_Dropped, Tx_Dropped, Rx_Errors, Tx_Errors])thanks for the contribution , I've done some test , it seems to work like a champ . @dmbaturin @c-po this script to do the steps necessary to compile the kernel module to use ovpn-dco . Could you check if it's correct or something needs to be improved :
Great, maybe we can use jool to build it!
Thanks! Setting a router-id fixed it for VPNv4 and VPNv6. It also works without creating a dummy interface.
In T5082#148096, @onedr0p wrote:@c-po I know we're on rolling for 1.4 but is there any way to communicate breaking changes like this in the future? If this was mentioned in the PR or ticket I don't think there would have been any confusion.
As for this tickets status it can be closed.
It should work for 1.4
set policy route foo interface eth1v1
Load-balancing op-mode output generated by https://github.com/vyos/vyatta-wanloadbalance/blob/current/src/lboutput.cc
@c-po I know we're on rolling for 1.4 but is there any way to communicate breaking changes like this in the future? If this was mentioned in the PR or ticket I don't think there would have been any confusion.
This can be implemented by multiple daemon instances in separate vrf's.
@dcplaya yeah that was a transitional error/quirk as we renamed that one during the development cycle.