I have investigated this a bit. Most operations for ports are doing one-by-one. Deleting as I see is always done in this way. Adding a range is done by a single command, but checking ports are doing one-by-one.
If we skip/change mentioned checking for adding ports, this should decrease initial commit time. But when we try to change/delete ports, the issue will back.
I think that there should be better to reimplement the whole firewall group section in Python, instead of fixing this logic now.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 8 2020
Apr 4 2020
To track similar https://github.com/FRRouting/frr/issues/4471
Apr 3 2020
My main question is why is this message displayed and do we need to worry.
I have had the maximum-paths setting for years since Vyos 1.1.x and I have a lot of routes ipv4 and ipv6 installed in the routing table with 2 or 3 routes even if they are not the same. I am not specifically using ecmp I just have multiple routes for fast failover.
For the ECMP it's necessary that as-path length, weight, localpref, med, etc were the same.
Only, in that case, more than one eq route will be installed in the routing table.
I have the following:
set protocols bgp as maximum-paths ebgp '3'
set protocols bgp as maximum-paths ibgp '3'
@Merijn If you don't use ECMP, only one best route will be installed in routing table.
In your case, the best path via 20562 6830 198611 with localpref 140.
In the bgp table, all prefixes will be present.
It's a general BGP Best Path Selection Algorithm.
The same is true for ipv4.
After receiving
zebra[1507]: 0:2804:fa0:8000::/33: Route install failed
How about parallel loops?
https://metacpan.org/pod/Parallel::Loops
Apr 1 2020
Mar 31 2020
Mar 13 2020
Works properly on VyOS 1.2.5-epa1 (FRRouting 7.2-20200121-02-g031c58) and 1.3-rolling-202003130217(FRRouting 7.3)
Mar 12 2020
Thanks @jestabro , works well with this change. After passing all the tests, I will write docs about VyOS in container.
Mar 11 2020
@Dmitry The simplest workaround for the moment is to add the following to your load steps:
I've tracked this down to a bug in libboost-filesystem, versions < 1.56, that occurs if the locale is not properly set, as is the case within the Docker environment:
Mar 10 2020
Mar 9 2020
Mar 2 2020
Feb 29 2020
All works as expected; thanks.
redeployed. please try again
Problem is local to crux only
Feb 27 2020
i think, you sould use crux branch for 1.2 build, current branch is 1.3
Feb 23 2020
A fix for this is available in the latest rolling release
Feb 21 2020
Feb 20 2020
Feb 16 2020
Feb 13 2020
$ make drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.i $ grep UNIQUE_ID_firmware drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.i
Feb 10 2020
Feb 8 2020
Feb 5 2020
Feb 2 2020
Okay, packages have been recreated for Debian Buster and RADIUS login works again (50%)
Feb 1 2020
Reason this is broken is b/c VyOS 1.2 crux uses libpam-radius-auth from Cumulus Linux
ii libpam-radius-auth 1.5.0-cl3u1 amd64 PAM RADIUS client authentication module
Jan 30 2020
Jan 29 2020
Jan 28 2020
Jan 27 2020
@hagbard, thank you! This feature works properly, last value define how many sessions server can to serve
works as expected on 1.3-rolling-202001270217
Jan 26 2020
I also can confirm this works in 1.2.4
Jan 24 2020
PR https://github.com/vyos/vyos-1x/pull/209
also added missing completion help values.
Jan 23 2020
Let me know if you come across any issues.
By default we don't need delay, I think it must be configurable feature.
set service pppoe-server pado-delay delay 100 sessions 100 set service pppoe-server pado-delay delay 200 sessions 300 set service pppoe-server pado-delay delay 300 sessions 1000
and configuration for this
@Dmitry What default delays do you suggest?
Jan 22 2020
When using logrotate we can take full owership about the resources that will be used for number of files and its size - so i think this will be the best approach.
I've attached a simple patch to expose FRRouting's built-in capability of being able to apply a route-map to routes that are submitted to the FIB from BGP to VyOS.
Why we not fix just logrotate config for it?
Jan 21 2020
Jan 20 2020
I've attached a simple patch to expose FRRouting's built-in capability of being able to set a prefix's local administrative distance to VyOS.
I've attached a simple patch to expose FRRouting's built-in capability of being able to match on prefix's BGP local preference to VyOS.
I like the idea, but unfortunately I do not understand why there needs to be a cancel node? If maintenance mode is not activated shouldnt this be enough?
Jan 19 2020
Jan 15 2020
Works in 1.3-rolling-202001150217, propose cherry-pick in to crux.
Jan 13 2020
The described problem exists in stable FRR 7.2, but fixed in FRR master branch by https://github.com/FRRouting/frr/pull/5184
We have tested 7.2 with this PR applied, and the bug was gone, so we can apply this PR to our FRR package and solve the problem.
Jan 12 2020
I was getting a lot missing dependencies even all the vyatta/vyos-* packages were being complained that they were required but weren't being installed. I'd already deleted and re-cloned the build repo and cleaned out my local docker several times so i'm not completely sure what fixed building 1.2 ISOs again. Frustrating but at least it's working for the time being.
Jan 10 2020
@bmhughes For me an issue was that cpio is missing from the docker image
edit:
I can build working images now, I have no idea what's changed over what i've been trying for the last few days.
@bmhughes I tested this on the downloaded lts 1.2.4 iso and it seems to work fine...
Service custom don't support 2 ddns entries now.
It overwrite login/pass to (login02) for each custom service
Please use service custom