- User Since
- Mar 18 2016, 8:43 PM (73 w, 5 d)
Tue, Aug 1
Trim is a good point, may be we can but I will emphasize these things here:
- DO NEVER install vyos or any other linux, intended for running 24x7 on cheap usb flash. I did it. Don't repeat my mistakes.
- /var/log in tmpfs is generally a very bad idea, as you will have no logs to examine system failures post-mortem.
- It's a good idea to monitor your ssd's health, and it's a good idea to include smartctl in VyOS default package list, but ssds have different vendor-specific SMART flags for their health indication, so it's up to user to specify the correct ones for his or her equipment.
- There is a damn dirty and simple solution to address trim issue without any modifications to running image:
tune2fs -o discard /dev/sdXY
but one has to make sure that device supports trim BEFORE doing this :)
Jun 28 2017
Actually merged year ago.
Merged in october.
Pull request - https://github.com/vyos/vyatta-quagga/pull/5
Anybody tested this .debs?
Seems to be OK.
May 29 2017
Do you have BIOS or UEFI boot mode in your motherboard setup selected?
To all - there was some reason why I've included grub-pc in my image, but I'not sure that it will help in this case.
May 24 2017
Mar 29 2017
@dsummers jool seems to be kernel-level and tayga seems to be userspace-level. The first one should be faster, and I expect package loss in the second one on high packet rate.
Well, I think I can some day do some things on adding this to CLI, if someone points me to known-working config for this feature. Am I right that this IPv4 - IPv6 NAT can not be implemented by iptables/ip6tables stuff? If netfilter already can do it - it's much better to do this things in kernel (as netflow, in my opinion).
Mar 10 2017
It seems to me that it should be linked with removal of in-kernel raid autodetection in recent kernels. We should employ user-space autodetect. Those people at gentoo have something on it here: https://wiki.gentoo.org/wiki/Custom_Initramfs#Software_RAID We should do something similar.
Mar 2 2017
Well, I take vyos-kernel, iptables, build them in packages directory, and put ipt-netflow from here: https://github.com/mickvav/ipt-netflow-code as git submodule in the same packages directory, build it there and get working .deb package containing module, crafted for current vyos kernel. I have no CLI integration for it though I use my own firewall-messing scripts. But in general, you jest have to do modprobe the module with right parameters (where to send collected data) and add somewhere in firewall the rule with "-j NETFLOW" to trigger, which packets to take into account.
Feb 23 2017
Feb 16 2017
Jan 9 2017
@Alexis , I've got my build environment up and running and created .deb's for this issue. Feel free to test.
For me the current defaults is fine for router-like device. But it's a good idea to have this option in user config, e.g.
Well, my vote is "No", because if for small configs it's OK to have just intent-expressed syntax, if you have huge one, e.g. several pages - if you omit prefix before, say, 55, you will have to guess from context, if it is a vlan or preffix list entry, or VRRP group or whatever.
Dec 19 2016
Well, I am not sure I can do this fast, as I am using different approach in flow collection - https://github.com/mickvav/ipt-netflow-code and have no idea on what do do with sflow. If you have someone else to assign this job to - do it.
Nov 19 2016
Well, just to make things clear - nDPI is actually a userspace software, that performs DPI analisis of data flow (from pcap-ed interface in real time or from .pcap file). It's interface to netfilter goes through ndpi-netfilter package, which actually opens kernel-userspace socket to forward some packets throug nDPI in userspace. If I am right in brief, we have two important steps:
- Make userspace software compile and work.
I thing, this should require almost no vyos-specific coding - just original package should be compiled on vyos vuild system into .deb
- Make netfilter-related package integrate into vyos iptables configuration.
Here we need to create some package like vyos-ndpi-netfilter, which fetches and compiles ndpi-netfilter, handles vyos configuration templates and creates correctly working .deb with all this stuff.
vyos-ndpi-netfilter.deb should depend on ndpi.deb
Nov 18 2016
How exactly can we help you?
Nov 10 2016
Sent pull request. This thing is really trivial. @Alexis, would be so kind to that resulting package is ok? My building appliance is somewhat disabled right now and I have only a tiny amount of time to do recreate it, so I will be able to test that everything is ok next week only, sorry.
Nov 3 2016
Reviewed the discussion there - I think we have to wait at least couple of weeks until it will be at least a little bit tested there...
Sep 30 2016
Well, than it seems to me that the reasonable starting idea is to start with the following configuration:
- make tree-like control pane topology on some stupid switch, for example.
- make "basic" configuration for every device, where only control pane interfaces are up and running
- make your jenkins or some other automated tool able to upload configuration into all these devices.
- make full-graph cabling between existing devices with some reasonable background logic
(e.g. "port 1 of any device always goes to hp,
port 2 of any device always goes to srx240
port 3 of any device always goes to ASA
port 4 always goes to Mikrotik)
Sep 29 2016
@syncer , do you have any drawing on network topology, that you are going to implement? If you do and it's not a secret, please share.
Sep 26 2016
@elico, have a look at https://github.com/mickvav/ipt-netflow-code - it's my vyos/debian repackage for ipt-netflow - another iptables target module which I've ported (and use in production) on my own vyos repackage. If you take it's "debian/" folder, put in your repo, than we can fork it and maintain as submodule.
Well, I think, I can try to make this thing work on VyOS, especially if the community is interested.
@elico, it seems to me to be that if you have this thing working with ubuntu you already have some debian folder which produces .deb's on dpkg-buildpackage correctly, or you mean that after just "make && make install" on running system, it installs and works?
Sep 19 2016
The last one seems to be really interesting - it's a kernel module, should be fast and so on.
It's an interesting idea, I've even tried this stuff couple of days ago, but it seems to be under heavy development, although seems to be a motion in right direction - snippets of code in documentation doesn't work, things which they demonstrate in videos are already moved in another modules and so on. So to make these things importable into vyos, they should first be made workable.
Thus, if someone needs this stuff to be integrated into vyos, he has to achive some simple goals:
Sep 16 2016
Ok, @Caesar305, than I'll ask another stupid question - why do you think that if someone will implement FULL linux bridging/routing/firewall stack with DPDK, he will get some significant profit from this decision? May be I miss something, but if all these things are already implemented in kernel, they are just already there, so DPDK seems to be extremely effective if you make it do specific things by throwing away all unneeded things, if you implement everything in userspace application instead of kernel you will benefit only on simplicity of debugging, am I right?
Well, I think this question can't be correctly answered until it is correctly stated. So I suggest waiting @Caesar305 for some clarifications. @rps 's answer implies that "support" means "ALL the routing stack works over dpdk" which seems to be really far now. But another option is the ability to run specific dpdk software on dedicated ports (e.g. traffic generator software for load testing of external equipment or high performance network sniffer) - this task seems to be achievable, if it's requested and donated for :)
Sep 15 2016
Sep 12 2016
Hm, I belive it should be relatively easy to make vyos "forget" about some interfaces, on which you plan to use your separate dpdk-enabled software and to just compile dpdk into main distribution. Is it enough for your needs, @Caesar305 or you need some specific application or you are talking about making all firewall stuff work over dpdk (which sounds like A VERY VERY HUGE task)?
And if you have any other known https destinations with different port numbers - redirect corresponding traffic explicitly.
Sep 4 2016
Aug 24 2016
I can suggest trying to do fork() on before line 139 and exit this forked child later - this should keep parent daemon's memory footprint constant.
Aug 22 2016
Can you push your recent changes to github?
You need "create" section in your templates/policy/route-map/node.tag/rule/node.tag/set/src/node.def to make things survive reboots, I think.
Jul 15 2016
May be you can run tcpdump -nvvv port bootps on your host to catch your client's requests to make sure that clients request hostnames without prefixes?
Jun 1 2016
Hm, as ipt-netflow is actually a firewall target, it looks like it's configuration logic should be slightly different from pmacct's one.
Looks like there should be some service level config tree, specifying module load parameters, like
May 31 2016
I had to disable dkms there
And if anyone is interested - I also have xtables-addons compilable against vyos kernel (it has several interesting firewall features - such as geoip and ipmark) - https://github.com/mickvav/xtables-addons
Well, I have ipt-netflow on self-rebuilt vyos kernel, no problems with performance. But I have no vyos-related scripts for interaction with this module.
May 30 2016
And some more, on the machine with working config:
Ok, now works, but I've got some strange notices on "show vrrp" :
May 21 2016
Why should we remove support for obsolete features, which do not break anything?
May 18 2016
I think it leads to incompatibilities with other device's default behavior - cisco, for example, exports/imports everything, if another behavior not stated explicitly, AFAIR.
May 13 2016
Would be great - with some make target for this it's possible to arrange nightly builds with these images.
May 12 2016
Hm, looks like it has 1gbe port working, am I right?
Do you have your .img creating procedure described or scripted somewhere?
You mean, I can order a board, take sd, put some image onto it and get working vyos on this board?
Well, you was discussing hardware here, and I know that mikrotiks used to be bootable into debian, so I've concluded that you are planing to port vyos on mikrotik's hardware. But clearfrog is also interesting idea.
Is there some place, where you track current work on mikrotik port? May I help it somehow?
Steel need someone with known working quagga MPLS confgiuration to test. @afics ?
May be we need some kind of lint-ing on scripts during package build process?
May 10 2016
Created pull request - https://github.com/vyos/vyatta-cfg-quagga/pull/9 to track changes, related to this ticket.
What is vRouter 5600?
Well, looks like pre-alpha is here:
N.B. It's completely untested. And I can't test one as I have no working MPLS config for clean quagga.
Well, it's somewhat more complicated than expected, but possible. I'll try do it today, but not 100% sure that I'll have enough time...
May 9 2016
I think, I can. Need two things - url to docs to check semantics and readyness to test.
May 5 2016
May 4 2016
Did you run into some trouble with snort? Are there any discussion on this topic somewhere?
Apr 28 2016
About systemd there is another point - if you look into systemd default setup (/lib/systemd/system/serial-getty@.service), you can find that it's default setup is rather clever - it takes advantage from agetty's ability to automatically select console baud rate. But current vyos configuration scheme insists on some fixed baud rate. So, we also have options:
- (simple) Remove speed option or ignore it. + allows usage of upstream systemd configuration
- Alter systemd configuration to use fixed speed from config.
- Modify speed to accept list of possible speeds, e.g.
Looks like this simple patch is ready for production. Backing idea - quagga has route-map to filter routes, going to be installed from ospf into kernel table, but we had no way to install it in vyos config. This patch creates 'router ospf route-map NAME' vyos configuration command, which maps into 'ip protocol ospf route-map NAME' quagga configuration mode command. The development was discussed under Q26.
Apr 27 2016
Well, I think that anyone, who really needs some specific feature set, nfs server, samba server, whatever, can make and maintain his own fork of vyos-build and it has (almost) no problem to build a speific iso himself.
Apr 26 2016
Looks like it's closed mostly.
Apr 19 2016
I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need mfs client and I'll double check, whether it's enabled in my branch tomorrow...
Apr 13 2016
Apr 12 2016
Apr 11 2016
Apr 5 2016
I am afraid that this is caused by incorrectly built .debs after this:
First one is a nightmare...
Apr 4 2016
Just a little bit of suggestion:
Omg... Please, no anime... :)
Apr 3 2016
Apr 1 2016
If this will be included, someone has to make deep testing of quagga vrf-related patchset. Looks like it's described here: http://permalink.gmane.org/gmane.network.quagga.devel/11770 but I'm not sure, whether it's included in upstream quagga or not.
Mar 31 2016
Mar 29 2016
Mar 28 2016
Mar 26 2016
Mar 20 2016
May be find a way to separate device tree and uboot from main build system?
.iso image is also not an option for most ARMs, I think.