@EwaldvanGeffen have you given the method I described a try on VyOS? I know it works on EdgeOS and pre- 6.4 releases of Vyatta and honestly haven't tested it on VyOS because it's not something I have a need for... so it very well could work differently/be broken on VyOS, but that would be surprising.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 16 2016
@mickvav I think when people ask "does it support DPDK" it's because they've read that using DPDK will allow forwarding and possible filtering and NATing of traffic at 10 Gbps+ rates. VyOS offering some DPDK stuff and saying "mission accomplished" would leave a bad taste in people's mouths the same way CloudRouter is claiming DPDK support when it's only for bridged traffic.
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
Short answer: not really.
@rps
i guess you can put this as answer and we can mark it as solved
"DPDK support" involved a lot of low-level contributions to a lot of different projects. Essentially you need to re-implement major parts of Linux on a case-by-case basis which is outside of the scope for VyOS right now.
You can use policy routing to match HTTP and HTTPS traffic and point it at a next-hop that is an external transparent proxy.
Sep 14 2016
Agree, we can do some slides for that purpose
i mean that people can add reporters and own companies as needed
Maybe really generic one should not reference specific companies, not sure.
@afics this ticket at least have description
i will merge all to one soon
Sep 12 2016
Thanks both.
As suggested, is there a way to check the device is live and then forward traffic or do a fallback to another device.
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 11 2016
You would have to forward traffic to your device. Preferably it handles all types of traffic. Otherwise you can forward dport 443 towards a specific IP.
Anything local should hardly be considered high priority, but the first one is remote. We definitely should include the fix in the 1.1.8
In T142#2451, @whiskeyalpharomeo wrote:Opinion: Yes, 1.1.8.
Opinion: Yes, 1.1.8.
Keep in mind that the specification has not yet been standardised. If you commit to implementing, make sure you only release it as a 'beta' or 'test release'.
Sep 10 2016
Interested in this too. We will be multi-homing soon and requesting an AS number from ARIN. I doubt we will be getting a 2-byte ASN.
Sep 9 2016
Sep 5 2016
Let me know if you require any additional information. I'm happy to help you with interop testing
@dmbaturin what do you think?
Sep 4 2016
@whiskeyalpharomeo maybe in your scope of interest
@dmbaturin is this good reason for 1.1.8 ?
@whiskeyalpharomeo you can do that already with the existing CLI.
Sep 3 2016
Welcome @whiskeyalpharomeo !
No code required(but of course welcomed if any)
After all this project not only about the code!
I like to think that is about giving access to advanced networking to everyone out there!
Since it not like 10 years ago, now technology(hardware) more accessible
Absent full vrf or vrf-lite behavior, there is a means of achieving a subset of this behavior using only iptables.
This is part of a broader AAA activity, such as TACACS+ and/or RADIUS integration for system level administration.
Sep 2 2016
It would be nice if this was available in the next release. Happy to receive any feedback if I need to improve the patch.
Sep 1 2016
I pushed the priority changes I had to do on my T132 branch.
Aug 25 2016
In T128#2209, @UnicronNL wrote:As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.
As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.
In T128#2194, @dmbaturin wrote:As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.
But what's worse, is that making it a commit fail will break the configs of those people who carelessly left a nonexistent interface in their DNS forwarding config, it will fail to load at boot time after upgrade.
As much as I hate generating configs that make no sense, leaving those people with potentially inaccessible systems after they upgrade (DNS loads before SSH AFAIR) is not an acceptable cost of somewhat tidier generated configs.
Aug 24 2016
As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.
Aug 23 2016
Aug 22 2016
@dmbaturin is about unsaved changes indication
@jeffbearer system loads last saved config
Can you push your recent changes to github?
Changing the priorities, I managed to make it work and it's loaded fine on reboot.
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.
Aug 21 2016
Aug 17 2016
Ok, so the main issue is that the route-map is only applied to routes installed _after_ it's been setup ... so you have to remove / readd all the static routes which obviously doesn't work when you reboot :(
This is my attempt :
Aug 16 2016
Aug 14 2016
Aug 13 2016
Aug 11 2016
vyos@r1-80001# run sh ver
Aug 10 2016
Aug 7 2016
@higebu seems correct.
It will be a good start
We need this? https://github.com/hiroyuki-sato/vyos-cfg-zabbix-agent
Aug 6 2016
Aug 4 2016
Jul 12 2016
Jul 10 2016
Jun 29 2016
Jun 27 2016
confirmed, works just fine of free esxi
Jun 21 2016
Jun 20 2016
Jun 1 2016
I think we can choose how to implement it. We can apply it as a default entry in one of the vyos chains or let the user-decide. The advantage with the latter is that both implementations can co-exist for a while. With the former solution I would remove the old implementation to not confuse the user.
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
@afics thanks, i merged it to this one
Related/duplicate: T33.
May 31 2016
I had to disable dkms there
https://github.com/mickvav/ipt-netflow-code
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.
These should be gone now.
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 26 2016
May 21 2016
Makes code simpler and easier to read. Makes kernel a bit smaller (leave out floppy module)
Makes booting a little bit faster.
Why should we remove support for obsolete features, which do not break anything?