PR https://github.com/vyos/vyos-1x/pull/1584
vyos@r14# cat /run/telegraf/telegraf.conf | grep 'inputs.exec' -A 8
[[inputs.exec]]
commands = [
"/etc/telegraf/custom_scripts/show_firewall_input_filter.py",
"/etc/telegraf/custom_scripts/show_interfaces_input_filter.py",
"/etc/telegraf/custom_scripts/vyos_services_input_filter.py"
]
timeout = "10s"
data_format = "influx"
[edit]
vyos@r14#PR for 1.3 https://github.com/vyos/vyos-1x/pull/1583
I believe the ISC DHCP is now officially deprecated and EOLed:
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1582
PR https://github.com/vyos/vyos-1x/pull/1581
vyos@r14:~$ show conntrack table ipv6 Entries not found vyos@r14:~$
In T4729#135230, @pasik wrote:Ah, yeah, that's a valid point for gretap.
Anyway, my point was, it would be good to test if the issue/bug also affects plain 'gre', as behind the scenes 'gre' and 'gretap' are handled and configured differently, even though they might seem as very similar in vyos cli/config.
The bug might affect both, but it would be good to check and verify.
zone policy has to be assigned to the firewall rule, that's why the commit failed.
@florin If this is needed I'll make a pull request coming week.
I think this needs to be backported to 1.3 too
I have tested it again. So it happens only if conntrack table is empty.
The same problem with IPv4.
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
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.