1.4 rolling does not help me, so there must be something "wrong" with my configuration. I've attached the private config, it would be awesome if someone might find what's broken.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
May 27 2022
May 27 2022
May 26 2022
May 26 2022
Viacheslav moved T4442: HTTP API add action "reset" from Need Triage to Finished on the VyOS 1.3 Equuleus (1.3.2) board.
GitHub <noreply@github.com> committed rVYOSONEXf2bc9448f8fb: Merge pull request #1335 from sever-sever/T4442-equ (authored by dmbaturin).
@panachoi , for me moving to 1.4 rolling release did the trick. Boot times went from > 10 mins in 1.2 to 2-3 minutes in 1.4. Hope that helps
Some debug info:
@panachoi If you can share the anonymized config that works in 1.2.8 that would be useful. I'd expect migrating to 1.4 to see a decent improvement in firewall load times.
I'm still having issues moving past anything higher than 1.2.8. Booting 1.2.8 looks thusly:
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1335
Unknown Object (User) added a comment to T4444: sstp: Feature request. Port number changing support.
showipintbri added a comment to T4445: [EDIT] Service Restored: Outage: Interface stops forwarding, IPv4 martian seen in the logs.
I'm trying to think what could have a 110 minute timer and the only think I can think of is the DHCP lease time:
May 26 05:58:49 rtr dhclient-script-vyos[7261]: No changes to apply via vyos-hostsd-client May 26 05:58:49 rtr dhclient[7216]: bound to 72.81.238.169 -- renewal in 3075 seconds.
GitHub <noreply@github.com> committed rVYOSONEX9854c72dfc8c: Merge pull request #1332 from c-po/t4441-equuleus-wwan (authored by c-po).
Unknown Object (User) renamed T4444: sstp: Feature request. Port number changing support from sstp: Feature request. Add support to change port number to sstp: Feature request. Port number changing support.
showipintbri added a comment to T4445: [EDIT] Service Restored: Outage: Interface stops forwarding, IPv4 martian seen in the logs.
I just caught it again. Same logs line up with my continuous ping.
Unknown Object (User) added a project to T4444: sstp: Feature request. Port number changing support: VyOS 1.4 Sagitta.
Unknown Object (User) created T4444: sstp: Feature request. Port number changing support.
GitHub <noreply@github.com> committed rVYOSONEXe25afbf4a589: Merge pull request #1333 from sever-sever/T4442 (authored by jestabro).
May 25 2022
May 25 2022
masterit changed the status of T305: loadbalancing does not work with one pppoe connection and another connection of either dhcp or static from On hold to Open.
Viacheslav moved T2763: New SNMP resource request - SNMP over TCP from Open to Finished on the VyOS 1.4 Sagitta board.
GitHub <noreply@github.com> committed rVYOSONEX7c1cb045ebbf: Merge pull request #1331 from jestabro/configtest-errors (authored by jestabro).
c-po added a comment to T4441: wwan: connection not possible after a change added after 1.3.1-S1 release.
PR pending approval https://github.com/vyos/vyos-1x/pull/1332
jestabro added a comment to T4382: Replacing legacy loadFile exposes missing steps in migration scripts and other errors.
PR fixing exposed errors:
https://github.com/vyos/vyos-1x/pull/1331
jestabro renamed T4382: Replacing legacy loadFile exposes missing steps in migration scripts and other errors from Replacing legacy loadFile exposes missing steps in migration scripts to Replacing legacy loadFile exposes missing steps in migration scripts and other errors.
Unknown Object (User) awarded T751: IDS and IPS (suricata) a 100 token.
goodNETnick <pknet@ya.ru> committed rVYOSONEXea83ba23b998: ocserv: T4420: show configured 2FA OTP key.
GitHub <noreply@github.com> committed rVYOSONEXec3a05d3dfda: Merge pull request #1319 from goodNETnick/ocserv_sh_otp_key (authored by Viacheslav).
Viacheslav closed T2194: "show firewall" garbled output, a subtask of T2199: Rewrite firewall in new XML/Python style, as Resolved.
GitHub <noreply@github.com> committed rVYOSONEXa943c7f36ffd: Merge pull request #1088 from zdc/T4020-sagitta (authored by dmbaturin).
May 24 2022
May 24 2022
jtcarnes changed the status of T4440: Add OCI compliant image labels to vyos-build and vyos containers from Open to In progress.
I removed my comment as my issue was not a bug AFAIK, but rather a miss-configuration and operation.
May 23 2022
May 23 2022
cgb added a comment to T4147: New Firewall Implementation - proposed changes on group implementation.
Yeah I discovered the same in forums:
adestis added a comment to T4147: New Firewall Implementation - proposed changes on group implementation.
I was not aware that the nft implementation changes the kind of how groups are used.
We have implemented a blacklisting approach which heavily relates on using ipset because no one wants to have hundred thousand of addresses in the config file.
So I think this is essential, at least for us.
May 21 2022
May 21 2022
c-po changed the status of T4437: flow-accounting: support IPv6 flow collectors from Open to In progress.
May 20 2022
May 20 2022
c-po changed the status of T4350: DMVPN opennhrp spokes dont work behind NAT from Open to Needs testing.
Viacheslav renamed T4435: Policy route and firewall - error when using undefined group from Policy route without definded port-group erros to Policy route without defined port-group error.
Viacheslav reopened T3522: policy based routing not working, a subtask of T3505: Commits do not respect changes in FRR that are not stored in a config, as Open.
Viacheslav closed T3522: policy based routing not working, a subtask of T3505: Commits do not respect changes in FRR that are not stored in a config, as Resolved.
GitHub <noreply@github.com> committed rVYOSONEX8dc416ade4fc: Merge pull request #1317 from sever-sever/T4418 (authored by c-po).
Viacheslav added a comment to T4431: route-map with match ip + ipv6 in same rule results in no advertisement of either.
FRR match always mean logical AND
In T4350#123620, @c-po wrote:Is the fix for DMVPN hub or spoke?
May 19 2022
May 19 2022
Viacheslav added a comment to T3933: The firewall does not filter incoming traffic on the interface with vrf..
There is an issue with vrf device for LOCAL direction
Imagine if you have 50 interfaces in one VRF and you want to drop all traffic from one interface for example - eth2 and don't touch other interfaces
You set firewall on eth2 Local - drop all traffic for device vrf and it will be affected to another 49 interfaces as iifname VRF_DEVICE the same
May 19 2022, 9:49 PM · Bugs, VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-GA), Restricted Project
Is the fix for DMVPN hub or spoke?