User Details
- User Since
- Aug 3 2017, 1:55 PM (186 w, 2 d)
Today
Temporary workaround for the VyOS 1.3-rc1 users:
Yesterday
Backport is complete - It will "work" once the 1.3 kernel is updated to 5.10 series
This is not applicable to VyOS 1.4 because of T3364.
Fri, Feb 26
Thu, Feb 25
This should have been fixed in the latest 1.3 beta - please try again
Wed, Feb 24
Better not touch crux ;)
Tue, Feb 23
If that works out wihtout an issue I would like to have it backported into 1.3 just to be more "fancy".
Mon, Feb 22
Any chance you can send this as GitHub PR?
Sun, Feb 21
Unfortunately I can not connect the dots between "still the same process" and set protocols bgp <asn> vs. set protocols vrf <vrf> bgp <asn> (I explicitly left the "move bgp tagNode to node with local-as" topic out of the discussion as this is something different and is addressed via a different task)
FRR actually supports configuring a different ASN per VRF in contrast to other vendors
Sat, Feb 20
Which VyOS CLI command enables LRO?
Fri, Feb 19
at first glance this looks very interesting. Befor this can be added I would like to give the following comments:
- adding a cli node that passes raw config values from cli to the daemon is bad (we inherited this for dhcp and openvpn and it caused more harm then good in the last 2 years) - is this mandatory?
- even dns using A, AAAA, PTR upper case types we should keep the CLI lowercase - this can be easily handled within the Jinja2 template.
- having > 20 dns records here could really bleow up the CLI, maybe we should thing about loading the zone from a file @zdc @dmbaturin @jestabro?
Thank you for giving put bleeding edge codebase a spin - I will check this out.
Can we also extend the available BGP smoketests to test this?
A verify() step will be added to prevent certain configurations when a specific type of driver is used. In this case if the xen driver is used, and MTU is > 1500 and sg is not set, a ConfigError() will be raised.
Thu, Feb 18
If this package supports all existing setups and the GRE usecase I see no reason to not replace it. @basalblas PR is happily accepted.
Wed, Feb 17
DHCPd shold be vonsistent for both v4 and v6 - running different daemons is simply bad.
Perfect, thanks