Added PR for this here, https://github.com/vyos/vyos-1x/pull/1574

I implemented address-mask as described above as well: https://github.com/Rain/vyos-1x/commit/ca6b7340714c6161337f508978b9834722be58dc

A separate mask field is cleaner also from a documentation point of view. But how would you do it for an address/network group? It only makes sense for a single address I suppose.

On second thought, maybe instead of supporting the ::beef/::ffff syntax we add an address-mask field to source and destination?

I closed the other PR, and put in https://github.com/vyos/vyos-1x/pull/1572.

I'd like to see this feature added so I went ahead and implemented it: https://github.com/Rain/vyos-1x/commit/975f4fc358f0073f1ad825ea209169766dc2fa51

Working directory here; PR pending:
https://github.com/vyos/vyos-1x/compare/current...jestabro:gql-simplify

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.