What version have you been using?

in edgeos each loadbalanced interface has it's ip table set directly at the interface-health section of the loadbalancing config. ex:

I tried doing some basic routing with ofp and it seemed to work but the shipped dpdk version does not compile for my kernel (4.10), so I can't test that.

I have tried this and I could not seem to get any data what-so-ever to go over the open fastpath interface, so I don't think it is a viable solution.

Has anyone tried to do something with the howtoforge: https://www.howtoforge.com/tutorial/opendataplane-with-open-fast-path-on-ubuntu/

for now it is set to fixed speed.
please close if agreed on this.
https://github.com/vyos/vyatta-cfg-system/commit/d582bbaf3ad95566de9b90d1572d60e39936a1a7

In T100#4801, @silverbp wrote:

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

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.

@mickvav I recall that you told in some task about IPT usage
can you share how you currently integrate IPT?
@jclendenan and me(and not only) will be interested to see this in 1.2

In T100#4598, @mtz4718 wrote:

Is this en-devour dead? I really want to help but I wonder I'd be much use. If there's any dumb testing or boring tasks let me know.

Is this en-devour dead? I really want to help but I wonder I'd be much use. If there's any dumb testing or boring tasks let me know.

Great, thanks!

Resolved? nightly builds appear to be now located:

with ubuntu 14.04 I still get the error above.
mount: wrong fs type, bad option, bad superblock on overlayfs,

@syncer yes please split it off. Sorry for taking over the ticket.

Hey @amos.shapira
Can you move this under separate ticket
or i can do that for you if you wish

I got the VyOS 1.2 AMI built by Packer but it doesn't get the ssh key pulled from the metadata and stored in the configuration. With lots of manual testing I got to a stage where "/bin/cli-shell-api setupSession" fails with a core dump.

I've updated https://github.com/amosshapira/thermal to let you specify VPC ID and subnet ID required to run Packer in AWS.

@jeff What exactly did you do when you "tried it with vpp"? Can you tell us a bit about what hardware you tested on and what your numbers were?

I was just going to try substitute the 1.1.7 url with the 1.2.0 url. I'm stepping through these steps manually until I can get through it. Then I can do a packer script.

How do you get the code for 1.2 into your image? I use the ISO of 1.1.7 and started work for 1.2.0 and made some progress but stopped when I hit too many problems and realised that 1.2 isn't stable (that was a few months ago).

I've just verified that the AMI gets built and runs correctly after making sure that the VPC ID and Subnet ID are set correctly in packer.json. I'll update my code when I get home. The issue to track this is https://github.com/amosshapira/thermal/issues/5

ami-72343365 is Ubuntu official public trusty AMI in us-east-1, name "ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-20161205" owner id "099720109477"

Hm, I can't get this command to work..

@syncer thanks for the heads up!

Hello!
I will advise to work on 1.2 and not spend time on 1.1.x
For GCE just as for Azure required fresher software so 1.1.x is problematic

@amos.shapira what linux / version is this: ami-72343365 I can't find that ami.

I've used packer before, I'll go through those scripts and see if I can replicate something similar on GCE, thanks for the link!

@silverbp have you considered using Packer? I got Packer building AMI's of VyOS on AWS here: https://github.com/amosshapira/thermal/tree/master/vyos-image, perhaps you can use it as a basis for a GCE image. Let me know if you need help with understanding the code there (it uses a trick to work around Packer's lack of support for creating the final image from a "side-mounted" volume by switching volumes and rebooting).

Also as far as variations from AWS

I'm trying to take the 1.1.7 version and get it working in GCE which I haven't had any luck so far.
I've performed the following steps:

Following a discussion with @dmbaturin in #vyos, I'm to work on this puppy.

I think we can just reference it directly.

In that case, BatString can just be added as a dependency, I guess, and we can call upon that function to sort as needed? Or would you still like a specific function for node sorting?

I've just done a quick test of the BatString.numeric_compare, looks perfect.

Depending on your feelings toward batteries, we could either use BatString's numeric_compare or just crib the implementation of that function (with all due credit given, of course).

I like this kind of problem.

For now they are working again.

Protobuf schema has been written.

@jpbostic My idea for interacting with vyconf from outside the interactive shell is a bit different. The issue with 'vyshell -c "set interfaces ethernet eth0 disable' is that it needs to setup a session first, and store the session ID between commands, so either it will be limited to 'vyshell -c "configure; set interfaces ethernet eth0 address 192.0.2.1/24; set interfaces ethernet eth0 mtu 1400"' (i.e. long command strings in single call), or it will be dependent on specific environment setup, and from VyOS 1.x we already know how problematic it will be.

@dmbaturin @mickvav yes, definitely a very good point, and I'm guessing that same new VyOS shell would then be callable from the changed-to Unix shell (e.g. cli -c "show configuration commands | match blah") ... nice.

I'm a "NO" as a network engineer with a bunch of different brands already XORP style, or as close to JunOS as you can get it the best. Yet another (Similar) config style would be way too much frustration for most of my peers to even consider.

@jpbostic I think @mickvav has a point here, making it configurable is relatively cheap (it's just a field in /etc/passwd after all, or a call to chsh). People who don't want it to be the deault like myself and service accounts for ansible etc. can just change the default.

Once @tmartinson setups a physical server for us (I'd like to say thanks to him, by the way!), it will become a permanent place for the jenkins VM and build hosts where we can give access all maintainers without worrying about mixing Sentrium corporate stuff with it.

@dmbaturin, you can probably assign this one to me, if you feel comfortable doing so. I think I'm nearly done. I'd just like to put together some decent test cases before making a PR.

FWIW, I definitely prefer JunOS-like (issue command to enter VyOS shell) behavior and agree with the comments about remote configuration, such as with Ansible. This makes mass configuration, change-controls, and backups much more like other *nix based installs. It also makes munging the VyOS command output available out-of-the-box on the VyOS install, i.e. IMO it would be much easier to call VyOS shell sniplets from scripts in bash, tcsh, python, perl, etc, than to deal with getting out of the more captive shell back to a "real" shell for a custom script, cron job, etc.

@UnicronNL Thanks.

I heard there will come a new server available to run jenkins on, i have to wait until i have more information.

And https://ci.vyos.net certificate is invalid.

https://ci.vyos.net/computer/jessie64devel.vyos.net/

Nightly builds are not working again? It seems jessie64devel.vyos.net is down now.

I think if you keep in mind the Principle of Least Astonishment, the answer becomes obvious: when you login to VyOS, do you expect a VyOS shell or a Unix shell? VyOS! Conversely, when you login to Unix, do you expect a Unix shell or a VyOS shell? Unix!

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.

The suggestion from @rps (XORP style) seems to be the best way from my point of view:
https://phabricator.vyos.net/V3#51

With respect to the concerns I mentioned above, I've voted no.

@dmbaturin, Im with you on the aesthetics, and the readability. In the firewall ruleset example I still feel that the first is easier read than the second. Are we talking hundreds of lines to parse the former vs the latter? It seems like the later, across a whole config would at 10-20 lines if not more depending on the complexity. I for one am interested in seeing as much of the config on one screen, vs needlessly needing to scroll. As for your Q on pfSense, I've had to edit the xml configuration file by hand based on how pfSense sorts VLANs based on their add date vs numerical value.

@tmartinson Well, you should change your vote then (votes are not final here, for the better I guess).

I keep coming back to a sense that dramatic syntax changes are very damaging and disruptive to users. My fear is that we'll be spending years explaining to people that they're looking at old documentation or examples and that they don't have their curly braces in the right place. Or that we'll alienate a segment of our user base that is averse to change.

In the example above, I vote that the first example where name Foo and rule 10 are on the same line. It is much easier to read, and shortens up the output on the display. Sometimes with long configurations, it is easier when you can see more information on the same screen without scrolling.

@systo Just to make sure you are looking at it the right way, in the large it's actually less verbose than old syntax. The vif may not be the best example but firewall would make it apparent:

As an end user, I just keep coming back to the verbosity of the syntax, and the divergence from all the other established command syntax in this space. VyOS doesn't have the following to do it differently, as it adds another barrier to adoption. Its a subtle change, but it has a long reach, especially when luring former vyatta or EdgeOS converts that want to roll-their-own, vs buy MIPS hardware. While I understand it may save coding time in the end, I'm trying to avoid the verbosity that is pfsense, and awall/shorewall. I bet if you asked a room of non-vyos engineers, they would prefer the first syntax with a much higher percentage, but alas I digress.

Any change that imparts simplicity for the coding ahead is worthwhile. Time saved in the parser's reduced complexity can be spent in other ways.

@rps An serious issue with "interfaces { eth0" is that when there is no parent subtree of all ethernet interfaces specifically, we don't know which script to call when something in "eth0" changes. We'd have to have one big script that handles the whole "interfaces" subtree, which is very problematic when it comes to adding new interface types. If eth* interfaces are children of the "ethernet" node and tun* interfaces are children of the "tunnel" node, it's easy to attach ethernet script to the "ethernet" node and "tunnel" script to the "tunnel" node, if we want to add "openvpn" later, we won't have to modify that large script to accomodate it

I haven't voted yet because I haven't decided ... It's a big change.

@rps No, that's not the biggest challenge. Semicolon at the end of leaf nodes makes them unambiguous enough and easy to tell from tag nodes (this is especially bad with valueless nodes by the way, think "disable", colon wouldn't help there, but semicolon at the end does the job). The biggest challenge is that with "ethernet eth0" the parser must be fully stateful and capable of tracking which parent nodes it's already seen. "eth0", "eth1" etc. are really children of the same node called "ethernet", but in the config they appear separately. Consider this unusual but logically valid config:

@rps this distinction also seems to be easy in the original proposed solution by @dmbaturin because key value pairs are not followed by '{' and the rest is.

From a parsing perspective the only challenge tag nodes present is that you can't easily distinguish between "key value" and "key tag" without context. "key" and "key tag value" are fine. Using a ":" you get "key: value" vs "key tag" which removes the ambiguity.

@dmbaturin I understand that the discussion is "unit 0" vs "unit { 0", what i meant was that i could be an option to keep following the JunOS style as much as possible to maybe enable more interoperability.

Well plain JSON would also be an option then :-)

@Merijn I'm still not sure why JunOS has that "unit" thing. To me it looks redundant, redundant ©. Though what we are discussing is "unit 0" vs "unit { 0" grammatic distinction, rather than specific syntax of ethernet interfaces.

The XORP configuration syntax (which Vyatta initially built upon) solves the parsing issue with the simple introduction of a ":" as a delimiter between keys and values.

In the blog post #7 i liked the address [ 192.168.2.1/24 10.10.10.1/30 ]; part. But since i work most of the time with mixed JunOS and Vyos environments a mostly the same syntax would be very nice :-)
However JunOS would be:

I was thinking that the variable would actually be "vlan-id 99". That was written simply to make it easier to read. But if it will be the top of a node, then we end up with vif, vlan-id. Which is redundant, redundant. In that case I would drop the "vlan-id" portion all together. It is only there for esthetics.