Any comments here? Is this a known issue/limitation? I can look into the internals and do some debugging if this should be working in the current state..
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Feb 16 2021
Feb 16 2021
pasik added a comment to T3259: many dnat rules makes the vyos http api crash, even showConfig op timeouts.
SrividyaA added a comment to T3307: address prefix destination NAT fails to render nftables rules / commit.
The translation is working properly now but it is not showing in the command output:
jack9603301 updated the task description for T3315: Supports dhcpv6 agent execution from pppoe0 interface.
jack9603301 renamed T3316: Use Kea DHCP(v6) instead of ISC DHCP(v6) from Use Kea DHCP instead of ISC DHCP to Use Kea DHCP(v6) instead of ISC DHCP(v6).
jack9603301 changed the subtype of T3316: Use Kea DHCP(v6) instead of ISC DHCP(v6) from "Bug" to "Feature Request".
jack9603301 updated the task description for T3315: Supports dhcpv6 agent execution from pppoe0 interface.
jack9603301 updated the task description for T3315: Supports dhcpv6 agent execution from pppoe0 interface.
Maybe we should consider using a better proxy server to complete the dhcpv6 agent
jack9603301 added a project to T3315: Supports dhcpv6 agent execution from pppoe0 interface: VyOS 1.3 Equuleus.
jack9603301 renamed T3315: Supports dhcpv6 agent execution from pppoe0 interface from Supports dhcpv6 agent execution from `pppoe0` interface to Supports dhcpv6 agent execution from pppoe0 interface.
jack9603301 renamed T3315: Supports dhcpv6 agent execution from pppoe0 interface from Supports DCPV6 agent execution from PPPOE0 interface to Supports dhcpv6 agent execution from `pppoe0` interface.
jack9603301 updated the task description for T3315: Supports dhcpv6 agent execution from pppoe0 interface.
jack9603301 added a parent task for T3315: Supports dhcpv6 agent execution from pppoe0 interface: T421: Add Pv6 prefix delegation support.
jack9603301 changed the subtype of T3315: Supports dhcpv6 agent execution from pppoe0 interface from "Feature Request" to "Bug".
Feb 15 2021
Feb 15 2021
Somehow this was lost in translation in my git repo....
Nackported to 1.3 equuleus
GitHub <noreply@github.com> committed rVYOSONEX96656b1a7bb7: Merge pull request #732 from c-po/t3310-bfd (authored by jestabro).
Unknown Object (User) claimed T3312: SolarFlare NICs support.
Unknown Object (User) changed the status of T3312: SolarFlare NICs support from Open to In progress.
Yes, I very much like this, and is what I am imaging with 3., above.
With this new information I see little to none reason to keep the key_mangling() workaround. If we manage to transform all nodes into "proper" syntax we can one day drop it.
GitHub <noreply@github.com> committed rVYOSONEX44596d08c374: GitHub: update help strings in PR template (authored by c-po).
PR https://github.com/vyos/vyatta-cfg-firewall/pull/20 is still pending to clean up the following log entry:
@c-po this is an excellent idea, and a useful reference for the bracket notation; this will need a bit of design of how best to slice the problem:
- keeping key_mangling but excluding on tag nodes
- removing key_mangling completely
- removing on a case by case basis with the existing argument to get_config_dict()
XML for policy access|access6|prefix|prefix6|community list
Unknown Object (User) created T3312: SolarFlare NICs support.
trae32566 updated the task description for T3311: BGP Error: Remote AS must be set for neighbor or peer-group.
trae32566 updated the task description for T3311: BGP Error: Remote AS must be set for neighbor or peer-group.
Feb 14 2021
Feb 14 2021
In the new xml/py rewrite, do they disapear if you rerun the bgp configurator script? Eg. Can we execute frr-reload twice as a workaround?
This actually feels like an FRR bug as this still occurs with the new XML/Python rewrite
c-po closed T2848: bgp-add-path configuration options, a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as Resolved.
c-po moved T2844: BGP conf_mode errors disable-send-community from Open to Finished on the VyOS 1.4 Sagitta board.
c-po moved T2848: bgp-add-path configuration options from Open to Finished on the VyOS 1.4 Sagitta board.
c-po reopened T2848: bgp-add-path configuration options, a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as In progress.
c-po closed T2848: bgp-add-path configuration options, a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as Invalid.
This is fixed in 1.4 as proper input validation happens.
c-po added a project to T1941: Config mismatch with FRR on misconfiguration of V6 peer: VyOS 1.4 Sagitta.
c-po added a project to T2315: Ability to have right address-family for BGP peers.: VyOS 1.4 Sagitta.
c-po edited projects for T2848: bgp-add-path configuration options, added: VyOS 1.4 Sagitta; removed VyOS 1.3 Equuleus.
Currently this requires BFD support to be added to frr-reload
Implemented/fixed for VyOS 1.4
c-po moved T2845: BGP conf_mode unable to delete configuration with peer-group from Open to Finished on the VyOS 1.4 Sagitta board.
Issue no longer persists in VyOS 1.4. Tested using: 1.4-rolling-20210214
c-po added a project to T2845: BGP conf_mode unable to delete configuration with peer-group: VyOS 1.4 Sagitta.
c-po closed T3308: BGP: add gracefull shutdown support, a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as Resolved.
c-po closed T1875: Add the ability to use network address as BGP neighbor (bgp listen range), a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as Resolved.
c-po closed T1875: Add the ability to use network address as BGP neighbor (bgp listen range) as Resolved.
Please re-test with latest current rolling release. Reverted back for FRR 7.5 and that bug should have been fixed in there.
Feb 13 2021
Feb 13 2021
zsdc changed the status of T3309: dhclient started by Cloud-init stays alive forever from Open to Needs testing.