- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 29 2020
This has a dependency on python3-flask-restx, which will need to be added using, for example, T2396.
Apr 28 2020
Marek Isalski Today at 6:31 PM
We've got full IPv4 and IPv6 routing tables on our VyOS boxes, and we *definitely* needed to increase net.ipv6.route.max_size (we picked 256k to give us some headroom).
Some statistics from ipv6 bgp summary
@thomas-mangin the sessions are still stable, for 7 days now. The only thing changed was that max_size limit. Also no packetloss on the IPv6 connections has been observed during this time.
Apr 27 2020
@Merjin is trying this:
sudo sysctl -w net.ipv6.route.max_size=131072
https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115
Apr 26 2020
any L2/L3 issue affecting TCP between the BGP speaker will cause this message. Looking forward to a TCP dump of the traffic when it occurs.
Apr 25 2020
@syncer Re-opening this. Had the first exact same incident on a different router with an IPv6 BGP session on a RJ45 connection, so that would rule out any issues with the Intel X710 card in relation to this issue.
Apr 24 2020
We ave no RPKI filtering active yet, so https://github.com/FRRouting/frr/issues/5458 seems not related.
Apr 23 2020
Apr 20 2020
Apr 18 2020
Apr 17 2020
I have made pull request in https://github.com/vyos/vyos-1x/pull/352, please help to review it.
I have made pull request in github, please help to reviw it: https://github.com/vyos/vyos-cloud-init/pull/8
This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved
This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved
Apr 16 2020
I can confirm this bug, also exist in 1.2.5 OVA
Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.
Is 1.2.3 was deployed from OVA or install from ISO?
Which hypervisor?
Apr 13 2020
Found that in drivers 2.3.6 and newer this should also work:
Note: will be good to disable this by udev rule for i40e
Upgraded the firmware of the X710 adapters from 6.0 to 6.8, waiting for Dell to get 7.0 and 7.2 ready. But for now the sessions are 18 hours stable so little optimistic that it was a firmware issue and not BGPd causing issues
Apr 12 2020
There are no other reports about such issues
we need valid reproduction procedure for this, otherwise, not much that we can do
Apr 11 2020
@Dmitry
set system flow-accounting interface 'eth4.XX'
set system flow-accounting interface 'eth4.XX'
set system flow-accounting sflow agent-address 'xxx.xxx.169.246'
set system flow-accounting sflow sampling-rate '2048'
set system flow-accounting sflow server xxxxx.tld port '6343'
@blackmetal provide, please flow accounting configuration show configuration commands | strip-private | match flow for reproducing
Apr 8 2020
T2199 for the firewall rewrite - free for the taking. I wouldn't stray much from the old code logic, as some things have hidden meanings. Especially leaving checks out could introduce bugs unless you're absolutely sure they can be bypassed.
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.
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