- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 10 2022
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.
Oct 9 2022
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.
Oct 8 2022
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
Oct 7 2022
Working directory here; PR pending:
https://github.com/vyos/vyos-1x/compare/current...jestabro:gql-simplify
Oct 6 2022
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
Oct 5 2022
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".
Oct 4 2022
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
Oct 3 2022
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)?
Oct 1 2022
Is there a way to isolate a NAT rule to operate within a VRF?
Sep 30 2022
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.
Sep 29 2022
@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