@kingrvbee this is not entirely correct. The problem comes from package vyos-1x which now holds the lldp configuration nodes. @dmbaturin is aware of this and wanted to fix it. Please be patient.

This patch something error

Any updates on this? I can't seem to win. On 1.1.7 snmp is broken due to my intel 10g nics and now on beta snmp works but netflow doesnt work :(

Yes, @Tania and I are working on the rewrite.

Please also see T393

@mickvav Interesting Idea, I should give it a try ...

@Asteroza this program forwards UDP packets (Layer 3) on specific ports. Unfortunately WoL is Layer 2 based.

Just wondering, if it's possible to address this problem by just addint some firewall rule like
iptables -t mangle -j TEE ...
Did anyone did some digging into xtables-addons package to elaborate, whether it's possible to use firewall for this kind of things? I think, it should be much faster to do this things in kernel, than in userspace.

This could be possibly used for targeted Wake-on-LAN packet relaying as well...

Create a new repo (dev.packages.vyos.net/debian) and moved hvinfo to there.

https://github.com/vyos/vyos-1x/commit/ecdbe7b6fb64ae7d27d9147aa2c4a55b3a491735
https://github.com/vyos/vyos-1x/commit/5404d4108b510765150c2ac54098cd26ec18a683

I've merged the quagga pull request. Do you have implementation of the CLI for it, or shall I add it?

Created "current" and "helium" branches.

I can verify that it now also boots on OVH.net VPS.

@babak that would be awesome as I do not have any IPv6 BGP connectivity. I created a temporary SSH key for this, could you please create a user cpo:

I might be able to stand up a Vyos Instance with v6 BGP for you to test. Let me know when you are ready for it and I'll get it spun up.

In T386#7593, @c-po wrote:

I guess that you are referring to the installation of VyOS, as a proper installed system will automatically boot up. At least last nights build does.

@UnicronNL @syncer Using the latest beta ISO I can happily report everything seems to install + boot just fine!

@UnicronNL applied changes in both 1.1.x and 1.2.x

I guess that you are referring to the installation of VyOS, as a proper installed system will automatically boot up. At least last nights build does.

Maybe this is the reason why we also can't boot a VyOS instance on VPSs rentet from OVH.net

News about this ?

Well I think porting this to vyos-1x package would be a good lesson to learn the new system. Let me have a look...

@UnicronNL please add this when you have time

I think that best way to implement it, will be use a "extends" in snmpd for BGP4-V2-MIB-JUNIPER and use a vtysh as backed.

@c-po The post I made yesterday (http://blog.vyos.net/vyos-development-digest-number-10), the vyos-1x package is pretty much that, the future single package for all config scripts and data. I would be reluctant to put things that are not VyOS-specific into it though. With small things such as the mDNS repeater things get shaky of course. Something like PMACCT is a clear case, merging it into another package would be insanity. Those relays are small enough to make one wonder if they really need their own packages.

@dmbaturin You have some good points. Using "service" to start/stop a daemon should be the weapon of choice now. This could/should be changed to have a consitent system, but this inital commit is just a 1:1 EdgeOS copy.

@JulesT I'm afraid Perl code is going to be around for quite a while, as many things need to be fixed before any rewrite of them can take place.
It's the code for new features that concerns me, not as much in the language as in the old approach that is not conductive to either automated testing or future implementation of transactional commit.

As I say... I don't have the standing or the background to really question the approach. If you guys aren't really interested in commits that are perl-based, though, then I'm afraid I don't really have a lot to offer.

@JulesT 99% of new EdgeOS code is proprietary. I see no reason to stick with it for the tiny open source bits they may release once in a while. EdgeOS could use their departure from Vyatta Core as a chance to rethink those decisions, but apparently due to time pressure they didn't... Now they are stuck with backporting UnionFS forever and never getting e.g. fully transactional commits or

In T379#7550, @dmbaturin wrote:

And now that I've actually looked into it... ;)

There are some bad practices that I think should be changed before we call it complete as well.

First, now that the Python configuration library and the templates convertor work, can we stop adding new Perl code? Those scripts are short at least.
There are some very good reasons to do that as well. For example, now that we are using systemd, why should we have start-stop-daemon? We should never had it right in Perl code to begin with.
Second, I'm strongly against mixing VyOS configuration code with applications it configures. Let's move that out of this, and if we are going to move the configuration code to vyos-1x package, it will come naturally. We can merge the bcast-relay and mDNS repeater into one package perhaps.

The features are appreciated, but let's add them in a fashion that will make VyOS easier to maintain, not harder.

just a thought - much of this is porting EdgeOS features, right? Those guys are still using perl, so any features they implement that VyOS wants is going to be perl by it's nature, surely?

And now that I've actually looked into it... ;)

I think before we call it finished, we should move those repos under vyos organization and give @c-po access to them (frankly, I also propose to add him to maintainers).

We should, but somehow I don't have write access to this task. We should find a way to change the default permissions so that all maintainers can do that.

Yes, let me regain access to this task

This is fixed, too. Can we close it?

This is definately fixed. Can we close this one?

Now as @higebu done T373 we can build custom config for waagent that will do provision via cloud-init mechanism

Moved the repo to vyos org. https://github.com/vyos/vyos-integration-test

Moved the repo to vyos org. https://github.com/vyos/vyos-cloudinit

Kim, can you merge this into current
Thanks!

Daniil, can you kindly review and merge
Thanks

Hi Kim, can you merge this
Thanks!

Resolving this and moving to finished

Tried on → 999.201706052137

@syncer can we close this task? see @higebu fix..

falso fixed in 1.1.8

Cool.

I checked on 2017-09-04 and I am not able to put in IPv6 address into the OpenVPN interfaces.

Agreed. I just re-tried it as of 2017-09-05 and it now saves the OpenVPN configuration file in the /config/config.boot file.

Found out that it already is implemented.

As workaround I used Beta/development build and get it working in my lab with dnsmasq(2.72) from

@syncer: Thinking about it I have a different proposal:

There is another problem. BGP4-MIB doen't cover IPv6 peers, the clue is implement a new MIB like https://iphostmonitor.com/mib/BGP4-V2-MIB-JUNIPER.html like Juniper did

Is it possible to do an strace of the snmp process?

I have access to to these routers, is VyOS like below will be ok?
vyos@vyos:~$ show version
Version: VyOS 1.1.7
Description: VyOS 1.1.7 (helium)

I think as not everybody has access to an IPv6 BGP router, a ro SNMP community for testing would be good. Even better would be a virtual instance to develop a fix for this problem.

I'm also really intereseted to make it working, is there any chance to help?

no problem:

config will be good to see