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.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Oct 17 2020
Must this command be executed from docker now?
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
Also very interested in this. Ready and willing to test.
@Cheeze_It thanks, works fine.
Oct 16 2020
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...
Quite interesting, support, in fact some information can not be captured from SNMP very well
How about this?
@D0peX That's correct? I updated pr
Thank you Viacheslav
@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.
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
It was fixed in the rolling T2573
https://phabricator.vyos.net/rVYOSONEXf812c5d1ce01efa8323bfb797c57f68f474665bb
Oct 15 2020
@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
awesome, thanks!
Also submitted PR for FRR 7.3 series https://github.com/FRRouting/frr/pull/7318
OK, thank you. I will test this. This should probably be made as default.
@runar The preliminary integration of tinc is basically completed, please see
Yes, both clients configured as DHCP clients.
Client 1 - eth0 - 50:00:00:06:00:00
Client 2 - eth0 - 50:00:00:07:00:00
This has come up multiple times before, see https://phabricator.vyos.net/T1698 for the solution.
I can confirm.
It happens after update procedure.
If I do a clean install of 1.2.6-s1 from iso, the rollback works fine.
If deploy from a qcow2 image, I see a similar error.
Oct 14 2020
I should add that building the package on arm64 hardware (pi3/4) works fine. Building in the docker container fails.
Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.
the issue is verified by soxrok2122 by using a stock ubuntu 20 host with the stock vyos/vyos-build:current-arm64 docker image
I'm reopening this issue as this seams to still be an issue. reported by user soxrok2212 on slack (#vyos-on-arm64)
It seems Client1 and Client2 only DHCP-clients.
Could you share also Client1 and Client2 configuration? Would be nice adding this lab setup to the docs
interfaces {
ethernet eth2 {
address 10.201.1.2/30
description WAN
hw-id 0c:6b:af:b0:4f:02
}
openvpn vtun11 {
description "CPE MGMT"
device-type tun
encryption {
cipher aes256
}
hash sha1
mode client
persistent-tunnel
protocol udp
remote-host 10.200.200.11
remote-port 1194
tls {
auth-file /config/auth/shared.key
ca-cert-file /config/auth/ca.crt
cert-file /config/auth/cpe1-1.crt
key-file /config/auth/cpe1-1.key
}
vrf CPE-MGMT
}
}
protocols {
static {
route 0.0.0.0/0 {
next-hop 10.201.1.1 {
}
}
}
}
vrf {
name CPE-MGMT {
description "CPE MGMT"
table 112
}
}Please share your OpenVPN config
Oct 13 2020
I think we could generate private/public keys using openssl instead of using the tinc utility to generate it... But i have not tested it
I am implementing tinc, but there is a problem I haven't figured out. Normally, in order for tinc to run, it must have a public key and a private key, and it happens that there will be a prompt for this generation command (ask where to save, etc), and it happens that the public key of the local node in the hosts directory is usually used together with some host configuration options. Is there a better way to implement it?
This bug seems to be worse than I thought.
Here's an example:
On reboot an openvpn client inteface will come up outside the vrf. Any routes that get pushed by the server will not get added to the client because it's wants to add the routes inside the vrf of the vtun interface - but the vtun isn't a member.
Heres a log snippet:
PR for CRUX https://github.com/vyos/vyos-1x/pull/568
You're right, if-up.d scripts only get run for the interfaces defined in /etc/network/interfaces.