It is true what @Viacheslav say, there is only possible to run one instance of bgp om a given router.. when using vrf's the bgp running inside the vrf is a subset of the main instance. to confirm, start vtysh and try to create multiple processes.. it will likly fail :)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 19 2019
As for my understanding frr only supports a single bgp instance running at a time. But i've not verified thid completly.
Oct 18 2019
As the AS number is a bgp specific attribute i don't think it's wise to move it out of the bgp hierarchy .
@c-po what you are describing don't look like a bug.. its more like a feature :) anyways its not related to this issue so please open another ticket on this.
Oct 15 2019
Also, as we are implementing this into the vyos cli, we can only omplement a small subset of the squid functionallity without doing lare efforts on implementing everything.. thats also why i favor to removing this functionallity..
+1
Oct 14 2019
Because the amount of logs from this system could be enormous, Is it possible to move these logs to another syslog file to not overcroud the main syslog file?
@hagbard This is still an issue in conf-mode. to replicate:
Oct 1 2019
@kroy just to be clear, i'm not against using dns as endpoint for wireguard.. i'm for it, because i have the same issue as you do, but what i'm against is the way to getting there. As the wireguard protocol does not support dns in it self using this method is a loosing game.. what i'm not against is writing a daemon that does the name resolution for you when it comes available.. and available could mean after 1sec, 1m, 1h or even longer after the system is booted.. this daemon also could do re-resolving when the peer is down and the dns has changed...
As for openvpn i dont know, but if the app itself does dns queries on connect it will work quite fint (as i think it does)
As i tried to say, this fix will only work in some scenarios, and this comes down to the implementation of the app were configuring. And to be clear, wireguard does NOT support dns, but the wg config utillity does. On execution time it reads the dns name and tries to resolve it once, and only once. When it fails things would not work.. this is the same with eg. Nhrp that works exactly the same.. using this has raise conditions with getting ip up and running and not only on the host file. We do not wait for dhcp to delegate an address or dns servers.. these could come many ms/sec after wireguard is configured.. this is even true in the case when you change the priority.. and the length of the config/execution time also comes in as an parameter in this raise condition.. so, if you ask me, revert the priority and instead create a dns daemon thing that could read the config and populate the entry when it has failed.
Sep 30 2019
Changing the priority will only change a portion of this. It.. could fix the situation there the user have static ip and a default route, but will not give effect when the user has dhcp or uses bgp el.. so my wote goes to not changing priorities on this. This is a loosing race as long as we dont have a daemon el. That manages the connections..
Sep 26 2019
Sep 15 2019
the error in the test-log is just the errorcode, but the real error message is a memory allocation error:
vyos_bld@dd27213bf7b5:/vyos/ipaddrcheck/src$ ./ipaddrcheck Error: could not allocate memory!
The same build procedure is tested fine on x86_64 and armhf without this issue
Sep 12 2019
Sep 7 2019
As a workaround could this be added as the first lines of the bash script?
This will check the primary group the script executes via and respawn as the vyattacfg group if it's something else before continuing.
if [ $(id -gn) != vyattacfg ]; then exec sg vyattacfg "$0 $*" fi
NB! the if is necessary because the script should not execute the exec when you respawn as correct group.
You will end in a exec loop if its not there .. :)
i've not tested this on vyos, but have helped me on other systems
Sep 6 2019
i agree with allowing this.
Aug 27 2019
improvement suggestion:
- remove the use of + in hash-policy names. layer2+3 and layer3+4. this could be replaced with the more used - character, so layer2-3 and layer3-4
- also add support for encap2-3 and encap3-4hash-policy
It is true that you need a hash-policy, but specifying a hash-policy is optional, if you don't specify it reverts to the kernel default that is layer2..
also defaults should not be listed in the configuration. (because then the configuration will be crowded with all kind of strange things that is a default)
Improvement suggestion:
set interfaces bonding bond0 hash-policy # defaults to layer2, listing layer2 as an configureable alternative is then redundant. to revert to level2 the user should delete the config entry instead. also update description about using layer2 as a default
Aug 23 2019
Full console dump to reproduce with comments:
## ## Start without anything
the current only way to get the interface added to the group is to remove and readd it to the group.
vyos@vyos# brctl show bridge name bridge id STP enabled interfaces br1 8000.525405123456 yes eth0.1
i've updated the description. the bridge is created and comitted prior to the creation of the interface.
Aug 22 2019
Aug 21 2019
@UnicronNL , no need to apply the patch, it is already applied to the codebase. this issue needs to be something else
@UnicronNL could you apply my patch to the codebase?
Aug 18 2019
I've also tested this on the newly released dune1.11.1 with the same result
Aug 16 2019
Maybe you could comment on this @zx2c4 ?
Aug 13 2019
A note when stating to convert physical interfaces.
Please keep this in mind when rewriting dummy/loopback interfaces: https://phabricator.vyos.net/T1467
Aug 10 2019
Thanks :) i see the pull message is updated, but could you also update the commit message to reflect this?
Hi! Thanks for the contribution!
Aug 9 2019
This sounds like a good improvement!
Is this still an issue?
Most of these files are autogenerated and dont need to be saved across reboots.. is it possible to make them in a overlay that does not save to disk? Or another aproach is to just delete them when the device starts (before or when vyatta starts)
Aug 8 2019
Aug 3 2019
This is a good start! The names should be made pythonic and why not use getters and setters? Then we dont need set_ functions but use the objects directly.
Jul 18 2019
This also affect manually built iso's that also fails because of pdns-recursor
Hi! The rolling release is broken because pdns-recursor has stopped to provide packages for jessie and the current index points to a file that is currently not available. We are working on fixing this and it migth be that we need to start building it ourself instead.
Jul 11 2019
As long as its allowed but not working its a bug.. :)
Jul 9 2019
Jul 6 2019
I've updated all found instances of hardcoded eth instances to also take systemd interfaces names. this will be working when were upgrading to buster.. i've built an iso with these changes and i'm able to set an ip on my ens3/ens4 nic's and it works. for buster this could be a solution on this issue. the question then is if buster comes soon enough to not rewrite these scripts until then.
Jul 4 2019
As i commented : the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think..
As for now, the mapping scheme is done with mac adress=>name, so as long as the mac address dont change and you preserve the persistent interface mapping file you should be all good.. i'm wondering if its possible to migrate from a mac-address mapping scheme to instead use eg. Pci index.. but havent found any good solution on this.. the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think.. so for now it's going to be mac address=>name
Jul 2 2019
The issue here is not the scripts themself, it is our(vyattas) mixing of hardware/ system configuration.. the ethernet mapping table is a device specific table that only works on one particular device, all other configuration inside vyos is portable between devices, but this information is not.
This also makes it impossible to move a config file to another hardware without modifications (removing the hw-id mappings)
Jul 1 2019
Jun 30 2019
Hi rob! Nize that more people is involved in this :) i've started the large task of marking things that have been migrated to github, it's a lot of pages with outdated info thats not going to be migrated, also i find a lot of pages not having enough "end user" documentation that i don't know where to put.. eg. devel docs etc..
Jun 29 2019
and always download the latest upstream driver
i think that out-of-tree drivers also needs to be under the same control as modules and the kernel
Jun 22 2019
with my last post in mind, here are the workings of a cisco IOS loopback:
router(config)#int loop 123 router(config-if)#ip addr 1.4.4.1 255.255.255.0 router(config-if)#exit router(config)#exit
@zsdc Thanks for your comments!
Thanks for quick reply! :)
Jun 21 2019
When were talking web-interface (not the api itself) it needs to have the functionality to "stage" multiple changes before commit'ing everything in one go, just like in the cli
Jun 19 2019
Jun 18 2019
this is also the case for ping 127.0.0.1 count 100 flood
Jun 5 2019
When you downloaded vyos-build did you download it or used git clone? It complains about an invalid git repository so i suppose you used the download option?
Is the vyos-builder container newly created?
What command did you use when starting the docker container? Make iso also require sudo to run but missing sudo that not generate that error message
May 31 2019
May 28 2019
May 17 2019
Hi yun, please open a new ticket with your issue, and make a reference to this case :)
Apr 25 2019
added not on old-style cfg-mode templates
Added a sidenote about switching on router and routing on switch
First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6
Apr 16 2019
@hagbard This commit adds a route to the kernel routingtable and bypassing FRR, this is no good and this would break. Please make the script add the appropiate commands to frr instead. This way frr will be in charge of populating the kernel table. Also note that this route needs to be removed on dhcp release
Apr 5 2019
That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..
looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….
When a host-name is not present, set the same default as on a newly installed device... router or vyos.. (atm. i don't remember what it says)