The dockerhub image is just an environment capable of generating the vyos image, it does not include any of the files needed to generate the image itself. These files are inside the vyos-build repository.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 18 2020
To clarify the hw-id tag. This is the only way VyOS scripts know what interface to give what name on bootup, as the boot-order of nics could be different on every reboot (potentially) vyos needs a way to identify the "correct" order of the nics when it boots. if you remove the hw-id tag from the interface the configuration script don't know what interface to give the configuration to, so you could potentially get nic-reordering on every single reboot.
What repository, and what errors? :)
May 10 2020
I've added an extra bulletpoint that needs to be fixed in the comment prior to this one.
VyOS dont provide the packages upstream to anyone, and a package is only installed at image create time and never upgraded. And as the changelog have up to now newer been used i dont see the point of over-complicating this. This will only make it harder to make a release image as more unnecessary (as i would call it) steps are added to the process.
Yes, i'm aware of these modifiers. But the issue here is not to generate newer then the upstream, because we are the upstream. these changes are to make the version visible in our upstream packages. the current solution with manually versioning does not work because the Debian version is "never" incremented. (there could be hundreds of commits between each version increase..) and in the mean time it is quite hard to identify exactly what changes are made to the package in the image. for this we automatically change the version tag on build-time and adds the most resent git version tag and the number of commits since that tag visible in the upstream version tag. as for the "downstream" part of the version tag we out the git commit id and info about the "state" of the repo on build-time. those we also could identify if the package build is indeed the upstream package or a custom package by the user. :)
upstream version will be in the format of : <git-version-tag> - <commits from tag> and downstream version: -g<commit-id>(+<dirty>)? an example : 1.3dev0-4 -g1234567 and 1.3.0-0 -g1234567
May 8 2020
May 3 2020
Apr 23 2020
"This is fine if used in conf_mode scripts that'll create it after that anyway" if the intention of the code was not to create the interdace this is not fine if you ask me. :)
thats correct @jjakob , when a mac is changed on a interface the ONLY place to find the original mac address for a interface is using the hw-id, this is because the kernel does not hold track of the original mac anywhere. for now on saving the config it reverts back to the original hw-id mac when the mac node is deleted witch should be quite fine to do. When the old boot interface mapping code is rewritten these pointers also need to match the new scripts. but thats another storry :)
Apr 18 2020
Actually, specifying wireguard peer as a hostname only worked on initial setup. The reason for this is that the hostname is resolved only on initial startup of the wireguard tunnel. On boot the ip stack is not fully operational resulting in wireguard beeing unable to resolve hostnames. (But this avtually could depend of the execution time of the initialization scripts) .. a better alternative to this is to make a initialization script that is delay'd and then resolves the hostname and inserts the correct ip in wireguard when the router is fully booted. This could be created using a custom script called from the post-bootup script or something like that.
Apr 13 2020
Apr 12 2020
Any comments @dmbaturin ?
Apr 11 2020
Apr 10 2020
Change description since last update:
Change description since original update.
versioning of 1.3dev-3-g1234567 will count as newer then 1.3dev3-3-g1234567 this means that all dev releases needs to have a initial index. i've added it indexed from zero.
for a full version list see here
Original order Sorted order Upstream Version 1.3dev-0-g1234567 - 1.3.1-2-g1234567 : 1.3.1-2 1.3dev0-0-g1234567 - 1.3.1 : 1.3.1 1.3.1-2-g1234567 - 1.3.0-7-g1234567 : 1.3.0-7 1.3.1 - 1.3.0-3-g1234567 : 1.3.0-3 1.3dev2-8-g12345671.3.0 - 1.3dev-4-g1234567 : 1.3dev-4 1.3.0-7-g1234567 - 1.3dev-0-g1234567 : 1.3dev-0 1.3dev - 1.3dev2-8-g12345671.3.0 : 1.3dev2-8 1.3dev-4-g1234567 - 1.3dev2 : 1.3dev2 1.3dev1 - 1.3dev1-4-g1234567 : 1.3dev1-4 1.3dev2 - 1.3dev1 : 1.3dev1 1.3dev1-4-g1234567 - 1.3dev0-1-g1234567 : 1.3dev0-1 1.3.0-3-g1234567 - 1.3dev0-0-g1234567 : 1.3dev0-0 1.3dev0-1-g1234567 - 1.3dev : 1.3dev
Apr 9 2020
Vrfs are for now not supported in dynamic routing protocols, only static routing is for now possible. Se also comment in T2257
For now only static routing supports vrf, bgp, ospf and rip does not support vrf for time beeing. Support for this is being workes on, but its quite a large rewrite required to add support for this in bgp.
Apr 2 2020
This is only for interfaces, T2175 is for all frr related daemons .. other features need a ticket
Mar 29 2020
Mar 20 2020
As the mtu on an ip network could exceed 1500b it is not so strange to allow larger than 1500b frames on the tunnel. But this could be adjusted to follow the max mtu values on ethernet interfaces. As taken from my head max mtu on ethernet is about 9000b
Feb 13 2020
Feb 12 2020
as discussed on slack, GRE is already supported: https://docs.vyos.io/en/latest/vpn/gre-ipsec.html , closing as invalid
Jan 22 2020
This also could be the same issue as described in T577
This issue is possibly fixed in current by ticket T1970, could you retry with the newest current rolling release?
Jan 20 2020
PR for this fix: https://github.com/vyos/vyatta-cfg/pull/20
Jan 1 2020
Dec 20 2019
This is a known fault, and is not easily fixable in the current implementation. This fault is because the vuos cli manually configures the frr process after it's started, and when the process dies/restarts it will read its config from the saved config file. This makes the process restart into an empty config as we have no way to save the config from the prior process.
Dec 8 2019
This looks like the same issue as described in T1846, can anyone confirm this?
Dec 5 2019
There have been some time since i've managed to work on this now, and in the mean-time the whole ethernet/bridge sertup have been rewritten into python, so i need to restart my work on this implementation , also the bridge membership part is moved around in the cli so information in this ticket is out-of-sync with the current implementation and needs to be rethinked
Dec 1 2019
as far as i know the content of the platform field is the first characters from sysdescr (20 characters?). on one of my devices this is
System Description: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE8, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2015 by Cisco Systems, Inc. Compiled Thu 14-May-15 02:39 by prod_rel_team
Oct 31 2019
To fix this inconsistancy the output of show int ethernet | json should be:
{ "eth0": { "address": "10.10.10.10/24" } }
Oct 27 2019
With this, will there also be possible to parse the same json into an json import? This to allow for a more programatic way to add things than via set commands
Oct 23 2019
Whats happening here is that the non-commit-able session is saved to disk. because of this BGP will fail on reload because of illegal configuration on the peer. What needs to be done here is to disallow the save command when there are non-commited work in the session.. or at least give a clear warning about this with a [y/N] answer. is this possible to incorporate into vbash? @dmbaturin
Oct 19 2019
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 :)
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.