@jack9603301 Do you know of a version of that FRR exporter that doesn't fork sub processes?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Oct 18 2020
Oct 18 2020
What information do you need access to from within op-mode?
I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?
It seems that we need to think about it now
You can pull the host configuration in operation mode using the following command:
generate tinc tincN host-conf <user@service:/path>
c-po closed T2985: Add glue code to create bridge interface on demand, a subtask of T2653: "set interfaces" Python handler code improvements - next iteration, as Resolved.
I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?
Note: my test found that when the server is in switch mode, the client cannot Ping to the peer in routing mode (more tests may be needed)
c-po changed the status of T2992: Automatically verify sha256 checksum on ISO download from Open to In progress.
To prevent forgetting, write the address of the exporter to task
c-po added a comment to T2969: OpenVPN: command_set on interface is not applied, if interface doesn't come up in commit.
The root cause of this problem is that OpenVPN when the deamon is started and in tries to connect to the server, yet did not create the vtun11 interface on the system. Thus all calls to the ifconfig python library will fail big time.
I updated pr. so far, tinc VPN cli will automatically generate the local node key file, such as the following code:
Isn't anyone implementing this feature right now?
Oct 17 2020
Oct 17 2020
c-po changed the status of T2985: Add glue code to create bridge interface on demand, a subtask of T2653: "set interfaces" Python handler code improvements - next iteration, from In progress to Needs testing.
c-po changed the status of T2985: Add glue code to create bridge interface on demand from In progress to Needs testing.
c-po closed T2991: Update WireGuard to 1.0.20200908, a subtask of T2990: Update Linux Kernel to v4.19.152, as Resolved.
tom.siewert added a comment to T2987: VxLAN not working properly after upgrading to latest October build and with a new installation.
My last comment was wrong, here are the outputs for bridge fdb show dev vxlan122:
Viacheslav added a comment to T2987: VxLAN not working properly after upgrading to latest October build and with a new installation.
I can't reproduce it with VyOS 1.3-rolling-202010170146 and other october releases
tom.siewert added a comment to T2987: VxLAN not working properly after upgrading to latest October build and with a new installation.
source-interface cannot be used as the routers are not in the same multicast group, neither can communicate via multicast
tom.siewert added a comment to T2987: VxLAN not working properly after upgrading to latest October build and with a new installation.
In T2987#77730, @Viacheslav wrote:@tom.siewert
What will be if you delete the source-address on "October" node?
Viacheslav added a comment to T2987: VxLAN not working properly after upgrading to latest October build and with a new installation.
@tom.siewert
What will be if you delete the source-address on "October" node?
GitHub <noreply@github.com> committed rVYOSONEX60109764cc18: Merge pull request #576 from sever-sever/T752 (authored by c-po).
UnicronNL changed the status of T2834: Config rollback function is broken due lack access to the config.boot from Confirmed to Needs testing.
Oct 17 2020, 1:27 PM · Restricted Project
We should avoid having a constellation of exporters, but favour having a single one. I feel like starting and stopping those would be pretty icky.
Oct 17 2020, 12:57 PM · Restricted Project
Viacheslav added a comment to T752: Add an option to disable IPv4 forwarding on specific interface only.
Must this command be executed from docker now?
c-po edited projects for T2792: Failed to run `sudo make qemu` with vyos-build container due to the change of packer, added: VyOS 1.3 Equuleus; removed vyos-build.
This will break builds in out Docker environment where we ship a packer version. See T2792 and https://github.com/vyos/vyos-build/commit/e2dd9db8a2539b6d13c98d89e18872336cf8f974
jack9603301 updated the task description for T2986: Unable to build qemu image due to misconfigured Packer.
c-po changed Version from - to 1.3-rolling-202010081758 on T2985: Add glue code to create bridge interface on demand.
c-po changed the status of T2985: Add glue code to create bridge interface on demand from Open to In progress.
c-po changed the status of T2985: Add glue code to create bridge interface on demand, a subtask of T2653: "set interfaces" Python handler code improvements - next iteration, from Open to In progress.
Also very interested in this. Ready and willing to test.
GitHub <noreply@github.com> committed rVYOSONEXfcf90cd860ba: Merge pull request #573 from sever-sever/T2938 (authored by c-po).
@Cheeze_It thanks, works fine.
GitHub <noreply@github.com> committed rVYOSONEXaa8445674565: Merge pull request #575 from DmitriyEshenko/ipoe-fix-issue01 (authored by c-po).
Unknown Object (User) changed the status of T2984: (igb, ixgbe) HW queues applied only for the first 2 interfaces from In progress to Needs testing.
Unknown Object (User) changed the status of T2984: (igb, ixgbe) HW queues applied only for the first 2 interfaces from Open to In progress.
Unknown Object (User) created T2984: (igb, ixgbe) HW queues applied only for the first 2 interfaces .
Oct 16 2020
Oct 16 2020
Unknown Object (User) changed the status of T2978: IPoE service does not work on shared mode from Confirmed to Needs testing.
Cheeze_It changed the status of T2981: MPLS LDP neighbor session clear capability from Open to Needs testing.
GitHub <noreply@github.com> committed rVYOSONEX397d6618d000: Merge pull request #574 from Cheeze-It/current (authored by c-po).
That would be a workaround only - see IPv6 syntax above. Using the refactored interface handling (T2653) makes this a low-hanging fruit.
I'll be giving those a test once T2981 is done. I'll report back here with results :)
PR is added here...
Unknown Object (User) created T2983: Add support to DHCP server include an extended config.
Quite interesting, support, in fact some information can not be captured from SNMP very well
owensresearch awarded T2257: BGP does not work with VRF a Heartbreak token.
Viacheslav added a comment to T752: Add an option to disable IPv4 forwarding on specific interface only.
How about this?
@D0peX That's correct? I updated pr
Thank you Viacheslav
Viacheslav changed the status of T2907: OpenVPN: Option to disable encryption from Open to Needs testing.
@c-po @dmbaturin It can be safely cherry-picked to the "crux".
I tested this on 1.2.6-s1, it works.
@trae32566 Will be added in the next rolling release.
Check, please.
GitHub <noreply@github.com> committed rVYOSONEX2b60994ce283: Merge pull request #572 from sever-sever/T2965 (authored by c-po).
The possible reason, that it can't get the lease file, because that directory not present in the LiveCD
lease_file = "/config/dhcpd.leases"
That sounds great to me! I actually like that more.
Proposed cli
One of them
GitHub <noreply@github.com> committed rVYOSONEXa5a77c47168b: Merge pull request #571 from sever-sever/T915_holdtime_explicit (authored by c-po).
It was fixed in the rolling T2573
https://phabricator.vyos.net/rVYOSONEXf812c5d1ce01efa8323bfb797c57f68f474665bb
Oct 15 2020
Oct 15 2020
c-po renamed T2980: FRR bfdd crash due to invalid length from FRR bfdd crash due to invlid length to FRR bfdd crash due to invalid length.
@Robot82
It will be by default in the new BGP implementation.
https://github.com/vyos/vyos-1x/blob/current/data/templates/frr/bgp.frr.tmpl#L5
Proposed CLI
reset mpls ldp neighbor x.x.x.x
Cheeze_It changed Is it a breaking change? from none to compatible on T2981: MPLS LDP neighbor session clear capability.