This a project for mobile access to enterprise networks. VyOS plays as an MPLS-PE router as well as L2TP Network Server. Every subscriber coming via l2tp is directed to the customer's VRF other than default (with RADIUS attribute)

Hi @aserkin! It looks like you have some frr server misbehavior. It sends up/down events with an unexisting vrf id.
Could you make/describe the setup that causes the issue to appear? Thanks

Ah, yeah, that's a valid point for gretap.

In T4729#135223, @pasik wrote:

well, "gre" and "gretap" are different types of tunnels, with different features.. so it makes sense to test and validate with the normal "gre", as in your config I don't see a need for "gretap".

I just checked based on your comment and I can also confirm that with 1.4-rolling-202210050218 (using also different syntax) is working perfectly with the authentication.

Update: latest rolling has a bit different syntax. I think users just not migrated properly on update. After adding

set service ipoe-server authentication interface eth1.50 mac 00:50:79:66:68:03
set service ipoe-server authentication interface eth1.51 mac 00:50:79:66:68:04

I see that chap-secrets file generated properly and users getsIPs

vyos@vyos# sudo cat /run/accel-pppd/ipoe.chap-secrets 
# username  server  password  acceptable local IP addresses   shaper
eth1.50     * 00:50:79:66:68:03 * 
eth1.51     * 00:50:79:66:68:04
vyos@vyos# run show ipoe-server sessions 
ifname | username |    calling-sid    |     ip      | rate-limit | type | comp | state  |  uptime  
--------+----------+-------------------+-------------+------------+------+------+--------+----------
 ipoe0  | eth1.50  | 00:50:79:66:68:03 | 172.16.50.2 |            | ipoe |      | active | 00:05:21 
 ipoe1  | eth1.51  | 00:50:79:66:68:04 | 172.16.98.2 |            | ipoe |      | active | 00:03:43

This issue also present in 1.3.0-1.3.2. Latest rolling 1.4-rolling-202210040218 also affected, it has empty user list in chap-secrets

vyos@vyos:~$ sudo cat /run/accel-pppd/ipoe.chap-secrets 
# username  server  password  acceptable local IP addresses   shaper
vyos@vyos:~$

well, "gre" and "gretap" are different types of tunnels, with different features.. so it makes sense to test and validate with the normal "gre", as in your config I don't see a need for "gretap".

In T4729#135221, @pasik wrote:

Hmm, any specific reason for the tun0 encapsulation 'gretap' ? did you try with normal 'gre' tunnels ? Does it change anything?

Hmm, any specific reason for the tun0 encapsulation 'gretap' ? did you try with normal 'gre' tunnels ? Does it change anything?

Needs to check, maybe fixed with rewriting in T4678

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

At least on my lab, with one of the latest 1.4, this is working for me:

In T4708#135016, @Viacheslav wrote:

@narey83 Could you re-check it with the latest rolling (start since vyos-1.4-rolling-202209290218-amd64.iso)?

Is there a way to isolate a NAT rule to operate within a VRF?

If you document this check then everything commits.
https://github.com/vyos/vyos-1x/blob/f5a50135f07ac4ec8ed431a757b9c56e607d2132/src/conf_mode/dhcp_server.py#L265-L271

I installed the latest release and its not working for me. Whenever I boot I lose eth0 and eth2 interfaces.
I end up with an eth1 (previously eth2) interface and startup errors that seem to indicate that migrate failed.
I would reconfigure everything to help test this, but I do need two network interfaces.

@pasik you can build your own image: https://github.com/vyos/vyos-build/compare/equuleus...fvlaicu:vyos-build:equuleus-1.3.2

It'd be nice to get a newer igc driver version in 1.3 branch though, as there are now multiple good 2.5 GbE based platforms out there..

Yes, and no updates for the driver in 1.3.2. Ok, thanks!

@pasik the problem is with the igc driver in the 5.4 kernel, not with vyos.

Sorted out the WARNING: terminal is not fully functional message with adding the following export command: -

Yeah, that new nightly release has fixed the issue, thanks. Strangely now getting some weird message in my show commands (WARNING: terminal is not fully functional). This message wasn't there on the previous nightly.

So hmm, is it still the same issue in stock vyos 1.3.2 with i225 nics?

@narey83 Could you re-check it with the latest rolling (start since vyos-1.4-rolling-202209290218-amd64.iso)?

@icyfire0573 Could you re-check it?
Should be fixed in vyos-1.4-rolling-202209290218-amd64.iso

I can't reproduce it, VyOS 1.4-rolling-202209290218
Config:

vyos@r14:~$ show conf com | match openv
set interfaces openvpn vtun10 hash 'sha1'
set interfaces openvpn vtun10 keep-alive failure-count '60'
set interfaces openvpn vtun10 keep-alive interval '10'
set interfaces openvpn vtun10 local-host '203.0.113.1'
set interfaces openvpn vtun10 local-port '1194'
set interfaces openvpn vtun10 mode 'server'
set interfaces openvpn vtun10 openvpn-option '--data-ciphers-fallback BF-CBC'
set interfaces openvpn vtun10 openvpn-option '--data-ciphers AES-128-CBC:AES-128-GCM:AES-256-CBC:AES-256-GCM:BF-CBC'
set interfaces openvpn vtun10 openvpn-option '--comp-lzo yes'
set interfaces openvpn vtun10 openvpn-option '--allow-compression yes'
set interfaces openvpn vtun10 openvpn-option '--push redirect-gateway def1'
set interfaces openvpn vtun10 openvpn-option '--push remote-gateway 10.9.1.1'
set interfaces openvpn vtun10 openvpn-option '--push dhcp-option DNS 8.8.8.8'
set interfaces openvpn vtun10 protocol 'udp'
set interfaces openvpn vtun10 server client-ip-pool start '10.9.1.10'
set interfaces openvpn vtun10 server client-ip-pool stop '10.9.1.99'
set interfaces openvpn vtun10 server domain-name 'vtr.example.com'
set interfaces openvpn vtun10 server max-connections '1000'
set interfaces openvpn vtun10 server name-server '10.8.0.1'
set interfaces openvpn vtun10 server subnet '10.9.1.0/24'
set interfaces openvpn vtun10 server topology 'net30'
set interfaces openvpn vtun10 tls ca-certificate 'ca'
set interfaces openvpn vtun10 tls certificate 'cert'
set interfaces openvpn vtun10 tls dh-params 'dh'
set interfaces openvpn vtun10 use-lzo-compression
vyos@r14:~$

Op-mode

vyos@r14:~$ show openvpn server

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.