The following adds support into the XML generation but I have no clue about vyatta-cfg how those files get executed.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
May 1 2020
May 1 2020
Presumably a val_help line in the op-mode node.def, too
c-po added a comment to T2129: XML schema: tagNode not allowed on first level in new XML op-mode definition.
Tested good - migrating traceroute now
c-po changed the status of T2129: XML schema: tagNode not allowed on first level in new XML op-mode definition from Open to Blocked.
Apr 30 2020
Apr 30 2020
On boot, the existing config file is committed.
jjakob triaged T2410: Unify addressing and options of dummy and other interfaces as Wishlist priority.
Right. In my opinion it would be necessary to change that.
Definition of effective is here:
Unknown Object (User) updated subscribers of T2408: DHCP Relay upstream and downstream interfaces.
jjakob triaged T2409: At boot, effective config should not be equal to current config as Normal priority.
Unknown Object (User) added a comment to T1276: dhcp relay + VLAN fails.
Enhancement created.
Question to ISC submitted (https://gitlab.isc.org/isc-projects/dhcp/-/issues/104)
Unknown Object (User) triaged T2408: DHCP Relay upstream and downstream interfaces as Normal priority.
thomas-mangin updated the task description for T2407: alternate installation for the vyos-1x python code.
jestabro edited projects for T2397: HTTP API: export OpenAPI definition, added: VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
jestabro edited projects for T2396: Add debian package for flask-restx, added: VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
jestabro edited projects for T2395: HTTP API move to flask/flask-restx as microframework, added: VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
Unknown Object (User) added a comment to T1276: dhcp relay + VLAN fails.
@ddiguru
I confirm all the issues that you have observed. I was able to reproduce them in the both our LTS and currect rolling releases.
- Issue with a wrong giaddr address. This sounds like a bug in the isc-dhp-relay package. Fortunately, those extra packets with a wrong giaddr address could be eliminated in newer versions by using "-id" and "-iu" instead of muliple "-i" options. isc-dhcp-relay allows for this since v4.3.5. I will create a Feature Request to modify the VyOS config syntax and isc-dhcp-relay config file accordingly. In the meantime I will try to confirm with ISC people that this indeed is a bug.
- Issue with duplicate packets. isc-dhp-relay seems to unnecessarily relay unicast packets (I have no idea why it does so). That's why you see all unicast packets doubled. Looks like another bug :) The good news is that it is more cosmetic issue. I already submitted the ticket for it (https://gitlab.isc.org/isc-projects/dhcp/-/issues/102)
zsdc changed the status of T2309: Wrong host-name value breaks the whole configuration in images with Cloud-init from Open to In progress.
zsdc changed the status of T2403: Full support for networking config in Cloud-init from Open to In progress.
kroy closed T2402: Live ISO should warn when configuring that changes won't persist as Unknown Status.
This PR should address this simple usability enhancement
Apr 29 2020
Apr 29 2020
I found that it was due to set_vrf which uses the same master/nomaster commands that bridge uses. I'm adding checks and conditions to all interfaces to prevent that - raise ConfigError if both are set, and only set_vrf if vrf is set. The prior idea I had with re-adding the interface to the bridge at the end isn't necessary in this case, but for other interface types, where the interface itself is deleted and recreated, re-adding it is still necessary. The PR should be ready for initial review tomorrow.
c-po changed the status of T2399: op-mode "dhcp client leases" does not return leases from Open to In progress.
c-po updated the task description for T2398: op-mode "dhcp client leases interface" completion helper misses interfaces.
Resolved with T2393
c-po closed T2394: dhcpv6 client does not start, a subtask of T2393: dhclient: migrate from SysVinit to systemd, as Resolved.
jestabro added a parent task for T2397: HTTP API: export OpenAPI definition: T2395: HTTP API move to flask/flask-restx as microframework.
jestabro added a parent task for T2396: Add debian package for flask-restx: T2395: HTTP API move to flask/flask-restx as microframework.
This has a dependency on python3-flask-restx, which will need to be added using, for example, T2396.
jestabro changed the status of T2396: Add debian package for flask-restx from Open to Needs testing.
jestabro changed the status of T2395: HTTP API move to flask/flask-restx as microframework from Open to In progress.
Apr 28 2020
Apr 28 2020
This is solved in both the current LTS and rolling releases.
I had already reported before my refactor of the code that DHCPv6 does not work.
https://phabricator.vyos.net/T2268
Marek Isalski Today at 6:31 PM
c-po renamed T2394: dhcpv6 client does not start from DHCPv6 broken to dhcpv6 client does not start.
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).
c-po changed the status of T2394: dhcpv6 client does not start, a subtask of T2393: dhclient: migrate from SysVinit to systemd, from Open to In progress.
c-po changed the status of T2393: dhclient: migrate from SysVinit to systemd from Open to In progress.
c-po moved T2131: Improve syslog remote host CLI definition from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
c-po added a project to T2131: Improve syslog remote host CLI definition: VyOS 1.2 Crux (VyOS 1.2.6).
c-po moved T2385: salt-minion: improve completion helpers from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
Some statistics from ipv6 bgp summary